简介
设计模式是一种最佳实践,是长期起来总结的解决一系列问题的一种套路。
一般针对面向对象语言而言,从大型软件架构出发,便于升级和维护的软件设计思想,强调降低依赖耦合
目的:代码重用和工程化
类型
创建型:创建对象的同时隐藏创建的业务逻辑
工厂模式、单例模式、建造者模式、原型模式
结构型:将现有的类和对象组织在一起形成更强大的功能结构
适配器模式、桥接模式、过滤器模式、组合模式、装饰器模式、外观模式、享元模式、代理模式
行为型:主要关注对象之间的通信
观察者模式、责任链模式、命令模式、解释器模式、中介模式、备忘录模式、状态模式
空对象模式、策略模式、模板模式、访问者模式
J2EE模式(因为Sun公司定的):主要关注表示层
MVC模式、拦截过滤器
七大原则
一、里氏替换:任何父类出现的地方子类都一定可以出现
防止继承泛滥
子类可以添加自有的方法,但是用父类接收时,是不能用子类特有方法或者特有成员的。
如果子类拥有和父类一样的属性或者方法或者其他非私有成员,此时会隐藏父类相同的非私有成员。
但是具体用的是父类的非私有成员还是子类的非私有成员,主要看声明的类型
如果需要解除这个限制,需要父类非私有成员声明为virtual,子类需要override
要求:
子类方法输入参数不能比父类更严格,返回值不能比父类宽松
二、依赖倒置原则:依赖于抽象而不依赖于具体。
是开闭原则的基础。面向接口编程,有利于代码的升级和扩展
三、开闭原则:对扩展开放,对修改关闭
在原程序需要扩展的时候,不能去修改原有的代码。降低维护带来的风险
四、单一职责原则:对象不应该承担太多职责
便于理解,提高代码的可读性
如果一个对象承担太多职责,则会引发:
1.类中的一个方法的改变可能会影响到这个类中的其他方法,从而导致这个类的不稳定。
2.对象需要某个方法时,不得不将其他不需要的方法一并包含进来
操作:把一个大类,按照领域或者业务拆分成小类
五、接口隔离原则 接口最小化,类最大化
多个接口比单个接口好,系统为了追求稳定应该依赖于其足够使用的最小接口,而不应该依赖于其他不需要的接口。
也可以降低类之间的耦合度
六、迪米特原则(最少知道原则)
降低耦合
一个实体应当尽量少的与其他实体之间发生相互作用,使系统的模块能够相互独立
七、合成复用原则:尽量使用合成和聚合,而不是使用继承
降低耦合
依赖:例如我们需要玩手机,于是我们对手机产生了依赖关系。依赖关系是四种关系中耦合度最小的。被依赖的类,一般在依赖类中会以返回值、形参、局部变量等方式出现。画图时一般以虚线箭头表示
关联:学生与老师,学生可以不玩手机,但是不能没有老师,没有老师,也没有所谓的学生。关联暗示依赖,但是耦合关系最强。可分为单向关联、双向关联、自身关联、多维关联
组合:主要是集体和个体之间的关系,如公司和员工
聚合:个体与组成部分的关系,如汽车和轮胎
接口的意义
1.接口可以规范和约束我们的类型,一旦在接口定义了未实现的方法声明,其实现的接口子类就必须实现该接口声明的未实现方法
2.用于项目之间的契约和层间的对接
3.在.net6的接口中,是可以写方法实现的(和c++一样实现了多继承),如果多个接口有同样的方法实现,那么哪个接口接收这个类的对象,就调用了哪个接口的方法。如果子类重写了该方法,一律调用的是子类重写的方法。
1.本站内容仅供参考,不作为任何法律依据。用户在使用本站内容时,应自行判断其真实性、准确性和完整性,并承担相应风险。
2.本站部分内容来源于互联网,仅用于交流学习研究知识,若侵犯了您的合法权益,请及时邮件或站内私信与本站联系,我们将尽快予以处理。
3.本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
4.根据《计算机软件保护条例》第十七条规定“为了学习和研究软件内含的设计思想和原理,通过安装、显示、传输或者存储软件等方式使用软件的,可以不经软件著作权人许可,不向其支付报酬。”您需知晓本站所有内容资源均来源于网络,仅供用户交流学习与研究使用,版权归属原版权方所有,版权争议与本站无关,用户本人下载后不能用作商业或非法用途,需在24个小时之内从您的电脑中彻底删除上述内容,否则后果均由用户承担责任;如果您访问和下载此文件,表示您同意只将此文件用于参考、学习而非其他用途,否则一切后果请您自行承担,如果您喜欢该程序,请支持正版软件,购买注册,得到更好的正版服务。
5.本站是非经营性个人站点,所有软件信息均来自网络,所有资源仅供学习参考研究目的,并不贩卖软件,不存在任何商业目的及用途
暂无评论内容