Reusability Tutorial: The way I do it.

[Gerald Davis]

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.1

 
class Foo:
  listA=[1,2,3,4,5,6,7,8,9]
  listB=[2,3,4,5,6,7,8]
 
   'create a list of objects that is in ListA that is not in ListB'
   'in this example the method return list [1,9]'
   def Difference():
      dif=[] 
      for anobject in listA:
          if anobject not in listB:
             dif.append(anobject)
      return dif 
 
   def Foo():
     i = Difference()
     ....
     ...
 

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.

Fig.2

class Foo:
    listA=[1,2,3,4,5,6,7,8,9]
    listB=[2,3,4,5,6,7,8]
 
    def Foo():
       i = Difference(listA,listB)
       ....
       ...
 
 
'procedure can be resused again'
def Difference(listA,listB):
     dif=[] 
     for anobject in listA:
         if anobject not in listB:
            dif.append(anobject)
     return dif 

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]

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);

instead.

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

[Gerald Davis]

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.