December 02, 2004
Some practical benefits of OOP
If you're an experienced developer, I'm afraid you won't find this post interesting.
But, if you're starting to learn about object oriented programming, maybe you've heard about its benefits, about how an object oriented approach can help in developing and maintaining your applications. But, is it true?. Does oop really make our work easier?.
Let's suppose that we have to develop a new website, and that this website, when launched, prompts the user with a form just to make him / her enter his / her username and password and, when the "send" button is clicked, sends the data to a server side script.
I can think of three different ways to solve the problem.
1.- The "old" way: We just place in the stage the two textfields we are going to need and the movieclip ( or button ) for the "send" button. Then, we select the button, hit F9, and write a script like the following:
on( release )
{
_root.getURL( "myscript.php", "_self", "GET" );
}
Work done!. We've solved the problem in two minutes. That's good!.
But, what happens if we have to implement a prompt like this in all the websites we develop?. We'll have to copy the code and paste it in every single button contained in every single fla we work on. And what happens if we have to change the server side script url?. We'll have to open all the fla files we've made before, and start changing all the scripts in all the "send" buttons.
So, the development time has been too short, but it can be a hell to maintain.
2.- We can put all the code in a frame, or even better, in a *.as file.
Let's think again about the example we used before. If we assign an instance name to the button ( "sendBtn", for instance ), we can write an as file with the following code:
sendBtn.onRelease = function( )
{
_root.getURL( "myScript.php", "_self", "GET" );
}
Now, we'll only have to include that *.as file in all our projects and we're done!. If we must change the url of the server side script, we just have to change it in the as file.
But, what happens if the server side script is not the same for every project?. One client might need an asp, another one a jsp... And what happens if we have to do something with the login and password values before sending them ( like, for instance, write then into a SharedObject )?.
Now our code is easier to maintain, but it has lost a lot of flexibility.
3.- The OOP solution. Why don't we break the whole process into small pieces ( or entities ), and make each one of them responsible of a single task ( and only one task )?. Why don't we make those entities independent enough, so when we change any of them, that change does not affect any other entity?. And even better, whay don't we implement those entities in a way that one entity doesn't know anything about how another one works?
Suppose we have one of those entities responsible of telling the "send" button that when clicked, it must fire an event that contains the user and password data. Suppose we have another entity that is waiting for data ( any data, in any format ), just to push that information to a third entity that just sends the information it receives to a server side script ( whose url can also be a parameter ).
Well, each one of those entities is a class. So, we'll implement a class to manage the user input, another one to manipulate that input data, and a third one to send any data to a server.
What happens if the url of the server side script changes?. Not much, that url is just a parameter of the third class ( the one that sends everything it receives to a server side script ). What if we need to perform any calculation before sending the data?. Not much. We just perform that operation before sending anything to the third class.
So, now, our program is easier to maintain. There's a lot of common code that can be used in many different websites. And we've also divided the functionality into many small pieces. So, from now one, it will be easier, for instance, to solve any possible bug ( just because we know where to look for its causes ). That's called modularity.
The versatility is also improved. The application 's behaviour can be changed without changing code ( we can make it send data to an jsp, a php,... ).
It's also easier to add new functionalities. We just have to add new pieces to our application. That's called scalability.
We've also said that the classes hide the details of how they work to other classes. So, if the way a class does its work must change, it doesn't affect the other ones. That's called encapsulation.
So, if we use the third solution, we'll have to write more code than if we use the first one. But, that brings us a lot of advantages. And the biggest one is that our applications will be easier to adapt to the changing requirements. And you can be sure, the requirements of a project will change. And not once.
Thanks to Ignacio Caballero for giving me the idea for this post.
Posted by Cesar Tardaguila Date: December 2, 2004 11:29 PM | TrackBack
