今日推荐英文原文：《Simplicity and Complexity Needn’t Be Mutually Exclusive In Your Code》
推荐理由：打开 A 应用的时候，经常会被推送符合自己喜好的 B 应用的广告。我们的足迹和信息分布在各个网站中并被记录，那为何不将它们收集起来为自己所用呢？这就是该项目的功能，旨在安全快捷的帮助用户拿回自己的数据。
今日推荐英文原文：《Simplicity and Complexity Needn’t Be Mutually Exclusive In Your Code》作者：Nick Hodges
Simplicity and Complexity Needn’t Be Mutually Exclusive In Your Code
Your code is only as complex as you make it
Good AdviceThe 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 PrincipleThe 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.
ThunderstruckI 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 SingerThis 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
SprocketEngineclass 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 WatchIn 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.