成都创建公司网站,潍坊百度seo公司,东莞工厂网站建设,网络网站推广首荐乐云seo文章目录一. 三大特征的理解#xff08;1#xff09;封装#xff08;2#xff09;继承#xff08;3#xff09;多态#xff08;4#xff09;面向对象、面向过程的对比二. 七大基本原则的理解#xff08;1#xff09;单一职责原则#xff08;2#xff09;开放封闭原…
文章目录一. 三大特征的理解1封装2继承3多态4面向对象、面向过程的对比二. 七大基本原则的理解1单一职责原则2开放封闭原则OOP 核心3里氏替换原则OOP 标志4依赖倒置原则5接口分离原则6迪米特原则最少知识法则7组合优先继承原则拖了好久的总结 。 对 OOP 的内容零散地看了一些想了一些还是自己写一个总结来提升一下理解吧 学好 OOP也利于设计模式的学习 一点自己的见解疏漏错误的地方期待大佬在评论区指正 文章定义、实例等参考了《大话设计模式》、什么是OOP、OOP七大原则等书籍、文章感谢 一. 三大特征的理解
1封装 定义每个对象都包含它能进行操作所需要的所有信息。 好处 减少耦合类内部实现可以自由修改类具有清晰的对外接口 例子房子用墙壁封装起来。 窗户、门口就是对外接口设想一下如果没有门窗或者门窗是秘密暗道不清晰我们无法进入房子来使用里面的家具那这个房子还有用吗清晰对外接口的必要性改变房间布局就是修改类内部我的房子想怎么改就怎么改不会给房外人带来困扰自由修改内部的体现减少耦合我想到的例子是合租耦合度过高相当于大家的房子都连在一起没有墙壁封装耦合度过高带来的问题就是不必要的相互联系比如我在家用着100寸电视打游戏你家高三孩子无法避免地看到了导致无心向学。而墙壁的封装就可以避免这个不必要的互相联系也就是达到减小耦合度的效果。 图源网络侵删
2继承
定义子类可以理解为对父类的特殊化除了具备父类特性外还具备自己的独立个性。 子类拥有父类非 private 的属性和功能子类具有自己的属性和功能拓展子类可以用自己的方式实现父类的功能重写 好处 提高代码复用率易拓展 缺点父类变则子类不得不变——继承会破坏1的封装性。 可以看到1的好处2【自由修改】。显而易见继承会威胁到这一效果 父类的自由修改可能会导致子类出现问题比如新增抽象函数。这也显示着继承是一种类与类之间强耦合的关系 因此有一项“组合优先于继承”的原则可以到下面的原则7再看一下 例子虽然大家应该都对继承熟悉了不过这边还是写一个吧 大凡是小凡的爹因此小明和大明一样都是黄种人父类特征 虽然是大凡不会rap但是小凡会子类拓展 大凡唱歌唱高音小凡唱歌唱电音方法重写 大凡改变肤色变成黑人小凡也得变成黑人破坏封装性不能自由修改内部 联动一下计网URI和URL也可以看成继承关系噢URL 是对 URI 的特殊化
3多态
定义不同对象执行相同动作但要通过对象自己的代码执行。 子类以父类身份出现对象声明必须是父类子类以自己方式实现无论对象是否转换成父类都用的继承链末端方法子类特有属性和方法不可使用 优点提高了代码的维护性、拓展性例子这里直接用《大话设计模式》里的例子这个讲的挺好的 京剧艺术家大明和子承父业的儿子小明。父亲表演当前生病了小明代父表演 小明穿大明的戏服以大明的身份进行表演父类身份 小明还是以自己的理解进行表演自己方式 小明虽然说学了一手Breaking但是父亲不会所以不能使用特有属性方法不可用重载算多态吗按照上面的定义来看应该不算。但是也有说算是静态多态的。总的来说应该是看具体定义看成一种多态应该也是可以的。
4面向对象、面向过程的对比 各自相对优点 面向过程效率更高。具体化、流程化不用进行实例化过程面向对象易维护、易复用、易扩展。三大特性
二. 七大基本原则的理解 诶网上很多都是五大原则为了全面点我这边还是写七个的吧 1单一职责原则
定义一个类应该有且只有一个引起它变化的原因好处 耦合度低变更引起的风险降低提高可维护性。类的职责明确增加代码可读性。 例子两种手机类按照单一职责原则手机应该只负责通话。 过多的功能会提高类的复杂度同时提高了耦合度。 当然显示中手机还是按照多种多样的来的这里只是想表达一下
class BadPhone {// 包括手电筒、相机、通话功能的手机类private int flashlightBrightness;private int cameraPixel;private int volume;public void flashlightFunctions() { }public void cameraFunctions() { }public void conversationFunctions() { }
}class GoodPhone {// 包括通话功能的手机类private int volume;public void conversationFunctions() { }
}2开放封闭原则OOP 核心
定义软件实体应该是可以拓展但是不可修改。理解一个类提供的外部可用接口如果由于新的需求进行了修改可能会导致依赖这个接口的其他方法瘫痪。解决方法就是通过拓展新接口而非修改旧接口来实现新需求。好处可维护、可拓展、可服用、灵活性好全包例子getID() 返回 StringprintID() 依赖 getID()。现在多了一个返回 int 型 ID 的需求。
class MyClass2 {public String getID() {return ID;}// Bad
// public int getID() {
// return 123;
// }// Goodpublic int getIntID() {return 123;}public void printID() {// 如果修改 getID()依赖 getID() 的 printID() 就会出错// 但是拓展 getIntID()就没问题System.out.printf(%s, getID());}
}3里氏替换原则OOP 标志
定义子类型必须能够替换掉父类型。优点保证使用父类的模块在无需修改的情况下就能拓展提升拓展性。例子举个开枪的例子吧
class Gun {public void shoot() {System.out.println(fire!);}
}class GoodGun extends Gun {Overridepublic void shoot() {System.out.println(fire! fire!);}
}class BadGun extends Gun {Overridepublic void shoot() {System.out.println(sorry, I cant fire);}
}class Man {public void fire() {new Gun().shoot();// new GoodGun().shoot(); 可以替换能开枪// new BadGun().shoot(); 不能替换不能开枪}
}4依赖倒置原则
定义抽象不应该依赖细节细节应该依赖于抽象。理解针对接口而非实现进行编程。例子写一个项目A用到 Redis高层模块项目A依赖于低层模块 Redis。如今由于机子太烂日常宕机因此打算换成 etcd 来避免数据丢失的问题。 问题来了由于项目A的代码绑定了 Redis因此无法复用项目A的代码这就问题很大如何解决呢如果项目A的代码依赖的不是Redis而是抽象的 K-V 数据库具有稳定的接口也就是依赖于抽象那就可以直接替换成 etcd 啦 讲道理我不会 Redis、etcd这里的例子是大概举出来的有误的话欢迎指出 5接口分离原则
定义客户端不应该依赖它不需要的接口。采用多个与特定客户类有关的接口比采用一个通用的接口要好。理解相对于1单一职责原则注重业务逻辑划分这里要求的是接口的方法尽量少好处 避免接口污染高内聚一个软件模块是由相关性很强的代码毕竟用多个合适接口啦灵活性 例子实现老人机类一个复杂的手机接口 VS 多个简单的功能接口
interface BadPhoneInterface {void fly();void swim();void watchTV();void buy();void talk();void sendMessage();
}// 老人机只希望能打电话、发短信就好
// 非接口分离采用了具有多个方法的接口并非高聚合
class OldPhone1 implements BadPhoneInterface {Overridepublic void fly() { }Overridepublic void swim() { }Overridepublic void watchTV() { }Overridepublic void buy() { }Overridepublic void talk() { }Overridepublic void sendMessage() { }
}// 接口分离高聚合灵活定制化
interface Talker {void talk();
}interface MessageSender {void sendMessage();
}class OldPhone2 implements Talker, MessageSender {Overridepublic void talk() { }Overridepublic void sendMessage() { }
}6迪米特原则最少知识法则
定义如果两个类不必彼此直接通信那么这两个类就不应该发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法可以通过第三者转发调用。理解根本思想是强调类之间的松耦合促进了类的复用例子秋招时节举一个求职例子吧当然具体面试流程肯定没我瞎写的这么糙 小红想进大厂A于是花了大功夫认识了面试官1投简历希望面试官1过几天能面她。 但是还没来得及面面试官1就跳槽了那小红接下来该怎么办继续花大时间来找面试官2、面试官3吗这就是没有遵循迪米特原则了 小红和具体面试官之间不应该有直接的联系这样耦合太高了。而应该是找HR让HR来充当这个转发“求面试调用”的第三者这样耦合度低而且不会发生像上面那样的事情了^ ^
7组合优先继承原则 定义能用组合的地方就不要继承以保证封装性。 6(7的代码有空再补了。。敲累了摆烂 花了一下午我是没想到的 希望这个总结能帮助读者有更多的OOP理解感谢你能阅读到这里
