From: salamond <jarodzz@...>
Date: 2010-07-10T08:44:09+09:00
Subject: Re: from functions to classes, where should I start?

Thanks, Robert and Jay.

I started programming with C, not the type of a natural OO programmer.
And yes, the Procedure Oriented way, or function way works fine for
me, almost all the time.

Until I'm considering adding unit tests to my own scripts.
With the mock pattern, an interface like Cat with a function
"catchRats" is a must to have, then CatImp and CatMock.
That's how mock works.

That's where I start thinking, maybe it's time to OO.

But as you say, it doesn't have to be OO all the time,
unless there is a specific problem better be solved that way.

So here's what I'll try:
* I have a copy of Design Patterns by "gang of 4", seldom read, I'll start now
* I think if unit testing is what I need, I should go through unit
testing patterns, see how OO works for a real problem
* I'll definately follow your suggestions, see if there's sign for OO
in my scripts, (encapsulation, etc).

Again, many thanks to you guys.



On Sat, Jul 10, 2010 at 5:15 AM, Robert Klemme
<shortcutter@googlemail.com> wrote:
> On 09.07.2010 19:11, Jay wrote:
>>
>> Hi JaordZZ,
>> I began software development using OOP can't recall any books to
>> recommend. I would encourage you to think critically about when to use
>> OOP, rather than doing it simply because of Agile dogma.  When
>> reviewing my code, I've often found that I tend to use classes for
>> everything -- just out of habit (and due to a heavy Java background).
>> When coding, I now try to ask myself, "Does this code represent
>> something that benefits from OOP, or should it exist as a function(or
>> Module or static method)?".
>>
>> Here are some of the most common reasons to consider OOP:
>>
>> 1) Making state information handy to the functions that need it.
>> If you find yourself passing the same data in as parameters to related
>> functions, then consider wrapping the data and functions up into a
>> class.
>
> The key word for this is "encapsulation".  I believe it is the most
> important aspect of OO.
>
>> 2) Organizing large amounts of code
>> OOP allows you to present public interfaces that simplify the usage of
>> code.  This is very helpful for large projects, but not usually
>> necessary for smaller scripts and projects.
>
> I think this is normally named "information hiding".  I use it even for
> smaller scripts.
>
>> 3) Use of inheritance or polymorphism
>> If you want to benefit from subclassing objects.
>
> IMHO inheritance is overrated (or maybe overused).  Often people turn to
> inheritance where composition would be a better choice.  But I agree, this
> is another important aspect of OO.
>
>> And some common reasons to consider your current approach:
>> 1) You are already using it and it works (or does it?)
>> 2) There is a small performance penalty with each object that is
>> instantiated
>>
>>
>> I know this is very oversimplified, but my lunch break is ending
>> soon.  ;-)
>
> ... and I have to go to bed now. :-)
>
> Cheers
>
>        robert
>
>
> PS: JaordZZ, a book or tutorial about patterns might help.  See here for a
> start:
> http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
>
> --
> remember.guy do |as, often| as.you_can - without end
> http://blog.rubybestpractices.com/
>
>