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
Related
I've created several iterable classes. The code to provide these iterable properties is repetitive throughout each of the classes and clutters the code, distracting from the class unique functions.
I'm talking about having to write down __iter__, __next__, __getitem__,__setitem__, __len__, and append functions, the same way for each of my classes (see image below).
Is there any way to just write this down once, and import it in my class?
If this seems a too basic question, I promise I tried to work my way through the search results, but they landed me many different types of imports, function and class usage, without answering my question.
I learned the solution to this problem as I learnt more about inheritance:
So the solution would be inherit to start with:
class Samples(list):
...
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.
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.
Personally, I've never liked the MyObject naming of classes. I would guess that the status quo would agree but I'd like to see the other side of the argument and if there's any validity to it.
'My' is already used by me, use something else
I've never seen it done in production code, although I dare say it exists.
It's like the metasyntactic variables "foo" and "bar" - it's usually used as a placeholder for a real name.
So for example, if I know that someone has their own class deriving from Form, but I don't know anything else about it, a code example would use:
public class MyForm : Form
I'd certainly take a firm stance against it for real code though :)
I suppose one instance where it would be close to acceptable is if the class you're prefixing with "My" is an inner class (i.e a private class declared within another class). I'm not sure if there are any naming conventions governing inner classes, but this could be one way to differentiate.
As far as I've ever seen, My is a prefix used in sample code that indicates "your stuff goes here".
It's kind of like foo. Teaching purposes only.
I've used My in 2 situations:
Way back when in my first programming classes in school
When I am doing basic 'hello world' applications to learn a language
but NEVER in production or even pseudo-production code.
I'd avoid it in production code, your type name should reflect the function its supposed to perform.
I've used it a couple of times when patching/hacking third party code, for instance replacing Controller with MyController to make it clear it is a hack, that should be approached with caution, and a bat.
I sometimes end up with a class hierarchy where I have an abstract base class with some common functionality and a couple of implementing classes that fall into two (rarely more) groups which I want to treat differently in some cases. An example would be an abstract tree node class and different branch and leaf implementations where I want to distinguish branches and leaves at some point.
These intermediate classes are then only used for "is-a" statements in flow control and they don't contain any code, although I have had cases where they "grew" some code later.
Does that seem smelly to you? In my tree example, one alternative would be to add isLeaf() / isBranch() abstract methods to the base class and implement those on the intermediate classes, but that didn't seem to be any better to me, really, unless I'd mean to have classes that could be multiple things at once.
To me, using "is-a" tests in flow control is just as smelly as using switch/case. In a good OO design, neither is needed.
Yes, deep inheritance hierarchies are a code smell anyway.
Yup, definitely a code smell -- don't code these empty classes unless you're ready to write that code into it. Think YAGNI (you aint gonna need it) -- don't do it unless you need it already.
Also, have you considered cases wherein these classes are only there to provide abstract methods, or to group them based on capabilities in terms of methods or properties?
If that's the case, maybe what you really need are interfaces, not additional abstract classes?
In general, empty classes are a code smell.
I agree your isLeaf or isBranch methods are a correct alternative.
They add information about the objects , which is helpful.
(This is because, on the super class, you can't express that subclasses are "either leaf or branch").
The two methods with opposite results might also be considered as code duplication.
You could use only one... But I would recommend return an enumerated value LEAF or BRANCH.
A class that doesn't contain any code is definitely a code-smell....
Seems alright to me, if you're going to put new functionality in later.
But if not, an enum is generally used here.
-- Edit
Though I must agree with Ber, that you shouldn't generally be using 'is-a' anyway.