R
Roedy Green
Let us say you wanted to end up with a class structure something like
this:
class Core : contains data fields and intelligent accessors and
virtual fields.
Stage1 extends Core
Stage2 extends Core
Stage3 extends Core
Stage1 Stage2 and Stage3 have nothing whatsoever to do with each
other.
Then you create a Core object and somehow invoke:
Stage1.doEverithing()
Stage2.doEverything();
Stage3.doEverything();
on your Core object.
Let us presume you have everything in one giant Core class now where
all the code is this.based.
In my particular case, long ago I have a similar problem where
refactored it like this:
Stage1 extends Core
Stage2 extends Stage1
Stage3 extends Stage2
This turned out to confusing, creating too many "adhesions" between
Stage1 Stage2 and Stage3. The compiler did not help enforce placement
of Stage3 code purely in class Stage3.
It looks as if I will need to pass a delegate Core object to Stage1,
Stage2 and Stage3. It then must do one of two things that I am
reluctant to do
1. have each Stage extend Core, and then in a copy-constructor copy
the values of all the individual fields to this.xxx (a maintenance
and debugging nightmare.) Java has no facility for creating code for a
copy constructor for the Dog Field to converta Dog to a Dalmatian,
even though in assembler it is just a single instruction.
2. use a delegate object. This means changing every reference to every
field in the entire code body.
Can you think of lower-labour approach?
--
Roedy Green Canadian Mind Products
http://mindprod.com
"Species evolve exactly as if they were adapting as best they could to a changing world, and not at all as if they were moving toward a set goal."
~ George Gaylord Simpson
this:
class Core : contains data fields and intelligent accessors and
virtual fields.
Stage1 extends Core
Stage2 extends Core
Stage3 extends Core
Stage1 Stage2 and Stage3 have nothing whatsoever to do with each
other.
Then you create a Core object and somehow invoke:
Stage1.doEverithing()
Stage2.doEverything();
Stage3.doEverything();
on your Core object.
Let us presume you have everything in one giant Core class now where
all the code is this.based.
In my particular case, long ago I have a similar problem where
refactored it like this:
Stage1 extends Core
Stage2 extends Stage1
Stage3 extends Stage2
This turned out to confusing, creating too many "adhesions" between
Stage1 Stage2 and Stage3. The compiler did not help enforce placement
of Stage3 code purely in class Stage3.
It looks as if I will need to pass a delegate Core object to Stage1,
Stage2 and Stage3. It then must do one of two things that I am
reluctant to do
1. have each Stage extend Core, and then in a copy-constructor copy
the values of all the individual fields to this.xxx (a maintenance
and debugging nightmare.) Java has no facility for creating code for a
copy constructor for the Dog Field to converta Dog to a Dalmatian,
even though in assembler it is just a single instruction.
2. use a delegate object. This means changing every reference to every
field in the entire code body.
Can you think of lower-labour approach?
--
Roedy Green Canadian Mind Products
http://mindprod.com
"Species evolve exactly as if they were adapting as best they could to a changing world, and not at all as if they were moving toward a set goal."
~ George Gaylord Simpson