诸暨网站建设书生商友,做网站怎样上传文件,徐州企业网站模板建站,世界上前端做的最好的网站一#xff0e;面向对象设计的七大原则是什么#xff1f;
1.开放封闭原则
2.里氏转换原则
3.依赖倒转原则
4.组合/聚合原则
5.接口隔离原则
6.“迪米特”法则
7.单一职责原则
二#xff0e;七大原则是什么含义#xff1f; 序号 面向对象设计七大原则 偶的理解 1 …一面向对象设计的七大原则是什么
1.开放封闭原则
2.里氏转换原则
3.依赖倒转原则
4.组合/聚合原则
5.接口隔离原则
6.“迪米特”法则
7.单一职责原则
二七大原则是什么含义 序号 面向对象设计七大原则 偶的理解 1 开放封闭原则 面向扩展开放面向修改关闭 2 里氏转换原则 超类存在的地方子类是可以替换的 3 依赖倒转原则 实现尽量依赖抽象不依赖具体实现 4 组合/聚合原则 要尽量使用合成/聚合达到复用而不是继承关系达到复用的目的。 5 接口隔离原则 应当为客户端提供尽可能小的单独的接口而不是提供大的总的接口 6 “迪米特”法则 又叫最少知识原则一个软件实体应当尽可能少的与其他实体发生相互作用 7 单一职责原则 每一个类应该专注于做一件事情 三解读七大原则
1.开放封闭原则
偶的理解
偶是做底层的设计与编码譬如车载导航系统的引擎的。该引擎系统包括地图数据格式的解析图层添加、修改、删除等地图符号的编辑、显示与润色基于两个地点之间的最短时间/最短距离的路径规划等等功能。 做车载导航系统的应用层的同事不能修改偶核心层代码也就是说您不能修改偶的接口但是您可以针对偶的接口做一些扩展。也就是对接口的修改是封闭但是对接口的扩展是开放。
为什么这样
1.同事修改偶的核心层代码不合适毕竟这些偶是专门整天研究这个的偶专业呀
2.同事为了自己的一己私利修改了接口如添加参数修改了参数数据类型或者去掉某个参数但是基于偶的核心车载导航引擎的不只同事一个人用好多同事与第三方公司都编译不过一堆会找上门来骂你个狗血喷头
3.但是同事将偶的引擎接口扩展了自己用影响不到其他人多好的一件事情
2.里氏转换原则
任何基类可以出现的地方子类一定可以出现。即超类存在的地方子类是可以替换的。替换后行为不变结果会变化。调用子类行为。
子类和父类必须有相同行为才能完全地实现替换。
实现开闭原则的关键是抽象化而里氏代换原则中的基类和子类的继承关系正是抽象化的具体体现所以里氏代换原则是对实现抽象化的具体步骤的规范。违反里氏代换原则
偶的理解
想通过基类的指针调用虚拟函数搞多态让一个函数针对不同的派生类指针会有不同的表现行为。派生类的虚拟函数不能搞特殊。派生类的指针不能赋值给基类哪就胡扯。 里氏代换原则是要求我们在使用继承时必须满足一定的条件。不能为了复用一味去继承。
3.依赖倒转原则
抽象不应该依赖细节。细节应该依赖抽象。
偶的理解
设计接口的时候不应该说俺设计的这一个接口就是给这个某一个具体实现功能而设计。
哪就不叫面向对象设计了抽象了也啥意思。因为你只为某一个具体功能而设计。 但是具体编码实现某一个功能还是要依赖于某一具体的接口的。 注意这是面向对象设计设计什么呢设计接口。接口是一个一对多的关系。一对多啥意思就是一个接口有多种实现。 哦明白了。多态讲的就是这个意思一个接口多种行为方式。挂上钩了。O(∩_∩)O~。
类似活着与吃饭的关系
活着不是为了吃饭但是吃饭为了活着。
4.组合/聚合原则
偶的理解
《设计模式》里23个模式就是整篇整篇地讲如何类与类之间的组合/聚合。 如果为了复用便使用继承的方式将两个不相干的类联系在一起违反里氏代换原则哪是生搬硬套忽略了继承了缺点。 继承的缺点有 1、继承复用破坏数据封装性将基类的实现细节全部暴露给了派生类基类的内部细节常常对派生类是透明的白箱复用。
虽然简单但不安全不能在程序的运行过程中随便改变。 2、基类的实现发生了改变派生类的实现也不得不改变。 3、从基类继承而来的派生类是静态的不可能在运行时间内发生改变因此没有足够的灵活性。
5.接口隔离原则
应当为客户端提供尽可能小的单独接口而不要提供大的总接口。暴露行为让后面的实现类知道的越少越好。
偶的理解
人家需要什么你给人家提供什么。
否则如果接口给人家提供多了暴露多了自己的麻烦不少。人家会问
1.这个接口是干什么的怎么用啊
2.这个接口与另外一个接口有什么区别啊又有什么联系啊什么情况下用这个接口什么情况下用另外一个接口 总之问得你烦死了烦透了。最后没办法只好弄一个版本就是提供客户需要的接口告诉他如何使用一了百了。清闲自在多了。 真是你好我好大家好 一旦某个漂亮的女孩子穿衣服要是暴露多了又露胸又露屁股被人家一阵狂扁“看哪个不要脸的狐狸精”“伤风败俗缺家教”“看又一个暴露狂”。搞的人家MM都要奔溃跳黄河自杀。偶算明白了。技术原理来源于生活。道理都是相通的。O(∩_∩)O~
6.“迪米特”法则
又叫最少知识原则一个对象对另一个对象知道的越少越好即一个软件实体应当尽可能少的与其他实体发生相互作用。 如果两个类不必彼此直接通信那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一方法的话可以通过第三者转发这个调用。
偶的理解
一个类包装好自己的private状态和方法不需要让别的类知道字段或者行为就不要公开哟 强调类之间的松耦合。 类与类之间的耦合性越低一旦一个处于弱耦合的类的代码被修改了不会对有关系的类造成波及与影响。这样这个类的复用性大大增强提高了开发效率降低了出错的可能性。 哥最怕的是修改了某一个不起眼的类一点代码跟她发生关系的类太多。牵一发而动全身。会发生多米诺效应。咱可惹不起。谁知道会出现什么后果汗颜
7.单一职责原则
每一个类应该专注于做一件事情。
偶的理解
这个讲的就是商业领域里面的定位概念。想打官司找律师想看病找医生想学习找老师。 一个类一个具体作用如微软的VC MFC里的CBrush、CPen、CFont等就是这个意思想搞字体用CFont想用画笔用CPen想用刷子用CBrush。各司其责一目了然。
