After recently writing an article on Why OOP is Bad, I spent little more time with OOP and… I fell in love with it. Here is how:
I decided to delve a bit into OOP and re-learn its concepts to make sure I’m not missing some of its main benefits. After a day of basic OOP coding I realized I was missing quite a lot.
I realized that a lot of, if not most of, OOP code out there is overcomplicated, confusing, or simply bad. Other times it may be so great it’s too advanced to understand. Thus most of my previous disappointment with object oriented programming was due to looking at complex or even confusing code and feeling its over my head. And not understanding advanced OOP code kept me away from believing that I can learn it.
- Simplicity and clarity.
I started writing my OOP code in such a basic and clear way, with lots of comments, that it doesn’t feel as complex as some advanced OOP out there. It looks similar to my previous static “functions”, except OOP helps me think how to better organize them into logical units, as well as how to better utilize them by “running each function” as an individual entity that doesn’t mess my variables. Overall the functional/procedural programming can still look similar, but with OOP I separate function parameters into reusable OOP properties. Sure this is basic OOP stuff, as long as its kept to basics. Once you complicate it, it may quickly become difficult to understand for others and possibly for yourself.
For these reasons I‘m also avoiding using anything that may even sound too complex in OOP terms, even though I may get to use some advanced OOP features in the future.
- Using OOP as needed.
I love coding as a way of solving problems and achieving my goals, thus it may not matter whether I program procedurally/functionally, or now OOP. By not focusing too much on being purely procedural or purely object-oriented, I have full control over how to use OOP to my advantage and I can use only as much OOP as I desire. Though as result I find myself using more and more OOP principles to achieve my goals. Thus my use of OOP comes naturally, rather than forcing myself to use OOP at all costs.
At the same time I also use static classes (similar to functions/procedures) as needed, without overusing them.
Here are examples of where I’m limiting my use of OOP:
- I have not used accessors (get & set methods), but I’m directly exposing class fields/properties. This also makes me realize how some programmers are just forcefully adding such code everywhere, and possibly overusing other OOP principles, to an extent of trashing their code to the point of utter crap.
- I have not used private fields/properties for a class. I see couple places where I may add it, but not sure yet if I need to.
- I have not used interfaces.
At the same time I’m using some advanced features of the language (ASP.NET Core/C#), being able to do anything I need.
Now I’ve spent full 5 days with OOP and I feel like I have already mastered quite a lot of it, but especially most of what I need for my project. Part of it is thanks to my comfort and expertise of using C# itself, as I can quickly achieve anything I need, whether using OOP or not. The point being that I do what comes to me naturally and knowing OOP helps me use it to my advantage, rather than being a requirement that could turn into an obstacle.
In the end I don’t know yet whether I will become an OOP master, but I know that I love creating great stuff, while discovering that OOP is absolutely awesome when used wisely.