java设计原则
❶ java面向对象设计有哪些原则
甚至还有经验丰富的Java程序员没有听说过OOPS和SOLID设计原则，他们根本不知道设计原则的好处，也不知道如何依照这些原则来进行编程。 众所周知，Java编程最基本的原则就是要追求高内聚和低耦合的解决方案和代码模块设计。查看Apache和Sun的开放源代码能帮助你发现其他Java设计原则在这些代码中的实际运用。Java DevelopmentKit则遵循以下模式：BorderFactory类中的工厂模式、Runtime类中的单件模式。 原则1:DRY（Don'trepeatyourself） 即不要写重复的代码，而是用"abstraction"类来抽象公有的东西。如果你需要多次用到一个硬编码值，那么可以设为公共常量；如果你要在两个以上的地方使用一个代码块，那么可以将它设为一个独立的方法。SOLID设计原则的优点是易于维护，但要注意，不要滥用，plicate不是针对代码，而是针对功能。这意味着，即使用公共代码来验证OrderID和SSN,二者也不会是相同的。使用公共代码来实现两个不同的功能，其实就是近似地把这两个功能永远捆绑到了一起，如果OrderID改变了其格式，SSN验证代码也会中断。因此要慎用这种组合，不要随意捆绑类似但不相关的功能。 原则2:封装变化 在软件领域中唯一不变的就是"Change",因此封装你认为或猜测未来将发生变化的代码。OOPS设计模式的优点在于易于测试和维护封装的代码。如果你使用Java编码，可以默认私有化变量和方法，并逐步增加访问权限，比如从private到protected和notpublic.有几种Java设计模式也使用封装，比如Factory设计模式是封装"对象创建",其灵活性使得之后引进新代码不会对现有的代码造成影响。 原则3:开闭原则 即对扩展开放，对修改关闭。这是另一种非常棒的设计原则，可以防止其他人更改已经测试好的代码。理论上，可以在不修改原有的模块的基础上，扩展功能。这也是开闭原则的宗旨。 原则4:单一职责原则 类被修改的几率很大，因此应该专注于单一的功能。如果你把多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，有可能中止另一个功能，这时就需要新一轮的测试来避免可能出现的问题。 原则5:依赖注入或倒置原则 这个设计原则的亮点在于任何被DI框架注入的类很容易用mock对象进行测试和维护，因为对象创建代码集中在框架中，客户端代码也不混乱。有很多方式可以实现依赖倒置，比如像AspectJ等的AOP（AspectOrientedprogramming）框架使用的字节码技术，或Spring框架使用的代理等。 原则6:优先利用组合而非继承 如果可能的话，优先利用组合而不是继承。一些人可能会质疑，但我发现，组合比继承灵活得多。组合允许在运行期间通过设置类的属性来改变类的行为，也可以通过使用接口来组合一个类，它提供了更高的灵活性，并可以随时实现。《EffectiveJava》也推荐此原则。 原则7:里氏代换原则（LSP） 根据该原则，子类必须能够替换掉它们的基类，也就是说使用基类的方法或函数能够顺利地引用子类对象。LSP原则与单一职责原则和接口分离原则密切相关，如果一个类比子类具备更多功能，很有可能某些功能会失效，这就违反了LSP原则。为了遵循该设计原则，派生类或子类必须增强功能。 原则8:接口分离原则 采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。设计接口很棘手，因为一旦释放接口，你就无法在不中断执行的情况下改变它。在Java中，该原则的另一个优势在于，在任何类使用接口之前，接口不利于实现所有的方法，所以单一的功能意味着更少的实现方法。 原则9:针对接口编程，而不是针对实现编程 该原则可以使代码更加灵活，以便可以在任何接口实现中使用。因此，在Java中最好使用变量接口类型、方法返回类型、方法参数类型等。《EffectiveJava》和《headfirstdesignpattern》书中也有提到。 原则10:委托原则 该原则最典型的例子是Java中的equals（）和hashCode（）方法。为了平等地比较两个对象，我们用类本身而不是客户端类来做比较。这个设计原则的好处是没有重复的代码，而且很容易对其进行修改。 总之，希望这些面向对象的设计原则能帮助你写出更灵活更好的代码。理论是第一步，更重要的是需要开发者在实践中去运用和体会。
❷ java编写规则是什么
查看文章
Java编写规则2008-12-28 00:27(1) 类名首字母应该大写。字段、方法以及对象(句柄)的首字母应小写。对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。例如：
ThisIsAClassName
thisIsMethodOrFieldName
若在定义中出现了常数初始化字符，则大写static final基本类型标识符中的所有字母。这样便可标志出它们属于编译期的常数。
Java包(Package)属于一种特殊情况：它们全都是小写字母，即便中间的单词亦是如此。对于域名扩展名称，如com，org，net或者e等，全部都应小写(这也是Java 1.1和Java 1.2的区别之一)。
(2) 为了常规用途而创建一个类时，请采取“经典形式”，并包含对下述元素的定义：
equals()
hashCode()
toString()
clone()(implement Cloneable)
implement Serializable
(3) 对于自己创建的每一个类，都考虑置入一个main()，其中包含了用于测试那个类的代码。为使用一个项目中的类，我们没必要删除测试代码。若进行了任何形式的改动，可方便地返回测试。这些代码也可作为如何使用类的一个示例使用。
(4) 应将方法设计成简要的、功能性单元，用它描述和实现一个不连续的类接口部分。理想情况下，方法应简明扼要。若长度很大，可考虑通过某种方式将其分割成较短的几个方法。这样做也便于类内代码的重复使用(有些时候，方法必须非常大，但它们仍应只做同样的一件事情)。 (5) 设计一个类时，请设身处地为客户程序员考虑一下(类的使用方法应该是非常明确的)。然后，再设身处地为管理代码的人考虑一下(预计有可能进行哪些形式的修改，想想用什么方法可把它们变得更简单)。
(6) 使类尽可能短小精悍，而且只解决一个特定的问题。下面是对类设计的一些建议：
■一个复杂的开关语句：考虑采用“多形”机制
■数量众多的方法涉及到类型差别极大的操作：考虑用几个类来分别实现
■许多成员变量在特征上有很大的差别：考虑使用几个类 。(7) 让一切东西都尽可能地“私有”——private。可使库的某一部分“公共化”(一个方法、类或者一个字段等等)，就永远不能把它拿出。若强行拿出，就可能破坏其他人现有的代码，使他们不得不重新编写和设计。若只公布自己必须公布的，就可放心大胆地改变其他任何东西。在多线程环境中，隐私是特别重要的一个因素——只有private字段才能在非同步使用的情况下受到保护。(8) 谨惕“巨大对象综合症”。对一些习惯于顺序编程思维、且初涉OOP领域的新手，往往喜欢先写一个顺序执行的程序，再把它嵌入一个或两个巨大的对象里。根据编程原理，对象表达的应该是应用程序的概念，而非应用程序本身。(9) 若不得已进行一些不太雅观的编程，至少应该把那些代码置于一个类的内部。(10) 任何时候只要发现类与类之间结合得非常紧密，就需要考虑是否采用内部类，从而改善编码及维护工作(11) 尽可能细致地加上注释，并用javadoc注释文档语法生成自己的程序文档。
(13) 涉及构建器和异常的时候，通常希望重新丢弃在构建器中捕获的任何异常——如果它造成了那个对象的创建失败。(14) 当客户程序员用完对象以后，若你的类要求进行任何清除工作，可考虑将清除代码置于一个良好定义的方法里，采用类似于cleanup()这样的名字，明确表明自己的用途(15) 在一个特定的作用域内，若一个对象必须清除(非由垃圾收集机制处理)，请采用下述方法：初始化对象;若成功，则立即进入一个含有finally从句的try块，开始清除工作。(16) 若在初始化过程中需要覆盖(取消)finalize()，请记住调用super.finalize()(若Object属于我们的直接超类，则无此必要)。(17) 创建大小固定的对象集合时，请将它们传输至一个数组(若准备从一个方法里返回这个集合，更应如此操作)。
❸ javaBean设计原则
JavaBean 的范围 Scope 是一个具有生命时间的变量。JavaBean的范围在<jsp:useBean scope=”….>标志中右边进行表示。将产生一个JavaBean的快捷参考。
说明：jsp服务器引擎将剥离<jsp。。。。标记。并且在最终用户的浏览器上无法显示实际代码。
存在下面四种范围： 页面page、 请求request、 对话session、 应用application。
对话范围
对话范围的JavaBean 主要应用于跨多个页面和时间段： 例如填充 用户信息。 添加信息并且接受回馈，保存用户最.近执行页面的轨迹。对话范围JavaBean保留一些和用户对话 ID 相关的信息。这些信息来自临时的对话cookie，并在当用户关闭浏览器时，这个cookie将从客户端和服务器删除。
请求范围
页面和请求范围的JavaBean有时类似表单的bean ， 这是因为 他们大都用于处理表单。表单需要很长的时间来处理用户的输入，通常情况下用于页面接受HTTP/POST或者GET请求。另外页面和请求范围的bean可以用于减少大型站点服务器上的负载，如果使用对话bean，耽搁的处理就可能会消耗掉很多资源。
应用范围
应用范围通常应用于服务器的部件，例如 JDBC连接池、应用监视、用户计数和其他参与用户行为的类。
在Bean中限制HTML的产生：
理论上，JavaBean 将不会产生任何HTML，因为这是jsp层负责的工作；然而，为动态消息提供一些预先准备的格式是非常有用的。产生的HTML将被标注的 JavaBean方法返回。
这里有一些非常重要的事情：
1. 不要试图在JavaBean返回的HTML中放置任何字体尺寸。
并不是所有的浏览器都相同。很多浏览器无法处理完整的字体尺寸。
2. 不要试图在JavaBean返回的HTML中放置任何脚本或者DHTML。
向页面直接输出脚本或者DHTML相当于自我毁灭，因为某些浏览器版本在处理不正确的脚本时会崩溃（非常少但是有）。如果用户的JavaBean在运行时是动态的推出复杂的HTML语言，用户将陷入调试的噩梦。另外，复杂的HTML将限制JavaBean的寿命和灵活性。
3. 不要提供任何的选择。
如果用户使用不同的系统浏览页面，可以提供一种可以替换的方法。
按着Sun公司的定义，JavaBean是一个可重复使用的软件组件。实际上JavaBean是一种Java类，通过封装属性和方法成为具有某种功能或者处理某个业务的对象，简称bean。由于javabean是基于java语言的，因此javabean不依赖平台，具有以下特点：
1． 可以实现代码的重复利用
2． 易编写、易维护、易使用
3． 可以在任何安装了Java运行环境的平台上的使用，而不需要重新编译。
编写javabean就是编写一个java的类，所以你只要会写类就能编写一个bean，这个类创建的一个对象称做一个bean。为了能让使用这个bean的应用程序构建工具（比如JSP引擎）知道这个bean的属性和方法，只需在类的方法命名上遵守以下规则：
1． 如果类的成员变量的名字是xxx，那么为了更改或获取成员变量的值，即更改或获取属性，在类中可以使用两个方法：
getXxx()，用来获取属性xxx。
setXxx()，用来修改属性xxx.。
2． 对于boolean类型的成员变量，即布尔逻辑类型的属性，允许使用"is"代替上面的"get"。
3． 类中访问属性的方法都必须是public的，一般属性是private的。
4． 类中如果有构造方法，那么这个构造方法也是public的并且是无参数的。
❹ JAVA设计模式的原则
近年来，大家都开始注意设计模式。那么，到底我们为什么要用设计模式呢？这么多设计模式为什么要这么设计呢？说实话，以前我还真没搞清楚。就是看大家一口一个"Design pattern"，心就有点发虚。于是就买了本"四人帮"的设计模式，结果看得似懂非懂:看得时候好像是懂了，过一会就忘了。可能是本人比较"愚钝"吧:))最近，有了点感悟。"独乐不如众乐"，与大家分享一下，还望指教!
为什么要提倡"Design Pattern"呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？OO界有前辈的几个原则："开－闭"原则(Open Closed Principal)、里氏代换原则、合成复用原则。设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。
一、"开－闭"原则
此原则是由"Bertrand Meyer"提出的。原文是："Software entities should be open for extension,but closed for modification"。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原(是"原"，指原来的代码)代码的情况下进行扩展。那么怎么扩展呢？我们看工厂模式"factory pattern":假设中关村有一个卖盗版盘和毛片的小子，我们给他设计一"光盘销售管理软件"。我们应该先设计一"光盘"接口。如图：而盗版盘和毛片是其子类。小子通过"DiscFactory"来管理这些光盘。代码为：
public class DiscFactory{
public static 光盘 getDisc(String name){
return (光盘)Class.forName(name).getInstance();
}}
有人要买盗版盘，怎么实现呢？
public class 小子{
public static void main(String[] args){
光盘 d=DiscFactory.getDisc("盗版盘");
光盘.卖();
}}
如果有一天，这小子良心发现了，开始卖正版软件。没关系，我们只要再创建一个"光盘"的子类"正版软件"就可以了。不需要修改原结构和代码。怎么样？对扩展开发，对修改关闭。"开-闭原则"
工厂模式是对具体产品进行扩展，有的项目可能需要更多的扩展性，要对这个"工厂"也进行扩展，那就成了"抽象工厂模式"。
二、里氏代换原则
里氏代换原则是由"Barbara Liskov"提出的。如果调用的是父类的话，那么换成子类也完全可以运行。比如：
光盘 d=new 盗版盘();
d.卖();
现在要将"盗版盘"类改为"毛片"类，没问题，完全可以运行。Java编译程序会检查程序是否符合里氏代换原则。还记得java继承的一个原则吗？子类overload方法的访问权限不能小于父类对应方法的访问权限。比如"光盘"中的方法"卖"访问权限是"public"，那么"盗版盘"和"毛片"中的"卖"方法就不能是package或private，编译不能通过。为什么要这样呢？你想啊：如果"盗版盘"的"卖"方法是private。那么下面这段代码就不能执行了：
光盘 d=new 盗版盘();
d.卖();
可以说：里氏代换原则是继承复用的一个基础。
三、合成复用原则
就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。"牵一发而动全身"!面向对象是要把波动限制在尽量小的范围。
在Java中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，"不要与陌生人说话"。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高
理解了这些原则，再看设计模式，只是在具体问题上怎么实现这些原则而已。张无忌学太极拳，忘记了所有招式，打倒了"玄幂二老"，所谓"心中无招"。设计模式可谓招数，如果先学通了各种模式，又忘掉了所有模式而随心所欲，可谓OO之最高境界。呵呵，搞笑，搞笑！
这是我的一点心得，大家可能理解得更深刻。还望指教！
❺ JAVA程序设计（开封原则） 求解（代码）
开闭原则结构图
代码：
public interface pay{
void wePay();
void aliPay();
void voucherPay();
void bankcardPay();
}
public class Patron implements pay{
private String name;
public void wePay(){//微信支付的内逻辑}
public void aliPay(){//支付宝支付的逻辑}
public void voucherPay(){//代金券支付的逻辑}
public void bankcardPay(){//银行卡容支付的逻辑}
}
❻ java程序设计有哪些设计原则
内聚性
类应该描述一个单一的实体，而所有的类操作应该在逻辑上相互配合，支持一个一致的目的。例如：可以设计一个类用于学生，但不应该将学生与教职工组合在一个类中，因为学生和教职工是不同的实体。
如果一个实体担负太多的职责，就应该按各自的职责分成几个类。例如：String类、StringBuffer类和 StringBuilder类用于处理字符串，但是他们的职责不同。String类处理不变的字符串，StringBuilder类创建可变字符串， StringBuffer()
与 StringBuffer() 类还包含更新字符串的同步方法。
一致性
遵循标准java程序设计风格和命名习惯。为类、数据域和方法选取具有信息的名字。通常的风格是将数据声明置于构造方法之前，并且将构造方法置于方法之前。
选择名字要保持一致。给类似的操作选择不同的名字并非良好的实践。例如：Length() 方法返回String、StringBuilder 和 StringBuffer 的大小。如果在这些类中给这个方法用不同的名字就不一致了。
一般来说，应该具有一致性地提供一个公共无参的构造函数，用于构建默认实例。如果一个类不支持无参的构造函数，要用文档写出原因。如果没有显示定义构造方法，即假定有一个空方法体的公共默认无参构造方法。
如果不想让用户创建类的对象，可以在类中声明一个私有的构造方法，Math类就是如此。
封装性
一个类应该使用private修饰符隐藏其数据，以免用户直接访问它。这使得类更易于维护。只在希望数据域可读的情况下，才提供get方法；也只在希望数据域可更新的情况下，才提供set方法。例如：Rational类为numerator和denominator提供了get方法，但是没有提供set方法，因为Rational对象是不可改变的。
清晰性
为使设计清晰，内聚性、一致性和封装性都是很好的设计原则。除此之外，类应该有一个很清晰的合约，从而易于解释和理解。
用户可以以各种不同的组合、顺序，以及在各种环境中结合使用多个类。因此，在设计一个类时，这个类不应该限制用户如何以及何时使用该类；以一种方式设计属性，以允许用户按值的任何顺序和任何组合来设置；设计方法应该使得实现的功能与他们出现的顺序无关。例如：Loan类包含属性loanAmount、numberOfYears和annualIntereRate，这些属性的值，可以按任何顺序来设置。
方法应在不生产混淆的情况下进行直观定义。例如：String类中的substring（int beginIndex， int endIndex）方法就有一点混乱。这个方法返回从beginIndex到endIndex-1而不是endIndex的子串。该方法应该返回从beginIndex到endIndex的子字符串，从而更加直观。
不应该声明一个来自其他数据域的数据域。例如，下面的Person类有两个数据域：birthDate和age。由于age可以从birthDate导出，所以age不应该声明为数据域。
❼ java六大设计原则
1、单一职责原则
不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。
2、里氏替换原则(Liskov Substitution Principle)
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。
里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。
LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。——
From Bai 网络
历史替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。
3、依赖倒转原则(Dependence Inversion Principle)
这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。
4、接口隔离原则(Interface Segregation Principle)
这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口(多个接口方法集合到一个的接口)要好。
5、迪米特法则(最少知道原则)(Demeter Principle)
就是说：一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。
最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
6、合成复用原则(Composite Reuse Principle)
原则是尽量首先使用合成/聚合的方式，而不是使用继承。
❽ 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语言中， abstract class 和interface 是支持抽象类定义的两种机制。正是由于这两种机制的存在，才赋予了Java强大的 面向对象能力。abstract class和interface之间在对于抽象类定义的支持方面具有很大的相似性，甚至可以相互替换，因此很多开发者在进 行抽象类定义时对于abstract class和interface的选择显得比较随意。其实，两者之间还是有很大的区别的，对于它们的选择甚至反映出对 于问题领域本质的理解、对于设计意图的理解是否正确、合理。本文将对它们之间的区别进行一番剖析，试图给开发者提供一个在二者之间进行选择的依据。
理解抽象类
abstract class和interface在Java语言中都是用来进行抽象类(本文 中的抽象类并非从abstract class翻译而来，它表示的是一个抽象体，而abstract class为Java语言中用于定义抽象类的一种方法， 请读者注意区分)定义的，那么什么是抽象类，使用抽象类能为我们带来什么好处呢?
在 面向对象的概念中，我们知道所有的对象都是通过类来描绘的，但是反过来却不是这样。并不是 所有的类都是用来描绘对象的，如果一个类中没有包含足够的信息来描绘一个具体的对象，这样的类就是抽象类。抽象类往往用来表征我们在对问题领域进行分析、 设计中得出的抽象概念，是对一系列看上去不同，但是本质上相同的具体概念的抽象。比如：如果我们进行一个图形编辑软件的开发，就会发现问题领域存在着圆、 三角形这样一些具体概念，它们是不同的，但是它们又都属于形状这样一个概念，形状这个概念在问题领域是不存在的，它就是一个抽象概念。正是因为抽象的概念 在问题领域没有对应的具体概念，所以用以表征抽象概念的抽象类是不能够实例化的。
在面向对象领域，抽象类主要用来进行类型隐藏。 我们可以构造出一个固定的一组行为的抽象描 述，但是这组行为却能够有任意个可能的具体实现方式。这个抽象描述就是抽象类，而这一组任意个可能的具体实现则表现为所有可能的派生类。模块可以操作一个 抽象体。由于模块依赖于一个固定的抽象体，因此它可以是不允许修改的;同时，通过从这个抽象体派生，也可扩展此模块的行为功能。熟悉OCP的读者一定知 道，为了能够实现面向对象设计的一个最核心的原则OCP(Open-Closed Principle)，抽象类是其中的关键所在。
从语法定义层面看abstract class 和 interface
在语法层面，Java语言对于abstract class和interface给出了不同的定义方式，下面以定义一个名为Demo的抽象类为例来说明这种不同。
使用abstract class的方式定义Demo抽象类的方式如下：
abstract class Demo{
abstract void method1();
abstract void method2();
…
｝
使用interface的方式定义Demo抽象类的方式如下：
interface Demo{
void method1();
void method2();
…
}
❿ java中设计模式是根据什么原则划分的
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。