https://github.com/rwobben/bankaccount
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.
