Since Joel Spolsky ranted about how few of his job applicants understand functional programming, it has become trendy (for some) to disparage object-oriented design. In the last few months, many perl afficionados, have rushed out to buy Higher Order Perl. This is a good thing, because re-thinking the need for OO is probably long overdue.
In OO design, all problems become problems of dealing with data. This works well when you really are dealing with data, say when you are pulling stuff out of a database and need to do something with the data. You design procedures 'aka methods' that work on this data transforming into other data.
For many tasks though, creating classes for everything, just creates an ugly, clunky design that is difficult to understand and a nightmare to maintain. So if, for example, I have a stream of characters that I need to transform into other characters. An OO approach would probably to create some sort of filter pattern. However, I'd suggest that a functional approach makes much more sense here and enables the problem to be broken down into simple actions so that small changes can easily be made to the system.
In this paper, the authors suggest a 'visitor' pattern to deal with a situation in an OO system where certain aspects are better dealt with in a functional way. To do this they create a 'processor' class, that behaves like a pure function.
The problem is that a 'processor' class is not in the spirit of OO. OO is about data. A class that doesn't contain any data, isn't really a class. It's a function. It means this aspect should be implemented 'functionally' rather than as 'OO'.
I'll probably get into trouble for say this. But the solution is ugly. OK, if you have to use OO then you're stuck with something like it. But if, you find you're creating classes just to transform objects of another class into objects of yet some other class, your design needs a rethink. IMHO, anyway.
Fortunately, in perl, it's fairly easy to combine both OO and functional approaches. The danger of the Perl freedom is that you end up with a mess, but done right, it should mean the best of all worlds.
OO is about data.
I think OO is about the behavior of models. Why do you think it's about data?
Re:Data?
TheNomad on 2006-12-10T20:11:08
I think OO is about the behavior of models. Why do you think it's about data?Well, I was really thinking of Steve Yegge's rant on nouns vs. verbs.
In OO every class is really a 'data type'. Even in perl where there are no types
:). The essence of OO is to have an object, say $obj, that is data of some type and to have methods that act upon that data: $other_obj = $obj->transform. Sure you can have objects that don't 'contain' any data and only methods. But you end up with an ugly looking model, IMHO.
BTW, I knew that post was going to get me into trouble. I shouldn't have turned on comments
:) If your problem doesn't reduce to data very well, then your model is going to look odd. Of course, you can alway make your problem reduce to objects if you try hard enough. But if you have to try too hard you need a new model.
OTOH, maybe I'm just p*ss*d off at having lots of stupid little classes, that don't do anything much, littering my HD
Re:Data?
chromatic on 2006-12-10T22:15:51
In OO every class is really a 'data type'.Not the way I write code. If I can create classes without data, I do. (Of course, I've also argued If we can solve problems without computers, perhaps we should.)
Re:Data?
TheNomad on 2006-12-10T22:44:05
Not the way I write code. If I can create classes without data, I do.
But then isn't the class just a namespace with a bundle of functions?Re:Data?
chromatic on 2006-12-11T00:12:00
It is, only in the same way that a function is just a
jmp/retpair. From the external point of view, a class is just a collection of behavior, not data. That's the important point.Re:Data?
TheNomad on 2006-12-25T13:36:56
You may well be right and it may be the best way to think about object-oriented design, but I think most people think of it differently, for example the McGraw Hill dictionary of technology:A computer programming methodology that focuses on data rather than processes
On the other hand TechWeb says:Writing software that supports a model wherein the data and their associated processing (called "methods") are defined as self-contained entities called "objects."
But the whole thing seems confused, the wikipedia says:Attempts to find a consensus definition or theory behind objects have not proven very successful, and often diverge widely.
Your way of thinking about it may be the best way to simplify design.Re:Data?
chromatic on 2006-12-25T19:20:46
Your way of thinking about it may be the best way to simplify design.Thanks! I have had roles banging around in my head for a bit over three years now.
