In my last post, I had complained about OOP and made some general statements, but those were probably too general to be readily usable. If OOP is not a swiss army knife and has cases where it would make sense - what are these cases?

Rephrasing this question - when to use Object Oriented Programming?

To know when to use OOP, it is important that we look at why does OOP even exist - what benefits did researchers have in mind when they came up with it.

Benefits of OOP:

• Aligns with our "model" of the world. A dog is an animal = you have a Dog class thats derived from an Animal class. Dog's do a bunch of actions like bark, eat, sleep etc... - the Dog class has bark, eat and sleep methods.
  
  What this alignment means is that the code becomes easier to read and understand. When a code is easier to read and understand, it is easier to maintain. Assuming good practices are followed, changes can be made easily and with a lower chance of breaking the app, by different people over a long time.
  
• Concepts such as inheritance reduce code duplication - thus you can make changes in less places and the change is universal, rather than you having to hunt down each instance of a code and changing it. This makes maintenance and extension of the application easier and less error-prone.
• Design patterns and Decoupling: Using OOP with design patterns you can decouple the many components in your application. When things are tightly coupled (have strong interdepency), you may not realize that one part of your app relies on another (this becomes true when the size of your app increases), and when you change one thing, a whole lot of things break elsewhere. You can use design patterns to decouple the components in your app (like the Model-View-Controller pattern)
  
  You have ready-made solutions to common problems, say you have different objects and you want one object to be automatically notified of changes in another object, you have a ready-made solution already - the observer pattern! This reduces the amount of work you have to do, and speeds up your development. See the posts on Design Patterns for more of their benefits.

OOP is not all sweet, it does have negatives that we should be aware of. Losses of OOP:

• In most cases, when you introduce OOP, you also introduce some performance drain. Objects are heavy things. They encapsulate what you want to work with and more. In procedural programming where you work directly with the data, you don't have the Object Overheads.
  
  Though, hardware is ever improving and in most cases we may not have the need to care about the performance degradation OOP results in.
• OOP results in writing a lot...sort of. OOP introduces a strong structure in the way you have to communicate, while this may be seen as a good thing, in reality it depends on what you want to do. The Coding horror blog has a good example of this: http://www.codinghorror.com/blog/archives/000617.html
  
  The OOP solutions spans 15 lines (mind you...the definition of the Object is not included in the line count), the procedural solution spans about 2-4 lines.
  
  OOP reduces the amount of code you write through reduction in code duplication. But increase the amount of fresh code you write to do things.
  

As you can see, most benefits of OOP come from its benefits in long-term maintenance and patterns for faster solutions . So, when is it best to use OOP?

The answer is when we can leverage off on these benefits and when the losses it comes up with do not significantly affect what you want to do.

Think!

• Is what you are coding something that can be extended?
• How likely is it to be extended?
  
• If I coded this in a non-OO way, will this be shorter, faster? will it result in me doing a whole bunch of copy-pastes?
• What is the scope of what I am coding...in the sense where is this going to run, who is going to use it, how many people, what is the environment? Given the scope...does it make sense for me to invest the time (and other resources?) to make this OO?

I hope this post is more definitive and helpful. Anything is useful when it is used at the right place. Sometimes, it is not easy to find the right place, but thinking about what we do, rather than just doing it would help. Same is the case with OOP.

Labels: OOP, programming

I wanted to create an address-book/contact-management type app in PHP yesterday. I started off with a Contact class (which is based off of the contact table) and typed up the private members, then wrote the get and set accessors.

Now, I had to focus on other things that make the class usable - CRUD (Creation, Read, Update and Deletion of records). I coded the constructor, which would take care of the creation; after an instance is selected, the get accessors can be used to do the reading - but a function for instance selection was needed - I coded this as getContactById where id is the unique key; I also needed functions for multi-record (subset) selection; updates would be taken care by the set Accessors; I coded a deletion function deleteById ... at this point, I got really frustrated! Thinking about it, the task I want to do is something really simple, but the amount of work/coding I was doing was disproportionately large.

I was very sure I could have coded the whole thing using procedural programming much faster. I felt very confused for an instant, this whole idea of object oriented programming did not make sense! of course, object oriented programming aligns more naturally with the way we think and all, but the amount of work was unacceptable!

Deep Breadth....Sigh....

Ok...ok...so what went wrong? and where? Doing some introspection and reading on the basics of OOP, I realized, I got carried away in my amazement of object oriented, the "clean"ness, the coolness...the ideas and concepts (like design patterns etc)...and what it made possible.

Here is what I have concluded, OOP is not a swiss army knife, its rather a complex instrument - something like a drill machine. Its powerful, it can do a lot of thing, but it is heavy and needs electricity.

Say I needed to screw one screw in, if I insisted and forced my self to use a drill machine each time, I end up doing a lot of work...when it was not necessary. I might have as well used a screw driver...and saved my energy and some power...and get the job done faster. On the other hand, if I am working on making a model of something which requires a lot of drilling, the drill machine would make more sense.

Simple, I know! But sometimes we just carried away, that we forget the simple things. We forget to think before we act, since we have trained to look at something/and act on it in a specific way.

Moral: Before attacking a problem, clear your mind, keep your mind open, think out your options and figure our what makes sense? what is the best way to do it? Do not blindly follow a general approach!

Labels: OOP, programming, thoughts