首页 > 嗟来之食 > 架构漫谈系列(2) 封装(Encapsulation)
2017
08-17

架构漫谈系列(2) 封装(Encapsulation)

这是这个系列的第二篇。在第二篇里,我决定讲一讲封装。
程序的不同部分应该用封装去互相隔离,模块之间应该不应该产生很随意的关联。
可能有的人觉得不解,又或觉得是有道理的废话,不急,先一步一步来。
我们先来看看面向对象的三个基本特征是什么?

继承
多态
封装

如果你是科班毕业,这6个字应该是你第一次学到类(class)的时候就听老师说了。
我们老师的话大概是这样的:

在类里面,封装就是通过一些手段来限制类外部的访问,依此隔离出类相对封闭的区域。

也就是说,如果有人想要操作类里面的成员(field),不应该让它直接进行这样操作。而应该通过良好定义的函数(或属性的Setter)来完成。除非你有不得不如此的理由,否则就不应该让人家直接访问你的私有成员。
下面的代码通常是bad practice。
任意的类均能任意的修改Person内的Name和Age,即便Name写成乱码或将Age设成负数,都是可以做到的,Person类自己是控制不住的。
public class Person
{
public int Age;
public string Name;
}
下面的代码则是演示的使用Setter或函数来控制name和age的值,防止错误的值被录入。
public class Person
{
private int _age;
private string _name;

public int Age
{
get => _age;
set
{
if (value >= 0 && value <= 200 && value != _age)
_age = value;
}
}

public void SetName(string newName)
{
if (!string.IsNullOrWhiteSpace(newName))
_name = newName;
}
}
上面的例子描述了class对外的封装。
同样道理,程序的模块之间也是如此,模块之间不应该任意的暴露内容出来,而应该通过良好定义的接口来实现模块之间的协作。
这种封装的设计方式隔离了模块内部的设计,只要模块的对外接口不产生变化,模块内部的任意变化都不会对模块间协作造成影响,从而实现子系统间的隔离。
实例
假如我们现在要设计一个系统,你可以简单的理解成某个在线商城的发货的或物流子系统。
这个子系统需要完成几个基本的功能:

将货物寄送出去(发货),这是最基本的功能
其他的子系统需要一个API来查询当前的寄送的进度
发货后,需要得到发货的运输船的信息
如果客户临时又取消了订单,则依据具体的寄送进度通知对应的运输船取消订单
后来业务扩大了,我们可能需要考虑增加其他的运输方式,例如空运。

我们首先分析一下,应该如何来完成这个功能。
首先,我们需要一个运输中心(ShippingCenter),使用这个运输中心,可以寄送本公司任意的产品(Product)。
我们需要返回运输船的信息,为了更好的表达我的想法,这里理解成要返回运输船的实例。
我们的运输船能直接告诉我们当前运输的状态,如果在运输前需要召回任何产品,我们的运输船会安排人自动的处理。
所以伪代码大概就长这个样子,ShippingCenter能运输货物,并返回运送这个货物的运输船实例,然后运输船本身有函数和属性来查看状态和召回货物。
也就是说,这是对外的最基本的接口:
class ShippingCenter{
Steamship Ship(Product p);
}
class Steamship{
ShipingProgress DeliveryProgress{get;}
void Recall(Product p);
}
可是,以后业务的扩张,增加了空运,那怎么办呢?
假如ShippingCenter不要返回SteamShip的具体类就好了。
那么,不如我们增加一个接口吧,比如,就叫IVehicle好了,其实vehicle也是个抽象的概念,我在iciba上查到vehicle的含义是『交通工具』。
慢……这里再引申出一个知识点:抽象类。
抽象类到底是个啥?
我在面试的时候有时候会问到这个问题,好多同学给出的答案就是abstract,里面不能写具体的实现。
我得补充一下,如果将抽象类跟现实的生活联系起来,这样就可以更好的理解。

抽象类就是包含的信息还不够具体化,于是就只能是抽象类。

举个例子,刚刚说的vehicle:交通工具。
如果你要写个类,叫做交通工具,这个就应该写成抽象类。
为什么呢?
因为交通工具这个概念本来就是抽象的概念,我们常常接触到的交通工具就有:

自行车、摩托车、三轮车
小轿车、公共汽车、卡车
地铁
飞机
轮船


所以说,今天早上小王问你今天怎么来上班的,你的回答是,我开车来的,或者是我坐公交、地铁来的。
你肯定不会回答说:『我是坐交通工具来的。』,如果你这样回答,小王会很懵逼的。
与此类似的概念比如哺乳动物、形状、玩具、机械装置等等,当有人跟你提到这些词时,你的脑海里是无法浮现出它的具体形象的,你只知道,他们属于某个类别。
扯了一段闲话,转回正题。
我们的运输中心,需要一个抽象的概念:那么,用接口还是抽象类呢?
这里暂时不扯这个问题了,不然离题越来越远。
今天在这里就选用接口好了(好像没有按常理出牌啊~~~)。
所以,这个系统大致变成了这个样子:
class ShippingCenter{
IVehicle Ship(Product p);
}
class Steamship : IVehicle{
ShipingProgress DeliveryProgress{get;}
void Recall(Product p);
}
可能这里还是有点不够形象,我先放出整段的代码。
public class ShippingCenter
{
public static IVehicle Ship(Product productToDeliver)
{
var vehicle = GetIVehicle();
Internalivery(vehicle, productToDeliver);
return vehicle;
}

private static IVehicle GetIVehicle()
{
if (DateTime.Now.Millisecond % 2 == 1)
{
return new AirliftPlane();
}

return new Steamship();
}

private static void Internalivery(IVehicle vehicle, Product delivery)
{
// some logic to deliver the Product.
}
}

public enum ShippingProgress
{
Preparing,
Shipping,
Deliveryed,
}
public interface IVehicle
{
ShippingProgress DeliveryProgress { get; }
void Recall(Product delivery);
}

public class Product
{
public Product(string name, int weight)
{
Name = name;
Weight = weight;
}

public string Name { get; }
public int Weight { get; }
}

internal class AirliftPlane : IVehicle
{
public ShippingProgress DeliveryProgress => ShippingProgress.Preparing;

public void Recall(Product delivery)
{
// recall product if the Shipping Progress is still ShippingProgress.Preparing
}
}

internal class Steamship : IVehicle
{
public ShippingProgress DeliveryProgress => ShippingProgress.Deliveryed;
public void Recall(Product delivery)
{
// if it's already devivered, maybe recalling is not allowed anymore.
// or some other business logic.
}
}
外部调用时,就像这样:
var p1 = new Product("iPad", 15);
var vehicle = ShippingCenter.Ship(p1);
Console.WriteLine($"current ship status {vehicle.DeliveryProgress}");
Console.WriteLine("now I want to cancel it.");
vehicle.Recall(p1);
var p2 = new Product("Books", 123);
vehicle = ShippingCenter.Ship(p2);
vehicle.Recall(p2);
其他的子系统只需要调用ShippingCenter.Ship()函数,然后返回一个IVehicle的接口,这个接口上可以调用DeliveryProgess的属性来获取当前的运输状态,也可以调用vehicle上的Recall()函数来召回产品。
所以,该系统的外部接口是

ShippingCenter.Ship()
IVehicle.DeliveryProgress
IVehicle.Recall()

这就回到本文最初的话题:子系统内部的封装。对外只有这三个接口。只要我的对外接口没变,其他的都不是问题。
所以,我要加空运、陆运、太空运都是系统内部的事情,我们内部的事情我们自己处理,你们统统不要管,你管的太多,你的脑子会乱掉的。所以,安安心心的交给我们物流子系统处理就好了。
所以,再进行分层和架构的时候,妥善的考虑对外的接口是很有必要的。如果你的代码位于不同的程序集,考虑更多的使用internal关键字,切勿动不动就是public。
如果你的类用上了public,那么其他开发者自然就可能调用到你的public函数,如果他们调用这些函数很多,你的子系统就不够独立,更像是一种千丝万缕的复杂网状关系了。
由于代码很简单,也不需要做过多的解释,但也稍微提一下:

ShippingProgress是个枚举,表示可能的运输状态
Product表示我们要运输的产品
AirliftPlane表示我们以后的空运方式
Steamship就是我们的水运方式
ShippingCenter就是我们的运输中心,它可以Ship产品,也能以接口方式返回当前运输方式的那个实例。GetIVechicle()模拟一种运输方式的选择,比如这个产品中含有电池,可能不能空运;这个是加急件,首先空运等等,但是为了简化动作,我只是取模而已,这不是本文的重点。
IVehicle上能返回ShippingProgress状态,也能召回产品。

至此,封装部分到此为止,记住,勿滥用public关键字哦。

小春 原创内容 本文地址:http://www.cnblogs.com/asis/p/architecture-encapsulation.html https://1few.com/architecture-encapsulation/

最后编辑:
作者:
这个作者貌似有点懒,什么都没有留下。

留下一个回复