Introduction

In many cases, basic OOP education focuses on data types, variables, methods, arrays and hashes, and classes. There are plenty of good reasons to start with the basics and to become comfortable with these tools before delving deeper into less navigated, turbulent waters. Indeed, some of the oldest human wisdom praises simplicity. However upon achieving a certain level of comfort with the basics, a programmer should look forward in order to continue growing. Consequently, the basics become building blocks which allow programmers to engage with other, elaborately designed libraries and frameworks. Generally, the better that a person understands the basics of any topic, the easier new and complicated topics will be to understand. Certainly the purpose of this article is not to propose that novice programmers should learn basic skills any less; to the contrary they are an indispensable part of programming.

However, in and of themselves, in their most basic forms, they do not cover all of the situations that software engineers face in the field — err, on the computer screen. So if the basics are so good but they do not provide enough functionality to cover every single design implementation, what pray tell is a coder to do? Its funny you should ask! There are some use cases that demand more flexibility when creating objects, functions, and classes within software applications. In this article, I would like to explore a few of OOPs shortcomings and afterwards provide a broad and basic introduction into some tools that Ruby gives us which augment the default functionality of the most basic building blocks of OOP: Procs, Modules and Mixins.

Let’s explore some of the disadvantages of OOP

Often times Object Oriented Programming is pitched as an ostensible paragon of problem-solving power and engineering might. However, before OOP, there were other paradigms used in the computer science field, such as Procedural or Functional programming, for example. In fact, there may be a set of problems where procedural programming is more efficient for solving than object-oriented programming. So if there are at least two schools of thought about how to program and the mere existence of both of them suggests that they were developed to solve a particular set of problems, it stands to reason that at least some trade offs exist between them, and by extension disadvantages to OOP.

The short comings with OOP are conceptual, stylistic, and architectural. It is no secret that Object Oriented Programming can be confusing and consequently have a steep learning curve. It requires time to get used to how to solve problems from this approach since how objects are created and other details may not seem logical at first. Additionally, object oriented design can be verbose. It astounds me the amount of packages and files and directories that a convention-fitting program needs to have to do relatively simple tasks. Another way to think of this is overhead. Programs will frequently become bigger than we, as programmers, originally intended. Consequently, program efficiency and performance can suffer due to its own size and architecture. Even, inheritance — one of OOPs defining features — has its shortcomings with certain edge cases where a member of a Class family has or lacks certain attributes common to its own hierarchy, but that it shares with another, unrelated class.

Fortunately, there are strategies and features that can be used to reduce the sheer size of the program, reduce the repetition of boilerplate code, and containerize component logic. Sure these details may seem trivial when beginning the never-ending journey that is programming. Even more cynically, these concerns may seem pompous in that they are simply a ruse to show off, using more complex syntax than necessary; all the while hiding clear meaning when a problem could be solved with a little extra work in accessible and clear code. But many lessons can be learned along the time it takes to tread the yellow brick road, if only to unmask a phony wizard in the end.

#programming #oop #proc #modules #ruby