From: MikkelFJ Date: 2003-04-02T07:28:26+09:00 Subject: Re: OO vs. procedural programming "Peter Ensch" 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