代码之家  ›  专栏  ›  技术社区  ›  Stefano Borini

暴露或隐藏依赖对象?

  •  1
  • Stefano Borini  · 技术社区  · 16 年前

    常见场景:我有一个使用其他库的库。例如,使用numpy的数学库(我们称之为foo)。

    foo的功能可以是:

    • 返回numpy对象(纯对象或继承的重新实现)
    • 返回列表
    • 返回行为类似numpy的foo实现对象(执行委派)

    这三个解决方案也可以重述为:

    • foo通过内部使用的对象,清楚地声明其库依赖项也是一个API依赖项(因为它返回服从numpy库接口的对象)
    • foo使用作为语言基础一部分的对象的公共子集。
    • foo完全隐藏其内部使用的内容。关于底层库的任何内容都不会从foo库转移到客户机代码。

    我们当然是在利弊的情况下。透明还是不透明?是否与底层工具强耦合?我知道这个练习,但我正在做这个选择的过程中,我想在做决定之前分享意见。非常感谢您的建议、想法和个人经验。

    2 回复  |  直到 16 年前
        1
  •  2
  •   Joshua    16 年前

    我要考虑的主要问题是,您的库中有多少会返回麻木的对象?如果它普遍存在,我会直接返回一个麻木作为你的如此捆绑到麻木,你也可以明确。另外,它可能会使使用其他基于numpy的库变得更容易。另一方面,如果您只有几个方法可以返回numpy,那么我要么使用numpy-like对象,要么使用列表,可能是numpy-like对象。

        2
  •  3
  •   Alex Martelli    16 年前

    既然您谈论的是返回值,那并不是真正的“内部对象”——您应该只记录返回对象将支持的接口(如果这是 numpy.array 或者别的;-)。我建议不要返回一个对内部可变属性的引用,并记录变异器间接地改变你自己的对象(而不记录它也不好得多),这会导致路上的耦合太强。

    如果你说的是实际的内部对象,我建议 Law of Demeter --在简单的阅读中,如果客户的编码 a.b.c.d.e.f() ,那么有些事情是非常错误的(“只有一个点”有时可能是极端的,但是,“四个是正确的”)。同样,问题是强耦合——使您不可能在不破坏一百万个客户机的情况下以甚至微小的方式更改内部实现…!