OOP: Just One Reason Why
Object-Oriented Programming is without a doubt an 800 pound gorilla. Ignore it at your peril, and be prepared for derision by your fellow programmers if you do. Actually, there is quite a backlash that's developed against OOP. I was surprised to find that a good part of the Wikipedia entry on the topic was actually a critique of it, rather than a clear explanation. (I guess that's the sort of thing that happens when you have an entire encyclopedia written by geeks who think they know everything...)
Rather than join in the chorus for or against, I simply wish to make a single point as to why OOP is extremely useful for building large-scale applications. Traditionally, the main benefits of OOP are claimed to be Reusability, Reliability, Robustness, Extensibility and Maintainability. From my experience, the only one that matters most of the time is Maintainability.
Let's face it: when you start a new project, it's unlikely that you're going to reuse large portains of old code. Okay, you might reuse some basic classes like "Rect" and "XML", but usually every project is unique and different, and has its own needs. Furthermore, the goal of reusability can be achieved pretty well just by creating libraries, even if they're not OOP. It is true, however, that reusability of Objects within a program is a major benefit over procedural programs. If you have a game with a ton of animated Sprites flying around, it's a very natural thing to make each a self-contained object.
Robustness and Reliability are both potential beneftis of OOP, but I would say they do not come for free, and have more to do with good planning and code design than with a particular programming paradigm.
Extensibility mainly refers to inheritance, which allows you to create subclasses that share the same functionality as parent classes. Unfortunately, inheritance can easily get out of hand and create massive, confusing hierarchies of Objects. In most cases, containment is the safer way to go. (The only time to use inheritance is when there is a true equality between two things. Thus, a Person may be considered a type of Animal, but Waiter is not a type of Person. Waiter extends Job, not erson.)
Finally, we have Maintainability, which is the most immediate benefit you are likely to experience if you follow good Object Oriented Practices. To get this benefit, it's not enough that you use objects, you must be strict about encapsulating all your data, and enforcing very strict limitations on how objects communicate back and forth. If you do this, you will find that your programs are significantly less buggy, and easier to modify as they become large, for the simple reason that every line of code has a specific place it must go where it makes the most sense -- an association with a particular Object.
Now, if you don't think about encapsulating your data, you're liable to have a mess on your hands, with numerous objects talking back and forth in an ad hoc manner. And you'll have twice as many lines of code as you would have had in a procedural program. I'm sure this experience has led many to start bashing OOP. But I've found that once you get into the habit of making each Object self-contained, it becomes easier. And before long, the magic starts to happen! If an artist asks you to make fundamental changes to an animation routine, you know that you can safely change your Animation Class, and you don't have to worry too much about breaking other parts of the application, potentially saving you tons of regression testing.
Procedural (non-OOP) programs can also be written in a modular way, as collections of functions, but there is a great tempatation to cut corners when doing so. That's when you get into trouble. All the rules of OOP may be tiresome, but they are there to help keep your code manageable. Certainly for shorter programs, there is a case to be made against OOP, and the additional overhead it entails. But for next big application, avoid it at your own risk!
Rather than join in the chorus for or against, I simply wish to make a single point as to why OOP is extremely useful for building large-scale applications. Traditionally, the main benefits of OOP are claimed to be Reusability, Reliability, Robustness, Extensibility and Maintainability. From my experience, the only one that matters most of the time is Maintainability.
Let's face it: when you start a new project, it's unlikely that you're going to reuse large portains of old code. Okay, you might reuse some basic classes like "Rect" and "XML", but usually every project is unique and different, and has its own needs. Furthermore, the goal of reusability can be achieved pretty well just by creating libraries, even if they're not OOP. It is true, however, that reusability of Objects within a program is a major benefit over procedural programs. If you have a game with a ton of animated Sprites flying around, it's a very natural thing to make each a self-contained object.
Robustness and Reliability are both potential beneftis of OOP, but I would say they do not come for free, and have more to do with good planning and code design than with a particular programming paradigm.
Extensibility mainly refers to inheritance, which allows you to create subclasses that share the same functionality as parent classes. Unfortunately, inheritance can easily get out of hand and create massive, confusing hierarchies of Objects. In most cases, containment is the safer way to go. (The only time to use inheritance is when there is a true equality between two things. Thus, a Person may be considered a type of Animal, but Waiter is not a type of Person. Waiter extends Job, not erson.)
Finally, we have Maintainability, which is the most immediate benefit you are likely to experience if you follow good Object Oriented Practices. To get this benefit, it's not enough that you use objects, you must be strict about encapsulating all your data, and enforcing very strict limitations on how objects communicate back and forth. If you do this, you will find that your programs are significantly less buggy, and easier to modify as they become large, for the simple reason that every line of code has a specific place it must go where it makes the most sense -- an association with a particular Object.
Now, if you don't think about encapsulating your data, you're liable to have a mess on your hands, with numerous objects talking back and forth in an ad hoc manner. And you'll have twice as many lines of code as you would have had in a procedural program. I'm sure this experience has led many to start bashing OOP. But I've found that once you get into the habit of making each Object self-contained, it becomes easier. And before long, the magic starts to happen! If an artist asks you to make fundamental changes to an animation routine, you know that you can safely change your Animation Class, and you don't have to worry too much about breaking other parts of the application, potentially saving you tons of regression testing.
Procedural (non-OOP) programs can also be written in a modular way, as collections of functions, but there is a great tempatation to cut corners when doing so. That's when you get into trouble. All the rules of OOP may be tiresome, but they are there to help keep your code manageable. Certainly for shorter programs, there is a case to be made against OOP, and the additional overhead it entails. But for next big application, avoid it at your own risk!
posted by adampasz at
7:00 AM
|
18 comments
