2017-10-10 13:38:12 】 瀏覽:10420

     最近有人問我 系統設計的原則,事實上不論今天各個技術棧怎么演化优乐棋牌app下载,那些本質的原則與方法不會變, 讓我們回顧一下 這些原則:

?分散關注 Separation of concerns. Divide your application into distinct features with as little overlap in functionality as possible. The important factor is minimization of interaction points to achieve high cohesion and low coupling. However, separating functionality at the wrong boundaries can result in high coupling and complexity between features even though the contained functionality within a feature does not significantly overlap. 不同領域的功能优乐棋牌app下载,應該由不同的代碼和最小重迭的模塊組成。

?單一職責优乐棋牌app下载,功能高內聚 Single Responsibility principle. Each component or module should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality.

?一個模塊不需要知道另一個模塊的內部細節 Principle of Least Knowledge (also known as the Law of Demeter or LoD). A component or object should not know about internal details of other components or objects.

?Don’t repeat yourself (DRY). You should only need to specify intent in one place. For example, in terms of application design, specific functionality should be implemented in only one component; the functionality should not be duplicated in any other component.

?不要過分設計過多模塊 Minimize upfront design. Only design what is necessary. In some cases, you may require upfront comprehensive design and testing if the cost of development or a failure in the design is very high. In other cases, especially for agile development, you can avoid big design upfront (BDUF). If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. This principle is sometimes known as YAGNI ("You ain’t gonna need it").


軟件設計 中 SOLID原則

    The Single Responsibility Principle

    There should never be more than one reason for a class to change. Basically, this means that your classes should exist for one purpose only. Responsibility is the heart of this principle, so to rephrase there should never be more than one responsibility per class.

    The Open Closed Principle

    Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. At first, this seems to be contradictory: how can you make an object behave differently without modifying it? The answer: by using abstractions, or by placing behavior(responsibility) in derivative classes. In other words, by creating base classes with override-able functions, we are able to create new classes that do the same thing differently without changing the base functionality. Further, if properties of the abstracted class need to be compared or organized together, another abstraction should handle this. This is the basis of the "keep all object variables private" argument.

    The Liskov Substitution Principle

    Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. In other words, if you are calling a method defined at a base class upon an abstracted class, the function must be implemented properly on the subtype class. Or, "when using an object through its base class interface, [the] derived object must not expect such users to obey preconditions that are stronger than those required by the base class."Turns out a square is not a rectangle, at least behavior-wise.

    The Interface Segregation Principle

    Clients should not be forced to depend upon interfaces that they do not use. My favorite version of this is written as &q


首頁 上一頁 1 2 3 4 5 下一頁 尾頁 1/5/5
】【打印繁體】【】【】 【】【】【】 【關閉】 【返回頂部
上一篇docker~學習筆記索引 下一篇autofac初識