精华内容
下载资源
问答
  • 代码设计应遵循哪些原则

    千次阅读 2018-09-06 13:59:58
    2.3 建议遵循30秒原则。如果另一个程序员无法在三十秒内无法知道你的函数在做什么,如何做以及为什么要这样做,那么说明你的代码是难于维护的,需要得到提高。 2.4 一个函数的代码长度不允许超过100行,超过一百行...

    1提高编码质量,代码可读性和可维护性。

    2代码编写规范

    2.1 删除所有无用代码
    2.2 必须给代码添加注释,一个类的注释字数不得小于代码的百分之20%
    2.3 建议遵循30秒原则。如果另一个程序员无法在三十秒内无法知道你的函数在做什么,如何做以及为什么要这样做,那么说明你的代码是难于维护的,需要得到提高。
    2.4 一个函数的代码长度不允许超过100行,超过一百行的函数建议在不破坏原子性的基础上进行拆分。
    2.5 变量都应在方法或者类的头部集中定义
    2.6 保证一行代码只做一件事
    2.7 使用括号来控制操作符的运算顺序,以免使用java默认的操作符优先级顺序。
    2.8 代码格式化:对代码进行格式化,再进行提交。
    2.9 接口不允许没有方法或者变量的声明

    1. 命名规范
      3.1 各种标识符的命名要使用有实际意义的英文单词或者英文单词缩写,缩写词及英文单词要收录在项目的简写词汇表中。切忌使用阿拉伯数字和拼音进行命名。
      3.2 类名:首字母大写,每个单词首字母都需要大写。
      3.3 方法名:首字母小写,其余单词首字母都需大写。
      3.4 全局变量,和常量名称要求全部字母大写。
      3.5 参数名称与局部变量基本相同,区别在于参数名称需要加上冠词a ,an 或者在单词结尾以s结束。

    2. 注释规范
      4.1 注释需要注意的事项:
      ★注释应该用中文清晰表达意思,应该是程序看起来更清晰,更容易理解
      ★注释要尽量简明,避免装饰性的注释。
      ★注释不但要说明做什么,还应当说明为什么要这样做。最好先写注释表明要做什么,再进行编码。

    4.2 类的注释
    ★类的用途,目的。包括其他人感兴趣的介绍。
    ★已知bug,当然最好是修改好所有的错误,但有时可能暂时没有办法修改,或者没有时间修改。
    ★开发和维护该类的历史列表,记录每一次修改的作者,日期,修改的内容。
    ★列举类的各种稳定状态,说明调用成员函数使类的状态产生的变迁(可选)。
    ★同步问题(可选)
    ★对主要的算法必须加以说明,主要流程必须给予引导性说明
    标准格式:
    如果对已经版本话的类进行了修改,需要按照如下格式为每一次修改附加修改历史记录:
    // 修改人 + 修改日期
    // 修改说明 范例:

    // 李四 2010/07/02
    // 添加错误数据修改后继续批量保存的处理函数 saveBatch(
    @Bind(key = “itemParams”, defaultValue = “”) String itemParams,
    @Bind(key = “pid”, defaultValue = “”) String pid)。
    // 王小二 2010/07/02

    4.3 接口注释:
    ★接口的注释风格基本与类的注释风格相同;
    ★在别人使用接口之前,必须了解接口所包含的概念。检验一个接口是否应该定义的简单方法是:你是否能★够容易的描述接口的用途;
    ★接口如何应当和不应当被使用。开发者需要知道该接口如何被使用,也希望知道该接口不能被怎样使用。

    4.4 函数的注释
    ★函数头注释必须包括:函数执行了什么功能,为什么要这样处理;函数处理过程中对对象的哪些属性
    ★可能进行更改;函数执行前后,对象的状态;
    ★比较、循环等控制结构加注释(可选);
    ★在代码的功能并非一目了然的情况下,应当说明为什么要这样做;
    ★局部变量必须加注释;
    ★复杂难写的代码必须加注释;

    4.5类属性的注释:
    ★描述域的用途。使别人知道如何去使用它;
    ★对于有着复杂事物规则的域,可以加入范例来说明。有时候一个简单的小例子,抵的上千言万语;

    展开全文
  • 代码设计的六大原则

    万次阅读 2018-07-03 15:17:27
    现在主要针对的是代码设计原则,在设计代码的时候,不能总是想到哪就打到哪,还需要有个大致的流程,否则写出来的代码也是很繁冗,不够简洁。对于自己的代码编程还没达到一个期望的程度,对于代码的设计。主要注意...

    开了博客,为了能够更好的学习,对于自己不了解和还没有掌握的知识加以归类,巩固以及加强。

    现在主要针对的是代码设计的原则,在设计代码的时候,不能总是想到哪就打到哪,还需要有个大致的流程,否则写出来的代码也是很繁冗,不够简洁。对于自己的代码编程还没达到一个期望的程度,对于代码的设计。主要注意以下的六大原则:

    单一职责

    一个类或者一个接口,最好只负责一项职责。

    开闭原则

    一个软件实体如类、模版和函数应该对扩展,对修改关闭;

    里氏替换原则

    子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法; 
    * 子类可以增加自己特有的方法; 
    * 当子类的方法重载父类的方法时,方法的形参要比父类方法的输入参数更佳宽松; 
    * 当子类的方法实现父类的抽象方法时,方法的返回值要比父类更加严格;

    依赖倒置原则

     低层模块尽量都要有抽象类或者接口,或者两者都有; 
    * 变量的声明类型尽量是抽象类或者接口; 
    * 使用继承时遵循里氏替换原则;

    接口隔离原则

    * 一个接口只服务于一个子模块或业务逻辑,服务定制; 
    * 通过业务逻辑压缩接口中的public方法,让接口看起来更加精悍; 
    * 已经被污染了的接口,尽量修改,如果变更风险太大,则用适配器模式进行转化; 
    * 根据具体的业务,深入了解逻辑,用心感知去控制设计思路;

    迪米特原则

    定义:一个对象应该对其他对象保持最少的了解,其核心精神就是:不和陌生人说话,通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少;这会导致类之间的耦合度降低,每个类都尽量减少对其他类的依赖。

    展开全文
  • 代码设计 六大原则

    万次阅读 2016-07-02 02:13:22
    单一职责原则 Single Responsibility Principle定义:一个类...解决方法:遵循单一职责原则。分别建立新的类来对应相应的职责;这样就能避免修改类时影响到其他的职责; 当遇到职责扩散的时候,在逻辑足够简单的时候,

    单一职责原则 Single Responsibility Principle

    定义:一个类或者一个接口,最好只负责一项职责。

    问题由来:类T负责两个不同的职责P1和P2。由于职责P1需要发生改变而需要修改T类,就有可能导致原来运行正常的职责P2功能发生故障。

    解决方法:遵循单一职责原则。分别建立新的类来对应相应的职责;这样就能避免修改类时影响到其他的职责;

    当遇到职责扩散的时候,在逻辑足够简单的时候,才可以在代码级别上面违反单一职责原则,只有类中方法数量足够少,才可以在方法级别上违反单一职责原则;

    优点:类的复杂性将会降低,可读性将会大大提高,维护性也会提高。


    里氏替换原则 Liskov Substitution Principle

    在使用基类的地方可以任意使用其子类,能保证子类完美替换基类;这一种精神其实是对继承机制约束规范的体现。在父类和子类的具体实现中,严格控制继承层次中的关系特征,以保证用子类替换基类时,程序行为不发生问题,且能正常进行下去。

    对于继承来说,父类定义了一系列的规范和契约,虽然不强制所有的子类必须遵从,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破环。

    如果非要重写父类的方法,比较通用的方法是:原来的父类和子类都继承一个更加通俗的基类,原有的继承关系去掉,采用依赖、聚合、组合等关系代替;

    原则包含了一下四层含义:
    * 子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法;
    * 子类可以增加自己特有的方法;
    * 当子类的方法重载父类的方法时,方法的形参要比父类方法的输入参数更佳宽松;
    * 当子类的方法实现父类的抽象方法时,方法的返回值要比父类更加严格;


    依赖倒置原则 Dependence Inversion Principle

    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象,其核心思想是依赖于抽象;

    问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来完成;这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原则操作;假如修改类A,会给程序带来不必要的风险。

    解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I来间接与类B和类C发生联系,则会降低修改类A的几率;

    在实际中,我们一般需要做到以下三点:
    * 低层模块尽量都要有抽象类或者接口,或者两者都有;
    * 变量的声明类型尽量是抽象类或者接口;
    * 使用继承时遵循里氏替换原则;


    接口隔离原则 Interface Segregation Principle

    定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上,否则将会造成接口污染;类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现它们不需要的方法;

    原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少;就是说,我们要为每个类建立专用的接口,而不要试图去建立一个庞大的接口供所有依赖它的类去调用;

    注意,接口尽量小,但是要有限度,对接口进行细化可以提高程序设计灵活性,但是如果过小,则会导致接口数量尽量小,使设计复杂化。所以一定要适度,为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来;

    规则:
    * 一个接口只服务于一个子模块或业务逻辑,服务定制;
    * 通过业务逻辑压缩接口中的public方法,让接口看起来更加精悍;
    * 已经被污染了的接口,尽量修改,如果变更风险太大,则用适配器模式进行转化;
    * 根据具体的业务,深入了解逻辑,用心感知去控制设计思路;

    如何实施接口隔离,主要有两种方法:
    1. 委托分离,通过增加一个新的接口类型来委托客户的请求,隔离客户和接口的直接依赖,注意这同时也会增加系统的开销;
    2. 多重继承分离,通过接口的多重继承来实现客户的需求;


    迪米特法则

    定义:一个对象应该对其他对象保持最少的了解,其核心精神就是:不和陌生人说话,通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少;这会导致类之间的耦合度降低,每个类都尽量减少对其他类的依赖。


    合成复用原则

    原则是尽量使用合成/聚合的方式,而不是使用继承;

    开闭原则

    定义:一个软件实体如类、模版和函数应该对扩展,对修改关闭;

    解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是修改已有的代码来实现变化;

    • 单一职责原则:实现类要职责单一;
    • 里氏替换原则:不要破坏继承体系;
    • 依赖倒置原则:面向接口编程;
    • 接口隔离原则:设计接口的时候要精简单一;
    • 迪米特法则:降低耦合;

    开闭原则:总纲,对扩展开放,对修改关闭;

    展开全文
  • 代码设计的几个基本原则

    千次阅读 2017-04-06 17:32:14
    Software entities should be open for extension,but closed for modification,(在设计一个模块的时候,应当使这个模块可以在不被修改的前提下扩展)。 对扩展开放open,对修改关闭close。 如何实现?1,抽象化是...

    1、OCP(Open-Close Principle)开闭原则

     

    Software entities should be open for extension,but closed for modification,(在设计一个模块的时候,应当使这个模块可以在不被修改的前提下扩展)。

    对扩展开放open,对修改关闭close。

    如何实现?1,抽象化是关键,2对可变性的封装原则(Principle of Encapsulation of Variation EVP)。3.对可能的拓展预留接口

    备注:

    1) 对于抽象化, 我的理解是, 接口是相对稳定的, 实现是根据需求多变的。对于大多数可能预料的变化点, 我们可以抽取出共性或者常态点, 进行接口的封装, 而选择不同的实现类嵌入模块, 从而达到可扩展的作用。

    2) 对于某个业务点, 可能以后有多种介入处理的情况, 那么这时候可以将业务抽象成事件(event)接口和监听器(listener)接口, 不同的处理需求生成不同的listener, 接入模块的listener收集器, 从而得到业务点的介入机会。最后达到功能的扩展。

    典型容易理解的例子,工厂模式。当需要新增加一个类的时候,直接继承product接口就可以了 , 由工厂类来组装产生需要的product, 而不用大范围修改原有代码。OCP~

    2、Liskov Subsitution Principle(LSP)里氏代换原则

     

    就是子类可以代替父类出现的任何地方,在抽象的时候,重要的要理解的一个地方两个类之间是什么关系,是“has-A”?还是“Is-a”的关系。在 “has-a”的关系中,两个类存在的是依赖的关系(在类A里面存在类B的的变量);在“Is-a”的关系中,可以提取这两个类的“共同代码”放在抽象类 C中,然后A,B继承与C,这也是一种重构。

    3、Dependency Inversion Principle(DIP)依赖倒转原则

     

    就是在我们编程的时候方法的参数类型,变量,对于其他具体类的依赖,我们尽量的使用抽象类。

    就是说尽量依赖于抽象,而不是依赖于实现。

    在书中两种表述:

    (1)Abstraction should not depend on details.details should depend on abstraction。(抽象不应当依赖于细节,细节应当依赖于抽象)。

    Abstraction就像是建筑物的基础,而其实现类就是在基础上面一层一层的往上面走。你拆掉最上面 那层,和拿走最下面的基础,有什么不同了,这就是差异了。所以Abstraction是要相当的稳定,是维护的重点。也正是因为稳定,所以我们尽量的依赖 于Abstraction,既是稳定系统,也是灵活系统。

    (2)Program to an Interface,not an implementation(要针对接口编程,不要针对实现编程)

    应当使用java接口和抽象java类进行变量的类型声明,参数的类型声明,方法返回值的类型和数据类型的转换。

    备注:

    依赖倒转原则的作用在于多模块或者类间有统一的”知识”, 都知道有这个接口, 都知道这个接口是这样用,会返回什么数据。

    至于最初的实现类是什么, 只有提供该接口功能的实现类自己关心, 其他模块或者类只管用就行了。即使以后需求更改, 实现会换成别的一个, 其他模块和类也无需修改代码。

    例如A模块提供了一个接口是: List getProducts()

    而B和C会使用该模块, 他们只知道这个方法就会返回List , 他们知道List和Product代表什么.

    但他们不会管你的接口内部是使用List list = new ArrayList() , 还是List lis = new LinkedList()

    或者具体的Product是什么(可能是衣服,鞋子等)

    4、Interface Segregation Principle(ISP)接口隔离原则

     

    限制一个实体对另一个实体通信时候的宽度。

    就是一个类对另外一个类依赖的时候,应当是建立在最小的接口上面。对于接口隔离原则来说,有两种接口,一种是真正意义上面的“java 接口”Interface;另外一种是指一个类的方法的集合。对于这来两种有,两个接口隔离的原则,对于一个类里面的方法的集合的接口隔离,我们称作是 “角色隔离原则”;另外一种叫做“定制服务”。

    定制服务,就是一个类,我给你这个客户端一些方法,我放在一个java接口(Interface)里面。给另外一个客户端另外一些方法,放在另外一个接口(Interface)。

    角色隔离原则,是指客户端要多个不同的类的方法,我们就搞几个不同类别的接口(Interface),在书中,这么比喻的,就相当于电影剧本里面的人物,我们找人来演,这个人就是具体的类。这就叫做角色隔离原则。

    5、Composition/Aggregation Reuse Principle(CARP)组合/聚合复用原则

     

    就是说要尽量的使用合成和聚合,而不是继承关系达到复用的目的。

    其实这里最终要的地方就是区分“has-a”和“is-a”的区别。相对于合成和聚合,继承的缺点在于:父类的方法全部暴露给子类。父类如果发生变化,子类也得发生变化。聚合的复用的时候就对另外的类依赖的比较的少。

    6、Least Knowledge Principle(LKP)最少知识原则,又称为“Law of Demeter”迪米特原则

     

    和ISP接口隔离原则一样,限制类与类之间的通信。ISP限制的是宽度,而LoD迪米特原则限制的是通信的广度和深度。

    LoD在广度上面,尽量减少远距离类的关联,而使用与自己有关的类,并且也与远距离类有关的类。

    可是这种做法有一点麻烦。多个远距离类产生关联的时候,不怎么容易处理,所以增加一个远距离类的抽象类。所有的远距离类都是通过抽象类的形式来访问。

    在深度上面,控制权限是最重要的,对于类,一个是default 和public,尽量最小权限;对于成员,private,default,protected,public。往上面走,权限越小,依赖的耦合就越小。

    有几种描述:

    (a)Only talk to your immediate friends.

    (b)Don’t talk to strangers.

    设计模式“facade”,”调停者模式”。在这里是IoD的典型表现。

    备注:

    当一个系统比较大的时候, 如果所有的模块都自己去寻找与自己相关的类的时候, 那么引用关系就会变得极度复杂, 耦合度高。

    这个时候最好就设定一个为各个模块所熟悉的对象, 例如Context容器。

    另外,各个模块可以应用facade模式, 提供一个简单的对外接口, 并将其嵌入Context容器。

    这样, 模块间通过熟人Context来获取其他模块的Facade接口, 即符合依赖倒转原则, 接口隔离原则和迪米特原则。

    展开全文
  • 代码设计基本原则

    千次阅读 2016-07-09 08:18:41
    1. Encapsulate what varies 2. Favor composition over inheritance 3.Program to interface,not implementations 4. Strive for loosely coupled designs between objects that interact ...
  • 而在html5设计过程中遵循了一系列原则,才使得html5得以快速推广,本文将介绍html5遵循的6个设计原则,具体如下 原则一:避免不必要的复杂性 html4 <!DOCTYPE ...
  • 代码设计原则

    千次阅读 2017-12-18 15:32:56
    单一职责原则 Single Responsibility Principle 定义:一个类或者一个接口,最好只负责...解决方法:遵循单一职责原则。分别建立新的类来对应相应的职责;这样就能避免修改类时影响到其他的职责; 当遇到职责扩
  • 或者创建一个方法如何给他起一个比较富有直译的方法名的时候,这个时候,束缚你的并不是你的代码能力,有时候就是你对于代码整体逻辑的设计的能力,而这个能力,是需要你长期的代码编写和代码设计的过程中,慢慢锻造...
  • 架构六大设计原则 设计原则图示: 这幅图清晰地表达了六大设计原则,下面将从原文、译文、理解、应用,这四个方面分别进行阐述。 1. 单一职责原则(Single Responsibility Principle - SRP) 原文:There should ...
  •  无论系统是采用电池供电还是由市电供电,应用需求将决定存储器的类型(易失性或非易失性)以及使用目的(存储代码、数据或者两者兼有)。另外,在选择过程中,存储器的尺寸和成本也是需要考虑的重要因素。对于较小...
  • 1. 单一职责原则:一个类或者一个接口只负责唯一项职责,尽量设计出功能单一的接口; 2. 依赖倒转原则:高层模块不应该依赖低层模块具体实现,解耦高层与低层。既面向接口编程,当实现发生变化时,只需提供新的实现...
  • 开闭原则:对外开放,对修改关闭。 里氏替换原则:继承必须确保超类所拥有的性质在子类中仍然成立。 依赖倒置原则:要面向接口编程,不要面向实现编程。 单一职责原则:控制类的粒度大小,将对象解耦,提高其内聚...
  • Java代码设计规范

    2014-08-19 11:19:53
    本文提供一整套编写高效可靠的 Java 代码的标准、约定和指南。它们以安全可靠的软件工程原则为基础,使代码易于理解、维护和...而且,通过遵循这些程序设计标准,你作为一个 Java 软件开发者的生产效率会有显著提高。
  • 而想要突出个性字体设计的特征,为企业或者品牌带来更好的消费者关注度或者带来商机,不仅需要个性,同时还需要遵循一定的原则,不然个性字体设计在使用的过程中可能会引来不必要的误会或者错误,而关于个性字体设计...
  • 软件工程六大设计原则

    千次阅读 2020-01-07 16:57:43
    1、单一职责原则 概念描述 对类来说,一个类应该只负责一项职责。如果一个类负责两个职责,可能存在职责1变化,引起职责2的变化情况。可以基于抽象逻辑,或者业务逻辑对类进行细化。 2、接口隔离原则 概念描述...
  • 工作至今没有认真读过什么书,觉得太浮躁,待业在家,希望自己可以珍惜这段时光,人生中最轻松愉快的时刻,当然还有个任务就是——毕业设计,=-=,无论如何,希望自己待业这段时间可以认真读几本书,好好做分享,...
  • 因此,高内聚、低耦合是一个软件系统设计中必须遵循的基本原则。  所谓高内聚,是指一个软件模块内各个元素彼此结合的紧密程度要高,即一个软件模块是由相关性很强的代码组成,只负责一项任务,也就是常说的单一...
  • 1. 软件设计模式的概念 软件设计模式(Software Design Pattern),又称设计模式,是一套被反复使用、多数人知晓的、经过分类编目的、...2. 软件开发设计过程中需要遵循原则 在软件开发中,为了提高软件系统...
  • 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置原则 设计模式六大原则(4):接口隔离原则 设计模式六大原则(5):迪米特法则 设计模式六大原则...
  • 优秀程序设计遵循原则

    千次阅读 2017-09-17 21:37:41
    可配置 (参数或者配置文件的形式);高效 (经过优化);简洁(一目了然 见名知意);...模块化,遵循单一责任原则;多用接口少用类;优先选择不可变的对象;经过充分的测试;尽量简短,调用成熟的库,避免bug
  • (图片来源于网络) 避免重复 尽量在项目的开发过程中减少产出重复的代码、方法和类,多数的设计模式根本目的是为了减少代码重复,尽可能将重复使用的代码抽象封装,是提高代码的可重用性和可维护性的最佳方式之一。...
  • 软件设计应遵循原则

    千次阅读 2007-03-19 12:10:22
    [b]转自[/b] ... ... [b]一、单一职责原则(SRP)[/b] 就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的指责.应该把多...
  • 第1原则:存在价值 一个软件系统因能给用户提供价值而具有存在价值,所有的决定都应该基于这个思想。在确定系统需求之前,在关注系统功能之前,在决定硬件平台或者开发过程之前,问问你自己:这确实能为系统增加真正...
  • 在面向对象的开发中,主要遵循的有以下6个设计原则: 单一职责 ,开放封闭 ,里氏代换,依赖倒转,迪米特法则,合成/聚合复用 下面将具体介绍这些设计原则: 单一职责原则:就一个类而言,应该仅有一个引起它发生...
  • 为得到较低的成本、提高可靠性和便于操作,电锁控制器的设计应遵循简明原则。本文介 绍采用RFM001射频模块的感应锁控制 器的设计思路,并提供软硬件设计实例。 感应锁控制器 , 射频IC卡
  • 设计模式的实现遵循了一些原则,从而达到代码的复用性及增加可维护性的目的,设计模式对理解面向对象的三大特征有很好的启发,不看设计模式,很难深层地体会到面向对象开发带来的好处 。在刚开始学习中,很难做到将...
  • C++代码设计与重用.pdf

    2012-10-30 01:00:14
    C++代码设计与重用,C++中函数设计需要遵守原则
  • PCB设计十大原则

    2020-07-18 00:47:41
    本文以下内容介绍了电子设计工程师在使用设计软件进行PCB布局设计及商业制造时牢记并践行的十条最有效的设计法则。工程师无需按时间先后或相对重要性依次执行这些法则,只需全部遵循便可极大地改变产品设计
  • Java代码优化六大原则

    2019-01-07 15:05:53
    代码优化第一步,单一职责原则 (Single Responsibility Principle)。对于一个java类,应该仅有一个引起它变化的原因,也就是说,一个类中,应该是一组相关性很高的函数、数据的封装。但是这个原则的界限划分的并不...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 141,925
精华内容 56,770
关键字:

代码设计应遵循的原则