Conversation
Notices
-
Embed this notice
>Do you mean data abstraction doesn't work?
data abstraction is a false goal
>Do you mean that component architectures don't work?
>Do you mean that modeling the domain doesn't work?
neither inherent nor exclusive to OOP
>Do you mean that a human-readable architectural structure doesn't work?
also not inherent to OOP, the way it's done usually is the opposite of human-readable
>Do you mean that focusing on doing things rather than state doesn't work?
no, it doesn't
>Do you mean that hiding the details of an operation to make it easier to understand doesn't work?
no, it doesn't
>Do you mean that single responsibility and delegation don't work?
no, it doesn't
>Do you mean that limiting the impact of a change to the smallest possible blast radius doesn't work?
>Do you mean that being able to make changes without impacting the clients of the thing you just changed doesn't work?
I think you're just bad at computers
-
Embed this notice
he has a ukrainian last name, but spiritually he is indian
-
Embed this notice
@Inginsub
A few bad ideas, and a few ideas that are not OO specific xD
Surprised he didn't claim that adding comments or design documents was exclusive to OO xD
-
Embed this notice
@hazlin why do you need comments or documentation anyway? the architecture is human readable, the code is your documentation
-
Embed this notice
@Inginsub
For the same reason we render images as color and light, instead of displaying a table of hex values.
They both have the same information. They both can be understood.
And both have their uses.
A comment or documentation for a trivial bit of code, is clutter, and a waste.
The denser the code, the greater the value of a comment. And, the larger the code base, the more value there is in documentation. It can be very tedious to discover the implicit structure without one.