如何写出优秀的代码?设计模式六大原则告诉你
Posted 顾林海
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何写出优秀的代码?设计模式六大原则告诉你相关的知识,希望对你有一定的参考价值。
温馨提示:阅读本文需要4-5分钟(少量代码)
今天,我们来解决一个问题:
如何写出优秀的代码?设计模式六大原则告诉你
人生一切难题,知识给你答案。
单一原则
定义:应该有且仅有一个原因引起类的变更。
单一原则适用于接口、类以及方法,对于接口,我们在设计的时候一定要做到单一,但对于实现类就需要多方面考虑。生搬硬套单一原则会引起类的剧增,给维护带来非常多的麻烦。而且过分细分类的职责也会人为地增加系统的复杂性。
最常见的就是Activity类,如果我们在Activity中进行网络请求操作,请求完毕又进行业务处理,处理之后通知View的刷新,这样做的话Activity就会变的十分臃肿,Activity的职责就是显示视图并处理与用户的交互,如何解决呢?抽离网络请求操作与业务操作,通过接口回调通知Activity视图的变更,推荐使用MVP模式。
对于单一原则,建议是接口一定要做的单一职责,类的设计尽量做到只有一个原因引起变化。
开闭原则
定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
开闭原则的定义已经非常明确地告诉我们:软件实体应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。
比如现有一个类ProductFactory用来生产一堆产品:
public class ProductFactory {
private final static List<Product> productList=new ArrayList<>();
static {
Product product=new Product();
product.setPrice(10);
product.setName("产品A");
productList.add(product);
product=new Product();
product.setPrice(10);
product.setName("产品B");
productList.add(product);
}
public List<Product> getProduct(){
return productList;
}
}
客户端通过创建ProductFactory并调用getProduct方法就可以获取产品列表,看似非常完美,如果这个时候产品说我想获取产品A,然后过了几天由于产品效益不是很高,需要做打折处理,这个时候怎么办?是在ProductFactory类中新增方法还是直接在该方法中修改?由于业务的不断变化,造成该类被频繁修改。
使用开闭原则来解决,创建一个接口IProduct,内部约定一个规则:
public interface IProduct {
List<Product> getProduct();
}
正常产品获取:
public class ProductFactory implements IProduct {
private final static List<Product> productList=new ArrayList<>();
static {
Product product=new Product();
product.setPrice(10);
product.setName("产品A");
productList.add(product);
product=new Product();
product.setPrice(10);
product.setName("产品B");
productList.add(product);
}
@Override
public List<Product> getProduct() {
return productList;
}
}
客户端使用:
public class Client {
public static void main(String[] args){
IProduct productFactory=new ProductFactory();
List<Product> productList=productFactory.getProduct();
}
}
产品经理说我只需要产品A的产品,通过扩展来实现:
public class ProductAFactory implements IProduct {
private final static List<Product> productList=new ArrayList<>();
static {
Product product=new Product();
product.setPrice(10);
product.setName("产品A");
productList.add(product);
product=new Product();
product.setPrice(10);
product.setName("产品B");
productList.add(product);
}
@Override
public List<Product> getProduct() {
List<Product> list=new ArrayList<>();
for(Product product:productList){
boolean isProductA=product.getName().equals("产品A");
if(isProductA){
list.add(product);
}
}
return list;
}
}
客户端那边只需要把ProductFactory替换成ProductAFactory即可,即使产品说需要将产品进行打折处理,我们只需要创建打折类实现IProduct并实现getProduct方法进行打折处理。
里氏替换原则
定义:所有引用基类(父类)的地方必须能透明地使用其子类的对象。
里氏替换原则告诉我们,在软件中将一个基类替换成其子类对象,程序将不会产生任何错误和异常;反之则不行,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。
子类的所有方法必须在父类中声明,或子类必须实现父类中声明的方法。根据里氏替换原则,为了保证系统的扩展性,在程序中通常使用父类来进行定义。
在运用里氏替换原则时,尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法。运行时,子类实例替换父类实例,我们可以方便地扩展系统的功能。
依赖倒置原则
定义:高层模块不应该依赖低层模块,两者都应该依赖于抽象。抽象不应该依赖于细节,细节应该依赖于抽象。
在Java中,抽象指接口或者抽象类,两者都不能直接被实例化。
细节就是实现类,实现接口或继承抽象类而产生的就是细节。
高层模块就是调用端,低层模块就是具体实现类。
依赖倒置的具体表现就是,模块间的依赖通过抽象发生,实现类之间不发生直接依赖关系,其依赖关系是通过接口或者抽象类产生的。
如果类与类直接依赖细节,那么就会直接耦合,如此一来当修改时,就会同时修改依赖者代码,限制了可扩展性。
迪米特原则
定义:一个软件实体应当尽可能少地与其他实体发生相互作用。
迪米特原则又被称为最少知识原则,通俗地讲,设计系统时尽量减少对象之间的交互,如果两个对象之间不必彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用。
如果其中的一个对象需要调用另一个对象的某个方法,可以通过第三方转发这个调用。引入一个合理的第三者来降低现有对象之间的耦合度。
接口隔离原则
定义:一个类对另一个类的依赖应该建立在最小的接口上。
建立单一接口,不要建立庞大臃肿的接口;尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图建立一个很庞大的接口供所有依赖它的类调用。
接口尽量小,但要有限度。对接口进行细化可以提高程序设计的灵活性,但是如果过度的细化,则会造成接口数量过多,使设计复杂化。
科技快讯
据新浪科技报道,今天百度创始人兼CEO李彦宏发内部信,全文多次提高百度对用户的重视。李彦宏称,公司营收突破千亿,百度的使命是用科技让复杂的世界更简单,百度要成为最懂用户,并能帮助人们成长的全球顶级高科技公司,这是百度的愿景。
李彦宏在此次的内部信中多次提到了“用户”一词。他还表示,这是百度历史上首次发布愿景,这24个字将上承新使命、下展公司“夯实移动基础、决胜AI时代”的整体战略,锚定百度在未来的新坐标——不仅是聚焦用户、成就他人的百度,也是立足全球、有所作为的百度。
wx号:gulinhai531
不定期推出优质文
章,喜欢的朋友们
给我个好看。
以上是关于如何写出优秀的代码?设计模式六大原则告诉你的主要内容,如果未能解决你的问题,请参考以下文章