I have one slight issue with the decorator design pattern. It seems that the decorated objects are tied to the same interface as a standard non-decorated object.
Please see the example of the website line below.
https://www.tutorialspoint.com/design_pattern/decorator_pattern.htm
In this example the RedShapeDecorator is tied to the shape interface so both the RedShapeDecorator and a standard Circle object can only call the draw() method.
Well what do I do when I want my decorated object to be able to call more then draw(). What if I want my decorated object to have methods like drawBlackAndWhite() and draw3D() both of which are not appropriate to wrap up in the draw() method.
In other words I want to be able to extend the RedShapeDecorator to do the following..
redShapeDecorator.draw()
redShapeDecorator.drawBlackAndWhite();
redShapeDecorator.draw3D();
But the Shape interaface is limiting me to only calling redShapeDecorator.draw(). How do I solve this?
I'm not sure if I get the question right, but if you want a method drawBlackAndWhite()(assuming it's analogue of RedShapeDecorator.draw()) you can define additional method in your decorator. To get draw3D() method in your decorator you should create a new implementation of Shape interface which capable to draw 3D objects(because existing implementations Circle and Rectangle are flat). If you want all these methods in one instance of your decorator put multiple Shape fields in it. But you won't be able to call methods drawBlackAndWhite() and draw3D() by reference with type Shape because Shape interface has only one method draw()
Related
There is a hello animation example, where, apparently, predefined character with predefined animations is used.
But what if I want to create some animation on-the-fly, programmatically? Suppose I want just cube perform some movements and rotations?
I found a class Animation which allows adding a tracks. One of the tracks type is SpatialTrack which has obvious structure: it apparently consists of a series of transformations and rotations over time.
But what to do with such an object, once it was created? How to "apply" or "execute" it on some geometry?
UPDATE
I found another pattern: first create MotionPath, then wrap it into MotionEvent and then add resulting object to the object you want to behave with addControl() method. Probably object will follow the path. Unfortunately, I can't find, how to set the orientation. Despite the fact that MotionEvent class has getRotation() method, which is documented as returning rotation of target object, I can't see any methods to set rotations in MotionPath, which constitues the MotionEvent.
I recommend using Cinematics for what you are attempting to do. All you have to do is create a cinematic object, add the appropriate events to it, and then use objectName.play().
The best part is that you are able to use both your original idea of animation objects as well as through your edited idea of using MotionPaths. You just have to use AnimationEvents and MotionEvents respectively.
You can also implement looping through a simple function that the wikipedia page gives you as well as being able to set direction for the movement.
I have some questions regarding the representation of the gui objects in uml class diagrams.
For example if a have a class which extends the JFrame, then i will design the UML class diagram with the inheritance symbol, but in the JFrame, i do not need to write down all of it's class variables and methods, but only those whose my class will use right??
Second how will i represent that my class will use a specific layout manager? With the association symbol, i quess but i am not sure.
Say for example I have a package named gr.mydomain.exampleproject, and I have a class extending the JFrame.
Is the following approach correct or do I need to put the JFrame in a separate package (javax.swing)?
Yes, you must draw the inheritance symbol to the JFrame class, but leave the JFrame class empty, don't put any fields or methods in it. Everybody knows or can look at the API to see what JFrame contains. Besides, you would fill up the space with the multitude of methods present in JFrame.
Do it like this:
As for layout managers: I believe the dependency relationship is the correct one in this situation. The association relationship would be correct if you would call methods on the layout manager's class. But you're probably just doing something like frame.setLayout (new LayoutManagerClass ()); (a.k.a. just creating the object). In this case, it's a dependency relationship.
Is there a time when it's more appropriate to subclass AbstractBorder than to implement the Border interface when developing a custom Swing border? And vice versa?
From the example code that I've seen, it seems quite arbitrary.
For clean OOP you should implement the Border interface. But, if you do not to plan to extend any more your new Border class with new classes that inherit from your Border, it is more convient to extend AbstractBorder.
AbstractBorder makes part of Swing to make your work easier. So use it, but do not make it the base of a class hierarchy.
Sometimes when Java has an interface XYZ and a class AbstractXYZ the class does quite a bit of work and leaves you just the bare minimum to implement (e.g List and AbstractList). Sometimes the abstract class just provides a do-nothing implementation (e.g. MouseInputListener and MouseInputAdapter).
AbstractBorder is more of the latter case; it doesn't really help the implementation of Border but it does provide some helper methods which (AFAICS) are of more use to the component 'hosting' the border than the border itself.
So, I would say it probably is a bit arbitary which one is used. I'd recommend using AbstractBorder anyway, there's no reason not to (unless you need to derive from another class of course.)
#PeterMmm, why shouldn't you use it as part of a hierarchy? A lot (All?) of the standard Swing borders derive from AbstractBorder.
I am writing a code that involves composite pattern and would like some clarification. I have Super Manager, a Main Manager and Ordinary Manager and they are in a descending hierarchy with the Super Manager at the top.
I would want the Super Manager to be able to give Main Manager some money and Main Manager to be able to give Ordinary Manager some money. The problem I have is I don't want Main Manager to be able to give Super Manager some money and I don't want to use instanceof to ensure that, since it defeats the purpose of Composite pattern.
My Main Manager and Ordinary Manager extend an abstract class called gradeManagers while my Super Manager has an array list to be able to to add components of type gradeManagers.
It doesn't sound like your hierarchy is a great fit for the Composite pattern. The Composite pattern is meant to allow a collection of objects to be treated in the same way as individual objects. (Think of parts being bolted together. Sometimes you want to think of a sub-assembly as a single part that can be bolted together with other parts/sub-assemblies. The sub-assemblies are the composites.) If I understand what you are trying to do, you don't have a collection of Manager objects that you want to treat as another Manager.
Nevertheless, whether or not you use Composite for this, I suggest adding a property (let's call it depth) that increases as you go down the hierarchy. You can then use this to implement your business rule: a Manager can only give money to another Manager of equal or higher depth. This allows you to code in a way that avoids any notion of object class.
As it has already been mentioned by Ted Hopp, this doesn't sound like something where you'd use a Composite Pattern. This just sounds like a case of polymorphism.
Composite Pattern should be used when you want a group of items to be treated as one. Consider a drawing program where you can place shapes on a screen, this could be triangles, squares, etc. Now, consider a functionality where you are able to change the background color of those shapes. If you wanted to change the background color of multiple shapes, you'd want to do something like this
interface Shape {
public void setBackgroundColor(Color c);
}
And in your actual implementation code:
for (Shape s : selectedShapes)
s.setBackgroundColor(c);
Instead of doing this in the code, you could use a composite pattern. This allows your implementation code to be completely oblivious to the fact that the "shape" you want to edit is actually multiple shapes, and allowing your application to treat it as any other shape.
class CompositeShape implements Shape
{
public void setBackgroundColor(Color c);
for (Shape s : Shapes)
s.setBackgroundColor(c);
}
class TriangleShape implements Shape { ... }
class SquareShape implements Shape { ... }
I would extend #Ted Hopp's answer and suggest that instead of depth you could use grade. This might be closer to the domain you are working with. Since you already pointed out that you do have grading managers this may be an elegant solution.
Hope that helps.
To illustrate my problem, let's say I have an instance of Thing which has two text properties - 'foo' and 'bar'.
I want to create a Panel to edit instances of Thing. The panel has two TextField components, one for the 'foo' property and one for the 'bar' property.
I want to be able to call setDefaultModel() on my Panel with an instance of IModel<Thing> and for the TextField components to reference this model. How best to achieve this?
Should I override the Panel.setDefaultModel() method to also call setModel() on the two TextField components? Or perhaps create anonymous ReadOnlyModels for the TextField components, overriding the getObject() method to retrieve the object from the containing Panel's model?
Neither of these seem very elegant to me, so I was wondering if there's a better way?
You can use a PropertyModel for the textFields. Pass the IModel<Thing> into the constructor of the PropertyModel with foo as the property name:
add(new TextField("fooFieldId", new PropertyModel(thingModel, "foo")));
The PropertyModel will figure out that the thingModel is a Model and call getObject().getFoo() etc.
This assumes the IModel<Thing> instance doesn't change, only its underlying object which can be changed calling setDefaultModelObject.
Maybe I'm just missing the point, but I can't find a Panel.setModel() in the JavaDocs of neither 1.4 nor 1.5. If it's something you implemented maybe you could change it not to replace the model object but to call model.setObject() instead?
Disclaimer: Can't really check right now, cause there is no wicket at work and my home machine suffered a video card breakdown earlier...
Maybe this would help?
public abstract class AbstractWrapModel<T> extends Object implements IWrapModel<T>
Simple base class for IWrapModel objects.
See IComponentAssignedModel or IComponentInheritedModel so that you don't have to have empty methods like detach or setObject() when not used in the wrapper. The detach method calls the wrapped models detach.