OO is not that great[2]: repeatedly passing the same object

[Shawn]

Hi,

I have several classes TellerA, TellerB, TellerC and BankAccount.
TellerA and TellerB and TellerC are working like in a chain. TellerA
does something to the bankaccount object and pass it to TellerB. TellerB
does something to the same bankaccount object and pass it to TellerC.
There is only one object of BankAccount class, which everybody works on
it. So TellerA, TellerB and TellerC all have a member reference to a
bankaccount and passing the object bankaccount is very deliberate and
redudant.

public class TellerA
{
BankAccount myAccount = new BankAccount("1 million");

..// did something to myAccount

TellerB b = new TellerB(myAccount, parameter A, parameter B); //I feel
the parameter myAccount is so redundant

}

public class TellerB
{
private BankAccount ac = null;

//constructor
public TellerB(BankAccount ac, parameter a, parameter b)
{
this.ac = ac;
...// do something to the bank account -- same account object
...//then pass it to TellerC who keeps working on it
}
}

As you see, both TellerA and TellerB are working with the same account
object. But the object has to be passed deliberately. In procedural
language, you can leave the object in the global place and let everybody
access it, modify it, like a chain in a factory.

 

[Michael D. Carney]

.... example deleted...

In procedural
language, you can leave the object in the global place and let everybody
access it, modify it, like a chain in a factory.

You said it.... EVERYBODY can access it.... you have absolutely no
guarantee that another piece of code that you know nothing about
accesses and modifies your global object.

Arguments == good
Global data == bad.

- Mike.

 

[Lasse Reichstein Nielsen]

As you see, both TellerA and TellerB are working with the same account
object. But the object has to be passed deliberately. In procedural
language, you can leave the object in the global place and let everybody
access it, modify it, like a chain in a factory.

You can leave the account in a global variable in Java too (it's just
called a public static field), and it has all the shortcommings of
global variables too.

Your design seems very far from an actual domain (does a TellerA
really *create* a TellerB?).
The roles are not clear, the object life times are untraditional,
there is no apparent reason why the tellar should be bound to
a single account, and there is little messaging going on between the
object instances, and all the computation happens in the constructors.
All in all, I'd say it's a case of bad object oriented analysis
and/or design.

/L

 

[Javier]

Shawn ha escrito:

As you see, both TellerA and TellerB are working with the same account
object. But the object has to be passed deliberately. In procedural
language, you can leave the object in the global place and let everybody
access it, modify it, like a chain in a factory.

TellerA, TellerB and TellerC are all Teller classes with things in
common (like BankAccount), so you should define a class named Teller,
with all the common coded embeded into it, and then inherit from it
TellerA, TellerB, and TellerC. There is not redundancy in this way, and
it is the way it should be if you pretend to correctly design your
program.
In this way, you can even add TellerD and other Tellers somwhere in the
future with very little effort.

Look at this:

http://java.sun.com/docs/books/tutorial/java/IandI/subclasses.html

 

[Stefan Ram]

http://java.sun.com/docs/books/tutorial/java/IandI/subclasses.html

¯¯¯¯¯
Looks as if Sun has hired Rastafaries recently.

»"I and I" means that God is in all men.«

http://en.wikipedia.org/wiki/Iandi

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shawn schreef:

Hi,

I have several classes TellerA, TellerB, TellerC and BankAccount.
TellerA and TellerB and TellerC are working like in a chain. TellerA
does something to the bankaccount object and pass it to TellerB. TellerB
does something to the same bankaccount object and pass it to TellerC.
There is only one object of BankAccount class, which everybody works on
it. So TellerA, TellerB and TellerC all have a member reference to a
bankaccount and passing the object bankaccount is very deliberate and
redudant.

As you see, both TellerA and TellerB are working with the same account
object. But the object has to be passed deliberately. In procedural
language, you can leave the object in the global place and let everybody
access it, modify it, like a chain in a factory.

Indeed, but you do not need to create a global space, rather, you will
have a method, which knows about the bank account and the teller
machines. So it will create the bank account and pass it to the
tellers, something like so:

public someMethod() {
BankAccount theAccount = new BankAccount(1000000);
Teller tellA = new TellerA(theAccount);
Teller tellB = new TellerB(theAccount);
// have tellA and tellB do something with theAccount
}

So now someMethod is responsible for ensuring encapsulation, i.e. it
takes care of it that the bank account is not handed to anybody that has
no business with it. As you see, I made both Tellers inherit from an
abstract Teller class, as Javier already suggested.

Often, someMethod will be static and be called main...

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFF4sge+7xMGD3itQRAqjwAJ4l/hZ1B1h03hPMmHWtYwDJ3NmGdQCfdQPm
hHomUIHwF2dgQ8iYVe0biDo=
=rjtr
-----END PGP SIGNATURE-----