simple class

[Stefan Ram]

If we started with a
typedef double MoneyType;
at the beginning of the header, and getBalance() defined to return a
MoneyType, then if the client used the MoneyType also, then no change in
client code might be needed.

In the client, one can have case A (old solution):

double b = account.getBalance();

or case B (your new suggestion):

MoneyType b = account.getBalance();

. In case A, the client's author can then write

::std:cout << 0.05 * b;

. In case B, the client needs more support from the
implementation to be able to do this. The client's author is
not supposed to know that »MoneyType« is just »double«.
Therefore, he cannot write:

::std:cout << 0.05 * b;

, because he does not know whether MoneyType supports those
operations and what their semantics is. But usually the
client might need to calculated something with the balance
or to serialize it to a human-readable stream. So he needs
more support from the library than just the statement
»MoneyType is an opaque type that you do not need to know
anything about.«

Possibly, MoneyType might grow to become a new type
implemented by a class. Well, then this class better not
have a »toDouble()« method, because otherwise the clients
might use it and then the same problem will arise anew.

 

[Osmium]

:

All that's needed here is an example where there's a relationship
between the members. Stroustrup picked (in TC++PL) a Date class with
year, month and day-of-month. Then you eventually want to prevent
things like the 31th of February year 0, and there's suddenly a real
reason to have more than just a boring struct.

On Page 236! Wow. What a buildup to the first introductory class. I have
always used the book as a reference, it's got post-its out the kazoo. But I
never actually read it as a student would do so I never saw that example.
K&R use dates a lot too - I have actually read it, many years ago. I think
the moral is "Dates are good."

 

[Seungbeom Kim]

One of the nice things about accessors, not just publicising the data,
is that you are hiding the implementation.

Imagine that I've decided to compress the data. Everyone whose name is
Wong will be described by having an ID of 1, everybody whose name is
Smith by 2, and so on.

If you've publicised the data you can't do this. If you've publicised
a method returning a const reference to the string you can. And
there's a different method for changing the name, which is going to do
clever stuff to make sure that Miss Wong's bank accounts are
associated with the new Mrs Smith. And a thousand other things...

What you're talking about is on a different level of abstraction;
if you want such a dictionary-based storage of strings, you can
employ a DictString class which holds an ID or an index into a
static dictionary member, but the Person type should still be:

struct Person
{
DictString name;
std::string address; // or any other sophicasted class
// instead of std::string
};

and there's no need to clutter the Person type with get_name()
and get_address() functions.

 

[Dombo]

Op 11-May-14 20:18, Stefan Ram schreef:

But the effect is the same: all clients that want to benefit
from the new implementation have to be changed. I used to
believe that the promise of encapsulation was that the
implementation can be changed without the clients having to
be changed.

Encapsulation won't help in case the interface itself is broken, like in
this example. And since the interface is broken, so are the client using
it, hence changing the client is unavoidable. Only if the interface
isn't broken you can change the implementation without having the change
the clients.

 

[Stefan Ram]

Op 11-May-14 20:18, Stefan Ram schreef:
Encapsulation won't help in case the interface itself is broken, like in
this example. And since the interface is broken, so are the client using
it, hence changing the client is unavoidable. Only if the interface
isn't broken you can change the implementation without having the change
the clients.

Can we derive any general lessons for interface design from
that, rules that might have helped to impede the offending
interface right from the start?