面试官：“你真的会面向对象开发吗？”，我沉默了(2)，Java开发了解这些自然无惧面试

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

软件组成实体应该是可扩展的，但是不可修改。开放-封闭原则认为应该试图设计永远也不需要改变的模块。可以添加新代码来打展系统的行为，不能对已有的代码进行修改。这个原则很好的实现了面向对象的封装性和可重用性。

(3)替换原则(LSP)

================

子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC(Design by Contract)的概念推出。以圆和椭圆为例，圆是椭圆的一一个特殊子类。因此任何出现椭圆的地方，圆均可以出现。

但反过来就可能行不通。运用替换原则时，尽量把类B设计为抽象类或者接口，让C类继承类B (接口B)并实现操作A和操作B,运行时，类C实例替换B,这样即可进行新类的扩展(继承类B或接口B)，同时无须对类A进行修改。

(4)依赖倒置原则(DIP)

==================

在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，可以看到底层的模块是对高层抽象模块的实现，这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个“硬伤”。

但面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。为此，在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过具体的实现类(子类)来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用。

(5)接口分离原则(ISP)

==================

采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。ISP 原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP组件类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

(6)组合重用原则

=============

就是能用组合实现的地方，尽量用组合来实现，而不要使用继承来扩展功能，因为组合能更好地实现封装，比继承具有更大的灵活性和更稳定的结构。

(7)迪米特原则

============

指一个对象应该对于其他对象有最少的了解，这样做的好处就是可以有效地降低类之间的耦合要求。

看完之后你是否还会觉得自己真正懂得面向对象开发的精髓呢？有不足或者见解的小伙伴欢迎在评论区留言！

觉得不错记得点赞关注哟！

总结

其他的内容都可以按照路线图里面整理出来的知识点逐一去熟悉，学习，消化，不建议你去看书学习，最好是多看一些视频，把不懂地方反复看，学习了一节视频内容第二天一定要去复习，并总结成思维导图，形成树状知识网络结构，方便日后复习。

这里还有一份很不错的《Java基础核心总结笔记》，特意跟大家分享出来

目录：

部分内容截图：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
84594440)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！