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@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/