Interface question 2

[zooxmusic]

Hi all, I have an interface question. I've been reading everywhere that you should use interfaces instead of abstract classes if at all possible. Now if I have a two functions that always does the same thing in five or six classes. One being something like getConnection() and the other something like buildXml(). Each of these functions do the exact same thing for all of the involved classes. Some are the same and some are not. Should I create an interface and then have to duplicate the code five or six times in each corresponding class? Or am I missing something basic on how to do this?

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[Jawk]

No, code duplicating is the last thing you should do. Factorize code as often as possible. So use an abstract class.

Which language are you coding in? Some languages don't make it possible for a class to inherit more than one abstract class. There is no limitation to interface inheritance.

 

[zooxmusic]

I am using java. But should I put both functions which are unrealated, buildXml() and getConnection in the same base class? I can't see any other way for my classes that have both to extend them. For example

Class1, Class2 and Class5 each have both functions
Class3 only has buildXml()
and Class6 only has getConnection()

what would be the model?

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[EdwardJS024]

NO! Do not rely on an inheritance hierarchy in any senerio that dooes not follow a strict "is-a" relationship...

ABSTRACTION:
In other words, If you can logically say :
"a car is an auomobile" then all automobiles can "Start();". So it might make sense to place the Start() behavior in an automobile abstraction and derive new Car classes from Automible. Hence, Car's can share this Start behavior or overide if necessary.

In your case, if your classes fall under a single logical abstraction that represents class1, class2, class3....etc then go ahead an implement an abstract base class. Otherwise, setting an abstract base class for unrelated classes is like saying a Person is a Dog, simply becase they can both Walk();


INTERFACES:
Interfaces are also a way to provide conceptual abstraction by allowing each class to implement code for accomplishing a similar behavior in a different way. [polymorphism]. It's similar to abstract classes in a few ways:

1. There are only contracts set in an Interface. No implementation

2. Interfaces do not tie objects to a single class hierarchy.

3. Interfaces do not promote code reuse.

4. Classes only implement an Interface when it's needed where as an abstraction hierarchy forces all classes to provide some implementation, even if it does nothing.


UTILITY CLASSES:
If you have generally unrelated classes that may share a similar behavior in only a few, I would lean against seperating out the commonality into a utility class, that can then be shared by other classes.

Any feedback?

 

[EdwardJS024]

Typo correction in the paragraph titled "INTERFACES"..

--> "It's similar to abstract classes in a few ways:"

Should be:

"It's different from abstract classes in a few ways:

 

[zooxmusic]

Thanks, you know I never looked at that and all I day I am trying to say keep logical things together. Certain classes "use" a database connection and othere "use" an xmlBuilder but they "are not" a database connection. Holy S&*#. What is wrong with me, that is so obvious. Thanks. I am new to this so I am sorry. I am about to CRC Card out my entire model so that may help. Thanx. If anyone knows of any good sites that can baby through a couple of examples of life cycle design at least up to getting ready to code, I would appreciate it.

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[zooxmusic]

I just had a thought. I just also was going to ask if I make a getConnection utility class should I put a protected variable in my abstract class so all the lower classes can use the utility but I realized I should pass my info into this utility class and the outside classes should not ever even touch a Connection object, or Statement or ResultSet. I think I understand that.

Now I also have the buildXml object which just builds xml and then another communicator class which posts it to another consumer. BUT if I make a utility class I actually have two ways that I will pass xml back and forth. One being through an HttpUrlConnection object and one just as a response on the OutputStream so I am lost on whether or not to put this utility class in the base class or a handler class or... just cant' see it yet. Sorry for my ignorance.

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[EdwardJS024]

Now I also have the buildXml object which just builds xml and then another communicator class which posts it to another consumer. BUT if I make a utility class I actually have two ways that I will pass xml back and forth. One being through an HttpUrlConnection object and one just as a response on the OutputStream so I am lost on whether or not to put this utility class in the base class or a handler class or... just cant' see it yet. Sorry for my ignorance.

You're not ignorant, it's just part of learning and refactoring. I end up refactoring my designs several times until I am comftable with a design that is extensible. Thats the key here, Extensibility.

Never short change your designs, think of ways to write code to be modular and capable of adapting as requirements change. Let me ask you a question, what if a new technology or java API came along that allowed you to post your xml to a server via an FTPConnection? VoIPConnection? HTTPConnection? URLConnection? PacketConnection?

See?, Your design should be capable of interchanging behaviors (connection strategies) as needed without haveing to mess with any existing logic.

This is called the Strategy Design pattern. It's a basic principal that says "take the behavior that varies and encapsulate it into it's own class". So you end up with several classes, each one representing just a single behavior, also know as an algorithm. Then, the client that needs a behavior can use anyone of the algorithms at runtime and be able to interchange them as needed,.

Think of how Microsof Word saves documents. Word is capable of saving a document in different formats. Each format is a special encoding algorithm. A user selects the saving behavior to use when he saves. Example algorithms:

RTFAlgorithm, DOCAlgorithm, HtmlAlgorithm, WPSAlgorithm

Each one of those classes represent a single encoding algorithm. And since each algorithm operates differently, there is no inheritance for code reuse here. Instead, I bet each class implements a common Interface for polymorphic behavior. They each may implement an interface: "ISavable"

the Isavable interface says that all algorithms that want to be interchangable must implement the method called "Save()" and provide custom algorithm for saving a stream of chars.

Now, when a user selects to save as .doc, Microsoft Word simply saves the current document by calling .save() on the algorithm. Word does not care what algorithm it is, nor does it care how saving is done. It just knows to call .Save();

That approach allows vendors to write their own custom saving algorithms and plug them into word. Imagine Adobe writing a PDFAlgorithm to allows saving a document to .pdf format. The algorithm implements .Save() and accepts a stream of characters and does it's own thing for encoding to pdf.

Let's take your Communicator object for example. I am not sure what is the responsiblity of Communicator, so I will assume in this example that it is responsible for posting xml to a destination via some algorithm. So far you listed 2 possible ways to post:

1. HttpUrlConnection
2. OutPutStream

Make those 2 their own classes and let them implement a common interface like "ITransferable" or something liek that. Let them provide implementation for a common method like "Post()". That way, each algorithm can accept a stream of xml as a param and post it using its own uniqu algorithm.

You can then say to your friends that you employed a Strategy Pattern for posting xml. Now you can let your client objects reuse any one of these algorithms as needed. Example:

Utility.SetPostingAlgorithm(new HttpUrlConnection());
Utility.Post("xml file string here");


The Post method in Utility will delegate (fancy for redirect) the Posting responsibility to HttpUrlConnection class.

I am not sure if Utility should be the host for Posting xml. Maybe that part looks strage and needs further thought. Maybe your class1,class2,class3 etc needs this postable behavior?