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

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.