Re: Short routines matter more in OO?

[pg]

NO, shorter function/procedure/method matters, but shorter method in OO does not matter more than its counterparty in traditional non-OO coding.

Let's imagine that you are converting some OO code back to traditional non-OO style, is there a need or will you merge two or more methods into one function? No, that is absolutely not required.

Let's look at the opposite: if you are converting some non-OO code into OO method, will you split some functions? Yes, but that is not because we are moving to OO, but becasue that they should be splited in the first place, even in non-OO style. If today you ask people to redo them again in non-OO way, they will do it in a more proper way, as we are making progress everyday, not just because of OO.

OO is beautiful enough, and there is really no need to decorate it with extra praises (that does not belong to her;-)

This is what I think/do:

• The size of the procedure/function/method matters, but it is less important than the length of code being blocked inside your out-most looping structure. In real life, I dislike any code has out-most looping goes accorss page boundary. It sharply decrease people's ability to understand the function/procedure/method. To me, this is unrelated to the fact whether the code is OO or not. (Those get/set/is method should be excluded from the discussion, as those 2 or 3 liners appears way too often in OO, and works against the fairness of our statistics.)
• Layering abstraction does cost something, but that is usually on the coding side. From a designer's point of view, adding a layer of abstraction usually means to extend the reusability and to make the structure much more clear, so the cost actually goes down. (I am thinking that this might also has something to do with the language, not really the OO concept. OO is not exactly the same thing in different languages. In java and c++ they are slightly different, but if you compare Perl OO with Java or c++, they are quite different.)
  (This paragraph is added later) I come up with the thought that, althouth layering is not wrong in Perl, it is, most of the time, less practical in Perl than in other languages, becaue Perl is usually used to put things together QUICKLY, and that's one of the major benefit most of the people seeking from Perl.

Oh, by the way, welcome back! The first time I started to deal with this site, you were away, and there were stories about you went around. This time I come back, you are a real person (at least in the virtual world).

[Abigail-II]

Let's imagine that you are converting some OO code back to traditional non-OO style, is there a need or will you merge two or more methods into one function? No, that is absolutely not required.

You wouldn't merge function, but remember that many objects are just containers for a bunch of variables. They are nothing more that structs, and many objects are full of small accessor functions of the form:

sub accessor {
    my $self = shift;
    $self -> {key} = shift if @_;
    $self -> {key}
}

That's code that will evaporate when converting OO to non-OO, as you would replace the call:

    $obj -> accessor ("value");

with

    $obj -> {key} = "value";

And by eliminating many short methods, the average size of the methods will increase.

Abigail

[tilly]

The loop point was made in Code Complete as well.

As for layering abstraction, my opinion is that there are real costs, and they tend to be much higher than many designers think. See Design Patterns Considered Harmful for a similar note.

And thanks for welcoming me back. Contrary to some allegations, I am a real person, not a myth. :-)

[pg]

I agree that layering has real cost there as anything else does, but I still think layering is extreamly important to a clear design, as long as you do it with a good PLAN. Lots of troubles are caused by bad designs under the cover of good principles, not those good principles themselves.

From time to time, I see people copy and paste code from one module to another, and then slightly modify them. Layering is usually the best way to save people's life under this kind of situation. and make it more beautiful. Copy and paste makes programmer's life miserable, as now you might have to change whole bunch of code for a slight modification that you would be able to make at a single point if you layering properly.

With layering in mind, now you start to establish the sense of digging the similarity between modules that usuaully looks totally unrelated, and an entire new world is opened for you and the people work with you.

Well the copy and paste stuff is just one extream (and most simple) example, but the most miserable one. As now programmers are turned into production lines, instead of human being who want to spend more time thinking and dreaming.

[tilly]

I don't mean to seem to discourage having abstraction layers. I'm all for them, as long as they are buying you something in the particular instance at hand.