java设计原则代码说明 java设计模式及例子
java面向对象设计原则和设计模式详解
Java面向对象设计原则
创新互联专注为客户提供全方位的互联网综合服务,包含不限于成都网站建设、成都网站设计、永平网络推广、微信小程序、永平网络营销、永平企业策划、永平品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等,从售前售中售后,我们都将竭诚为您服务,您的肯定,是我们最大的嘉奖;创新互联为所有大学生创业者提供永平建站搭建服务,24小时服务热线:13518219792,官方网址:www.cdcxhl.com
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)的法则。
设计模式:
1)适配器模式
2)桥接器模式
3)职责链模式
4)命令模式
5)装饰器模式
6)外观模式
7)工厂模式
8)享元模式
9)代理模式
10)单例模式
11)状态模式
12)策略模式
13)模板模式
14)访问者模式
代码设计时应遵循哪些原则
1提高编码质量,代码可读性和可维护性。
2代码编写规范
2.1删除所有无用代码
2.2必须给代码添加注释,一个类的注释字数不得小于代码的百分之20%
2.3建议遵循30秒原则。如果另一个程序员无法在三十秒内无法知道你的函数在做什么,如何做以及为什么要这样做,那么说明你的代码是难于维护的,需要得到提高。
2.4一个函数的代码长度不允许超过100行,超过一百行的函数建议在不破坏原子性的基础上进行拆分。
2.5变量都应在方法或者类的头部集中定义
2.6保证一行代码只做一件事
2.7使用括号来控制操作符的运算顺序,以免使用java默认的操作符优先级顺序。
2.8代码格式化:对代码进行格式化,再进行提交。
2.9接口不允许没有方法或者变量的声明
3.命名规范
3.1各种标识符的命名要使用有实际意义的英文单词或者英文单词缩写,缩写词及英文单词要收录在项目的简写词汇表中。切忌使用阿拉伯数字和拼音进行命名。
3.2类名:首字母大写,每个单词首字母都需要大写。
3.3方法名:首字母小写,其余单词首字母都需大写。
3.4全局变量,和常量名称要求全部字母大写。
3.5参数名称与局部变量基本相同,区别在于参数名称需要加上冠词a,an或者在单词结尾以s结束。
4.注释规范
4.1注释需要注意的事项:
★注释应该用中文清晰表达意思,应该是程序看起来更清晰,更容易理解
★注释要尽量简明,避免装饰性的注释。
★注释不但要说明做什么,还应当说明为什么要这样做。最好先写注释表明要做什么,再进行编码。
4.2类的注释
★类的用途,目的。包括其他人感兴趣的介绍。
★已知bug,当然最好是修改好所有的错误,但有时可能暂时没有办法修改,或者没有时间修改。
★开发和维护该类的历史列表,记录每一次修改的作者,日期,修改的内容。
★列举类的各种稳定状态,说明调用成员函数使类的状态产生的变迁(可选)。
★同步问题(可选)
★对主要的算法必须加以说明,主要流程必须给予引导性说明
标准格式:
如果对已经版本话的类进行了修改,需要按照如下格式为每一次修改附加修改历史记录:
//修改人+修改日期
//修改说明范例:
//李四2010/07/02
//添加错误数据修改后继续批量保存的处理函数saveBatch(
@Bind(key="itemParams",defaultValue="")StringitemParams,
@Bind(key="pid",defaultValue="")Stringpid)。
//王小二2010/07/02
4.3接口注释:
★接口的注释风格基本与类的注释风格相同;
★在别人使用接口之前,必须了解接口所包含的概念。检验一个接口是否应该定义的简单方法是:你是否能★够容易的描述接口的用途;
★接口如何应当和不应当被使用。开发者需要知道该接口如何被使用,也希望知道该接口不能被怎样使用。
4.4函数的注释
★函数头注释必须包括:函数执行了什么功能,为什么要这样处理;函数处理过程中对对象的哪些属性
★可能进行更改;函数执行前后,对象的状态;
★比较、循环等控制结构加注释(可选);
★在代码的功能并非一目了然的情况下,应当说明为什么要这样做;
★局部变量必须加注释;
★复杂难写的代码必须加注释;
4.5类属性的注释:
★描述域的用途。使别人知道如何去使用它;
★对于有着复杂事物规则的域,可以加入范例来说明。有时候一个简单的小例子,抵的上千言万语;
Java编程开发常用的几种设计模式?
随着我们对Java编程开发语言的掌握,对于不同场景下使用哪种设计模式会有更清晰的判断。下面IT培训就一起来了解一下,JavaScript编程中的几种常见设计模式都有哪些类型。
设计原则
单一职责原则(SRP)
一个对象或方法只做一件事情。如果一个方法承担了过多的职责,那么在需求的变迁过程中,需要改写这个方法的可能性就越大。
应该把对象或方法划分成较小的粒度
少知识原则(LKP)
一个软件实体应当尽可能少地与其他实体发生相互作用
应当尽量减少对象之间的交互。如果两个对象之间不必彼此直接通信,那么这两个对象就不要发生直接的相互联系,可以转交给三方进行处理
开放-封闭原则(OCP)
软件实体(类、模块、函数)等应该是可以扩展的,但是不可修改
当需要改变一个程序的功能或者给这个程序增加新功能的时候,可以使用增加代码的方式,尽量避免改动程序的源代码,防止影响原系统的稳定
什么是设计模式
作者的这个说明解释得挺好
假设有一个空房间,我们要日复一日地往里面放一些东西。简单的办法当然是把这些东西直接扔进去,但是时间久了,就会发现很难从这个房子里找到自己想要的东西,要调整某几样东西的位置也不容易。所以在房间里做一些柜子也许是个更好的选择,虽然柜子会增加我们的成本,但它可以在维护阶段为我们带来好处。使用这些柜子存放东西的规则,或许就是一种模式
java六大设计原则?
1、单一职责原则
不要存在多于一个导致类变更的原因,也就是说每个类应该实现单一的职责,如若不然,就应该把类拆分。
2、里氏替换原则(Liskov Substitution Principle)
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。
里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。
LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。——
From Baidu 百科
历史替换原则中,子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构,通过这个规范的接口与外界交互,子类不应该随便破坏它。
3、依赖倒转原则(Dependence Inversion Principle)
这个是开闭原则的基础,具体内容:面向接口编程,依赖于抽象而不依赖于具体。写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互。
4、接口隔离原则(Interface Segregation Principle)
这个原则的意思是:每个接口中不存在子类用不到却必须实现的方法,如果不然,就要将接口拆分。使用多个隔离的接口,比使用单个接口(多个接口方法集合到一个的接口)要好。
5、迪米特法则(最少知道原则)(Demeter Principle)
就是说:一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂,都应该将逻辑封装在方法的内部,通过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。
最少知道原则的另一个表达方式是:只与直接的朋友通信。类之间只要有耦合关系,就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
6、合成复用原则(Composite Reuse Principle)
原则是尽量首先使用合成/聚合的方式,而不是使用继承。
分享名称:java设计原则代码说明 java设计模式及例子
网页路径:http://ybzwz.com/article/ddeghdj.html