※ 引述《kanandg1 (臻@kanandg1)》之铭言：
: 可能是对design pattern不是甚熟
: 我一直对command pattern有疑问
: 在该pattern中，常常某个command是针对特定物件做操作的
: 举例：开跟关的command可能是针对"电灯"、"电扇"
: 而音量大小等等command可能是针对"电视"
: 请问这些受词（不太会描述，或称operand?被操纵者）的reference
你讲的东西如果是电灯电扇电视等等的，
这种东西就叫 Receiver。
: 该何时被设定到command中呢？
Command 物件是由 client code 产生 (也可能透过 factory，但源头还是 client)，
所以一般是在产生的那一瞬间就顺便把 Receiver 设定进去了，
也就是说一般是使用建构子传入 Receiver，
不然你高兴的话也可以写一些 setReceiver 的 method，
自己可以变通。
: 之前我都是看到在建构子时......不过总觉得这样不够一般化
: 这样做常常使得在create command处的程式码变得乱七八糟且
: 相依很严重
产生物件的地方一定是 OO 程式最难看的地方，
这一点是立志写出漂亮程式的人最需要深刻去体认的，
美好的事物并不可能真正存在于每个角落里，
但是你可以将这些丑陋的东西集中在一处管理避免散落在各地，
这就是为什么要有 factory 的一大原因，
你可以将传入 factory 的参数设计为单一参数物件，
或是更一般化的字串形式也是可以的 (当然你的 factory 内就要建表判断)，
反正透过 factory 这一层的话就能把难看的 code 集中在 factory 内部，
不会每次想造 Command 物件的时候就写一大串难看的 code。
: 另外想问MVC中是否有完全切开且较美观的作法？
: 我在写Java swing时一直想把UI跟事件（逻辑）的部份拆开
: 一方面是我找不到有小型framework可支援
: 而且一般来说，事件逻辑里操纵著的，常常是UI元件
: 精华区内只有提到VC常常在一起（对阿！）而似乎没说明如何分开
: 是不是能请前辈们举例某些小型的framework在这部份
: 处理的不错的？
: （我并不是想伸framework，而是想知道solution的架构长啥样子，thx）
我常用的 Qt 也只有 Model/View 的概念而已，
完全遵循古典 MVC 设计的 framework 我也不晓得，
除非全部自己从最低阶的 Xlib 刻上来，
我才会实作完全的 MVC 概念 (但不是设计 framework，就单纯是写出程式而已)，
因为程式会比较好维护。
至于跟 Java 有关的问题我没办法回答，
因为我没有在玩 Java，
其它比较一般化的问题倒是可以回，
不过也是要在问题能更明确的前提下。