Java and good OO practices question

[Richard Molyneux]

Hey,

I have a question which has been nagging me for quite some time, regarding
OO programming (in particular Java). I've written code which passes the
instance of a class (called A) as a parameter in the creation of an instance
of (another) class (called B). The instance of class A maintains a long term
state of the program, while the instances of B merely provide updates to the
state of A.

Basically, I'm wondering if the use of such practices is wise in regard to
OO (despite being technically allowed within Java)?

Thanks,
Richard.

 

[Yakov]

This is fine as long as the class B does not changes the properties of
the class A directly. For example, the class A may have a private
variable int status, but the class B should update this variable using
a public method setStatus().

 

[iamfractal]

Hey,

I have a question which has been nagging me for quite some time, regarding
OO programming (in particular Java). I've written code which passes the
instance of a class (called A) as a parameter in the creation of an instance
of (another) class (called B). The instance of class A maintains a long term
state of the program, while the instances of B merely provide updates to the
state of A.

Basically, I'm wondering if the use of such practices is wise in regard to
OO (despite being technically allowed within Java)?

Thanks,
Richard.

Hi, Richard!

Note that the use of classes and objects doesn't imply OO. OO concerns
variance encapsulation; it allows the programmer to, in a sense,
separate those parts of his program that may change frequently from
those that may not, and thus quickly update his program as those
changes hit.

The scenario you describe above provides very little problem for OO to
solve. If, however, you think that the implementation of A might
change a lot, and that you may at some time wish to pass C to B, then
it might be better to pass A's interface to B, rather than the object
A itself.

Your solution does look wonderfully simple, though, so stick with it.

..ed

www.EdmundKirwan.com - Home of The Fractal Class Composition

 

[Richard Molyneux]

Hello,

Thank you for your replies (Ed and Yakov). The 'problem' that my program
attempts to model is a simple DBMS. Actually the class A (actually called
PhysicalHandler) provides access to physical data (stored on HDD), 'caching'
the data within the internal private state. The class B (called QueryEngine)
accesses the data as appropriate to any database query via the methods of
PhysicalHandler. Throughout the runtime of the program many queries maybe
run (requiring new instrance of the QueryEngine each time) but only one
instance (longterm) of PhysicalHandler ever exists (hopefully minising HDD
accesses - via its caching of data).

I'm quite happy with the abstract concepts that both classes model as part
of the intended solution, perhaps my only gripe is that my representation of
OO as UML diagrams (according to my understanding) can not depict the
relationship between PhysicalHandler and QueryEngine. That's really been my
main concern.

Your solution does look wonderfully simple, though, so stick with it.

Cheers )


Thanks,
Richard.

 

[Mark Wright]

One joyful day (Thu, 09 Sep 2004 14:36:46 GMT to be precise), "Richard

I have a question which has been nagging me for quite some time, regarding
OO programming (in particular Java). I've written code which passes the
instance of a class (called A) as a parameter in the creation of an instance
of (another) class (called B). The instance of class A maintains a long term
state of the program, while the instances of B merely provide updates to the
state of A.

Basically, I'm wondering if the use of such practices is wise in regard to
OO (despite being technically allowed within Java)?

I see no problem with it, especially since it seems to me that this is a
minor variation on two well-established OO patterns:

1. The Visitor pattern, with B being the visitor.

2. The Mediator pattern, with B being the mediator controlling the state
of A.

Providing A is manipulated via accessors, this is hunkey-dorey as far as
OO is concerned.

Mark Wright
- (e-mail address removed)

================Today's Thought====================
"In places where books are burned, one day,
people will be burned" - Heinrich Heine, Germany -
100 years later, Hitler proved him right
===================================================