I do not want to extend a class, just a one instance of a class with a protocol. is this possible?
What you are describing sounds like the current proposal for specify! (JIRA and Design Document). So, it is currently not possible to extend a single instance with a protocol.
Related
I know there is this question on multiple inheritance/composition. However, it seems like this question is more about how to reuse functionality from multiple existing elements in other elements. And obviously, the solution for that are mixins.
I would like to know, how I can actually "decorate" existing elements without really borrow functionality from them. We know there is this extends property one can use to extend an existing element with Polymer.
So making a normal <button> behave like a mega-button is as simple as attaching <button is="mega-button"> and write a component for it. But it turns out, that it's not possible to extend multiple elements. So something like extends="foo bar" doesn't work. What if I want to build a web component, that can actually be applied to different elements?
For example, I don't want to only extend <button> elements with mega-button but probably also an <a> element so that it looks like and behaves like a mega-button too?
The mixin approach doesn't really help here (as far as I get it), because they do nothing more then providing shared logic for different web components. That means, you create multiple components, and reuse logic (packed in a mixin) from a mixin.
What I need is a way to create one web component that can be applied to multiple elements.
Any idea how to solve that?
UPDATE
Addy answered with some approaches to handle that use case. Here's a follow up question based on one approach
How to find out what element is going to be extended, while registering my own in Polymer
And another one on Is it possible to share mixins across web components (and imports) in Polymer?
UPDATE 2
I've written an article and concludes my experiences and learnings about inheritance and composition with polymer: http://pascalprecht.github.io/2014/07/14/inheritance-and-composition-with-polymer/
If you need to have just a single import that has support for being applied to multiple elements, your element could include multiple element definitions which may or may not take advantage of Polymer.mixin in order to share functionality between your decorating elements.
So pascal-decorator.html could contain Polymer element definitions for <pascal-span> and <pascal-button>, both of which mixin logic from some object defined within pascal-decorator.html. You can then do <button is="pascal-button"> and <button is="pascal-span"> whilst the logic for doing so remains inside the same import.
The alternative (if you strictly want to do this all in one custom element, which imo, makes this less clean) is to do something like checking against the type of element being extended, which could either be done in the manner you linked to or by checking as part of your element registration process.
In general, I personally prefer to figure out what logic I may need to share between elements that could be decorated, isolate that functionality into an element and then just import them into dedicated elements that have knowledge about the tag (e.g <addy-button>, <addy-video> etc).
I want to dispatch events to announce the progress of an asynchronous process. The event should contain 2 properties: work done and work total.
As the name suggests ;) i could use ProgressEvent; it has bytesLoaded and bytesTotal properties that i can use. However, my async process isn't loading bytes, its processing pixels, so the property names are a bit misleading for my use case - although the class name is perfect.
The alternative is to create a custom event with two properties that i can name how i like. But this means another class added to the code base.
So my question is; Is it better to reuse an existing class where the properties are suitable but maybe the naming isn't ideal; Or to create a custom class that perfectly fits the requirement? Obviously, one extra class is no big deal, but OOP is all about reusing stuff so adding an unnecessary class does make me uneasy.
I await your thoughts...
PS: This is my first question on stack so be gentle
For clarity, I'd create a new class. Adding a new class is not much overhead at all, especially for something simple like an event. I find that code is more readable when I don't have to make mental translations (like bytesLoaded really means pixelsLoaded). To me this is akin to choosing poor names for variables.
In addition, by going the other route and re-using the ProgressEvent class, I would feel compelled to document the code to indicate that we're dealing with pixels rather than bytes. That starts to get messy if you have a lot of classes that uses the event.
Re-use is great, but I'd opt for clarity as long as it doesn't impact your productivity or the app's performance.
writing in doc clearly, using custom event or ProgressEvent is well.
Could anyone give me a good use case for ActionScript dynamic classes?
Because it really looks like a bad pratice, for me, in every case.
Anything that uses Proxy must by extension be dynamic. I use Proxy fairly regularly; for example, here's a replacement syntax for ExternalInterface using Proxy.
URLVariables, for example.
You could store the data in a dictionary / object / array too, but you don't gain much in this case, I think, and you cut down some boilerplate.
Well you could use an Object object, but using a dynamic class ensures that it is typed. That's the way I see it, and it's the only reason I would use them. What Juan Pablo is saying is a good reason too.
Disclaimer: I'm trying to learn proper OO programming/design, so I'm pretty new to this stuff.
I guess this is a general design patterns question, but I'll base my example on a game engine or something that renders objects to the display.
Consider the following:
hierarchy http://img31.imageshack.us/img31/9633/diagrame.png
How can this sort of separation between physical objects (e.g., cubes, spheres, etc.) and the rendering mechanism be achieved in an extensible manner?
This design is not set in stone, and perhaps I've got something wrong from the start. I'm just curious as to how a problem like this is solved in real world code.
That would be the Adapter pattern, or it could be implemented as a Strategy pattern.
The renderer should not be extended by the objects which he is supposed to draw. (Just my opinion) an object in your world is NOT a renderer but the renderer uses objects.
So you have maybe:
Interface IRenderer which defines a function draw(BasicObject).
Then your objects just extend BasicObject to be handled by the/a renderer.
As I said just my opinion. :)
Strategy patern it is.
I would use a Visitor pattern here.
Where the Visitor is the renderer and were the Visited is the 3D/Object.
I would also make the 3D/Object a composite.
I have problems with how to design some classes. I have three classes. One superclass, and two subclasses.
One subclass (AnimatedCharacter) is made by flash, and is used to display the object on screen. The other (CharacterPhysics) is made by myself to extend the superclass.
The problem is that the object I use, is of the type AnimatedCharacter, so I can't just put it in a variable of type CharacterPhysics.
What I tried is some sort of Decorator pattern, by giving the object of type CharacterPhysics a reference to the other object. But now I have to override all the methods of the superclass and pass the methodcalls to the reference. Not an ideal situation.
Does someone know how to solve this kind of problem?
alt text http://www.freeimagehosting.net/uploads/7a95f8352c.png
I don't quite understand the purpose of this class structure you describe (the class names confuse me), but in general a few things come to mind that might help you:
Almost always the best solution is to try and rethink your class model by evaluating whether you should for example break up the responsibilities of classes in an alternate way so that you could utilize inheritance and polymorphism in a better way.
"The problem is that the object I use,
is of the type AnimatedCharacter, so I
can't just put it in a variable of
type CharacterPhysics."
If you want to put an AnimatedCharacter into a variable of type CharacterPhysics, the former should extend the latter, or you should have a common interface (or superclass) for both and then type the variable as such. If this is not possible, my opinion is that you should probably try to rethink and refactor your whole class structure, assuming that you have a solid "object-oriented" reason for wanting to do this in the first place ;).
If the above is not possible, there are some other tricks you can evaluate in your context:
The use of mixins can work as a "poor man's multiple inheritance". Derek Wischusen has some examples on how to implement them in AS3 at flexonrails.net.
"Kind of" implementing the decorator pattern with flash.utils.Proxy. The problem with this approach is that you defer a lot of error checking from compile time to runtime, but the good thing is that you don't have to manually write the "proxying" implementations of all of the methods of the "decorated" object, but write just one (callProperty()) instead.
You can interpret a sublass as an instance of a superclass but not vice sersa. Did you state this backwards?
If so, you could use:
vas cp:CharacterPhysics;
...
var ac:AnimatedCharacter = cp As AnimatedCharacter
Off the top of my head, it seems like those 2 should be interfaces which your main class implements