开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《个人数据 InfoSpider》
今日推荐英文原文:《Simplicity and Complexity Needn’t Be Mutually Exclusive In Your Code》
开源日报第1032期:《个人数据 InfoSpider》
今日推荐开源项目:《个人数据 InfoSpider》传送门:项目链接
推荐理由:打开 A 应用的时候,经常会被推送符合自己喜好的 B 应用的广告。我们的足迹和信息分布在各个网站中并被记录,那为何不将它们收集起来为自己所用呢?这就是该项目的功能,旨在安全快捷的帮助用户拿回自己的数据。
今日推荐英文原文:《Simplicity and Complexity Needn’t Be Mutually Exclusive In Your Code》作者:Nick Hodges
原文链接:https://medium.com/better-programming/simplicity-and-complexity-neednt-be-mutually-exclusive-in-your-code-cb07154f77db
推荐理由:单一职责原则(SRP)又称单一功能原则,是面向对象五个基本原则(SOLID)之一,它规定一个类应该只有一个发生变化的原因。本文详细阐释了这一原则,一个螺丝钉的功能应当足够简单。

Simplicity and Complexity Needn’t Be Mutually Exclusive In Your Code

Your code is only as complex as you make it

Good Advice

The number one piece of advice I would give to a new software developer is this: “Code against abstractions, not implementations.”

But a close second would be to follow the Single Responsibility Principle.

The Single Responsibility Principle (SRP) is the first of the five SOLID principles of object-oriented programming. It is also probably the most important one. By following it, you can avoid all kinds of mischief, grief, and trouble.

Single Responsibility Principle

The SRP is officially stated as follows:

A class should have only one reason to change.
Now, I’m very unsatisfied with this definition. A class can have all kinds of reasons to change — you might find a better implementation, you might fix a bug, you might even decide that it needs an additional parameter or dependency. These are all good reasons for a class to change.

But what a class should not do is try to do more than one thing. It should have, well, a single responsibility and not take on any more responsibilities.

Thunderstruck

I remember sitting at my desk at work one day and being struck by the utter profundity of this notion:

So much complexity in software comes from trying to make one thing do two things. — Ryan Singer
This quote hit me like a ton of bricks. It’s so true it made my brain hurt.

We’ve all been there — you run across some WidgetManager or SprocketEngine class that does fourteen different things. It all starts when someone decides to add another responsibility to a class. Pretty soon that class becomes a magnet for functionality and before you know it, it’s doing everything and it becomes a God Class.

For the love of Sweet Baby Elvis, don’t do that! Build a new class for the new responsibility.

The beauty of Singer’s words made me think about what complexity is and what simplicity is. I realized that if you don’t want to build a complex system, don’t create any individual thing that’s complex.

A Watch

In one way, a watch is a complex system, but in another way it is not. It consists of individual pieces that are, in themselves, simple: A gear is a simple thing that has one responsibility, same as the Bezel, and the band, and the second hand. Each part is simple.

The complexity, such as it is, exists because the simple parts interact to provide some amazing functionality. Gears turn the hands, the mainspring pushes a single gear which turns other gears, and so on. Each component interacts with just a few other components to create a powerful system. Yet because of the basic interfaces between parts, there is a simplicity to the whole mechanism.

The same can be true of our software. All meaningful or useful software will be complex in function. However, it need not be made up of complex things. Just as a watch can be broken down into its component parts, with each part serving a single purpose, so should your software be made up of the interaction of simple classes.

You should be able to break your software down into individual classes that in and of themselves are not complex. Each class should do a single thing. It is only by interacting with other classes through dependency injection and clean, separated interfaces should complexity appear.

Complexity in our actual code comes, as Singer notes, when the bindings between classes become so tight that any given class is doing too much. Imagine having a pendulum in a grandfather clock that not only swings back and forth to drive the entire engine, but that also is responsible for spinning that little moon phase indicator around. One can’t even conceive of the machinations that would require, but we do this kind of thing in software all the time.

So listen to Ryan Singer. Let the stark profundity of his words wash over you, and never let a class do more than one thing.


下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/