良好的类接口

抽象

类的接口应展现一致的抽象

接口?

类所具有的公有(外界可直接使用)子程序所构成的集合

一致?

各接口的功能应密切联系(这一系列的功能都围绕着一个共同的中心)

创建类的抽象接口的指导建议

  1. 接口应展现一致的抽象层次
    每个类应仅实现一个ADT
    如果不确定该类实现了哪种ADT,应该将其重新组织为1个或多个定义明确的ADT
    一致的抽象层次让程序易被理解(易维护)

  2. 理解类实现的抽象是什么
    明确目的

  3. 提供成对服务
    很多操作都有其对应的另一个操作(通常是两个相反的操作)

  4. 移除不相关信息

  5. 让接口可编程
    接口的使用条件应在其可编程的部分(如接口中的数据类型)中体现,这样才能保证编译器能够检查出错误

  6. 防止在修改时破坏接口的抽象

  7. 不添加与接口抽象不一致的公用成员

  8. 同时考虑抽象性和内聚性
    关注类的接口表现出的抽象比关注类的内聚性更有助于理解类的设计

封装

封装比抽象更强硬

抽象:提供一个可让你忽略实现细节的模型 -> 管理复杂度
封装:阻止你看到细节

为什么有了抽象,还要有封装?

没有封装,抽象往往易被打破

如何封装?

  1. 尽可能限制类和成员的可访问性
    采取最严格且可行的访问级别(能不暴露就不暴露)

  2. 不公开暴露成员数据
    暴露成员数据会限制对抽象的控制能力(类本身不知道外界是否修改了自己的成员数据)

  3. 不将私用的实现细节放入类接口
    将类的接口与实现隔离开,不让接口调用者知道接口的具体实现细节
    不应诱导接口调用者去了解接口的具体实现

  4. 不对类的使用者做假设
    除了类的接口中隐含的契约,不对调用者做任何假设
    自行处理调用者使用错误可能造成的崩溃情况
    判断每一个输入内容的合法性

  5. 不使用友元类
    互为友元类的两个类可访问对方的保护成员和私有成员
    友元类破坏了封装

  6. 谨慎划归公开接口
    暴露子程序可能会影响接口展示的抽象的一致性

  7. 让代码易读
    读的次数会远大于写的次数

  8. 不从语义上破坏封装性
    调用方代码不应依赖于类的私用实现

  9. 注意过于紧密的耦合关系
    紧密的耦合性总发生在抽象不严谨或封装性被破坏的时候

你可能感兴趣的:(良好的类接口)