From Procedural to Object Oriented Programming

The leap to Object Oriented Programming from procedural must be made by all aspiring developers. In the words of Stack Overflow user, exclsr, at how-to-teach-object-oriented-programming-to-procedural-programmers, "OOP is one of those things that can take time to 'get', and each person takes their own path to get there." 

When I first started learning about object oriented programming two examples were given in a course on Java for a college major I soon elected to abandon (I'll explain later). Both will sound familiar to anyone whomever that has had such elementary instruction. One, the example of a Vehicle from which can be derived Car, Bus, Airplane, etc. Two, the example of an Animal wherewith the derivations Dog, Cat and so forth are fathomable. The instructor followed the examples with a discussion of the importance in memorizing the definition of certain OOP terminology claiming that all programming interviews will ask about three words in particular. The words were encapsulation, polymorphism and inheritance. One can already imagine employers of large companies like Amazon overseeing this abuse and being monumentally disappointed.

Needless to say, I aced this course and soon thereafter transferred whatever credits I could to Computer Science. I make a huge distinction between learning and memorization. And I don't fancy the idea of going back to school in the future when being a walking dictionary for programming words ceases to fool potential employers.

OOP is fundamentally different from procedural programming in various ways. Neither one implies the presence or lack of data structures, another important topic. One might recall writing C programs for a data structures course and using structs to define nodes for a linked list, graph, binary tree, heap and so on. The difference lies in the use of said data structures. A strictly procedural programmer may have become fairly appreciative of structs to represent a real world object, such as a game board, because of its ability to aggregate all the properties of the real world object. Henceforth, the procedural programmer is responsible for defining a set of functions that act upon the data structure (aligning them into a linked list, defining their parents to form a tree, traversals of said structures, ...). OOP says, might the tree be capable of organizing itself? Shouldn't the linked list simply have a function like
bool contains(Node n)? In C#, a List may be constructed of any type whatever, and the coder deservedly may expect to find all the functions he or she desires to act upon the list.  

Nowadays ideas like what I just mentioned are commonplace in languages such as C# and Java that call themselves object oriented. An aside about the sarcasm in the last sentence: I've heard programmers tout that they 'know' object oriented programming because such and such language is object oriented. Nonetheless, they use the language in the same mundane, procedural way they would any other language.

A second difference between procedural and object oriented programming is described by the potential for domain decomposition. By this, it is meant that the design of a system is thought of less in terms of what happens first, next and last, but what the components of the system are and how they interact with one another. The problem domain for a pharmacy and general store's inventory/sales software might consist of objects such as Item (from which we get PurchasableItem, RentalItem, PharmacyItem), RentalPolicy, POSTerminal, Inventory, etc. The inventory has some kind of collection of Item objects, functions for adding and removing Item objects and so forth. These are the separate components of what constitutes a larger system. They interact with each other in exactly the way we imagine they should. They are capable of being extended parallel with the evolution of users' needs.

To make the leap from procedural to object oriented programming a bit more of a breeze, I suggest the following progression.

• It is ok to start with the silly Vehicle or Animal class, even the popular Shape class (whose derivatives are Rectangle, Circle, and for the bravehearted, the ellipse). Use these to practice with subclasses and to enforce the ideas of inheritance and polymorphism. 
• But unless you are writing some odd vehicular diagramming tool or a taxonomy application, there needs to be some implementation of solutions to real world problems to bring the understanding home. Using OOP in assignments for college courses is a great way to practice. Even writing games using OOP presents a more realistic scenario.
• Look into responsibility driven design. 
• A topic often connected to OOP is object oriented design patterns an principles. Research these. Patterns aren't created. They exist because they work very well and people have come to realize this over time. Principles should be taken as guidelines for good practice. A common object oriented topic is that of coupling and cohesion. Look into these and why we should seek to lower the former and increase the latter. Many of the design principles exist because they help achieve one or the other or both.
• Check out one of the more important offspring of OOP, model-view-controller. Understand why we strive for separation of concerns. 
• Continue your research in this same vein, interspersing practice projects alongside your research. 

You will be more likely to answer any OOP interview question whatever than had you memorized definitions.