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.
