File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Reusability Tutorial: The way I do it. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Reusability Tutorial: The way I do it. " Watch "Reusability Tutorial: The way I do it. " New topic

Reusability Tutorial: The way I do it.

Gerald Davis
Ranch Hand

Joined: May 15, 2002
Posts: 872
I want to give an simple tutorial on code reuseability that is often overlooked especially if you are using object oriented methodology.

Fig 1. Is a simple class containing two list( means arrays). The code works out what elements are are in the first list but not in the second. It does it's job ok, but it does not contain any reusable code.
The problem with fig 1 is its instance methods are mixed in with the method. This makes the whole method impossible to reuse.


Fig. 2 Is an improvement. This class has one instance method who's sole responsibility is to manage instance variables and to pass them to other functionality. And it has another, implemented as a function that implements the functionality.


So, one of the reason why reuseability can be hard to achievers is because classes often have instance variables that tie methods functionality to this one class. I have to admit this sometime is necessary, most of the time it ties down more functionality then it has to.

The role of the instance method should be only to pass instance veritable date to other parts of application like it does in fig.2 'i = Difference(listA,listB)'
[ January 08, 2005: Message edited by: Gerald Davis ]
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Yes, Fig. 2 *is* an improvement. In Java, I often do such things. Actually we have quite a lot of only-static-utility-method classes at work - StringUtilitites, CollectionUtilities, ArrayUtilities, you name it.

But that's because of a short coming of Java, namely that it doesn't allow me to implement those methods where they really belong - in the example the array class. In languages wich do (Smalltalk, as far as I know, Nice probably too, Ruby?), I'd prefer to do that, so that clients can write

i = listA.subtract(listB);


Interestingly, the Java Collection interface already has similar methods: removeAll and retainAll.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Gerald Davis
Ranch Hand

Joined: May 15, 2002
Posts: 872
Mmmm, Indeed the 'Difference(listA,listB)' could be refactored into an instance method of the List Class by subclassing it or it could be left as it is. But the most important thing is to realise this kind of re-usability in first place.

In my application, I manage to factor out quite a lot of function like 'Difference(listA,listB)' some of them might find a home in a relevant class implemented as a class or instance method. However, it would be foolish to move them prematurely. Only with excellent experience of using Object Oriented Design and the problem domain can this be done correctly.

This is one of the reasons why I am holding back from doing so. Only when the design of my application is mature enough , will I know what function belongs in with class and whether to implement them as an instance or class method. If done prematurely It would be hard to find and get them back again without breaking other code specially if I chose to implement them as instance methods.
I agree. Here's the link:
subject: Reusability Tutorial: The way I do it.
It's not a secret anymore!