松散耦合与信息隐藏和易于更改[关闭]

2. 更改签名并不一定“困难”,尤其是在现在的工具中,只要点击一个按钮,就会突出显示每个呼叫位置。

你的第1个论点的主要问题是它没有像其他人说的那样破坏封装。您展示的是what,而不是how,这正是封装的意义所在。

最终松动 coupling 赢了。从高耦合到低耦合,有各种类型的耦合:

1. 内容耦合(高):一个模块修改或依赖
2. 变量)。更改共享资源 资源意味着改变所有的资源
3. 外部耦合:两个模块共享外部施加的数据 格式、通信协议或 设备接口。
4. 向it传递有关如何做的信息
5. Stamp耦合(数据结构耦合):当模块共享复合数据结构并使用 只是它的一部分,可能是一个 不同的部分(例如通过一个整体 一个领域)。
6. 数据耦合:当模块通过例如参数共享数据时。 每个基准都是一个基本块,并且 只有这些数据是正确的 共享(例如,将整数传递给 根)。
7. 消息耦合(低):模块不依赖于每个 消息(或事件,请参阅 Message passing ).

传入 Employee 受雇者

最好的最解耦的方法是定义一个接口 IHolidayable ,但在这种情况下,这样做未免太过分了。

int holidays(Date entryDate, Number sales) . 高级API的设计目的是为了尽可能方便地为客户机做好一件事。这证明了 int holidays(Employee emp)

2) 假日方法不应是Employee类的一部分。

int holidays(Employee emp)

在这种情况下,只有员工才能使用该功能。。。

1. 这并不是破坏封装。打破封装将揭示它用于计算假期的内部方法。定义API的是提供起始参数。

在我看来,最好通过尽可能多的解耦和封装来规划更改,以便尽可能容易地完成重构。试图提前预测每一个可能的场景最终都会导致过度设计的系统臃肿。

我想说松耦合的一个主要好处是易于更改。松散耦合类型可以彼此独立地更改,因此我不理解您在问题中的“vs”。

此外,我不会说您通过为方法提供参数来破坏封装。您可以实现 Sum(int a, int b)

与其他一些帖子不同,我同意你的观点,这打破了封装。不是类的封装,而是计算假期的概念。如果您希望在将来更改此计算的工作方式,并且仍然避免紧密耦合,我建议将Employee设置为一个接口。如果由于您认为可能需要为其他事情计算假期,所以这仍然与Employee紧密耦合,那么您可以拥有一个GetsHolidays接口,Employee从该接口继承。

最好的最解耦的方法是定义一个接口IHolidayable

这种笼统的说法真让我恼火。仅仅因为您使用了一个接口,并不意味着您可以自动解耦任何东西。如果employee类实现了计算假期的接口,则调用该方法的任何代码, 调用相同的方法。在最坏的情况下,调用代码将通过直接访问employee对象而不是IHolidayable接口引用来实现这一点,在这种情况下,您只会使情况变得更糟(因为现在接口和实现它的任何类之间存在更微妙的耦合)。

接口确实有助于解耦,但实际上并非如此 自动地

int holidays (IHolidayInfo obj)

这可能是一种方式。在本例中,任何实现 IHolidayInfo