为什么说锁违反了抽象和可组合性原则?

我不是专家,在网上也找不到任何东西。我可能和你在大学学的是同一个科目,以下是我的想法(根据个人经验)。

锁对抽象原理提出的问题是,锁及其资源的状态可能无法由当前执行的指令集的状态确定。例如,在C++中,您可能有一个Baker类,该类需要对某些Oven对象进行互斥访问。面包师需要经常使用烤箱(打开/关闭/放入物品),并且需要独占访问烤箱才能这样做,但是这不能真正抽象出来,因为他何时需要这种互斥访问可能会影响他的功能。

我们可能需要向我们的系统添加独立于面包师的功能,但需要相互排斥地访问面包师正在使用的同一个烤箱。在实现这些更改时,由于锁如何同时依赖于多个线程的状态,我们不能保证先前抽象的Baker类的行为在程序的运行时保持不变。(例如:如果烤箱被另一个线程使用,面包师可能会决定等待30分钟,然后再检查烤箱是否空闲,这可能是不必要的、低效的行为)。

由于同样的问题,锁也违反了可组合性原则,因为在多线程应用程序中,如果程序的不同组件相互依赖,则它们无法无缝组合。

希望这能有所帮助-让我知道你的想法,这样我们就可以一起得分了。

非正式地说,可组合性意味着获取两个或多个功能程序,并从中生成更大的程序。合成应基于已发布的接口,不知道内部细节。

提到 https://en.wikipedia.org/wiki/Lock_(computer_science)#cite_note-5 . 在本例中,如果不知道锁定协议(account类的实现细节),则无法正确编写传输方法