Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

TheNomad (7014)

TheNomad
  (email not shown publicly)

Journal of TheNomad (7014)

Sunday December 10, 2006
04:27 AM

Functional vs. OO

[ #31871 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • OO is about data.

    I think OO is about the behavior of models. Why do you think it's about data?

    • 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 [blogspot.com].

      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, IMH

      • 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. [oreillynet.com])

        • 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?
          • It is, only in the same way that a function is just a jmp/ret pair. From the external point of view, a class is just a collection of behavior, not data. That's the important point.

            • 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 [answers.com]:

              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 wik

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