designed principle

Review Of designed Pattern principle

OutLine:

Explanation in principles of designed pattern and useful designed pattern’s samples, As we known, there are six principles at designing program, no matter what kind of object-oriented programing language. They are Single responsibility principle, Open and Close principle, Dependency inversion principle, Interface segregation principle, Liskov’s substitution principle. Of course, not all of them need to be implemented at the same time wherever reality environment is.

Principles

Open and close principle

Summary:

Software entities (software, modules, functions, or classes) should be open to extension and closed to modification.

How to get understanding of the key principle at software design? Essentially, we can remember that if a module  is available for extension, it will be likely to add new data fields  to it’s data structure, and it should be also easy to plus  new items into the set of function this module contains. Because of that, some modification at proper context is allowed. But, on the other hand, almost all of software are fairly difficult to get known all aspects without a long period of look at every classes, these classes composite the extremely complicated relative composition, for a good software program which is outstanding and excellent at framework’s architecture. The code is assigned and divided into many hierarchies by the logic.

Dependency inversion principle

Summary:

2       following statements below can summarize it:

Firstly, High level module should not depend on low level module, both them should lean on abstraction.

Secondly, Abstraction should not depend on details, details should depend on abstraction.

Abstract code defines the main functionalities their inheritance or concrete module can do and not do, but abstraction couldn’t create new instances which have single responsibility in details. Actually, in the program’s proceeding they are not executed and transferred to their inheritance. Because of the stability of abstractions and fragility of details, if high level and low level module both lean on the abstraction. Whatever and whenever they change, they are also quite easy to have ability to interact with each other very well, since the abstractions they communicate with are unchangeable only! But for the principle, if we want to change the final result of detail. We just initializes and holds a different reference which are both defined with one kind of abstraction. As the result, behaviors will differ from each other.

IOC:

So, what if we can decouple software module from their direct references of relative module. What will happen? That the main cause of why ioc is called ioc. An external module controlling the dependencies will inject the reference to the module that need dependencies. The specialized framework for that is known as inversion of control container.

Single Responsibility Principle

Summary: a class should have only one reason to change

Description: this principle states that if we have two reasons to change a class, that means we have to split the functionality in two classes; each class will handle only one responsibility and on future if we need to make a change we are going to make it in the class which handle it. But if not, when we need to make a change in a class having more responsibilities the change might affect the other functionalities of classes;

Interface segregation principle

Summary:

Clients should not be forced to depend upon some interfaces they don’t use.

This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?

Liskov’s substitution principle

Summary:

Derived class should be completely substitutable for their base classes.

This principle is just an extension of the Open Close Principle in terms of behavior. We must make sure that new derived classes are extending the base classes without changing their behavior.

Least knowledge principle

Summary

Just talk with your friends

Advantages:

Reduce the dependencies between objects and reduce software maintenance

Disadvantages:

Result in more "wrapper" classes being written to handle method calls to other components.

This can result in increased complexity and development time as well as decreased runtime performance.

To conclude:

Software design principles represent a set of guidelines that help us avoid having a bad design. But when to determine which design pattern or patterns, we should choose the most suitable patterns corresponding to the different environments. So that will result in some of shortage and disadvantages which don’t follow all principles. But if the final software frameworks can avoid the rigidity, the fragility, the immobility, those defective points could be accepted on programmer even if it is not perfect absolutely.

时间: 2024-08-06 03:33:21

designed principle的相关文章

Neumann's Principle and Curie laws

Neumann's Principle Neumann's principle, or principle of symmetry, states that, if a crystal is invariant with respect to certain symmetry elements, any of its physical properties must also be invariant with respect to the same symmetry elements, or

Linux Kernel Module(LKM) Init、Delete Code Principle Learning

目录 1. Linux模块(LKM)简介 2. 使用Linux模块 3. LKM模块加载原理 4. LKM模块卸载原理 1. Linux模块(LKM)简介 模块是一种向linux内核添加"设备驱动程序"."文件系统"."其他组件"的有效方法,而无须重新编译内核或重启系统,这消除了许多限制,同时带来了很多的优点 1. 通过使用模块,内核程序员能够预先编译大量驱动程序,而不会致使内核映像的尺寸发生膨胀.在自动检测硬件或用户提示后,安装例程会选择适当的

Linux /proc、/dev Principle Learning

目录 1. /proc简介 2. 内核机制相关 3. 进程信息 4. 硬件设备相关 5. 系统信息 6. /dev简介 1. /proc简介 在linux的根目录下有一个/proc目录,/proc文件系统是一个虚拟文件系统,通过它可以使用一种新的方法在Linux内核空间和用户空间之间进行通信.在/proc文件系统中,我们可以将对虚拟文件的读写作为与内核中实体进行通信的一种手段,但是与普通文件不同的是,这些虚拟文件的内容都是动态创建的(即在我们执行指令的那一刹那才产生的) /proc文件系统包含了

C#设计模式系列:单一职责原则(Single Responsibility Principle)

1.单一职责原则的核心思想 一个类应该有且只有一个变化的原因. 2.为什么要引入单一职责原则 单一职责原则将不同的职责分离到单独的类,每一个职责都是一个变化的中心.当需求变化时,这个变化将通过更改职责相关的类来体现.如果一个类拥有多于一个的职责,则这些职责就耦合到在了一起,那么就会有多于一个原因来导致这个类的变化.对于某一职责的更改可能会损害类满足其他耦合职责的能力.这样职责的耦合会导致设计的脆弱,以至于当职责发生更改时产生无法预期的破坏. 3.单一职责原则的优点 1>.可以降低类的复杂度,一个

里氏替换原则(Liskov Substitution Principle)

开放封闭原则(Open Closed Principle)是构建可维护性和可重用性代码的基础.它强调设计良好的代码可以不通过修改而扩展,新的功能通过添加新的代码来实现,而不需要更改已有的可工作的代码.抽象(Abstraction)和多态(Polymorphism)是实现这一原则的主要机制,而继承(Inheritance)则是实现抽象和多态的主要方法. 那么是什么设计规则在保证对继承的使用呢?优秀的继承层级设计都有哪些特征呢?是什么在诱使我们构建了不符合开放封闭原则的层级结构呢?这些就是本篇文章将

接口隔离原则(Interface Segregation Principle)ISP

using System; using System.Collections.Generic; using System.Text; namespace InterfaceSegregationPrinciple { //接口隔离原则(Interface Segregation Principle)ISP //Clients should not be forced to depend upon interfaces that they don's use.(客户端不应该依赖它不需要的接口) /

里氏替换原则(Liskov Substitution Principle) LSP

using System; using System.Collections.Generic; using System.Text; namespace LiskovSubstitutionPrinciple { //里氏替换原则(Liskov Substitution Principle) LSP //If for each object o1 of type S there is an object o2 of type T such that for all programs P defi

设计模式六大原则(2):里氏替换原则(Liskov Substitution Principle)

肯定有不少人跟我刚看到这项原则的时候一样,对这个原则的名字充满疑惑.其实原因就是这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的. 定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型. 定义2:所有引用基类的地方必须能透明地使用其子类的对象. 问题由来:有一功能P1,由类A完成.现需

设计模式六大原则(4):接口隔离原则(Interface Segregation Principle)

接口隔离原则: 使用多个专门的接口比使用单一的总接口要好. 一个类对另外一个类的依赖性应当是建立在最小的接口上的. 一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染. "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法,那么这些客户就会面临由于这些不使用的方法的改变所带来的改变. 定义: