※ 引述《lueichun (= =)》之铭言：
: ※ [本文转录自 java 看板 #1X_brSTw ]
: 作者: lueichun (= =) 看板: java
: 标题: [问题] 装饰者模式的原理
: 时间: Sat Feb 5 19:19:54 2022
: ※状况概述：
: ※程式码：
: ※错误讯息：
: ※补充说明：
: 就是我最近在看JAVA IO，而JAVA IO大量地使用装饰者模式来实作 所以我也看了
: 装饰者模式的原理，我看了好几个文章跟影片，里面都会说到装饰者类别(Decorate)
: 和被装饰者类别(Component)，是继承+组合的关系，组合的部分指的是装饰者包含了
: 要被装饰的物件，
: 例如咖啡是被装饰者，牛奶是装饰者，那么牛奶这个类别就会包含咖啡这个物件；也就是
: public class Milk{
: private Coffee coffee;
: ......
: }
: 又例如主菜是被装饰者，小菜是装饰者，那么小菜这个类别就包含主菜物件
: 但是我不能理解的是，如果code写成以上那样，那就表示牛奶has a咖啡；
: 但在逻辑上牛奶或是小菜又不包含咖啡和主菜
: 我的想法是牛奶本身跟咖啡没有has a的关系，不能说成是牛奶has a咖啡；
: 而小菜跟主菜也不是has a的关系，也不能说成是小菜has a主菜，
: 是因为现在牛奶装饰咖啡，所以牛奶has a咖啡？？这样的话为什么不能是咖啡has a牛奶
: 让咖啡类别去包含牛奶属性？？
: 所以我的问题是，
: 为什么咖啡跟牛奶，主菜和小菜会有这种组合关系，或者是说has a的关系？
: 另外就是，为什么装饰者，这里就是牛奶和小菜，需要去继承抽象的被装饰类(Component)
: 这样牛奶和小菜就去继承到咖啡主菜共同的属性方法，这个继承的逻辑或目的是？？
: 所以我在这个抽象的装饰者类，他的继承和组合关系搞不懂。
: 还有一个问题，就是装饰者模式相较于继承，可以降低耦合度，是因为要扩充功能的话，
: 不用改到既有的程式，而是增加装饰者就好吗？如果真是这样，那难道用了装饰者模式，
: 就都不会有修改既有程式的需求，就一直增加装饰者？？
: 例如咖啡不用动，就一直增加牛奶、豆浆、巧克力......等配料(装饰者)。
: 应该不会有完全不会动到咖啡的状况，那这样降低耦合度是体现在哪呢？？
应该是has a和own让你误会了aggregation
把aggregation 和 composition 搞混了
所以才会纠结在has a = a part of的错误认知里
Aggregation 的拥有(has a or own）
并没有真的独占对象或依赖对象组成（composite）
我举个例子你就懂了
Aggregation就好比包养干女儿
Composition就好比自己撸老二
当干女儿A喜欢包包的时候
她就跟你have a fuck之前先buy包
当干女儿B喜欢戒指的时候
她就跟你have a fuck之前先buy戒
干女儿就是你人生中的装饰者
这时候如果你更有钱了
出现了干女儿C、D、E....XXYYZ
每个人的喜好都不同
装饰者模式就蛮好用的
因为干女儿会告诉你他要什么之后
再have a fuck
而且当你不想干了但朋友想当表兄弟的时候
你只要跟干女儿说
你朋友也会fuck & pay两个动作
众干女儿就能继续do something then have a fuck
这不就解耦和了吗？
难不成你朋友跟众干女儿
很想要先喝杯咖啡先聊聊懂不懂装饰者模式？
甚至我们SOD化来看
当你的朋友蒙面装成你
干女儿也可以在不知认错人的状态下
继续装饰陌生人的性生活
最后，你是a part of 干女儿吗？
如果你说yes就表示你晕船了
搞不清楚状况跟关系
这时候来ptt问人就对了
实际上you are not a part of your 干女儿
干女儿只是短暂的has a 你
一旦双方解除关系就什么也不是了
而干女儿可以用同样的方式丰富其他干爹的生活
至于撸老二
Your dick is a part of you
你可以撸也可以花钱给别人撸
但绝对没有人会宣称你的老二是他的一部分
你死了就没有人可以撸你的老二
除非你的老二被做成标本
但那时候就是标本而不是老二
老二标本是标本
白马不是马！
最后回到咖啡牛奶的例子
牛奶可以倒进咖啡变成牛奶咖啡
黑糖倒进咖啡也变成黑糖咖啡
这时候如果新增焦糖口味
马上可以新增焦糖咖啡
但如果咖啡换成茶呢？
如果这时候有装饰者模式
你只要把咖啡换成茶就好了
这些原料之间只要懂搅拌就行了
这就形成了原材料与添加风味间各自的继承体系
而互相暴露的接口就是仅有的耦合
不用互相了解彼此
也不用知道各自的继承体系
就跟跟你与干女儿间的关系一样单纯