“Decorator的招供”，用采访的方式讨论了Decorator模式的缺点，这本书中处处都是这种恰当的拟人写法。
HeadFirst: Welcome Decorator Pattern. We’ve heard that you’ve been a bit down on yourself lately?
Decorator: Yes, I know the world sees me as the glamorous design pattern, but you know, I’ve got my share of problems just like everyone.
HeadFirst: Can you perhaps share some of your troubles with us?
Decorator: Sure. Well, you know I’ve got the power to add flexibility to designs, that much is for sure, but I also have a dark side. You see, I can sometimes add a lot of small classes to a design and this occasionally results in a design that’s less than straightforward for others to understand.
HeadFirst: Can you give us an example?
Decorator: Take the Java I/O libraries. These are notoriously difficult for people to understand at first. But if they just saw the classes as a set of wrappers around an InputStream, life would be much easier.
HeadFirst: That doesn’t sound so bad. You’re still a great pattern, and improving this is just a matter of public education, right?
Decorator: There’s more, I’m afraid. I’ve got typing problems: you see, people sometimes take a piece of client code that relies on specific types and introduce decorators without thinking through everything. Now, one great thing about me is that you can usually insert decorators transparently and the client never has to know it’s dealing with a decorator. But like I said, some code is dependent on specific types and when you start introducing decorators, boom! Bad things happen.
HeadFirst: Well, I think everyone understands that you have to be careful when inserting decorators, I don’t think this is a reason to be too down on yourself.
Decorator: I know, I try not to be. I also have the problem that introducing decorators can increase the complexity of the code needed to instantiate the component. Once you’ve got decorators, you’ve got to not only instantiate the component, but also wrap it with who knows how many decorators.
HeadFirst: I’ll be interviewing the Factory and Builder patterns next week – I hear they can be very helpful with this?
Decorator: That’s true; I should talk to those guys more often.
HeadFirst: Well, we all think you’re a great pattern for creating flexible designs and staying true to the Open-Closed Principle, so keep your chin up and think positively!
Decorator: I’ll do my best, thank you
HeadFirst: Welcome Decorator Pattern. We’ve heard that you’ve been a bit down on yourself lately?
Decorator: Yes, I know the world sees me as the glamorous design pattern, but you know, I’ve got my share of problems just like everyone.
HeadFirst: Can you perhaps share some of your troubles with us?
Decorator: Sure. Well, you know I’ve got the power to add flexibility to designs, that much is for sure, but I also have a dark side. You see, I can sometimes add a lot of small classes to a design and this occasionally results in a design that’s less than straightforward for others to understand.
HeadFirst: Can you give us an example?
Decorator: Take the Java I/O libraries. These are notoriously difficult for people to understand at first. But if they just saw the classes as a set of wrappers around an InputStream, life would be much easier.
HeadFirst: That doesn’t sound so bad. You’re still a great pattern, and improving this is just a matter of public education, right?
Decorator: There’s more, I’m afraid. I’ve got typing problems: you see, people sometimes take a piece of client code that relies on specific types and introduce decorators without thinking through everything. Now, one great thing about me is that you can usually insert decorators transparently and the client never has to know it’s dealing with a decorator. But like I said, some code is dependent on specific types and when you start introducing decorators, boom! Bad things happen.
HeadFirst: Well, I think everyone understands that you have to be careful when inserting decorators, I don’t think this is a reason to be too down on yourself.
Decorator: I know, I try not to be. I also have the problem that introducing decorators can increase the complexity of the code needed to instantiate the component. Once you’ve got decorators, you’ve got to not only instantiate the component, but also wrap it with who knows how many decorators.
HeadFirst: I’ll be interviewing the Factory and Builder patterns next week – I hear they can be very helpful with this?
Decorator: That’s true; I should talk to those guys more often.
HeadFirst: Well, we all think you’re a great pattern for creating flexible designs and staying true to the Open-Closed Principle, so keep your chin up and think positively!
Decorator: I’ll do my best, thank you
发表评论
AllenYoung
- 浏览: 142224 次
- 来自: 上海交通大学软件学院
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
另一只眼看Eclipse，所谓 ...
其他不管你学什么都会遇到一定的困惑的，一定的。
-- by mylvan -
我的第一关rake文件
robbin 写道每次当我想操起ruby写rake file的时候，都发现我三行 ...
-- by rubynroll -
我的第一关rake文件
抛出异常的爱 写道rake是建表结构的....不是用来导数据的 不如用exce ...
-- by liusong1111 -
我的第一关rake文件
不知大家有没有这种需求，用户的日常操作中，原始数据可能是其他人员发给他的exce ...
-- by zengyinbo -
使用ruby生成zip文件
如果已经拿到了csv文件,就用OO转成Excel成么? ---非程序员思路
-- by lgn21st
评论排行榜