In programming literature and on internet in general I noticed frequent use of term "wrapping".
For example "to wrap library in classes" or to "wrap database". Is that official in programming or just a slang ? And what is the best way to describe it ?
Thanks
"Wrap" is a standard English word meaning "Cover or enclose". Typically programmers use it to mean enclosing the functionality of something with something else. It's a fairly widely accepted term. There is no "official programming terms" guideline, so that's about as close as it gets.
Example:
a wrapper function is a function that calls another function;
a wrapping class is a class that holds inside itself a reference to another object;
the Facade design-pattern is a class/object that wraps around another object, for the purpose of simplifying the interface to access/use such object;
a Decorator design-pattern is a class/object that wraps around another object at run-time, for the purpose of enhancing the object's interface with new functionality (without having to modify the object itself).
Related
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 am building a simple swing GUI in Clojure. I am trying to apply a single function to multiple GUI components by using map in the context of a let:
(map #(f % component4) [component1 component2 component3])
Where the components are all defined in the let.
Problematically, map is lazy, and the action is not applied to the components, however, I can force it by wrapping the above in a 'take'.
Is there a non lazy alternative to map? Or should I be going about this differently?
EDIT:
Using counterclockwise in eclipse. I had different results using (use 'Lib :reload) from the REPL and using CTRL+Enter from the editor. Reloading would launch the GUI, but the problem described above would occur. The problem did not occur when using CTRL+Enter from the editor, therefore I think my description of the problem may be inaccurate. Regardless, doseq seems to be a better alternative to map in this scenario.
I challenge your assertion that getting take involved makes any difference at all. If you wrapped it in doall or dorun it would do what you want, but you should consider using doseq instead of map for this sort of side-effect-only action.
Note
Originally posted as comment on question; copied to answer by popular demand.
doseq is probably the best way to approach this. doseq is roughly equivalent to a "for-each" statement that loops over each element of a collection in many other languages. It is guaranteed to be non-lazy.
(doseq
[comp [component1 component2 component3]]
(f comp component4))
Some general advice:
Use map and its lazy friends (including take, drop etc.) when you want a sequence as an output
Use doseq, doall, dotimes etc. when you are more interested in the side effects
Wrapping your map in a doall will force its evaluation. or a better alternative is doseq which is used for things involving side effects.
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