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.
