“Peter Ensch” nobody@bogus.com wrote in message
news:b6cdeh$i8v$1@tilde.itg.ti.com…
I people don’t always write OO programs in Ruby, how do
they decide when to do so?
When it feels natural.
Pragmatically, sometimes in Ruby there are benefits using class member
variables such as @myvar instead of a global variable $myvar, or a local
variable myvar. This indicates there is a bond between multiple procedures.
You can easily put a class around all the procedures and suddenly you have
OO. This is a very week form of OO, but it does provide a level of code
isolation and you can create multiple instances of the code.
For example you are writing formatted data. One variable may hold
indentation level and another variable might hold an output file. If you
have two different data writers active at the same time, it is good to have
a class such that each configuration variable is controlled per instance.
In Ruby this naturally grows from initiallyy being procedural towards more
OO as the need increases. Just never depend on global variables.
The next reason for going OO is when you realize you need a single data
formatter interface, but multiple implementations. For instance a file
writer and a string writer. In other langauges you would create a common
base class - in Ruby you need not use inheritance just make sure the same
methods are present in each class. Despite not using inheritance, you still
need OO because you need a plugable data writer instance, that is, one
object or another providing the functionality.
From that point on you can start looking at cooperating objects using
various patterns such as visitors and what not.
But you shouldn’t over objectify everything just for the sake of it.
It takes a lot of practice to know how to model a problem in OO - if you are
not familar with OO just try it out slowly - see how one object could hold a
reference to another object, or to a collection of other objects - see how
this might make the information flow easier. Do not focus too much on how
you could make you code very general - it does not really work in praxis. In
my data writer example you may need to abstract to cover both file and
string writers, and then it is fine to generalize. But if you only imagine
the need, prefer a simpler solution - but also do not hardcode anything
unnecessarily - i.e. users of datawriter should not assume there is a file
reference - this should be controlled by the datawriter so you can later
generalize if necessary.
I have come to like a procedural, or functional, programming style where
some functions do not operate and data other than input arguments, but these
input arguments are objects.
For example, a function could take a datawriter object and a data provider
object and pass the data from the provider to the writer.
This approach can be very flexible. The nice thing about functions are that
they do not have sideeffects. The nice thing about objects is that side
effects are carefully controlled within the objects. In this combined
approach, a datawriter object can be passed around between highly generic
formatting functions and still maintain formatting state within the writer
object.
Finally, I’d like to point out that what is objects with member variables
and member functions can be functions operating on records in other
languages. It may look like a very different style, but often they
accomplish the same thing - not always, but in many cases. In fact, the
situations where this is not possible is where OO is really interesting
because it actually solves a problem rather than just providing yet another
way to do the job.
Remember - use OO when it feels natural, not when you think: How could I
make this in OO style. A similar argument goes in functional programming
languages where you sometimes need an imperative style.
In the end it is about making information flow natural within the program.
Mikkel