C#面向对象设计原则之组合/聚合复用原则

组合/聚合复用原则（LSP）

定义：优先使用组合，使系统更灵活，其次才考虑继承，达到复用的目的。
重用的方式：
继承、组合、聚合
解释说明：

  • 继承：在我们想复用代码时，我们一般会优先想到继承，但是具有继承关系的两个类是耦合度最高的两个类。（父类改了子类可能会受影响，子类改了父类也可能会受影响）
    如果父类的功能比较稳定，建议使用继承来实现代码复用，因为继承是静态定义的，在运行时无法动态调用。
  • 组合：是整体与部分的关系，整体离不开部分，部分离开了整体没有意义，如飞机翅膀与飞机的关系。
  • 聚合：也是整体与部分的关系，但整体可以分离部分，部分也可以离开整体，如火车与车厢的关系。

组合/聚合：是通过获得其他对象的引用，在运行时刻动态定义的，也就是在一个对象中保存其他对象的属性，这种方式要求对象有良好定义的接口，并且这个接口也不经常发生改变，而且对象只能通过接口来访问，这样我们并不破坏封装性，所以只要类型一致，运行时还可以通过一个对象替换另外一个对象。

示例1：组合

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace 组合聚合复用原则
{
    /// <summary>
    /// 定义一个飞机翅膀类
    /// </summary>
    public class Airfoil
    {
        /// <summary>
        /// 定义方法
        /// </summary>
        public void AdjustAngle()
        {
            Console.WriteLine("调整角度");
        }
    }

    public class Plane
    {
        // 定义一个私有的飞机翅膀类的变量
        private Airfoil airfoil;
        // 省略setter、getter
        public void Fly()
        {
            // 使用组合实现代码的复用
            airfoil.AdjustAngle();
        }
    }
}

上面代码中飞机翅膀和飞机之间使用继承就不太合适，本身也就是组合关系，这样就实现了代码的复用。在平常使用最多的就是在一个对象中声明另外一个对象的变量。

示例2：聚合

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace 组合聚合复用原则
{
    /// <summary>
    /// 定义一个车厢类
    /// </summary>
    public class RailwayCarriage
    {
        public void Loading()
        {
            Console.WriteLine("车厢装载118人");
        }
    }

    /// <summary>
    /// 定义一个火车类
    /// </summary>
    public class Train
    {
        // 定义一个私有的车厢类的变量（在一个类中定义另外一个类的引用）
        private RailwayCarriage rc;
        // 省略setter、getter
        public void Carry()
        {
            // 可以使用车厢，也可以不使用车厢
           if(rc!=null)
           {
               rc.Loading();
           }
           Console.WriteLine("车头装载5人");
        }

        public void Run()
        { }
    }
}

代码下载链接：点此下载

到此这篇关于C#面向对象设计原则之组合/聚合复用原则的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持我们。

赞 (0)

相关推荐

  • 浅谈C#六大设计原则

    笔者作为一个菜鸟,会尝试以简单的代码和容易理解的语句去解释这几种原则的特性和应用场景. 这六种原则分别为单一职责原则.接口隔离原则.里氏替换原则.迪米特法则.依赖倒置原则.开闭原则. 单一职责原则 单一职责原则(SRP:Single responsibility principle),规定一个类中应该只有一个原因引起类的变化. 单一职责原则的核心就是解耦和增强内聚性. 问题: // 假设此类是数据库上下文 public class DatabaseContext { } public class

  • C#面向对象设计原则之接口隔离原则

    接口隔离原则(ISP) 定义:使用多个专门的接口比使用单一的总接口要好.即不要把鸡蛋都放到一个篮子里.好处:比较灵活.方便,不想实现的或不用实现的可以不实现.解释说明:大部分人都喜欢用一个接口把需要用到的方法全部声明出来,但是ISP建议我们使用多个专门的接口比使用单一的总接口要好,也就是一个接口里的方法多的话,实现起来不是很方便. 示例1: using System; using System.Collections.Generic; using System.Linq; using Syste

  • C#面向对象设计原则之单一职责原则

    单一职责原则(SRP) 定义:系统中的每一个类都应该只有一个职责. 好处:高内聚.低耦合. 解释说明: 单一职责也就是说我们应该让一个类或一个对象只做一件事情,每个类所要关注的就是自己要完成的职责是什么,能够引起这个类变化的原因也应该只有一个,这也是后面提到的所有的设计模式都会遵守的一个原则. 高内聚:先按照面向对象的封装特性来理解,封装也就是我们说的,应该把一个类或对象它所有相关的属性.方法.行为放到一起,放到一个类中,这样就实现了一个封装的特性.那么内聚,就是一个类里面应该包含它所有的属性和

  • C#面向对象设计原则之开闭原则

    开闭原则(OCP) 定义:对扩展开发,对修改关闭.好处: 适应性和灵活性. 稳定性和延续性. 可复用性与可维护性. 解释说明:开闭原则指的是两方面:对功能扩展开发,对修改进行关闭:有时当用户要求或需求发生变化时,我们不得不打开原来的代码进行修改,进行功能的扩展或增加,这种设计如果应用到我们以后的项目开发中会导致严重的问题,这样容易导致意外的错误.好的程序,应该保证在我们进行程序扩展时,不会更改以前的代码.如何才能保证这样的效果呢?我们在定义一个类的功能时:最好先定义他的抽象类或接口,这样在功能扩

  • C#实现六大设计原则之接口隔离原则

    C#实现六大设计原则之接口隔离原则

    接口隔离原则(ISP)定义: 客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来: 类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案: 将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: 类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现. 类C依赖接口I中的方法1.方法4.

  • C#面向对象设计原则之里氏替换原则

    里氏替换原则(LSP) 定义:在任何父类出现的地方都可以用它的子类类替换,且不影响功能.解释说明:其实LSP是对开闭原则的一个扩展,在OO思想中,我们知道对象是由一系列的状态和行为组成的,里氏替换原则说的就是在一个继承体系中,对象应该具有共同的外在特性,使用LSP时,如果想让我们的程序达到一个父类出现的地方都可以用它的子类来替换且不影响功能,那么这个父类也应该尽量声明出子类所需要的一些公共的方法,父类被子类替换之后,会比较顺利,那么为什么说它是对开闭原则的一个扩展呢?因为我们在开闭原则中说尽量使

  • C#实现六大设计原则之单一职责原则

    单一职责(SRP)定义: 不要存在多于一个导致类变更的原因,通俗的说,即一个类只负责一项职责. 问题由来: 类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案: 遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. ps: 说到单一职责原则,很多人都会不屑一顾.因为

  • C#实现六大设计原则之依赖倒置原则

    C#实现六大设计原则之依赖倒置原则

    依赖倒置原则(DIP)定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块, 负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案: 将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率. ps: 依赖倒置原则

  • C#实现六大设计原则之迪米特法则

    定义: 一个对象应该对其他对象保持最少的了解. 问题由来: 类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案: 尽量降低类与类之间的耦合. PS: 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚. 无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率. 低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的. 迪米特法则又叫最少知道原则,最早是在1987年由美国Northe

  • C#实现六大设计原则之里氏替换原则

    定义: 1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子型. 2:所有引用基类的地方必须能透明地使用其子类的对象. 问题由来: 有一功能P1,由类A完成.现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成. 新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障. 解决

随机推荐