怎样才能写出规范的好代码?
本文收录于JavaStarter ,里面有我完整的Java系列文章,学习或面试都可以看看
(一)前言
最近发现一件事情,自己写的代码和公司里工作5到10年的前辈写的代码虽然功能一样,但是他们的代码更规范,更优雅。比如有时候我会给一个需求写一个方法,但是有些人就可以好几个需求通过同一个方法实现。因此有了今天这个疑问,怎样才能写出规范的好代码?
(二)什么样的代码是好的代码
我们在写程序的过程中,除了要实现功能之外,还需要考虑:
1.代码重用性(相同功能的代码,不用多次编写)
2.可读性(便于其他程序员阅读与理解)
3.可扩展性(需要新增功能时可以很方便的维护)
4.可靠性(新功能的加入不会对已有的功能造成影响)
5.高内聚、低耦合
而为了实现上面这些目的,我们需要遵循一些原则,因此,设计模式出现了。
(三)设计模式的原则
设计模式的原则,就是指在编写程序时应该遵守的原则,设计模式的原则也是各种设计模式设计的依据。
设计模式常用的原则有以下七种:
1.单一职责原则
2.接口隔离原则
3.依赖倒转原则
4.里式替换原则
5.开闭原则
6.迪米特法则
7.合成复用原则
接下来我将对以上七种设计模式进行介绍。
(四)单一职责原则
单一职责原则顾名思义就是每个类只负责一项原则,很好理解,如果一个类中负责了两个甚至更多的职责,当其中一个职责的需求发生变更而要改变时,可能造成其他职责的执行错误。
单一职责原则的注意事项和原则:
-
降低类的复杂度,一个类只负责一项职责
-
提高类的可读性,可维护性
-
降低变更引起的风险
-
通常情况下,我们都应该遵守单一职责原则,除非该类的逻辑足够简单,才可以在代码中违反单一职责原则。
(五)接口隔离原则
接口隔离原则的意思是表明客户端不应该被强迫实现一些他们不会使用的接口,应该把胖接口(指一个接口中有大量不会使用的方法的接口)中的方法分组,然后用多个接口替代它,每个接口服务于一个子模块。简单地说,就是使用多个专门的接口比使用单个接口要好很多。
(六)依赖倒转原则
依赖倒转原则的含义有下面三点:
1、高层模块不应该依赖低层模块,两者都应该依赖其抽象
2、抽象不应该依赖细节
3、细节应该依赖抽象
光看三点含义会很难理解,但是从设计理念层面就会好理解很多,依赖倒转原则的设计理念是:以接口和抽象为基础的系统会比以细节为基础的系统稳定很多。因此我们设计一个系统时,应该先设计接口和抽象类,然后通过具体的实现类去实现细节功能。
因此依赖倒转原则的核心是面向接口编程。
(七)里式替换原则
里式替换原则主要为了解决继承会导致的一些问题。
继承作为面向对象的三个基本特性之一,在给程序带来便利的同时也增加了一些潜在的风险。比如子类B和子类C同时继承父类A,如果父类A需要修改,必须要考虑所有的子类,否则就可能导致子类的方法出现故障。
里式替换原则的定义为:继承必须确保超类所拥有的性质在子类中仍然成立。
通俗来讲,就是子类可以扩展父类的功能,但不能改变父类原有的功能。
在实际编程中,我们遵循里式原则的方式就是子类尽量不要去重写父类的方法,通过依赖、聚合、组合等关系代替。
(八)开闭原则
开闭原则的核心是一个应用,应该对扩展开放,对修改关闭。
简单来讲,如果一个需求变更了,尽量通过扩展的方式去实现,而不是去修改原来的代码。而在代码中具体实现的话就是合理利用接口和抽象类,扩展时只需要继承抽象类或实现接口而不用去修改原来的代码。
开闭原则是编程中最基础和重要的原则。
(九)迪米特法则
迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。
通过迪米特法则,可以实现代码之间的低耦合。我们在写代码时,尽量减少每个类不必要的依赖,陌生的类不要作为成员变量出现在类里(这里陌生的类是值没有在方法参数或者请求参数中出现的类)。
但是迪米特法则并非要求类之间完全没有依赖!
(十)合成复用原则
合成复用原则的核心是尽量使用合成(聚合)的方法,而不是使用继承。
举个例子:如果A类想要用B类的某个方法,通过继承是肯定可以实现的。但是继承的话就会导致A和B的耦合性增强,这个时候就可以通过合成的方式,在A类中引用B类,来降低耦合性。
(十一)总结
即使将上面的七种原则全部理解清楚,想要真的在编码时完全按照原则来还是很难,这是一个长期的过程,而我们能做的是尽量在赶工的同时留意代码质量,逐步将设计模式等准则应用在代码中。
我是鱼仔,我们下期再见!(最近太忙了,更新可能会有点慢)

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
警惕看不见的重试机制:为什么使用RPC必须考虑幂等性
欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章,主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等,同时欢迎大家加我个人微信「java_front」一起交流学习 0 文章概述 在RPC场景中因为重试或者没有实现幂等性而导致的重复数据问题,必须引起大家重视,有可能会造成例如一次购买创建多笔订单,一条通知信息被发送多次等问题,这是技术人员必须面对和解决的问题。 有人可能会说:当调用失败时程序并没有显示重试,为什么还会产生重复数据问题呢?这是因为即使没有显示重试,RPC框架在集群容错机制中自动进行了重试,这个问题必须引起关注。 本文我们以DUBBO框架为例分析为什么重试,怎么做重试,怎么做幂等三个问题。 1 为什么重试 如果简单对一个RPC交互过程进行分类,可以分为三类:响应成功、响应失败、没有响应。 对于响应成功和响应失败两种情况,消费者很好处理。因为响应信息明确,所以只要根据响应信息,继续处理成功或者失败逻辑即可。但是没有响应这种场景比较难处理,这是因为没有响应可能包含以下情况: (1)生产者根本没有接收到请求 (2)生产者接收到请求并且已处理成功,但是消费者没有...
- 下一篇
Kubernetes Pod篇:带你轻松玩转Pod
本文将对Kubernetes如何发布与管理容器应用进行详细说明,主要包括Pod概述、基本用法、生命周期、Pod的控制和调度管理、Pod的升级和回滚,以及Pod的扩容机制等内容,并结合具体详细的示例,带你轻松玩转Pod,开启Kubernetes容器的编排之路。 1、Pod概述 1.1 Pod是什么? Pod是Kubernetes中的原子对象,是基本构建单元。 Pod表示集群上一组正在运行的容器。通常创建Pod是为了运行单个主容器。Pod 还可以运行可选的sidecar容器,以实现诸如日志记录之类的补充特性。(如:在Service Mesh中,和应用一起存在的istio-proxy、istio-init容器) 一个Pod中可以包含多个容器(其他容器作为功能补充),负责处理容器的数据卷、秘钥、配置。 1.2 为什么要引入Pod概念? 原因1:Kubernetes可扩展 Kubernetes不会直接和容器打交道,Kubernetes的使用者能接触到的资源只有Pod,而Pod里可以包含多个容器。当我们在Kubernetes里用kubectl执行各种命令操作各类资源时,是无法直接操作容器的,往往都...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS关闭SELinux安全模块
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Linux系统CentOS6、CentOS7手动修改IP地址