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):
...
Related
I'm currently working on an Angular app, specifically a quite complex table, in terms of styling and features.
My component file currently has 2k lines of code, and it comprehends functions for styling text, styling the table, functions for check if data treated are correct, data formatting and so on...
Many of theese funtions are called directly from the HTML fiel thorugh interpolation.
Is there any way to break up this quite large file into smaller ones?
You can break up your component into smaller ones and nest them.
Typical example:
<app-list>
<app-list-item></app-list-item>
</app-list>
The parent component can then pass its properties down to the child components:
<app-list>
<app-list-item [name]="valueFromParent"></app-list-item>
</app-list>
It is further possible to emit values back up from the child to the parent:
<app-list>
<app-list-item (onChildEvent)="updateParent($event)"></app-list-item>
</app-list>
I tried to keep it simple here, but there is more to it.
I suggest going through the official Angular tutorials, because they explain these concepts pretty well.
You should further try to put as much functionality into Services as possible. This also helps to make your components smaller, easier to reason about and helps testing.
E.g. a functions for check if data treated are correct would be a good example for a service method.
It might be a matter of preference, and thus be biased. But it's such an important matter that I find it really interesting to have some feedback on this question.
Needless to say, any language needs them. But when and why is it best to resort on them?
Is it wise to use a function just for clarity, even if it's not used more than once in the code?
Where do you usually declare your functions (in js for instance), just before you use them for the first time? at the beginning of the script? …?
The practice we use at our company is to only use functions when a piece of code is reused, were the function is located depends on what is reusing the function. If it is only used, lets say within a class then we would keep the function within that scope. If is it reused by other classes then most likely we would add it to a utility class accessible by other classes unless it is directly associated with that class object in that case we would make it public within that class.
Hope that helps!
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.
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
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.