Re: [Flashcoders] Decorator Pattern - removing a decorator
it only gets worse :)
This is a nice read too:
http://www.moserware.com/2008/03/what-does-it-take-to-become-grandmaster.html
On Thu, Mar 20, 2008 at 11:08 PM, Jiri Heitlager
[EMAIL PROTECTED] wrote:
Steven,
thanks for that helpfull reply. It is funny becuase I was just thinking
about the dualism, on the one hand there are these wonderfull elegant
design patterns that supposed to make things easier and on the other
hand it seems like coding has just became harder ever since when I
started applying them. Knowing about them seems sometimes almost a
burden. But the absolute elegance of how they can be used, which is
reflected in the many articles and books on them, just makes me want to
understand them better. And as you say, applying them and failing
horribly is a perfect way to get to know their individual intrisic
workings.
Strategy is the one that I am just now looking into, because the
Decorator and the possibilty of not removing them just doesnt make them
suitable for the behaviour I was after on that level.
I have something like this now.
var item = new Item()
item.executeModifier() {
modifier.execute(item.mc)
}
item.setModifier(modifier) this.modifier = modifier
item.setClip(mc) this.mc = mc
Then I will use the Decorator pattern, for decorating (what else) the
items. It so happens that some Items contain text that can be edited.
class ItemTextDecorator implements itemInterface{
_item:Iteminterface
function ItemTextDecorator(item:Iteminterface)
{
_item = item
}
function executeModifier() {
_item.executeModifier(_item.mc)
}
function setModifier(modifier) {
_item.setModifier(modifier)
}
function.setClip(mc) this.mc = mc
//additional function to set Text and edit text
}
It feels beautiful to piece things together like this :)
Just understand that you won't understand until
you code yourself into a corner a few times. :)
When will it end, if ever?
What you're experiencing is premature enlightenment. - Tyler Durden
The Gang of Four specifically warns about this, and it's important to
acknowledge that it's happening.
When people first learn about design patterns, they will immediately
begin looking for places to apply them. They will do this and fail in
some particular way, and in doing so, learn more about that design
pattern or perhaps one that they don't know of, yet. The issue most
people have is trying to solve a problem with a design pattern they just
learned without understanding that it isn't an appropriate pattern.
But, you have to do it wrong in order to learn why. Prepare to fail and
learn from those failures. It will make you a better coder.
Your initial hunch is that your problem would best be solved by the
Decorator pattern, but it very well may not be. The Decorator pattern
has fallen out of favor in recent years, as many people believe it
violates good OOP practices. It has its uses, but they're limited.
You should continue coding this using Decorator if you like, so you can
discover what its limitations are. It sounds like you're already
hitting them. It's possible that Strategy and Composition might be
useful here, as well. Just understand that you won't understand until
you code yourself into a corner a few times. :)
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
[Flashcoders] Decorator Pattern - removing a decorator
Hello List, i am looking into the decorator pattern for an upcoming AS2 project. I was wondering if the following is possible var com:Component = new Component() com = new decoratorA(com) com = new decoratorB(decA) com = new decoratorC(decB) I cant seem to figure out what I need to do in order to remove let say decB at runtime? I tried a search on the internet, but all the articles about the decorator pattern are about runtime adding, not removing. Can somebody please help me if it is at all possible. Thank you, Jiri ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Decorator Pattern - removing a decorator
That's not really how Decorator is meant to work. You could hack around it by exposing the decorated instance in your Decorator interface, digging down to it, and using a bunch of instanceof calls to figure out which is which. I really don't recommend this, though -- instead, use a different design pattern or program architecture. On 3/20/08, Jiri Heitlager [EMAIL PROTECTED] wrote: Hello List, i am looking into the decorator pattern for an upcoming AS2 project. I was wondering if the following is possible var com:Component = new Component() com = new decoratorA(com) com = new decoratorB(decA) com = new decoratorC(decB) I cant seem to figure out what I need to do in order to remove let say decB at runtime? I tried a search on the internet, but all the articles about the decorator pattern are about runtime adding, not removing. Can somebody please help me if it is at all possible. Thank you, Jiri ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- Cory Petosky : Lead Developer : PUNY 1618 Central Ave NE Suite 130 Minneapolis, MN 55413 Office: 612.216.3924 Mobile: 240.422.9652 Fax: 612.605.9216 http://www.punyentertainment.com ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Decorator Pattern - removing a decorator
I could use another design pattern, but I need to figure out which one then. The application is one where the user can selected certain items and those items are put on a canvas. Then when the user selects the item on the canvas, a panel shows up that allows the item to be rotated, scaled and possible edited ,i.e add text. I thought that the decorator would be perfect for this. Come to think of it maybe it still is. I really dont ever need to remove any decorator that is added do I. Them item starts blank and when the user rotates it, I just add a decorator, rotatorModifier. Then the decorator interface has a method setModifierProperty(key , value), in this case key = rot value=number. The decorator component holds a hash and checks if hash[rot]!=undefined, then adds the rot and the value. Then calls an update method to reflect the property set. Deleting the modifier would be then just setting the hash[rot] to 0. Does that make sense and I am approaching this in a efficient way. I am quit new to design patterns, but fell in love with there elegance and would like to learn how to implement them as best as possible. Some feedback would be very much appreciated. Jiri Cory Petosky wrote: That's not really how Decorator is meant to work. You could hack around it by exposing the decorated instance in your Decorator interface, digging down to it, and using a bunch of instanceof calls to figure out which is which. I really don't recommend this, though -- instead, use a different design pattern or program architecture. On 3/20/08, Jiri Heitlager [EMAIL PROTECTED] wrote: Hello List, i am looking into the decorator pattern for an upcoming AS2 project. I was wondering if the following is possible var com:Component = new Component() com = new decoratorA(com) com = new decoratorB(decA) com = new decoratorC(decB) I cant seem to figure out what I need to do in order to remove let say decB at runtime? I tried a search on the internet, but all the articles about the decorator pattern are about runtime adding, not removing. Can somebody please help me if it is at all possible. Thank you, Jiri ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Decorator Pattern - removing a decorator
it's better to code and accidentally discover you've used a design pattern, than beginning to code thinking you have to use a specifick pattern, but that's just my humble opinion. On Thu, Mar 20, 2008 at 6:08 PM, Jiri Heitlager [EMAIL PROTECTED] wrote: I could use another design pattern, but I need to figure out which one then. The application is one where the user can selected certain items and those items are put on a canvas. Then when the user selects the item on the canvas, a panel shows up that allows the item to be rotated, scaled and possible edited ,i.e add text. I thought that the decorator would be perfect for this. Come to think of it maybe it still is. I really dont ever need to remove any decorator that is added do I. Them item starts blank and when the user rotates it, I just add a decorator, rotatorModifier. Then the decorator interface has a method setModifierProperty(key , value), in this case key = rot value=number. The decorator component holds a hash and checks if hash[rot]!=undefined, then adds the rot and the value. Then calls an update method to reflect the property set. Deleting the modifier would be then just setting the hash[rot] to 0. Does that make sense and I am approaching this in a efficient way. I am quit new to design patterns, but fell in love with there elegance and would like to learn how to implement them as best as possible. Some feedback would be very much appreciated. Jiri Cory Petosky wrote: That's not really how Decorator is meant to work. You could hack around it by exposing the decorated instance in your Decorator interface, digging down to it, and using a bunch of instanceof calls to figure out which is which. I really don't recommend this, though -- instead, use a different design pattern or program architecture. On 3/20/08, Jiri Heitlager [EMAIL PROTECTED] wrote: Hello List, i am looking into the decorator pattern for an upcoming AS2 project. I was wondering if the following is possible var com:Component = new Component() com = new decoratorA(com) com = new decoratorB(decA) com = new decoratorC(decB) I cant seem to figure out what I need to do in order to remove let say decB at runtime? I tried a search on the internet, but all the articles about the decorator pattern are about runtime adding, not removing. Can somebody please help me if it is at all possible. Thank you, Jiri ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders -- M.A. van't Kruis http://www.malatze.nl/ ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Decorator Pattern - removing a decorator
Meinte, i have been doing that for the last 4 years and I am not saying you are wrong, but I get the feeling that I am reinventing the wheel every time. Why not use patterns that have been developed over the last n years and as a result get better maintainable code. I just dont have that god given gift/talent or education that I can just code and discover that I used a pattern. And how can I discover I used a pattern, if I dont know them that well yet. So maybe your right, but personally I dont think it will cut the cake for me, if I want to develop myself as a better programmer and be able to start delivering code that is easy for other programmers to recognize. Am I living in a dream? I am still looking for some feedback about my last post, do you wanna give it a go? Jiri Meinte van't Kruis wrote: it's better to code and accidentally discover you've used a design pattern, than beginning to code thinking you have to use a specifick pattern, but that's just my humble opinion. On Thu, Mar 20, 2008 at 6:08 PM, Jiri Heitlager [EMAIL PROTECTED] wrote: I could use another design pattern, but I need to figure out which one then. The application is one where the user can selected certain items and those items are put on a canvas. Then when the user selects the item on the canvas, a panel shows up that allows the item to be rotated, scaled and possible edited ,i.e add text. I thought that the decorator would be perfect for this. Come to think of it maybe it still is. I really dont ever need to remove any decorator that is added do I. Them item starts blank and when the user rotates it, I just add a decorator, rotatorModifier. Then the decorator interface has a method setModifierProperty(key , value), in this case key = rot value=number. The decorator component holds a hash and checks if hash[rot]!=undefined, then adds the rot and the value. Then calls an update method to reflect the property set. Deleting the modifier would be then just setting the hash[rot] to 0. Does that make sense and I am approaching this in a efficient way. I am quit new to design patterns, but fell in love with there elegance and would like to learn how to implement them as best as possible. Some feedback would be very much appreciated. Jiri Cory Petosky wrote: That's not really how Decorator is meant to work. You could hack around it by exposing the decorated instance in your Decorator interface, digging down to it, and using a bunch of instanceof calls to figure out which is which. I really don't recommend this, though -- instead, use a different design pattern or program architecture. On 3/20/08, Jiri Heitlager [EMAIL PROTECTED] wrote: Hello List, i am looking into the decorator pattern for an upcoming AS2 project. I was wondering if the following is possible var com:Component = new Component() com = new decoratorA(com) com = new decoratorB(decA) com = new decoratorC(decB) I cant seem to figure out what I need to do in order to remove let say decB at runtime? I tried a search on the internet, but all the articles about the decorator pattern are about runtime adding, not removing. Can somebody please help me if it is at all possible. Thank you, Jiri ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Decorator Pattern - removing a decorator
What you're experiencing is premature enlightenment. - Tyler Durden The Gang of Four specifically warns about this, and it's important to acknowledge that it's happening. When people first learn about design patterns, they will immediately begin looking for places to apply them. They will do this and fail in some particular way, and in doing so, learn more about that design pattern or perhaps one that they don't know of, yet. The issue most people have is trying to solve a problem with a design pattern they just learned without understanding that it isn't an appropriate pattern. But, you have to do it wrong in order to learn why. Prepare to fail and learn from those failures. It will make you a better coder. Your initial hunch is that your problem would best be solved by the Decorator pattern, but it very well may not be. The Decorator pattern has fallen out of favor in recent years, as many people believe it violates good OOP practices. It has its uses, but they're limited. You should continue coding this using Decorator if you like, so you can discover what its limitations are. It sounds like you're already hitting them. It's possible that Strategy and Composition might be useful here, as well. Just understand that you won't understand until you code yourself into a corner a few times. :) ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] Decorator Pattern - removing a decorator
Steven Sacks wrote: Your initial hunch is that your problem would best be solved by the Decorator pattern, but it very well may not be. The Decorator pattern has fallen out of favor in recent years, as many people believe it violates good OOP practices. It has its uses, but they're limited. Design Patterns, the book by the gang of four, is a very, very good book, but I wouldn't make it my only way of structuring code. Read it, use it, but be aware of its limitations. The OOP paradigm has gone through different phases. At first it was all about inheritance and reusable code. Then we discovered composition, and pretty soon everybody was doing composition. Design Patterns is very strongly composition-oriented, to the point of almost being dismissive of inheritance. And, sure enough, the pendulum has swung back to a more inheritance-centric OOP paradigm. In practice, both inheritance and composition are important, useful approaches to OOP design. I'm a stubborn old cuss, and I've always resisted following the latest trend (extreme programming and the like). I read, observe, and cherry-pick what looks useful to me. I guess I'm saying pretty much the same thing Steven is--don't just follow the gurus. Understand the guru's approach, then choose what's useful to you. The gang of four, as good (and popular) as they are, don't have all the answers. Cordially, Kerry Thompson ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Decorator Pattern - removing a decorator
Steven,
thanks for that helpfull reply. It is funny becuase I was just thinking
about the dualism, on the one hand there are these wonderfull elegant
design patterns that supposed to make things easier and on the other
hand it seems like coding has just became harder ever since when I
started applying them. Knowing about them seems sometimes almost a
burden. But the absolute elegance of how they can be used, which is
reflected in the many articles and books on them, just makes me want to
understand them better. And as you say, applying them and failing
horribly is a perfect way to get to know their individual intrisic workings.
Strategy is the one that I am just now looking into, because the
Decorator and the possibilty of not removing them just doesnt make them
suitable for the behaviour I was after on that level.
I have something like this now.
var item = new Item()
item.executeModifier() {
modifier.execute(item.mc)
}
item.setModifier(modifier) this.modifier = modifier
item.setClip(mc) this.mc = mc
Then I will use the Decorator pattern, for decorating (what else) the
items. It so happens that some Items contain text that can be edited.
class ItemTextDecorator implements itemInterface{
_item:Iteminterface
function ItemTextDecorator(item:Iteminterface)
{
_item = item
}
function executeModifier() {
_item.executeModifier(_item.mc)
}
function setModifier(modifier) {
_item.setModifier(modifier)
}
function.setClip(mc) this.mc = mc
//additional function to set Text and edit text
}
It feels beautiful to piece things together like this :)
Just understand that you won't understand until
you code yourself into a corner a few times. :)
When will it end, if ever?
What you're experiencing is premature enlightenment. - Tyler Durden
The Gang of Four specifically warns about this, and it's important to
acknowledge that it's happening.
When people first learn about design patterns, they will immediately
begin looking for places to apply them. They will do this and fail in
some particular way, and in doing so, learn more about that design
pattern or perhaps one that they don't know of, yet. The issue most
people have is trying to solve a problem with a design pattern they just
learned without understanding that it isn't an appropriate pattern.
But, you have to do it wrong in order to learn why. Prepare to fail and
learn from those failures. It will make you a better coder.
Your initial hunch is that your problem would best be solved by the
Decorator pattern, but it very well may not be. The Decorator pattern
has fallen out of favor in recent years, as many people believe it
violates good OOP practices. It has its uses, but they're limited.
You should continue coding this using Decorator if you like, so you can
discover what its limitations are. It sounds like you're already
hitting them. It's possible that Strategy and Composition might be
useful here, as well. Just understand that you won't understand until
you code yourself into a corner a few times. :)
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
