「java原则」java几大原则
本篇文章给大家谈谈java原则，以及java几大原则对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
java中 就近原则 (1) 解释什么是就近原则？
字面意思……先在作用域内向上找，没有就在外面找
如：
第一个println(x)向上找是10
第二个println(x)向上找，作用域没有，于是找到外面的20，但如果外面的20没有，则会报异常
第三个println(x)向上找是30
JAVA23种设计模式
一、大约分为三类：
1、创建型模式（5种）：工厂方法模式，抽象工厂模式，单例模式，建造者模式，原型模式。
2、结构型模式（7种）：适配器模式，装饰器模式，代理模式，外观模式，桥接模式，组合模式，享元模式。
3、行为型模式（11种）：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
二、设计模式遵循的原则有6个：
1、开闭原则（OpenClosePrinciple）
对扩展开放，对修改关闭。
2、里氏代换原则（LiskovSubstitutionPrinciple）
只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
3、依赖倒转原则（DependenceInversionPrinciple）
这个是开闭原则的基础，对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（InterfaceSegregationPrinciple）
使用多个隔离的借口来降低耦合度。
5、迪米特法则（最少知道原则）（DemeterPrinciple）
一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（CompositeReusePrinciple）
原则是尽量使用合成/聚合的方式，而不是使用继承。继承实际上破坏了类的封装性，超类的方法可能会被子类修改。
java中对类分装的原因及原则
1、“纸上得来终觉浅”，直到经历一段时间的编码活动以后，才能对封装的原因及原则有所体会。那个时候书本上的理论知识才能觉得亲切。
2、其实不封装也是可以的，很久以前，我们的前辈们就是那么干的。但是当项目在空间方面有很大的体量，在时间方面持续很长的开发和维护时间，在开发人员方面不断的变动的，在需求方面不断的更改的时候。你会发现之前那样信马由缰，没有组织，随心所欲的编码方式就会带来很多问题。比如说：
①、今天路人甲开发了一块功能，后来他离职了，工作交接给你，让你修改它遗留的一些功能或者修改它的bug。那个时候，你会发现，自己掉在了一片大海里，东南西北都找不到。如果他写的代码是在一个类里，或者是在一个包里，局限在一块区域，那么就好找，好修改，否则你只有在大量的时间以后，才能从其潇洒的编码风格中体会出其当时的思维逻辑和良苦用心
②、更重要的是，当你今天开发了一个甲功能，明天客户的想法变了，需要换成乙功能。那么如果你的代码分散在不同的类里，你的麻烦就大了，需要一一修改。如果你是把它们写在一个方法里，那么你只需要重新提供一个方法即可，而不必担心这个方法删除以后对其他功能会不会产生负面影响。现实项目开发过程中，这种需求的变更是客观存在的，无法抹去，所以你就需要时时刻刻想着如果把自己的代码整理在一起，使相关的一块功能对应着一块代码，这样当需要需改它时，可以找到，也方便修改，花费的代价较小
3、所以封装与不封装对于结果来说，往往不是能不能做出产品的问题，而是能不能高效的做出的问题。它就是为了大量的减少内部矛盾，一致对外。
4、所以，代码最好局限在一块区域里，有问题时只修改它，而不会对其他功能产生影响。这种思想被总结为设计原则：“高内聚，低耦合”。
JAVA面向对象六大原则是什么？
1) Open-Close Principle（OCP），开-闭原则，讲的是设计要对扩展有好的支持，而对修改要严格限制。这是最重要也是最为抽象的原则，基本上我们所说的Reusable Software既是基于此原则而开发的。其他的原则也是对它的实现提供了路径。
2) Liskov Substituition Principle（LSP），里氏代换原则，很严格的原则，规则是“子类必须能够替换基类，否则不应当设计为其子类。”也就是说，子类只能去扩展基类，而不是隐藏或覆盖基类.
3) Dependence Inversion Principle（DIP），依赖倒换原则，“设计要依赖于抽象而不是具体化”。换句话说就是设计的时候我们要用抽象来思考，而不是一上来就开始划分我需要哪些哪些类，因为这些是具体。这样做有什么好处呢？人的思维本身实际上就是很抽象的，我们分析问题的时候不是一下子就考虑到细节，而是很抽象的将整个问题都构思出来，所以面向抽象设计是符合人的思维的。另外这个原则会很好的支持OCP，面向抽象的设计使我们能够不必太多依赖于实现，这样扩展就成为了可能，这个原则也是另一篇文章《Design by Contract》的基石。
4) Interface Segregation Principle（ISP），“将大的接口打散成多个小接口”，这样做的好处很明显，我不知道有没有必要再继续描述了，为了节省篇幅，实际上我对这些原则只是做了一个小总结，如果有需要更深入了解的话推荐看《Java与模式》，MS MVP的一本巨作！^_^
5) Composition/Aggregation Reuse Principle（CARP），设计者首先应当考虑复合/聚合，而不是继承（因为它很直观，第一印象就是“哦，这个就是OO啊”）。这个就是所谓的“Favor Composition over Inheritance”，在实践中复合/聚合会带来比继承更大的利益，所以要优先考虑。
6) Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法则或最少知识原则，这个原则首次在Demeter系统中得到正式运用，所以定义为迪米特法则。它讲的是“一个对象应当尽可能少的去了解其他对象”。也就是又一个关于如何松耦合（Loosely-Coupled）的法则。
关于java原则和java几大原则的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。