O.O.P: Pleasant by Nature
In the early days of programming, all we had was procedural programming. Our applications would contain hundreds of functions one after another, listed line-by-line-by line. Constantly, developers would have to repeat themselves by calling similar functions with similar logic in multiple location so of the application. The functions would relate to each other sometimes too, further complicating what each function was try to perform as applications grew.
OOP was introduced to solve this problem. It combines like features and classes into units, or objects. Variables are referred to as properties and functions as methods.
Example: A car has properties such as a make, model and color, with methods available such as
The 4 Pillars of O.O.P
Each object keeps its state private, inside a class. Other objects don’t have direct access to the state, can only call on it from a list of public functions (methods). Also
Example: If a cat is hungry we can feed a cat with the
feed()method, but can’t directly change how hungry the cat is with decreasing the hunger property directly on the cat.
Extension of encapsulation. Because programs and codebases are complex and grow overtime, each object should only expose a high-level mechanism for using it.
Example: Your iPhone has a home button, which you know how to use all the time. Not critical to understand what the home button does under the hood. A software update wouldn’t change how you use the home button.
While large code bases grow, many objects and classes share like features. You can create a child class by deriving from another parent class, forming a hierarchy.
Example: If we need to build a program that manages a school, can create a teacher class, and then two teacher classes (regular vs. subs), while also maintaining a separate student class, which all derive their logic from “Person”.
While parents and their children are different classes, they sometimes require like methods that can be used on both of the classes while still keeping them separate.
Example: A triangle, circle and rectangle are children of “Figure”, which has access to
OOP vs. Functional Programming
Aside from procedural programming which we first looked at above, developers also have functional programming available to them separate from OOP. At the heart of functional programming, is the principle that each function should only do one particular, specific, small task for the application. It attempts to allow for very clean, readable, reliable code. Each function can be easily invoked anywhere in the application, and functions can be reused and recycle to avoid repetition of code throughout the base. In contrast, OOP uses objects to represent like features as opposed to standalone functions.
Say we wanted to create a program which would analyze the score of a basketball game.
In OOP, we would:
- Create a Game class would would be initialized with a team and players as its children, with the players having properties of points scored, rebounds, assists, steals, etc.
- We would create instances of the players
- Invoke a method of
pointsScored()to assign points to a player.
In a Functional Program, we would:
- Create a players array, which is an array of a hash of their team and game played.
- Create a
pointsScored()method which returns the player name and the amount of points they scored in that game.
- To add points to the player if they scored a basket, we could create a new method, called
addPoints(),which maps through the players array and assigns the points to that player.
- We could invoke both methods,
addPoints()to return a new dataset: final_game.
OOP proponents would argue its paradigm does a better job making code re-useable through inheritance, and encapsulations helps managing and manipulating the dataset. Function programming developers would argue that keeping methods and datasets separated leave less room for bugs and errors. Each of the paradigms have their own use cases, but ultimately, it’s up to the dev team which structure they prefer to develop their application in.