架构漫谈系列(3)其他原则

在最开始,先重复一下第一篇的内容,这个系列是写我们如何来组织代码,如何提高可扩展性和维护性的,并不涉及到网络拓补结构或各类中间件的使用。

首先,提一提面向对象设计的五大原则:SOLID。

SOLID原则

SOLID都是些什么呢?
– SRP, Single responsibility principle,单一职责。一个类只能有一个职责,如果这个类需要被修改,那只能是某一个需求更改导致的(仅此一个,没有更多的)。例如,book类里面有一个print的函数,当我们修改book类的书名时,我们需要改book类,当我们把book的打印从打印到A4改成打印成6寸时,也需要修改此类,这就违背了SRP原则。
– OCP, Open/closed principle,开闭原则,Open for extension, but closed for modification
– LSP, Liskov substitution principle,父类能够被子类无忧的替代,不必担心产生副作用。
– ISP, Interface segregation principle,如果一个接口能够被拆分成多个接口,那就不该用这个通用的接口来呈现。
– DIP, Dependency Inversion principle,依赖于抽象,而不依赖与具体的实现。

今天先从SRP和DI开始。

单一职责

它的定义上面已经讲过了。
这一条是用来帮助我们创建更为松耦合和模块化的程序,因为每种不同的行为我们都封装到一个新的类或对象里面去了。未来要增加新的行为或特性,新增的内容也会增加新的对象里面,而不是把这些行为加到原来的对象上去。
这样做的好处是更安全,更不容易出错,因为以前的类可能是含有多种多样的依赖关系的,但新增加的类却没有那些依赖在里面。所以我们可以放心的修改系统行为,不必担心修改带来的副作用。

在分层结构中,这个思想也有体现。我们的UI/Presentation层专管UI的显示,logic层专攻业务逻辑,数据访问层只做数据访问相关内容。其实,都是同样的道理。

如果SRP思想贯穿了你的整个程序,你的逻辑层里的某一个服务是不是就成了微服务,一个微服务只有一个单一的职责,你要给你的程序增加功能,那再加一个微服务即可(切忌在已有的微服务上添加)

依赖反转(Dependency Inversion)

应用程序内部的依赖不应该依赖于具体的实现,应该依赖于抽象。
也是五大原则之一。

很多应用的依赖是在编译期就确定了依赖的顺序,就如同模块A调用了模块B的一个函数,刚好这个模块B内的函数又调用了模块C的某个函数,于是,A就依赖B,B依赖于C。

应用了DIP之后,就像这个样子:

可以看到,ClassA不再依赖于Class B,转而依赖InterfaceB,ClassB也不再依赖于Class C,转变成Interface B依赖于Interface C。

ClassA现在依赖的是B的抽象(即Interface B),这使得A在运行时依然可以调用到B的函数,运行时应有的行为还能得以保留。不过B依赖已经变化了,它现在依赖于Interface B了(反转依赖),现在的好处在于,不但B的功能可用,未来你想变成B1,B2,B3,这些都不必修改Class A了(如果你现在还不明白如何去实现,参考Ioc Container的实现)。

依赖翻转是构建松耦合应用的关键所在,既然具体的实现都依赖于更高层的抽象了,那么程序就应该更容易被测试、维护和模块化。其实依赖注入(Dependency injection)也是准照这个原则来扩展实现的,所以掌握这个方法也是十分的重要。

以下原则跟SOLID无关,但我认为也是比较重要的。

显式依赖

如果函数或类必须依赖其他类或对象的某些状态才能正常工作,那应该显式的声明其依赖的对象或类。
这有点拗口。

实际上类的构造函数提供了一个约定:我要构造这个类A的对象,需要提供1、2、3、4个参数,如果没有这几个参数,我的类就可能工作不正常。
ClassA的依赖关系很明确,就是要1、2、3、4个参数,这是合理的。

假设这样一种情况,ClassA除了上述依赖以外,后来增加了一个新的依赖,在增加这个依赖的时候,我没有将它显示的写在构造函数里面,因为这个依赖项是个全局对象。

一般来说这样的代码运行起来也没有什么问题,但是在实际上,它在逻辑上已经引发了一个问题:你的这个类的依赖关系内外不一致。试想如果在另外一个场景里,这个全局的对象失效了或不存在,那么你的这个类就不能用了。
你的类已经不能用了,但是你们团队里面的其他成员可能并不知道,他们仍然按照之前的模式继续使用你的类,于是这就引起了潜在的错误。

如果你的类能够显式声明它的所有依赖,你的类才能够更友好,代码本身也能更清楚的表达自身的含义。你的小组其他成员相信,只要完全的传递了你要的参数,你的代码就一定会按既定的逻辑运行下去。

避免重复(Don’t repeat yourself)

重复代码是后期bug修复的大敌。

我们要尽量避免编程时使用复制和粘贴的功能,如果同样的逻辑在代码里的多个位置出现,每次我们维护的时候就不得不同时维护多处。当功能转交给其他人时,其他人也会厌烦多处查找这些问题;其他人将这类代码转交给你时,你也会头疼不已。

忽略持久化(Persistence Ignorance)

这个概念PI,有些地方也称作持久性无知,是指你需要存储某个对象,但是这些代码不应该受到持久化方式更改的的影响。
在.Net里,有一种类叫POCOs(Plain Old CLR Objects),在Java里,这种叫POJOs(Plain Old Java Objects),这种类是不需要从基类或接口来继承的。
我们需要保证这类对象不要插手如何保存或如何获取(持久化和获取数据回来)。

做到这一点,我们的业务逻辑能更纯粹,而存储对象时,也能灵活地按需调整(比如说用Redis或Azure或Sql Server等等),无论存储的策略如何调整,我们的业务逻辑都是稳定的。

注意,如果你的代码有以下几类情况,那这些代码可能就是违反PI规则的:
– 必须继承自某个基类或必须实现某个接口
– 类的内部含有保存他们自己的代码
– 必须要写构造函数
– 属性上要求加Virtual
– 有自定义的存储相关的Attribute

如果类里面有上面的逻辑,暗示着这些类的持久化跟持久化的策略产生关联性,可以理解为她们是耦合的,将来如果要更换新的持久化方式,也许就比较困难了。

有界上下文(Bounded Contexts)

有界上下文是DDD中的一个核心模式,这种模式是帮助我们剥离开复杂的应用程序,将他们隔离开,形成不同的上下文边界。不同的模块有着不同的上下文,且能独立调用,而各自的模块可以有自己的持久化的,互不干扰。

在大型的应用程序中,不同的人对不同的的东西可能取相同的名字,这跟我们程序的类一样,为何我们要在外面放一个namespace在外面,其实也是形成一个边界。程序内部也是如此。

例如,售楼部内的员工把商品房认为是产品(Product);但是在工程部,可能他们把刷灰和修理管道的服务叫做产品,为了消除这些歧义,可以定义一个边界,分离开两种情况,以免在系统内产生混淆。

结语

这是这个系列的最后内容,实际上每一个小点都能展开成一大章节来说,后续有时间可以进行延伸的讨论。而因为这篇的内容除了SOLID外,跨度都还比较大,以至于我都不好写标题,暂以《其他原则》为题好了。

面向对象编程其实挺难的,我们很多的人都没有真正的理解面向对象,以至于所谓的面向对象,就是我们用上了class关键字而已。如果有时间,可以专门看看设计模式的书,相信还是会有很多的收获的。

这些内容可能过于偏于理论,但是有了这些理论的指导,我们的开发的日子才会更容易一些。但话又说回来,如果你要做的项目是个一杆子买卖,根本不会持续维护,那你还是尽量的使用反模式吧,又快又省心不烧脑。可是如果你的项目是长度维护的项目,必要的考量还是需要的,否则,你就陷入了泥潭,总是发梦期望公司将原来的推翻重写,一次偿还所有的技术债了。

这种人呢,我们把他叫做『老赖』,以前的技术债还不清了……那不还了,申请『破产』,我们重来吧。

本文地址:https://1few.com/architecture-others/

《架构漫谈系列(3)其他原则》有1个想法

  1. 博主你好
    请问怎么样来学习编程比较好呢?
    我自己也有疑问,现在老板其实都不要求写得好,都是要写得快,但是到了最后感觉自己就是熟练工,一事无成,确实有点迷茫

发表评论

电子邮件地址不会被公开。 必填项已用*标注