[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Koha-devel] koha and objecting to libraries [RT]
From: |
MJ Ray |
Subject: |
[Koha-devel] koha and objecting to libraries [RT] |
Date: |
Sun Oct 26 05:02:01 2003 |
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/ address@hidden
Creative copyleft computing services via http://www.ttllp.co.uk/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Koha-devel] koha and objecting to libraries [RT],
MJ Ray <=