Oop

设计模式系列文章链接：

如何看懂源码 (Jun 28, 2021)
如何重构代码 (Jun 28, 2021)
设计原则概述 (Jun 28, 2021)
Oop (Jun 28, 2021)
设计模式概述 (Jun 28, 2021)

如何判定某编程语言是否是面向对象编程语言？

什么是面向对象编程
面向对象编程是一种编程范式或编程风格。它以类或对象作为组织代码的基本单元，并将封装、抽象、继承、多态四个特性，作为代码设计和实现的基石。
严格定义的面向对象编程语言
面向对象编程语言是支持类或对象的语法机制，并有现成的语法机制，能方便地实现面向对象编程四大特性（封装、抽象、继承、多态）的编程语言。

实际上，面向对象编程从字面上，按照最简单、最原始的方式来理解，就是将对象或类作为代码组织的基本单元，来进行编程的一种编程范式或者编程风格，并不一定需要封装、抽象、继承、多态这四大特性的支持。但是，在进行面向对象编程的过程中，人们不停地总结发现，有了这四大特性，我们就能更容易地实现各种面向对象的代码设计思路。

比如，我们在面向对象编程的过程中，经常会遇到 is-a 这种类关系（比如狗是一种动物），而继承这个特性就能很好地支持这种 is-a 的代码设计思路，并且解决代码复用的问题，所以，继承就成了面向对象编程的四大特性之一。但是随着编程语言的不断迭代、演化，人们发现继承这种特性容易造成层次不清、代码混乱，所以，很多编程语言在设计的时候就开始摒弃继承特性，比如 Go 语言。但是，我们并不能因为它摒弃了继承特性，就一刀切地认为它不是面向对象编程语言了。

实际上，我个人觉得，只要某种编程语言支持类或对象的语法概念，并且以此作为组织代码的基本单元，那就可以被粗略地认为它就是面向对象编程语言了。至于是否有现成的语法机制，完全地支持了面向对象编程的四大特性、是否对四大特性有所取舍和优化，可以不作为判定的标准。基于此，我们才有了前面的说法，按照严格的定义，很多语言都不能算得上面向对象编程语言，但按照不严格的定义来讲，现在流行的大部分编程语言都是面向对象编程语言。

所以，多说一句，关于这个问题，我们一定不要过于学院派，非要给面向对象编程、面向对象编程语言下个死定义，非得对某种语言是否是面向对象编程语言争个一清二白，这样做意义不大。

OOA和OOD

面向对象分析、设计、编程到底都负责做哪些工作呢？
简单点讲，面向对象分析就是要搞清楚做什么，面向对象设计就是要搞清楚怎么做，面向对象编程就是将分析和设计的的结果翻译成代码的过程。

面向对象分析的产出是详细的需求描述。

面向对象设计的产出是类。在面向对象设计这一环节中，我们将需求描述转化为具体的类的设计。这个环节的工作可以拆分为下面四个部分。

划分职责进而识别出有哪些类

根据需求描述，我们把其中涉及的功能点，一个一个罗列出来，然后再去看哪些功能点职责相近，操作同样的属性，可否归为同一个类。

定义类及其属性和方法

我们识别出需求描述中的动词，作为候选的方法，再进一步过滤筛选出真正的方法，把功能点中涉及的名词，作为候选属性，然后同样再进行过滤筛选。

定义类与类之间的交互关系

UML 统一建模语言中定义了六种类之间的关系。它们分别是：泛化、实现、关联、聚合、组合、依赖。我们从更加贴近编程的角度，对类与类之间的关系做了调整，保留四个关系：泛化、实现、组合、依赖。

将类组装起来并提供执行入口

我们要将所有的类组装在一起，提供一个执行入口。这个入口可能是一个 main() 函数，也可能是一组给外部用的 API 接口。通过这个入口，我们能触发整个代码跑起来。

理解面向对象编程的四大特性

理解面向对象编程及面向对象编程语言的关键就是理解其四大特性：封装、抽象、继承、多态。不过，对于这四大特性，光知道它们的定义是不够的，我们还要知道每个特性存在的意义和目的，以及它们能解决哪些编程问题。

1. 封装（Encapsulation）

封装也叫作信息隐藏或者数据访问保护。类通过暴露有限的访问接口，授权外部仅能通过类提供的方式（或者叫函数）来访问内部信息或者数据。对于封装这个特性，我们需要编程语言本身提供一定的语法机制来支持。这个语法机制就是访问权限控制。在go语言中，通过首字母大小来决定属性或方法是否是私有的。

下面这段代码是金融系统中一个简化版的虚拟钱包的代码实现。在金融系统中，我们会给每个用户创建一个虚拟钱包，用来记录用户在我们的系统中的虚拟货币量。

type Wallet struct {
        id                      string
        createTime              int64
        balance                 *big.Float
        balanceLastModifiedTime int64
}

func NewWallet() *Wallet {
        return &Wallet{
                id:                      uuid.New().String(),
                createTime:              time.Now().Unix(),
                balance:                 big.NewFloat(0),
                balanceLastModifiedTime: time.Now().Unix(),
        }
}

func (w *Wallet) GetID() string                     { return w.id }
func (w *Wallet) GetCreateTime() int64              { return w.createTime }
func (w *Wallet) GetBalance() *big.Float            { return w.balance }
func (w *Wallet) GetBalanceLastModifiedTime() int64 { return w.balanceLastModifiedTime }

func (w *Wallet) IncreaseBalance(increasedAmount *big.Float) error {
        if increasedAmount.Cmp(big.NewFloat(0)) < 0 {
                return errors.New("invalid amount")
        }
        w.balance.Add(w.balance, increasedAmount)
        w.balanceLastModifiedTime = time.Now().Unix()
        return nil
}
func (w *Wallet) DecreaseBalance(decreasedAmount *big.Float) error {
        if decreasedAmount.Cmp(big.NewFloat(0)) < 0 {
                return errors.New("Invalid amount")
        }
        if decreasedAmount.Cmp(w.balance) > 0 {
                return errors.New("Invalid amount")
        }
        w.balance.Sub(w.balance, decreasedAmount)
        w.balanceLastModifiedTime = time.Now().Unix()
        return nil
}

从业务的角度来说，id、createTime 在创建钱包的时候就确定好了，之后不应该再被改动，所以，我们并没有在 Wallet 类中，暴露 id、createTime 这两个属性的任何修改方法，比如 set 方法。而且，这两个属性的初始化设置，对于 Wallet 类的调用者来说，也应该是透明的，所以，我们在 Wallet 类的构造函数内部将其初始化设置好，而不是通过构造函数的参数来外部赋值。

对于钱包余额 balance 这个属性，从业务的角度来说，只能增或者减，不会被重新设置。所以，我们在 Wallet 类中，只暴露了 increaseBalance() 和 decreaseBalance() 方法，并没有暴露 set 方法。对于 balanceLastModifiedTime 这个属性，它完全是跟 balance 这个属性的修改操作绑定在一起的。只有在 balance 修改的时候，这个属性才会被修改。所以，我们把 balanceLastModifiedTime 这个属性的修改操作完全封装在了 increaseBalance() 和 decreaseBalance() 两个方法中，不对外暴露任何修改这个属性的方法和业务细节。这样也可以保证 balance 和 balanceLastModifiedTime 两个数据的一致性。

2. 抽象（Abstraction）

在golang中，常借助interface这种语法机制，来实现抽象这一特性。基于接口的抽象，可以让我们在不改变原有实现的情况下，轻松替换新的实现逻辑，提高了代码的可扩展性。

或者通过函数这一语法机制来实现抽象，因为函数能包裹具体的实现逻辑，这本身就是一种抽象。调用者在使用函数的时候，并不需要去研究函数内部的实现逻辑，只需要通过函数的命名、注释或者文档，了解其提供了什么功能，就可以直接使用了。比如，我们在使用 C 语言的 malloc() 函数的时候，并不需要了解它的底层代码是怎么实现的。

抽象这个概念是一个非常通用的设计思想，并不单单用在面向对象编程中，也可以用来指导架构设计等。而且这个特性也并不需要编程语言提供特殊的语法机制来支持，只需要提供“函数”这一非常基础的语法机制，就可以实现抽象特性。所以，抽象并不是面向对象编程所特有的，这也是为什么有的人认为面向对象只有三大特性，不把“抽象”作为面向对象特性的原因。

抽象是人类处理复杂问题的有效手段，在面对复杂系统的时候，人脑能承受的信息复杂程度是有限的，所以我们必须忽略掉一些非关键性的实现细节。而抽象作为一种只关注功能点不关心实现的设计思路，正好帮我们的大脑过滤掉许多非必要的信息。

许多设计原则都体现了抽象这种设计思想，比如基于接口而非实现编程、开闭原则（对扩展开放、对修改关闭）、代码解耦（降低代码的耦合性）等。

换一个角度来考虑，我们在定义类的方法的时候，也要有抽象思维，不要在方法定义中，暴露太多的实现细节，以保证在某个时间点需要改变方法的实现逻辑的时候，不用去修改其定义。举个简单例子，比如getTencentYunPictureUrl()就不是一个具有抽象思维的命名，因为某一天如果我们不再把图片存储在腾讯云上，而是存储在私有云上，那这个命名也要随之被修改。相反，如果我们定义一个比较抽象的函数，比如叫做getPictrueURL()，那即便内部存储方式修改了，我们也不需要修改命名。

抽象分为两种，一种是自上而下的抽象，一种是自下而上的抽象。这两种方法相互补充，同时使用这两种方法才能抽象得好。

“基于接口而非实现编程”这条原则的另一个表述方式，是“基于抽象而非实现编程”。后者的表述方式其实更能体现这条原则的设计初衷。在软件开发中，最大的挑战之一就是需求的不断变化，这也是考验代码设计好坏的一个标准。越抽象、越顶层、越脱离具体某一实现的设计，越能提高代码的灵活性，越能应对未来的需求变化。好的代码设计，不仅能应对当下的需求，而且在将来需求发生变化的时候，仍然能够在不破坏原有代码设计的情况下灵活应对。而抽象就是提高代码扩展性、灵活性、可维护性最有效的手段之一。

在编写代码的时候，要遵从“基于接口而非实现编程”的原则，具体来讲，我们需要做到下面这 3 点。

函数的命名不能暴露任何实现细节。比如，前面提到的 uploadToTencentYun() 就不符合要求，应该改为去掉 TencentYun 这样的字眼，改为更加抽象的命名方式，比如：upload()。
封装具体的实现细节。比如，跟腾讯云相关的特殊上传（或下载）流程不应该暴露给调用者。我们对上传（或下载）流程进行封装，对外提供一个包裹所有上传（或下载）细节的方法，给调用者使用。
为实现类定义抽象的接口。具体的实现类都依赖统一的接口定义，遵从一致的上传功能协议。使用者依赖接口，而不是具体的实现类来编程。

注意：如果在我们的业务场景中，某个功能只有一种实现方式，未来也不可能被其他实现方式替换，那我们就没有必要为其设计接口，也没有必要基于接口编程，直接使用实现类就可以了。

3. 继承（Inheritance）

继承是用来表示类之间的 is-a 关系，比如猫是一种哺乳动物。从继承关系上来讲，继承可以分为两种模式，单继承和多继承。单继承表示一个子类只继承一个父类，多继承表示一个子类可以继承多个父类，比如猫既是哺乳动物，又是爬行动物。

为了实现继承这个特性，编程语言需要提供特殊的语法机制来支持，比如C++ 使用冒号（class B : public A），Python 使用括号 ()

继承其实是一种反模式，有损可读性和可维护性：为了了解一个类的功能，我们不仅需要查看这个类的代码，还需要按照继承关系一层一层地往上查看“父类、父类的父类……”的代码。还有，子类和父类高度耦合，修改父类的代码，会直接影响到子类。

证明golang中不支持继承：

package main
type Fly struct {}

func (f *Fly) CanFly() { println("can fly") }

type Owl struct {Fly}

func test(f *Fly) { f.CanFly() }

func main() {
        test(new(Owl))  // cannot use new(Owl) (value of type *Owl) as *Fly value in argument to test
}

理论上讲，通过组合、接口、委托三个技术手段，我们完全可以替换掉继承。

现在有这样的需求：

设计一个关于鸟的类。我们将“鸟类”这样一个抽象的事物概念，定义为一个抽象类 AbstractBird。所有更细分的鸟，比如麻雀、鸵鸟、乌鸦等，都继承这个抽象类。

由于并不是所有的鸟都会飞，所以需要通过 AbstractBird 类派生出两个更加细分的抽象类：会飞的鸟类 AbstractFlyableBird 和不会飞的鸟类 AbstractUnFlyableBird。让麻雀、乌鸦这些会飞的鸟都继承 AbstractFlyableBird，让鸵鸟、企鹅这些不会飞的鸟，都继承 AbstractUnFlyableBird 类。

假设并不是所有的鸟都会叫，那么就需要再定义四个抽象类（AbstractFlyableTweetableBird、AbstractFlyableUnTweetableBird、AbstractUnFlyableTweetableBird、AbstractUnFlyableUnTweetableBird）

假定并不是所有的鸟都会下蛋，那么就需要再定义8个抽象类。如果还要考虑其他的情况，比如有没有羽毛，那类的继承层次会越来越深、继承关系会越来越复杂。而这种层次很深、很复杂的继承关系，一方面，会导致代码的可读性变差。因为我们要搞清楚某个类具有哪些方法、属性，必须阅读父类的代码、父类的父类的代码……一直追溯到最顶层父类的代码。另一方面，这也破坏了类的封装特性，将父类的实现细节暴露给了子类。子类的实现依赖父类的实现，两者高度耦合，一旦父类代码修改，就会影响所有子类的逻辑。

用接口取代继承后的样子是这样的：

type Flyable interface { Fly() }

// Tweetable 可以鸣叫
type Tweetable interface { Tweet() }

// EggLayable 可以下蛋
type EggLayable interface { LayEgg() }

// Ostrich 鸵鸟可以叫，可以下蛋
type Ostrich struct {}
func (o *Ostrich) Tweet() { println("我可以叫") }
func (o *Ostrich) LayEgg() { println("我可以下蛋") }

// Sparrow 麻雀可以飞，可以叫，可以下蛋
type Sparrow struct {}
func (s *Sparrow) Fly() { println("我可以飞") }
func (s *Sparrow) Tweet() { println("我可以叫") }
func (s *Sparrow) LayEgg() { println("我可以下蛋") }

接口只声明方法，不定义实现。也就是说，每个会下蛋的鸟都要实现一遍 layEgg() 方法，并且实现逻辑是一样的，这就会导致代码重复的问题。那这个问题又该如何解决呢？

我们可以针对三个接口再定义三个实现类，它们分别是：实现了 Fly() 方法的 FlyAbility 类、实现了 Tweet() 方法的 TweetAbility 类、实现了 LayEgg() 方法的 EggLayAbility 类。然后，通过组合和委托技术来消除代码重复。具体的代码实现如下所示：

type Flyable interface { Fly() }
type FlyAbility struct {}
func (f *FlyAbility) Fly() { println("我可以飞") }

// Tweetable 可以鸣叫
type Tweetable interface { Tweet() }
type TweetAbility struct {}
func (f *TweetAbility) Tweet() { println("我可以叫") }

// EggLayable 可以下蛋
type EggLayable interface { LayEgg() }
type EggAbility struct {}
func (f *EggAbility) LayEgg() { println("我可以下蛋") }

// Ostrich 鸵鸟可以叫，可以下蛋
type Ostrich struct {
        tweetAbility TweetAbility
        eggAbility EggAbility
}
func (o *Ostrich) Tweet() { o.tweetAbility.Tweet() }
func (o *Ostrich) LayEgg() { o.eggAbility.LayEgg() }

// Sparrow 麻雀可以飞，可以叫，可以下蛋
type Sparrow struct {
        flyAbility  FlyAbility
        tweetAbility TweetAbility
        eggAbility EggAbility
}
func (s *Sparrow) Fly() { s.flyAbility.Fly() }
func (s *Sparrow) Tweet() { s.tweetAbility.Tweet() }
func (s *Sparrow) LayEgg() { s.eggAbility.LayEgg() }

不过golang对组合和委托做了优化，所以上面的代码可以简化为如下：

type Flyable interface { Fly() }
type FlyAbility struct {}
func (f *FlyAbility) Fly() { println("我可以飞") }

// Tweetable 可以鸣叫
type Tweetable interface { Tweet() }
type TweetAbility struct {}
func (f *TweetAbility) Tweet() { println("我可以叫") }

// EggLayable 可以下蛋
type EggLayable interface { LayEgg() }
type EggAbility struct {}
func (f *EggAbility) LayEgg() { println("我可以下蛋") }

// Ostrich 鸵鸟可以叫，可以下蛋
type Ostrich struct {TweetAbility; EggAbility}

// Sparrow 麻雀可以飞，可以叫，可以下蛋
type Sparrow struct { FlyAbility; TweetAbility; EggAbility}

4. 多态（Polymorphism）

golang中使用duck-typing类型的interface来实现多态，只要这个结构体实现了这个接口的所有方法，那它就可以赋值给使用该接口的变量。

多态是很多设计模式、设计原则、编程技巧的代码实现基础，比如策略模式、基于接口而非实现编程、依赖倒置原则、里式替换原则、利用多态去掉冗长的 if-else 语句等等。

专题: 设计模式

本文发表于 2021-06-28，最后修改于 2021-06-28。

本站永久域名「 jiavvc.top 」，也可搜索「后浪笔记一零二四」找到我。

上一篇 « 设计原则概述下一篇 » 设计模式概述

Oop