開源日報 每天推薦一個 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/