【封装那些事】 未利用封装

未利用封装

客户代码使用显式类型检查(使用一系列if-else或switch语句检查对象的类型),而不利用出层次结构内已封装的类型变化时,将导致这种坏味。

为什么要利用封装?

一种臭名昭著的坏味是,在客户代码中使用条件语句(if-else或switch语句)来显式地检查类型,并根据类型执行相应的操作。我们这里讨论的是:要检查的类型都封装在了层次结构中,但没有利用这一点,即使用显式类型检查,而不依赖于动态多态性。这将导致如下问题:

  • 显式类型检查让客户程序和具体类型紧密耦合,降低了设计的可维护性。例如,引入新类型后,必须修改客户程序,在其中检查新类型以及执行相应操作的代码。
  • 客户程序必须显式地检查层次结构中所有相关的类型。如果未检查一个或多个这样的类型,客户程序在运行阶段可能出现意外的行为。相反,如果利用了运行时多态,完全可以避免这种问题。

未利用封装潜在的原因

###以过程型思维使用面向对象语言

开发时的思维是以代码执行过程为导向,自然而然就会使用if-else语句和switch语句。

未应用面向对象原则

无力将面向对象的概念付诸实践。

示例分析一

根为抽象类DataBuffer的层次结构封装了各种基本数据结构型数组,DataBuffer的子类DataBufferByte、DataBufferUShort、DataBufferInt支持相应的基本数据类型数组。DataBuffer定义了常量TYPE_BYTE、TYPE_USHORT、TYPE_INT。客户程序使用TYPE_BYTE、TYPE_USHORT、TYPE_INT的DataBuffer来存储数据。

下面是客户程序的示例,演示如何使用switch语句执行针对具体类型的显式类型检查。

switch (transferType)
{
    case DataBuffer.TYPE_BYTE:
        byte[] bdata = (byte[])inData;
        pixel = bdata[0] & 0xff;
        length = bdata.Length;
        break;
    case DataBuffer.TYPE_USHORT:
        short[] sdata = (short[])inData;
        pixel = sdata[0] & 0xffff;
        length = sdata.Length;
        break;
    case DataBuffer.TYPE_INT:
        int[] idata = (int[])inData;
        pixel = idata[0];
        length = idata.Length;
        break;
    default:
        throw new Exception("不支持的transferType");
}

上面代码使用的数据成员transferType定义如下:

protected int transferType;

重构建议:将决定行为的条件语句删除,并在层次结构中引入多态方法。

在客户程序中,提供合适的DataBuffer子类对象。在DataBuffer层次结构类型中,定义方法GetPixel()和GetLengthl()。

public abstract class DataBuffer
{
    public const int TYPE_BYTE = 1;
    public const int TYPE_DOUBLE = 2;
    public const int TYPE_FLOAT = 3;
    public const int TYPE_INT = 4;
    public const int TYPE_USHORT = 5;

    public abstract int GetPixel(object inData);
    public abstract int GetLength(object inData);
}

public class DataBufferInt: DataBuffer
{
    public override int GetPixel(object inData)
    {
        int[] idata = (int[])inData;
        return  idata[0];
    }
    public override int GetLength(object inData)
    {
        int[] idata = (int[])inData;
        return idata.Length;
    }
}

public class DataBufferByte : DataBuffer
{
    public override int GetPixel(object inData)
    {
        byte[] bdata = (byte[])inData;
        return bdata[0] & 0xff;
    }
    public override int GetLength(object inData)
    {
        byte[] bdata = (byte[])inData;
        return bdata.Length;
    }
}

public class DataBufferUShort : DataBuffer
{
    public override int GetPixel(object inData)
    {
        short[] sdata = (short[])inData;
        return sdata[0] & 0xffff;  
    }
    public override int GetLength(object inData)
    {
        short[] sdata = (short[])inData;
        return sdata.Length;
    }
}

并将客户程序switch语句及其case语句简化为:

int pixel = GetPixel(inData);
int length = GetLength(inData);

由于引用dataBuffer指向的是传入的DataBuffer子类对象,因此上述语句将调用相应子类的GetPixel()和GetLength()方法。这里需要注意的是客户程序代码提供特定DataBuffer子类对象,检查输入数据类型和创建DataBuffer子类对象的工作由客户程序负责。可能需要在客户代码或一个工厂类中使用switch-case语句,而只需要使用一次这个switch-case语句。由于客户程序不知道具体是哪个DataBuffer子类,所以它与DataBuffer层次结构耦合更低。这样在DataBuffer层次结构修改既有类型和添加新类型时,不会对客户程序造成影响。即使有影响也是只需要使用一次的这个switch-case语句,修改代码代价极小。

这让我想起,我在看完《重构》后天真幼稚的想消除项目中的switch-case语句,只要项目中存在switch-case语句我就觉得存在坏味道,此后的一段时间我很痛苦,因为项目中总是存在消灭不了的switch-case语句。其实如果项目中需要与外部世界的实体交互,要避免使用条件逻辑很难。例如用户在页面的操作在代码中肯定对应不同的对象来处理,这中间必须使用条件逻辑判断使用哪个对象处理。但是这样的判断应该只有一处,负责日后的代码维护是个灾难。

示例分析二

还是那句话switch-case语句和if-else语句不可怕,可怕的是多个witch-case语句和if-else语句。

对于这样的代码我们要给予充分的关注:

代码1:

if(obj is XXX)
{
    //做事情A
}
if(obj is YYY)
{
    //做事情B
}
if(obj is ZZZ)
{
    //做事情C
}

代码2:

if(obj is XXX)
{
    //做事情A
}
if(obj is YYY)
{
    //做事情B
}
if(obj is ZZZ)
{
    //做事情C
}

代码3:

if(obj is XXX)
{
    //做事情A
}
if(obj is YYY)
{
    //做事情B
}
if(obj is ZZZ)
{
    //做事情C
}

这样的代码是难以扩展的,新增一个类NNN,就需要找到代码1、2、3甚至n进行修改,很容易遗漏。而且遗漏造成的错误只用在代码运行阶段才能发现。

这种情况反映出来的问题就是没有利用封装,已经有了层次结构,却没有予以利用。没有面向接口编程,每个地方面向的都是具体的实现类,每个地方都需要判断实例的类型才可以进行下一步的动作。

进行重构:

代码1:

obj.DoSomething1();

代码2:

obj.DoSomething2();

代码3:

obj.DoSomething3();

obj可以是XXX、YYY、ZZZ。对于现在的代码,新增一个类NNN,代码1、2、3甚至n处根本不需要任何改动。因为它们实现了统一的接口,并且符合开闭原则。

参考:《软件设计重构》

                                                            -----END-----

                      喜欢本文的朋友们,欢迎扫一扫下图关注公众号撸码那些事,收看更多精彩内容

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏前端新视界

关于面试题 Array.indexof() 方法的实现及思考

这是我在面试大公司时碰到的一个笔试题,当时自己云里雾里的胡写了一番,回头也曾思考过,最终没实现也就不了了之了。 昨天看到有网友说面试中也碰到过这个问题,我就重新...

2329
来自专栏代码世界

Python之递归函数

递归函数 初识递归函数 递归函数的定义:在一个函数里再调用这个函数本身 Python为了考虑保护内存占用情况,有一个递归深度的限制。 探究递归的默认最大深度: ...

2836
来自专栏听雨堂

字符串处理总结(旧)

在各类应用软件的开发中,字符串操作是最常见的操作之一。在各种不同的数据类型中,字符串类型是和现实世界关联最紧密的。对字符串的读入、比较、拼接、搜索、匹配、替换、...

2458
来自专栏瓜大三哥

HLS Lesson8-基本操作

1.算术操作 ? 如果是定点数处理时候,需要遵循的原则是:大数据不溢出,小数据不损失 2.算数赋值 ? ? #include<iostream> #includ...

2447
来自专栏撸码那些事

【封装那些事】 未利用封装

1584
来自专栏数据的力量

Vlookup多条件匹配(不用辅助列)

4574
来自专栏Java工程师日常干货

使用Google Guava快乐编程以面向对象思想处理字符串:Joiner/Splitter/CharMatcher对基本类型进行支持对JDK集合的有效补充函数式编程:Functions断言:Pred

目前Google Guava在实际应用中非常广泛,本篇博客将以博主对Guava使用的认识以及在项目中的经验来给大家分享!正如标题所言,学习使用Google Gu...

1133
来自专栏容器云生态

Python中关于集合(set)的思考

        又是好久没有发技术上的文章了,一方面是最近工作也比较忙,同时自己也在学习python,另外一方面是因为个人不喜欢发表一些在互联网上可以直接找到的...

2765
来自专栏风口上的猪的文章

.NET面试题系列[15] - LINQ:性能

当你使用LINQ to SQL时,请使用工具(比如LINQPad)查看系统生成的SQL语句,这会帮你发现问题可能发生在何处。

2974
来自专栏Java技术栈

刚写完这段代码,就被开除了……

显然不是,休眠的逻辑,大家都懂,不需要写注释,你注释写休眠 1 天也没意义啊。。。

1101

扫码关注云+社区