代码示例是 C#,但这是一个一般的 OO 问题。
我知道根据 OO 规则,应尽量减少类耦合,成员应尽可能保持私有,等等。
考虑这个例子:
您正在编写一个深奥的程序,该程序具有某种数据集(我不是在谈论System.Data.DataSet),它实际上用于程序的各个方面。事实上,程序的存在基本上只是为了加载、显示、操作和保存数据集。此外,任何时候都只能加载一个数据集,并且在程序打开时加载。
如果我们严格遵循 OO 规则,我们将有
public void ShowSomeGraphs(IData data)
{
// do stuff with data which implements IData
}
但是,例如,我们可能会将public static Data
成员存储在 中Program
。
public void ShowSomeGraphs()
{
// do stuff with Program.Data
}
一方面,我们用一个稍短的函数签名换取了大大增加的类耦合。另一方面,我们不再将 Data 参数传递给几乎每个函数,无处不在。
正确的答案可能是:尽可能避免类耦合。本地数据变量只是指针,因此内存开销可以忽略不计,并且由于类是解耦的,它们可以在以后在其他地方使用。
虽然现实地说,Data 类的结构在不同的应用程序中可能会有显着的不同,所以你不能直接从这个程序中拉出一个类,然后把它放到其他地方而不做任何调整。以一种可以直接加入的方式编写类所需的额外时间和精力可能很难向利益相关者证明是合理的。
我现在正在研究这种程序,并且我使用了 OO-canon 方法:在需要的地方传递数据参数 我已经最小化了与 IData 接口的类耦合,以概括数据集以供将来代码重用。鉴于应用程序,我几乎可以肯定这段代码永远不会被重用。如果没有这些额外的接口和抽象,就最终用户而言,该程序的工作方式将完全相同,但对我来说将大大减少头痛和开发时间。
你怎么看待这件事?您是否认为花费所有额外的时间来编写接口和泛化以确保类在可能的情况下解耦是合理的,尤其是当您以后看不到在其他地方使用的类时?