Rethinking Object‑Oriented Programming: From Myth to Practical Understanding

Ten years ago, object‑oriented programming (OOP) was hailed as the ultimate solution, but after a decade the author still finds it clouded by myth and misuse. The author believes the main reason is that OOP has been overly glorified, turning it into a dogma rather than a pragmatic technique.

When teaching OOP, the author suggests starting from what students already know: functions. In a project of 100,000 lines of code, roughly 2,000 functions would exist. Grouping related functions into classes (e.g., Blog.Publish() , Comment.Publish() ) makes the code more organized and reduces naming conflicts.

The core purpose of OOP—and all enterprise‑level software design—is to lower system complexity for human developers, not to increase it. Classification of functions into classes, and later grouping classes via inheritance and polymorphism, should serve this goal.

However, many developers jump straight to high‑level concepts like inheritance, polymorphism, and design patterns without a solid grasp of the basic idea of classifying functions. This leads to “abuse” of inheritance and patterns, making the code more tangled.

The author uses the metaphor of a machine gun versus a pistol to illustrate that OOP tools are not universally superior; each has its appropriate use case. Over‑reliance on OOP can result in “god objects” that try to do everything, which defeats the purpose of classification.

Through a concrete example of a User class and a Blog class, the author shows the dilemma of where to place the Publish method. While a naïve “everything is an object” mindset would put it in User.Publish(Blog) , experienced developers recognize that the method belongs to the Blog entity ( Blog.Publish() ), because the operation is conceptually about the blog itself.

In summary, OOP and related software engineering practices aim to simplify problems for human brains, not to make the computer’s job harder. The principles to remember are: reduce complexity, keep the focus on solving real problems, and avoid using OOP as a mere showcase of technical prowess.