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
