[Koha-devel] koha and objecting to libraries [RT]

[MJ Ray]

This is almost a random thought, so I add the RT tag to the subject 
line. If you've not seen random thoughts before, I stole the idea from 
apache cocoon and you should brace yourself. The subject line is a 
tease. This is nothing to do with physical libraries, who I wouldn't 
dare object to (honest) and all to do with turning libraries into 
objects. Here, I'm going to explore the use of perl modules by koha a 
little, or at least the ".pm" files which contain them.

I think that the .pm files in koha are used for two purposes at the 
moment. Some of them are simple libraries, while others are object 
classes.

Libraries are quite simple to evaluate, in a way. You can tell whether 
libraries are in a sensible structure by using some measures. Two that 
I know are called "coupling" and "cohesion". Cohesion is a description 
of the contents of a library. Some common forms are "functional 
cohesion," "temporal cohesion" and "accidental cohesion". Functional 
cohesion is what we want: all the things in the library relate to the 
same task. Temporal cohesion sometimes happens: the things in the 
library do different tasks, but normally happen around the same time. 
Sadly, accidental cohesion is most common: it's a rag bag of bits and 
pieces that have almost nothing to do with each other.

Coupling is a description of how two libraries relate to each other, 
but more vague. If two libraries have "high coupling" with each other, 
then one requires knowledge of the internal behaviour of another, 
beyond what is exposed through method calls.

Cohesion is almost a given for OO. That may be part of the reason that 
objects look so nice to software engineers. It solves part of the 
problem for them. I think it's coupling that normally causes problems 
for library-based programs that are moving to object orientation. 
Programs that use libraries with low coupling and functional cohesion 
normally hold the data that become the objects in the program itself. 
As the design is refactored, this data becomes part of the "state" of 
the object, which is normally kept private and accessed through 
methods belonging to the object. It's actually quite tricky to do the 
refactoring in a way that still has low coupling without massive 
changes. Sometimes if you want OO, you have to radically redesign 
parts of the program.

The temptation is to ignore the demands for low coupling and produce 
programs or libraries that need internal knowledge of the object and 
objects that show too much of themselves to the outside world. As soon 
as the object encapsulation has gone, not only do you get high 
coupling, but you probably damage the cohesion, with one task being 
implemented across two libraries. That causes all sorts of problems. 
For example, it reduces the size of unit tests that you can write (and 
you'd expect me not to like that, wouldn't you?).

How do we spot this problem? I don't have an absolute answer. The 
developers who know their parts of the code might be able to tell from 
smells.  I think a tell-tale sign is when most private data gets 
exposed to the outside world. If that happens, we should ask just why 
do we want to be able to access all those parts of the object? Is that 
object really the right thing to have here?

What productive things can we do with this information? We can look at 
the designs of our own favourite parts of koha and see whether we can 
organise into functionally cohesive libraries, if we haven't already, 
and move state from our programs to an object made from our library, 
if and only if it looks like an object is a good idea. We can look at 
any objects we've already got and look at how wide open it is.

Feel free to question this. I can probably dig up references for parts 
of it if desired.

-- 
MJR/slef     My Opinion Only and possibly not of any group I know.
Please http://remember.to/edit_messages on lists to be sure I read
http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef at jabber.at
  Creative copyleft computing services via http://www.ttllp.co.uk/