In Need of Object Orientation
My career as a professional Software Engineer started just a year and a half ago but for what I’ve read and seen so far, the industry is in need of some true Object orientation. Don’t get me wrong, procedural programming, functional programming and other paradigms have their strengths and they should be used when their advantages can be leveraged, but most of the industry has been adopting OOP as their main paradigm with languages such as Java, C++, Objective-C, C#, Ruby and Python. The problem is that OOP is not used to it’s full potential and we can still see procedural programming all over the place.
Objects have been around in the programming world since the 60’s, Smalltalk the first real Object Oriented Programming language was released in 1980, the Design Patterns book from the Gang of Four was released in 1994, and we still don’t know how to use objects properly.
One of the main give aways of this problem are god classes and long methods. These two are hard to read, hard to understand, hard to maintain and hard to debug. Most probably it means that you have duplicate functionality in your code. I’m sure there are a few classes hidden inside the god class which can be reused elsewhere in your program. I’m also sure that the methods have plenty of code paths in result of excessive use of ‘if’ and ‘switch’ statements which could be broken down into smaller methods or replaced by introducing new classes (switch statement = polymorphism).
The problem is not only with having procedural code in your object oriented code, but also not applying some of the most fundamental concepts of Object Oriented Programming such as Abstraction, Encapsulation, Decoupling and Polymorphism. Simply by using abstract classed, interfaces and some inheritance with careful design you can apply all of these concepts to your code. Why should a User object need to know how to login? Let the login system take care of that. Why should the Book object communicate with the database to retrieve it’s information? Let the data provider take care of that. We’re mostly just placing the functionality in the wrong place, exposing too much of the internal structure, and making our objects depend too much on each other. Sure your code can compile and work but… Can it be unit tested? How much effort would it take to change database servers? How much effort would it take to add x functionality? How easy would a developer new to the code be able to understand it, fix bugs, and add features?
On the world of Software Engineering there is much talk of finding a silver bullet which will solve all of our problems. I’m sure there is no single silver bullet but we can surely apply a range of practices which will help make software more reliable and maintainable. In my opinion Object Oriented Programming provides many tools which can be used to improve software quality so code can be easily tested, fixed, enhanced and understood. Take advantage of OOP’s concepts, spawn as many objects as you need and let them dance to make your programs come to life.
