points to
a repository with C# code, so I cannot comment on
the Smalltalk.
There is,
however, a striking thing about the C# code, qua
C#, that is
worth
mentioning.
It is not
encapsulated.
Let's
start with the most obvious one.
A bank
account has a password, and you are
supposed
to provide the right password in order
to get
information from it.
Your
interface *reveals* the password, so
malicious
code can do
var
pass = theBankAccount.password;
and then
provide the password back. What's
needed is
something like
var
balance = theBankAccount.queryBalance(pass);
where
passwords go *in* to theBankAccount but never ever
ever come
*out*.
Another
thing is that a BankAccount belongs to a specific
Customer.
There's a good way and a bad way to manage this.
The bad
way is for the caller to create a new account that
belongs to
nobody, and then *tell* the Customer "here is a
new
account". With this interface, you could tell any
number of
Customers that they own the account. That's
possible
in the real world, but in the challenge, it isn't.
The good
way is to *ask* the Customer "please create a new
account
and tell me what it is", and have no way to force
a Customer
to accept an account willy nilly. That way a
Customer
can be certain that the accounts it is holding
belong to
it and it alone.
Or it
could be were it not for a major encapsulation
issue.
The idea
of encapsulation is that
EVERY
CHANGE TO AN OBJECT'S STATE MUST BE MADE BY THAT
OBJECT
including
the start of owned containers.
In Java,
for example, you might have
public
class Customer {
private final ArrayList<Account> accounts =
new ArrayList<Account>();
...
public List<Account> getAccounts() {
return Collections.unmodifiableList(accounts);
}
...
public Account newAccount(...details...) {
final Account a = new Account(...details...');
accounts.add(a);
return a;
}
...
}
If you are
going to provide access to a collection,
(1) make
the collection immutable in the first place, or
(2) return
an immutable view of it, or
(3) best
of all, DON'T provide access to the collection
but
provide queries that extract just the information
you
want to
make available.
This has
nothing to do with Java or Smalltalk or C# as
such;
encapsulation
is object-oriented-programming 102.
For what
it's worth, I used to be a University lecturer,
and
it was
MUCH harder for students to grasp encapsulation
than
to grasp
recursion. I have no idea why. Just pretend that
you
are a nice
little object surrounded by malevolent pranksters
who can
force you to do anything in your interface, and
make
sure they
cannot harm you.
Oh, when I
asked about the source of the challenge, what I
was
getting at
was "is this your paraphrase of the challenge, in
which case
please tell us to find the original, or is this
the actual
unmodified original text, in which case --ing
h---,
you have
my profound sympathy."
This looks
like a garbled version of an exercise that I did
a little
over 10 years ago, which I found in a Java-based
book
whose
details I unfortunately forgot to record. Right
down to
the names
of the classes! That is why I am pretty sure that
there is a
description of the problem somewhere that makes
sense.
