The Case Against OOP is Wildly Overstated

栏目: IT技术 · 发布时间: 3年前

内容简介:Maybe that’s why we’ve suffered through a never-ending series of hot takes about OOP. They’ve described it as a productivity-destroyingdisaster, a set ofWhat all these rants have in common is that they point out (rightfully) some of the pitfalls in modern

After 50 years, we’re still confused about programming’s dominant paradigm

The Case Against OOP is Wildly Overstated

Illustration by Thierry Fousse from Icons8

Y ou can’t rule the development world for decades without attracting some enemies. And object-oriented programming, which provides the conceptual underpinning for dozens of languages old and new, certainly has some enemies.

Maybe that’s why we’ve suffered through a never-ending series of hot takes about OOP. They’ve described it as a productivity-destroyingdisaster, a set of deceitful programming patterns , and amediocre tool designed to help poor programmers hide their incompetence. OOP was even proclaimed dead (14 years ago, so take that one with a grain of salt).

The Case Against OOP is Wildly Overstated

The four pillars of OOP

What all these rants have in common is that they point out (rightfully) some of the pitfalls in modern software design and then conclude (wrongfully) that this indicates a terrible rot at the core of the programming world. Yes, object-oriented programming doesn’t look so great if you conflate it with sloppy design practices and fuzzy architectural thinking. But are these crimes really an unavoidable part of OOP? Or are they just one of the wrong paths we sometimes wander as programming neophytes, armed with too much confidence and too much curiosity?

The Original Sin

The problems start with one brittle assumption made by some OOP supporters and almost all of its critics — that OOP is meant to model the real world . This is the original sin of OOP, a corrosive idea that’s responsible for countless bloated codebases.

Although there’s nothing in OOP theory that requires programming objects to parallel the real world, plenty of well-meaning teachers use this idea to lower the curve of complexity for new students. Here’s an illustration of the problem from Oracle’s official Java documentation :

“Objects are key to understanding object-oriented technology. Look around right now and you’ll find many examples of real-world objects: your dog, your desk, your television set, your bicycle … Software objects are conceptually similar to real-world objects.”

This is not an isolated example. Many introductory texts blur the line between code constructs and real-world objects, by presenting examples with Car and Wheel objects, or hopelessly tied-together groups of Person and Family objects. It’s madness.

This idea also leads to antipatterns, like exploding a database into a fog of linked classes with object-relational mapping .

The Case Against OOP is Wildly Overstated

This sort of design isn’t wrong for everyone. But there are plenty of unhappy people handcuffed to ORM systems, endlessly generating data class boilerplate that’s far less efficient than they want and for more complicated than they need. Did OOP encourage this? Maybe, but the real culprit is the idea-gone-wild that every identifiable thing deserves its own object representation.

Nothing good happens when we forget that our designs should be led by the needs of our code, not the completeness of our object models.

A better description of objects is — like many honest answers — a little vague. It goes something like this:

An object is a programming construct that lets you pack together data and functionality in a somewhat reusable package. Some objects may be structs by another name. Other objects may simply be libraries of related functionality. Deciding how to break down a programming problem into objects is part of the art of OOP.

And, from the always-insightful Eloquent JavaScript :

“The fact that something sounds like an object does not automatically mean that it should be an object in your program. Reflexively writing classes for every concept in your application tends to leave you with a collection of interconnected objects that each have their own internal, changing state. Such programs are often hard to understand and thus easy to break.”

An experienced programmer knows that when choosing between a solution that’s less object-oriented and one that’s more object-oriented, you should pick the simplest approach that meets the needs of your project.

Design is Difficult

If OOP is difficult to do right, that’s at least partly because software design is hard to do right, no matter what tools you use.

In fact, OOP is much less prescriptive in design than many people believe. Object-oriented languages give you a set of tools for using objects (formalizing their interactions with interfaces, extending them with inheritance, and so on). But they don’t say much about how you should apply these objects to a problem. This is a great and deliberate ambiguity.

The gap between theory and practice has fueled the interest indesign patterns. As OOP became more popular, programmers looked to them for help with their achitecture. Unfortunately, design patterns can easily become a way to smuggle in overly complex OOP design under a veneer of respectability.

The Case Against OOP is Wildly Overstated

How do you avoid this trap? Focus on the rock-solid principles of good programming that are cited so often some have turned into acronyms. That includes principles likeDRY (Don’t Repeat Yourself), YAGNI (don’t build it if You Ain’t Gonna Need It), the Law of Demeter (restrict what classes must know about each other), continuous refactoring , and valuing simplicity and readability above all else. Start with these solid principles — a philosophy of coding — and let your design take shape in that environment.

The Expectation Mismatch of Inheritance

Some of the sharpest attacks launched on OOP target inheritance. Critics point out the very real fragile base class problem , where a codebase becomes frozen in time thanks to subtle dependencies between child classes and their parents.

The solution to the fragile base class problem and other inheritance hangovers is surprisingly simple — don’t use it . All the cautionary tales you’ve heard are true.

When inheritance makes sense is in framework design — in other words, as a tool for the people who build the tools that you use. The .NET or Java class libraries would be a far poorer and less organized place without a rigorous inheritance hierarchy tying things together. But creating and maintaining this type of framework is a massive architectural task. It’s not the kind of thing you want to undertake if you’re a fast-moving customer-focused team of agile developers. And here’s a dirty secret — you probably won’t get it right unless you do it wrong a few times first.

The Case Against OOP is Wildly Overstated

First day on the job for an OO programmer

In other words, inheritance is a great feature when you use it indirectly, but rat poison squared when you use it to extend your own classes. And you don’t even need it . If you want a way to reuse functionality, containment and delegation work perfectly well. And if you need to standardize different classes, that’s what interfaces are for.

Which brings us to the real limitations of OOP. It doesn’t prevent you from applying the wrong solution to a problem. It doesn’t prevent you from designing yourself into a cramped corner before a tight deadline and next to a hungry alligator. It gives you set of tools that can be enjoyed or abused. The rest is up to you.

There’s one criticism leveled against OOP that’s probably true. OOP may not be dead, but its moment of total world domination is fading. Functional programming continues to grow alongside OOP (although it’s a fire that’s been very slow in starting). And pure OOP is shifting to make room for so-called multi-paradigm languages like Go and Rust — languages that have a slimmer set of object-oriented features, and avoid some of the traditional OOP baggage. Sometime in the next decade we’ll know these languages have truly arrived, when we see them featured in their own developer take-downs. Until then, enjoy your OOP, and keep your code clean.


以上所述就是小编给大家介绍的《The Case Against OOP is Wildly Overstated》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

电子商务:管理与社交网络视角(原书第7版)

电子商务:管理与社交网络视角(原书第7版)

(美)埃弗雷姆·特班(Efraim Turban)、戴维.金(David King)、李在奎、梁定澎、德博拉·特班(Deborrah Turban) / 时启亮、陈育君、占丽 / 机械工业出版社 / 2014-1-1 / 79.00元

本书对电子学习、电子政务、基于web的供应链、协同商务等专题进行了详细的介绍,全书涵盖丰富的资料以及个案,讨论了Web 2.0环境内的产业结构、竞争变化以及对当今社会的影响。另外,本书在消费者行为、协同商务、网络安全、网络交易及客户管理管理、电子商务策略等内容上都有最新的改编,提供读者最新颖的内容,贴近当代电子商务的现实。 本书适合高等院校电子商务及相关专业的本科生、研究生及MBA学员,也可......一起来看看 《电子商务:管理与社交网络视角(原书第7版)》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具