I don't really know what the term OOP really really means in the end. Objects? Isn't all programming about objects?

Anyway. Can someone give me a really good example:

if i want to make a piece of software to house the names and phone numbers in my phone book at home, just a simple application, can you summarize how you'd do it

(A) with oop
(B) some other/default/un-oop way?

cheers.

Well, the counterpart (non OOP) would be procedural programming. In addition, there is functional programming which is not OOP, unless you're talking about JavaScript, because in JS, everything, including functions, is an object, though the inheritance rules are different and there are no classes.

I would say OOP is anything that has a class structure or an inheritance heirachy to it: namespaces, abstract classes, child classes, objects which create instances of those classes, and various methods that are associated with them once they are instantiated. Then there are class methods that don't need an object to be instantiated to be used. In PHP these are the static methods, accessed like this:

PHP Code:

classname::method(); 


I'm still relatively new to this game. Maybe someone who has more years on me can give a more complete explanation.

I'm a heavily procedural programmer. I spent years using BBC basic, which is obviously as unobject-oriented as it gets. Then when I got into proper programming I was swallowed up by perl and the methods I used were heavily procedural, and I steer clear of the whole world of inheritance and shared characteristics and indeed pointers.

When trying to get jobs I found that people wanted OOP perl programmers and they wanted them to know a lot about modular perl - they seemed to roll it into one, but now I have done a lot of work with modules and use perl in a modular way quite a lot, on my new designs of things and stuff, and yet none of it is yet oop. I think OOP has always been too much headache for me. I try to get involved. When I was forced to use C++ and pascal both, for a few applications i wrote, once on macs and once on windows machines, was slow, laborious, but i did it. It wasn't anywhere as easy as procedural programming is all by yourself. Some problems took days and weeks to solve.

I am learning Java now, again, having only used it a few times. Occasionally in very involved ways, reworking applets I found after much digging around, ideally suited to tasks I wanted to do.

java is clearly completely oop.

It wasn't anywhere as easy as procedural programming is all by yourself. Some problems took days and weeks to solve

I would not say it's easier in procedural than on object oriented to program, but the way you need to model your application behavior is different.

It's more "thinking in procedural" or "thinking in object" related.
I was immediately seduced by OOP the first time I touched it.
he whole concept of inheritance and derivation/overloading seems totally logic to me, and it was quite easy to jump in that train.

I had a much harder ride when I started digging a bit on the set based programming techniques.
But I have to say I think I handle them quite well today, which is rather preferable in my position, as an T-SQL developer and DBA.

You may or may not be familiar with some of this, but I'll write it out a bit for everbody's use.

The most basic set of vocabulary for OOP is a class, a method, and a parameter.

A class is a set of functions that work together to accomplish a task. An instance of a class is considered an object.

A method simply refers to a function that is encased in a class.

A parameter is a variable that is passed into a function that instructs it how to act or gives it information to process.

Like Tripy, I've found that I quite enjoy object-oriented programming, at least as I've used it in PHP and JavaScript. However, it does take a little while to "get it" because it is as much a mindset as a programming style.

If you do a bit of digging, you'll find a wealth of information about design patterns. Some of these might be useful to look at, though I'd be careful about getting into them too much at first because they can be overwhelming. There are two helpful (and somewhat overused) acronyms you might keep in mind when trying to get yourself into an OOP mindset: DRY and KISS.

DRY stands for Don't Repeat Yourself and it means just that. If you write some code, you shouldn't have to repeat that particular code ever again. In practical terms, it means thinking more abstractly and planning a little better at the outset. I'll give an example shortly.

KISS stands for Keep It Simple, Stupid and means that you should try to write code that accomplishes its goal in the simplest manner possible. Simpler means fewer possibilities for errors and easier maintenance. In the context of OOP, this usually means making sure that each method or function has only one task. If you find that a method does more than one thing, it usually means that it can be refactored into several smaller methods, each dedicated to a specific task.

Now for a simple example:

Let's say that you need to program two different forms, one that processes information about cars and one that does the same for trucks.

For cars, we will want to record the following info:

Color
Engine Size
Transmission Type
Number of doors

For trucks, we need:

Color
Engine Size
Transmission Type
Cab Size
Towing Capacity

In procedural programming, you would write the code first to process the car form and then the code for the truck form.

With object-oriented programming, you would write a base class called vehicle that would record the common characteristics what we need from both trucks and cars. In this case, the vehicle class will record:

Color
Engine size
Transmission type

We'll make each one of those characteristics into a separate method. The color method, for example, could take the color of the vehicle as a parameter and do something with it, like storing it in a database.

Next, we will create two more classes: truck and car, both of which will inherit all of the methods of the vehicle class and extend it with methods that are unique to them.

The car class will have a method called numberOfDoors and the truck class will have the methods cabSize and towingCapacity.


Okay, so let's assume that we have a working example for both procedural and OO programming. Now, let's run through a few scenarios.



Scenario 1: Suppose that we suddenly need to add a bus form, that records the following information:

Color
Engine Size
Transmission Type
Number of passengers

Procedural: We need to recreate the entire form, repeating the code for Color, Engine Size, and Transmission Type.

OOP: We simply extend the vehicle class with a bus class and add the method, numberOfPassengers.



Scenario 2: Instead of storing color in a database like we previously did, for some strange reason our client wants the color emailed to him.

Procedural: We change three different forms: cars, trucks, and buses to email the color to the client rather than storing it in the database.

OOP: We change the color method in the vehicle class and because the car, truck, and bus classes all extend (or inherit from, to put it another way) the vehicle class, they are automatically updated.



Scenario 3: We want to move from a generic car to specific makes, for example: Nissan and Mazda.

Procedural: We create a new form for each make, repeating all of the code for generic car information and adding the code specific to each make.

OOP: We extend the car class with a nissan class and a mazda class and add methods for each set of unique information for that car make.


Scenario 4: We found a bug in the transmission type area of our form and need to fix it.

Procedural: We open and update each form.

OOP: We fix the transmissionType method in the vehicle class and the change perpetuates in every class that inherits from it.


As you can see from the above scenarios, employing an OOP style has significant advantages over procedural programming, especially as your scale increases. Consider the savings we would receive from OOP in terms of repeated code, flexibility, and maintenance if we also had to add forms for boats, motorcycles, planes, go-karts, ATVs, snowmobiles, etc.

Objects and methods are also far easier to test than procedural programming by using unit testing to test results.

Does this mean that you should never use procedural programming? Not necessarily. If you're doing a mockup or a proof-of-concept app, you might not have the time to make everything object-oriented and so I think it might would be better to use procedural programming for a prototype, but it would be best to make the production product in an OO-manner.

Hopefully this will help answer at least a few of your questions about the differences between OOP and procedural progamming.

Cheers. Both tutorials have helped, naturally the second one is very detailed and explanatory... I'd say worth at least half a day of a 1000 pound a week training course - so 100 pounds. The least I can do is click "add reputation"!

I think you're being too hard on procedural methods. Sure I see the absolute necessity for the oop approach, but there are many functions of programming, particularly in server management, in which a script is really just one or two procedures and to lay down a whole world of classes and inheritance would be a waste of time and money!

In my coming a.i. work I think oop is pretty key - it's the biggest thing missing from my previous structures. At the same time the one part of the a.i. system which acts as the true brain - that is just a wee bunch of procedures attached to a 'translating' system. Of course without OOP I can't take advantage of how this can work when "plugged in" to ANY type of language usage by humans!

So thanks. I enjoyed reading this lesson and will re-read it many times as I grapple with this trickiness. I do think I use a BIT of oop in my work nowadays - eg the reading in of variables on web scripts - checking all the input from users and the environment - is a task all my scripts call on from a shared package. and i could now rewrite a lof of my old software with that approach thrown in, but it's only really a wee tad of oop, my scripts are pretty heavily procedural...

I guess the presence of wee things like this in my scripts, though, does maintain the very tadliest amount of oop methodology a guy can butter his technological bread with...

sub db_execute {
$sth = $dbh->do($_[0]) or print "no can do";
}

sub db_query {
my ($sth) = $dbh->prepare($_[0]) or print "no can do";
$rv=$sth->execute or print "no can do";
return ($sth);
}

So every time I put an sql query into action, I just call upon one of those procedures. That way the procedure is just used over and over for diff stuff. However I still haven't jigged it so that I can put those procedures into packages and be able to execute them from any script without having to add the procedure to each script! Thinking about it, I can do that, but not as neatly as if I'd set the whole thing up in the OOP way.

Still, the way I see it, I want to be able to program in EVERY way, even oop. Actually I want to even build games for consoles. It's my usual raison d'etre - software development. It's a shame I spend much of my life mastering advertising instead of software. Just like it's a shame I spend much of my life trying to contain my libido instead of unleash it! The world seems to insist on matching your best with its worst, following your good with its bad and treating your fidelity with mistrust.

I'm glad it was helpful. In my experience, it took a while for it to 'click', so do what you can to start and just take it one step at a time. I started creating classes and using them, even though I'm sure they were horrible bits of code with huge methods. Really, it was a lot of procedural code wrapped in a class, but it was a start. Over time, I started seeing the bigger picture as I used my code, refactored it, and looked at other people's code as well. I'm definitely not an expert and I'm sure I still write some ugly code at times, but I'd like to think I've gotten better.

You're right about setting up an OO environment...it definitely can take more time at the outset and so it might not make enough economic or time-use sense for smaller or quick projects. However, I can't recommend an OO style enough if any of the following are true:

1. The code will be maintenanced over a long period of time
2. The project will expand in the future
3. More than one or two people will eventually be working on it
4. You want to reuse the code in some other project

I don't know what language you're using, but let me give you an actual code example from PHP. Validation is a pretty common programming task and you should be using it for every form, regardless of what kind of form it is or who has access to it. I've created a fairly comprehensive validation system for a PHP framework I'm building. I won't share it all because that would be way too much code to put on here, but I'll share hopefully enough to be helpful so you can see it in practice.

This is my basic validator class. It really doesn't do much but store an error message and a validation state and then display them, but it will be immensely useful later on.

PHP Code:

class Vm_Validator {

    protected $validates = TRUE;

    protected $error = NULL; 

    /**
     * @return boolean - TRUE if the validator validates, FALSE otherwise
     */
    public function validates() {
        return $this->validates;
    }
    
    /**
     * @return string - The error message
     */
    public function getError(){
        return $this->error;
    }
} 


If you're wondering what $this means, it refers to the object itself, but it should only be used within the class. You can refer to a class variable like $error by writing $this->error. Likewise, you could refer to the getError method by writing $this->getError().

Now that I have defined methods for how my validators should show their validation state and get an error, I'm going to extend my base validator class (I'll just do three for this example).

PHP Code:

class Vm_Validate_Regex extends Vm_Validator{

    /**
    * @param string $regex - The regular expression to be evaluated
    * @param string $input - The input to be validated
    * @param string $error - optional - A custom error message to be returned if the input fails validation
    */
    function __construct($regex, $input, $error = NULL){    
        if (!preg_match($regex, $input)){
            if ($error) {
                $this->error = $error;
            }
            $this->validates = false;            
        }
    }
} 


The above class is a generic class for validating regular expressions. You'll notice that I can access the class variables from the parent class (Vm_Validator) just as if it were a part of this class. I'm also writing a construct method, which means that I should use the parameters $regex and $input whenever I create a new instance of the regex class ($error is optional in this case).

Now I'm going to extend the regex class with a class that validates email address by using a regular expression for emails.

PHP Code:

class Vm_Validate_Email extends Vm_Validate_Regex{

    /**
    * @param string $input - The input to be validated
    * @param string $error - optional - A custom error message to be returned if the input fails validation
    */
    function __construct($input, $error = NULL){    
        $error = ($error) ? $error : 'Please enter a valid email address';
        parent::__construct('/^([a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4})*$/', $input, $error);
    }
} 


Again, I'm using the construct method, but I'm also using it to pass items into the parent's construct method, in this case the regex for email and then a default error message if none is given. If you wanted to validate URLs instead, just change the class name, change the regex to instead validate a URL, and use a different default error message.

Let's do one more. This one extends Vm_Validator but checks for a minimum length.

PHP Code:

class Vm_Validate_MinLength extends Vm_Validator{

    /* 
    * @param int $minLength - The minimum number of characters    
    * @param string $input - The input to be validated
    * @param string $error - optional - A custom error message to be returned if the input fails validation
    */
    function __construct($minLength, $input, $error = NULL){    
        $defaultError = "Please enter at least $minLength character(s)";    
        if (strlen($input) < $minLength){
            $this->error = ($error) ? $error : $defaultError;
            $this->validates = false;            
        }
    }
} 


Validation can be a real pain using procedural programming. You have to be very careful that you don't make a typo, which can be very easy when you are copy-pasting code into new situations and making slight changes. I think it's what first made me start exploring OOP. I think I now have 50-60 different types of validation that are very similar to the above classes since I switched over, but they will be far easier to maintain than any of my previous procedural code.

Here's how you would use the above code, assuming you either used the autoload function or included all the necessary class files.

PHP Code:

//This is the value of an email field from a form
$email = $_POST['email'];

//$emailCheck is a new instance of the Vm_Validate_Email class
$emailCheck = new Vm_Validate_Email($email);

//Now, rather than using $this to refer to class methods, we use the name of the class instance, which is $emailCheck
if ($emailCheck->validates()){
     echo 'Email address validated!';
} else {
     echo $emailCheck->getError();
}

//I'll also use the minLength class to make sure a username is the right length (at least 5 characters)
$username = $_POST['username'];

$usernameCheck = new Vm_Validate_MinLength(5, $username);

if ($usernameCheck ->validates()){
     echo 'Username validated!';
} else {
     echo $usernameCheck->getError();
} 


I have a few higher level classes that handle the validation to an even greater degree, but hopefully this real world example should help you out a little more, especially if you're using PHP at all.

If you're worried about spending a whole bunch of time writing classes, I have good news. You probably don't have to. Use a framework. PHP has Zend, CodeIgnitor, Symfony, Cake and a whole lot of others. JavaScript has MooTools, Prototype, Jquery and more. I'm sure there are multiple frameworks for almost any language that have already done a lot of the hard work for you.

Don't worry master yoda, I'll come back and finish what I've started... but first I have places to fly.

I'm starting to "get it", though... the classes are object 'templates' of a sort. a call like "new vm_validate_monkeynuts" is basically sending data to the class and coming back with responses in various ways.

I have touched upon this style of programming once or twice in my life and I do look forward to just "falling in" to it one day. I think my new self-teachings in Java will probably be the thing which pushes me into that particular habit... I read about JavaFX and I am keen to discover it and become part of the new wave of programming that hopes to put the people power back into network programming!

See ya. Gotta go now. Regards to Obiwan, or as we call him, President Obiwama.

Originally Posted by witnesstheday

I'm starting to "get it", though... the classes are object 'templates' of a sort.

You're on the right track, but classes are not necissarily templates. There is a subset of classes called template classes (or generics in java) but that is something else all together.

Classes should be used when something can be characterized as an object. If I am parsing a file I might want to have Parser object containing all of the code for parsing a file. Understanding the concepts of encapsulation, abstraction, modularization, and reuse will help to better understand OOP and how it should be used.

I'm not sure about encapsulation and abstraction... what's that? Modularization I'm au fait with. I use little packages in perl, in fact one of the key ones is my parser package - which i call universal_variables.pm and use it in pretty much everything i write.

Abstraction allows a programmer to work at a higher level by abstracting away from specific details of an implimentation. If you have an object ArrayList and a method add, you don't have to worry about how add is implimented when you call add on an ArrayList.

Encapsulation is basically just putting everything in one place. if an class contains all of the attributes of an object then it encapsulates that object. You can probably find better explanations by doing a search on those terms.

Your explanations are understandable. I can see these are methods I shy away from, preferring spontaneous instant code pouring to organised activity - not because it's better but because I'm always "programming on the run" as it were.

Java looks like it could be my new beginning - a big step forwards in my development methodologies.

Perl makes it so easy to not give much consideration to organised methods of programming - to the longterm. You kind of make everything as a one-off, and then when you upgrade, rather than adjusting what you've got, you often just remake. It's practicallly a disposable language!

I'll give you my explanation of encapsulation, and why it is so important. One of the reasons this is such an important concept in OOP is that one of the main advantages of class based hierarchies is that the code is supposed to be highly reusable. Lately I've been designing classes that I intend to keep using for years.

When something is encapsulated, its values are kept away from the public or global namespace. This insures that there is no clouding or polluting of a space that has an uncertain quality to it. The very act of creating a class makes a space in which values only exist locally, by declaring them. This type of strictness makes everything much more modular and manageable, since your thought process only has to extend as far as return values and the relatively small space of the class itself, as well as the local space of each of its methods. Also, by keeping properties encapsulated within a class, you allow values to be tightly bound within objects, so that there is not only an organizational scheme, but a manageable global namespace.

Encapsulation is vital not only for the sake of reusability, but for working in a team environment. When programmers are working on a specific task, they won't need to be constantly checking with the other developers to make sure they aren't stepping on toes by defining variables that may already be in use. They can instead, just simply finish their task, then document how the module is to be used so that it can be immediately put to use.

So although using objects and classes takes more planning than using procedures to run an application, the larger the application the more vital classes become to the overall scheme of things. The extra planning will save a lot of time in the long term. I still do things procedurally when I build small websites, because the time saved in the execution of things is not significant enough to take the extra time to plan out and write a bunch of classes, but for medium and larger sites, OOP is a Godsend.

JavaScript, which is not class based, allows you instead to create closures by writing functions within functions. Those functions will then be local to the parent function:

<script type="text/javascript">
function outerFunction() {
     function innerFunction() {
        alert("inner function called");
     }
}
innerFunction();//will produce an error
</script>

will produce an error, but if the function is called within outerFunction, it will alert correctly. This is a type of encapsulation. JavaScript also allows you to create temporary, anonymous function wrappers, which make everything defined within them local to the wrapper, so that you can make simple variables without worrying about what may happen later on in the page. This is how I create reusable code in JS:

<script type="text/javascript">
(function() {
     var x;
     var i;
     var n;
     //etc
})();
</script>

This is also a form of encapsulation.

<script type="text/javascript">
(function() {
     var x;
     var i;
     var n;
     //etc
})();
</script>

That's a tricky little doohickey, that. So are you saying that putting a bracket around the entire function and its curly brackets is a wrapper and localizes it?

Originally Posted by witnesstheday

<script type="text/javascript">
(function() {
     var x;
     var i;
     var n;
     //etc
})();
</script>

That's a tricky little doohickey, that. So are you saying that putting a bracket around the entire function and its curly brackets is a wrapper and localizes it?

That's what I'm saying. The only trouble in JavaScript is that if you use a variable without first defining it with the "var" keyword within your local space, it falls back to a global definition, which can have an impact on the global chain. This will include variables defined within any space, regular functions, or anonymous wrapper shown here. This was definitely a mistake when the language was designed, but it has been written into the standard so that everyone's scripts will not break.

Can't that have advantages? So you can keep everything localized but some key element that needs to be global... everything but the girl, kind of thing.

Well, it can, and is used frequently (accessing the global variables by not declaring them "var"), but it's the way that JavaScript implemented it that is the problem. It is easy to forget to include a "var", and suddenly your variable goes global, which can mess with things. In most other languages, to access a global, you need to declare in as such within the function or method. In PHP this is done either with the $GLOBALS array (kind of like using the window object in JavaScript), or by declaring the variable "global" inside the function body:

PHP Code:

function myFunction() {
global $page_request; //now I can change this global within function
$page_request = "whatever"
$GLOBALS["page_request"] = "whatever";//or I could do it like this.
} 


PHP is pretty loose, however: like PERL, there are many ways to accomplish the same thing. I don't know much about Java, but I bet it is stricter.

<offtopic>
Just thought I'd post that Abel's talkupation at post 13 (the excellent explanation of encapsulation) was: 1337! </offtopic>

Thanks Chris, I like seeing my talkupation points jump by almost 100 points . I'd like to point out that my little bars haven't maxed out yet however, so everyone else needs to chip in.

"you must spread some talkupation around before giving it to wayfarer07 again"
sorry, i tried - i was hoping to barter for a bump to my boycott-israel post! go on, give it a bump. don't worry - it's only until the apartheid ceases and all people in the region has peace - it's not permanent.

I've dug out my second edition blue camel perl workbook and found a place where a few perl merlins can give me sudden-death tuition when i find those gigantic f***ups in the stuff i write, so I'm going to now go full on to total perl mastery. I'm probably 30% to 40% there so far, so it's not such a big battle. Still more than I've done. I also have my book on Java - small book "teach yourself java" with loads of basics covered, and beyond that there's my fat linux book, my aspx book and LOOOOADS of C++ and C training materials. Plus this lisp thing sounds well cool. But perl is the key - I can master oop, functional programming's underlying "ways" (if that's a good way to describe what i can't really know until i really properly discover it) and simultaneously qualify for a really superhigh contract salary which I might get (I doubt i'd have the same trouble in Perl jobs as in Sales jobs, in terms of recruitment... particularly not contracts {ie non longterm}). But I'm only doing it for the knowlege and (self)mastery. The cash I'll probably never reap. I've even switched off the targeting computer / tardis-performance-monitor... there's no doubt it's flying fine, so I'll just focus on development issues on the three main fronts (the programming, the money, the revolution!)