[转帖]A summary of OO Principles


Introduction

OO Design is more than just using an OO language. Over the years many bright programmers have built up a collection of rules that help to build well designed maintainable code. This article lists the main rules of OO programming. The intention is to inspire the reader to think about these rules and make further reading. There is a lot of material on the web that drills down into more details with plenty of examples. 

Ivar Jacabson said ”All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version”. In other words software requirements change with time. The goal of Object Orientated Design is to program in such a way that such changes to the software are predictable and do not make a large impact in the program. In other words it should be stable in the presence of change 

Bad design is characterized by 

A single change affects many other parts of the system (Rigidity) 
A single change affects unexpected parts of the system (Fragility) 
It is hard to reuse in another application (Immobility) 
The Dependency Inversion Principle DIP(依赖倒置原则)

Imagine you have a simple database program. You don’t want to change the entire application when changing the database. This principle is targeted at removing such unwanted interdependency that can cause a design to be fragile. The rule states

High level modules should not depend upon low level modules. Both should depend upon abstractions 
Abstractions should not depend upon details. Details should depend upon abstractions 
Booch said “All well structured object orientated architectures have clearly-defined layers with each layer providing some coherent set of services through a well defined and controlled interface.”

In other words design applications in layers where high level layers call lower level layers using Abstract interfaces. To conform to the principle of dependency inversion, we must isolate abstraction from the details of the problem. Then we must direct the dependencies of the design upon the abstractions.

Good dependencies are extremely unlikely to change. In other words they are stable. We would like to base our architectural design around stable, non-volatile modules.

The Open-Close Principle OCP(开闭原则)

Software entities (Classes, Modules, functions etc) should be open for extension, but closed for modification

In other words design classes that never change. When a new requirements come add new code and don’t edit existing code. It is not possible to close against all possible changes. Therefore an experienced developer needs to understand the possible future wishes of users in order to make Strategic Closure. There are two ways of closure:

Using Abstraction to gain explicit closure - This means the programmer applies abstraction to those parts of the programmer the designer feels are subject to change. 
Using Data Driven Approach to achieve closure 
Liskov Substitution Principle LSP (李氏代换原则)

Every function that operates upon a reference or pointer to a base class should be able to operate on derivatives of that base class without knowing it. This means that virtual member functions of the derived class must expect only all the corresponding member functions of the base class. In other words any function that uses a base class must not be confused when a derived class is substituted for the base class

This is a difficult principle to apply. To conform avoid overwriting base class functions because this involves programming with details, instead try to program in abstractions

If this is violated then functions that operate on the pointers must first check the type of the actual object in order to work correctly.

Heuristics and Conventions

Make all member variables Private: Otherwise no function that calls the class can be closed to change. For example a status variable can change from Boolean to an enumeration, if this is not handled as a property then we cannot close status. This is called encapsulation.

No Global Variables. Because misbehaving modules may write erroneous data to such global variables whose effect can be felt in many places throughout the program. Sometimes Global variables are useful e.g. cout and cin in c++. If they do not violate the open close principle then sometimes they are worth the style violation

Stability Dependencies Principle SDP(稳定依赖原则)

The dependencies between packages in a design should be in the direction of stability of the packages. A package should only depend upon packages that are more stable than it is.

Some volatility is necessary if the design is to be maintained. This is achieved by using the Common Closure Principle, in this way we design packages to be volatile and we expect them to change. Any package that we expect to be volatile should not be depended upon by a package that is difficult to change.

Some things we don’t want to change. For example architectural decisions should be stable and not at all volatile. Therefore classes that encapsulate the high level design should be stable.

The stable Abstractions Principle SAP(稳定抽象原则)

Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to it's stability

Common Reuse Principle CRP(共同通用原则)

If you reuse one class of a package, you reuse them all. This because any package delivered contains a released set of classes, therefore a change in any class means a new release of the entire package.

The Reuse / Release Equivalence Principle REP(重用发布等价原则)

The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This principle is important when there are several teams working on an application. To avoid one team disrupting another all packages used are tested and released. In this way the introduction of modified packages is in a controlled way.

The Common Closure Principle CCP(共同封闭原则)

The classes in a package should be closed together against the same kinds of changes. Any change in a package affects all classes in the package. Just like a well organized team has a common goal because they all have to work together. This principle means that you should have a common strategic closure concept used through all classes in a package because they have to be released all together.

The stability Dependencies Principle SDP(稳定依赖原则)

The dependencies between packages in a design should be in the direction of stability of the packages. A package should only depend upon packages that are more stable than it is. 

Designs that are highly interdependent tend to be rigid, not reusable and hard to maintain

The Acyclic Dependencies Principle (ADP) (吴环依赖原则)

The dependency structure between package must be a Direct Acyclic Graph (DAG). This means that if you plot out all packages it should be possible to arrange the dependencies to always point from top to bottom. Also it should not be possible to follow any lines of dependence and end up back at the same package. Because such packages would have to be released all at the same time defeating the object of having them as separate packages

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

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

This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions. Each groups servers a different set of clients. Separation can be achieved by:

Separation through Delegation 
Separation through multiple inheritance 
If this principle is violated then there is a coupling between all clients 

Polyad vs Monad

Monad is when properties are grouped into 1 single object that is then passed in a function parameter. Unfortunately this brings a dependency across all properties in that single object. Therefore its better to pass smaller objects (Polyad), in this way the dependencies are broken into smaller groups.

Interface Pollution

As we build up classes there is a tendency for us to add functionality that is specific for a particular implementation. In this way the interface gets populated by functions and properties that are not required if the class was in a different context, thus making the interface fat. In this way this violates the Liskov Substitution principle. Separate Clients means separate interfaces

There is a backward force applied by clients upon interfaces. For example a user may wish to add a trivial extra function that cannot be exactly positioned in existing interfaces. 
资源下载链接为: https://pan.quark.cn/s/fe886b97b3d0 “CSDN-中文IT社区-600万.rar” 这个文件名称表明它与CSDN(中国软件开发者网络)有关,且包含600万份资源。CSDN作为中国最大的IT技术交流平台,覆盖了编程语言、软件开发、网络安全、大数据、云计算等多个领域的知识和资讯。该压缩包可能包含用户数据、文章、讨论话题或学习资料等。其内容可能极为丰富,涵盖大量用户生成内容,如博客文章、论坛帖子、问答记录等,对于研究IT行业趋势、开发者行为和技术热点等具有重要价值。尽管目前没有具体内容,但推测可能涉及“编程”“开发”“社区数据”“技术文章”“学习资源”等标签。 从文件名称来看,压缩包的内容可能包括以下几类:一是用户数据,如注册信息、活动记录、帖子和评论等,可用于分析用户行为和社区活跃度;二是技术文章和博客,涵盖众多技术专家分享的教程、解决方案和经验;三是源代码和项目,供其他开发者学习参考;四是论坛讨论,反映开发者关注的技术问题和热点;五是资源下载,如教程素材、工具软件、开发库等;六是会议和活动记录,包括报告、演讲稿和视频;七是学习路径和课程,帮助开发者提升技能;八是排行榜和奖项,体现社区的认可度和影响力。 “CSDN-中文IT社区-600万.rar” 压缩包可能是一个极具价值的IT知识宝库,涵盖从基础编程到高级技术实践的广泛主题,反映了中国IT社区的发展动态。对于IT从业者、研究人员以及编程爱好者来说,它是一个极具价值的学习和研究资源,能够帮助人们洞察开发者需求、技术趋势和社区变化。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值