|
 |
Darren New <dne### [at] san rrcom> wrote:
> Warp wrote:
> > I still can't comprehend what's so bad in the compiler doing the check
> > that you don't access the private members.
> If it's actually enforced (as in an error rather than a warning), it makes
> lots of things harder than they need to be, because the running code winds
> up with less information than the compiler had. You're throwing away half
> the work the compiler did once you generate the code, so you wind up with
> lots of boilerplate to enter into code things the compiler already knows.
That's the whole idea in modular thinking: You don't know what's inside
the module, and you *don't care*. You don't need to care.
As soon as you start worrying what's inside the module, you are already
breaking module boundaries and abstraction.
> If it's half-enforced, as in the compiler complains and won't compile the
> code, but there's ways to get around it anyway (on purpose or by mistake),
> then it's IMO the worst of all possible worlds. You'll spend hours or days
> trying to debug code that's already right because the client is convinced
> the other code they've written is bugfree and it's easier to blame you than
> to find the wild pointer in their own code. The whole idea of class
> invariants goes out the window.
No you'll explain to me how a naming convention of public variables helps
this problem.
> Incidentally, I see little wrong with breaking encapsulation if you maintain
> the invariants. It makes it harder to upgrade in the future without changing
> the client, but that's the price you pay for it. If you can automate the
> access to where it doesn't hurt to change the client, it seems like a
> win-win to me.
IMO if anyone feels the need to break your interface and access private
members directly, then your class design sucks and should be redesigned.
If your class design is good, nobody will need to access anything
directly.
--
- Warp
Post a reply to this message
|
|
