3 ms·
I think the argument that a developer can access and write-to private methods bypassing setters so therefore encapsulation is broken is pretty weak IMO. On one
by encoderer 16y ago
I think the argument that a developer can access and write-to private methods bypassing setters so therefore encapsulation is broken is pretty weak IMO.
On one hand you have an option where you have to trust the developer will chain the appropriate method calls to build an unrelated data structure that gets passed-in to your target method.
On the other, you have the possibility that a developer will knowingly and willing subvert the encapsulation by writing directly to private variables while ignoring the business logic that's being enforced in the setters.
Do you mind me asking... what exactly are you arguing there? In the first example it's easier to do it wrong than it is to do it right. In the second example it's easier to do it right than it is to do it wrong -- in fact you have to specifically write to protected members to break it.
How are we still discussing this?
- rbranson 16y agoI believe your conclusion is rooted in a lack of experience in writing C code. You seem to think that developers are going to go out of their way to allocate and initialize the struct manually. In almost every codebase I've worked in, struct types always have an allocation/initializer function, so I look for that first, and generally find a set of other functions that are used to work on that struct type, organized into a single .c file usually named something similar to that struct type. It is a convention, not syntactic sugar. In C++ or C#, you have syntactic sugar that makes it more difficult to violate the rule, but does not actually enforce anything.
- encoderer 16y agoRbranson: Well if you personally want to use a procedural language for OO development, that would explain a lot about this conversation. Anyway, good talk. Appreciate the back and forth. I wouldn't hire somebody with a mindset like yours but I certainly like chatting on HN.