CJ <spamb...@mindspring.com> wrote:
Thanks in advance for your responses.
I am relatively new to OOP and though I have muscled my way through
Java, I am still trying to correctly understand the concepts of OO and
how then are modeled into Java.
I am a thirty year procedural language developer, c and assembler, to
this (recent) technology called Object Oriented whatever is somewhat
alien to my experiences. I think I grasp the basic concepts of OO,
that being describing concrete "objects" as a series of refinements to
abstract "conceptual objects." (Please don't flame me if that
statement is incorrect, I am seeking to increase my understanding.)
The following Java 1.5 code I believe demonstrates the statement
above. I needed Vector container that would notify() all active
Objects it contains. My thinking was to simply extend Vector adding
the functionality I wanted.
However, a co-worker is rather irate at me for "doing such a silly
thing," preferring instead to Instantiate a Vector object with
SignaledVector, and implement the entire Vector contract method by
method. That just sounds contrary to principles OO.
Your thoughts?
I agree, it would be very silly to use a has-as relationship and duplicate
the entire vector contract. If you want it to act like a vector, you did
the right thing.
However, I'm not sure if you decision to create an object which acts like a
vector is the right choice. You would have to tell us more about your
application and what you were putting in that vector to allow us to suggest
a different way to fracture your code to solve the problem.
Extending classes you don't have control over can be a risky business.
What happens if the Java guys decide to add a "SignalAll" to the Vector
class? (highly unlikely, but this is just an example). If they not only
added that method in some future release but the Vector would call it's own
signalAll method at times, your version of the method could end up breaking
their code if it didn't happen to do just the right thing.
Using has-a relationships instead of is-a relationships in general is far
safer.
You could have for example made a simple object which held the Vector and
implemented the signal and signalAll methods on the vector as you did, as
well as a getter to get the vector. To use the Vector methods, you just
get the vector from the object and use the Vector methods on the vector
instead of trying to make your object be a vector.
Though in OO terms, you did the right thing based on your description, as a
practical mater of code maintenance, it might have been better to approach
it differently.
On a larger scale, surely there is more you have to do with the objects in
the vector than send these signals to them right? What puts the objects in
the Vector and what takes them out? What type of objects are in the Vector?
In general, when I find I need to do something to a Vector (like perform a
method on every object in the Vector) it would be highly unlikely that I
would end up approaching it like you did and extend the Vector class.
I'm sitting at my car dealer writing this message so let me make up an
example based on that. Lets say I needed to represent the inventory of the
dealer as a collection of cars. And one of the functions I needed to
perform on the collection was to add up the wholesale price of all the
calls to get a total value of the inventory. I could do this like you did
by extending Vector to create a CarVector class and include in that class a
totalWholesaleCost method which would call the wholeSaleCost method of each
car in the Vector and return the sum. But I would not tend to do that.
Instead, I would create a CarDealer Object which had an inventory variable
which was a Vector<Car>. And I would but the totalWholesaleCost method in
the CarDealer object. It's likely the CarDealer object would have other
instance variables as well such as the name of the dealer. There would be
no need to create a special CarVector class to make any of this work just
because there were things I needed to do to the objects in the Vector. So
this is an example of the CarDealer class using the has-a relationship with
the Vector instead of using the is-a relationship.
It's hard to tell whether the has-a relationship might work for you without
understanding more about your application.
--
Curt Welch http://CurtWelch.Com/
c...@kcwc.com http://NewsReader.Com/
Thank you all for your time spend responding. While the discussion
move. I am more interested in the technique, as opposed to the
concept of OO. Specifically, Mr Welch wrote:
Extending classes you don't have control over can be a risky business.
What happens if the Java guys decide to add a "SignalAll" to the Vector
class? (highly unlikely, but this is just an example). If they not only
added that method in some future release but the Vector would call it's own
signalAll method at times, your version of the method could end up breaking
their code if it didn't happen to do just the right thing.
core object of the language. Any object can be "enhanced" -- for lack
with an object extending it. Does not his statement belie the