Re: encapsulation / concealmeant / data hiding / implementation hiding / whatever you call it
From: Daniel T. (postmaster_at_eathlink.net)
Date: 07/23/04
- Next message: Phlip: "Re: Design questions"
- Previous message: Thomas Gagne: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
- In reply to: Corno: "encapsulation / concealmeant / data hiding / implementation hiding / whatever you call it"
- Next in thread: Robert C. Martin: "Re: encapsulation / concealmeant / data hiding / implementation hiding / whatever you call it"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 23 Jul 2004 14:39:44 GMT
"Corno" <Corno@dds%FAKE%.nl> wrote:
> Which of the classes Y1 and Y2 in the following C++ pseudo code has your
> prereference, and why?
Y1. The reasons are listed at the end of this post.
> I know that it is considered good programming
> practice to hide the implementation/data of a class (as in Y1) but I really
> don't see what I gain by implementing a getXXX method so I'm wondering why
> not just to use Y2. Are there pitfalls?
If there is nothing to be gained by implementing the getXX method, then
don't do it, but keep the data private unless you have a compelling
reason to make it public.
> (Ofcourse I know that if I don't have to, I should not have public access to
> the reference in the first place but this is sometimes desirable).
The fact that 'referenceToX' is a reference means that some other object
has direct access to the X being referred to. Yx has little or no
control over the X in question. Why is that X in this particular Y? What
is the invariant you are trying to maintain?
> ---------------------------------------
> class X
> {
> ...
> };
>
> class Y1
> {
> ...
> private:
> X& referenceToX;
> public:
> X& getReferenceToX() const;
> };
>
> class Y2
> {
> ...
> public:
> X& referenceToX;
> };
> ---------------------------------------
Because class Y1 will not compile (returning a non-const reference from
a const function is illegal. Let's use an example that is more correct:
class Y1 {
int x;
public:
int getX() const;
};
class Y2 {
public:
int x;
};
First, x is in the class for some reason, ie it has some inherent
importance to Yx, and there is probably some invariant regarding x that
must be maintained in order for it to be valid. For example, let's
assume that x must always be >= 0... Y1 can maintain that invariant, Y2
can't.
Second, maybe 'x' can be calculated on the fly. For example, maybe some
time later in the development a bottleneck is found because x is
modified every time some other part of Yx changes, a good solution would
be to implement a lazy modification scheme. This can be done with Y1,
but not with Y2.
Third, 'x' may not need to exist in RAM. For example, after some
development, it turns out that 'x' can easily be calculated on the fly
when needed, rather than maintained in RAM. With Y1, the variable store
can be replaced with a calculation, while with Y2 it cannot.
- Next message: Phlip: "Re: Design questions"
- Previous message: Thomas Gagne: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
- In reply to: Corno: "encapsulation / concealmeant / data hiding / implementation hiding / whatever you call it"
- Next in thread: Robert C. Martin: "Re: encapsulation / concealmeant / data hiding / implementation hiding / whatever you call it"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
