Everywhere I could read about Liskov Substitution, only 1 example is available which is Rectangle and Square and It is explained how we can violate it but no corrective actions are described.
One such example is available at This link :
I want to know corrective steps If we are violating it.
Thanks in advance.
In the case of Rectangle and Square the corrective action is simply, don't implement inheritance between them. The LSP tells us that neither is a parent or child of the other, so keep them separate. They can still be siblings, e.g. both can inherit from Shape; but they are separate branches of the Shape hierarchy.
The other potential solution to an LSP violation between two classes is to redefine one or both of them. This isn't a viable solution for Rectangle and Square because they are defined mathematically; but in a scenario where you have control of the abstraction or its implementation, you can edit the contract to fit the code or vice versa.
Related
We have to make a custom dataset for object detection for CNN. So we're going to note objects for detection with bounding boxes. I referred to several guides for object detection labeling like PASCAL. However, we encountered an issue for labeling.
If we want to label people in dataset images, do we need to label all visible objects(=people) in a picture? If we skip some objects(=people) in a picture, does it effect on object detection? I added some examples for labeling. Image (1) is a case of labeling all visible people in an image. And in Image (2), we just labeled some people in entire image.
Is Image (2) influence bad effect on object detection? It it does, we're going to label all visible objects as possible in an image.
(Image 1) Labeling all visible objects in a picture
(Image 2) Labeling some visible objects in a picture
Object detection models usually consist of 2 basic building blocks:
Region Proposal Generator
Classifier
The first block generates various region proposals. As its name suggest, the region proposal is a candidate region that might contain an object.
The second block receives every region proposal and classify it.
If you neglected a true positive object within the image, then you force the object detection model to label this true positive object as background. This heavily affects the learning experience of the model. Think of it for a while. You ask the model to do different classifications for the same sort of object.
As a conclusion, you have to label each true positive object to the model.
Yes it is important, if you skip some persons the network will only partially learn how to detect and regress a person location. The network may be resilient to few labelling errors but not as many as in your second example image.
To train an accurate network you need to label every visible object instance and if you want your network to be resilient to object obfuscation you should label partially masked objects too.
You can easily verify this behaviour by training two networks: one with all labels and the other one with half of them.
I have a component which presents an x/y axis plane and a nub that users can move around within the plane. Some aspects of accessibility here seem pretty straight forward: the nub should be focusable; keyboard up/down/left/right should move the nub by some interval to increment the x/y values in the appropriate directions. Even with a secondary text input, these behaviors for the widget-proper may be helpful regardless of whether users are employing assistive technology.
But when I began investigating how I should mark this up aria-wise, I wasn’t sure what the appropriate role/roles should be, or what the best way to communicate the available functionality is.
The closest match for a role appeared to be "slider":
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_slider_role
However the slider role as described on MDN seems like it may be specific to single-axis sliders.
A slider is effectively 1D only, so it isn't the appropriate role.
To convaince of this, read the description of slider in ARIA 1.1.
http://www.w3.org/TR/wai-aria-1.1/
Nothing in the description mentions that you may use something else than simple numerical values, comparison between values should be unique and total (for 2D points it is not), and it also reads the following:
Elements with the role slider have an implicit aria-orientation value of horizontal
It's horizontal; it may certainly be vertical; but definitely not both at the same time.
By the way, by default, Jaws for example announce more or less this for a slider: "left right slider. Use left and right arrow keys to adjust the value" which is wrong for your case.
IF you were in a discrete plane, I would have suggested grid/row/gridcell. But since you are selecting coordinates in a continuous plane (or almost),
your case is special / unconventional, hance there doesn't exist a predefined ARIA recipe you can apply.
IN such a case where there is no really adequate role, tehe best play is probably to not indicate any role at all for your component.
An assistive technology will therefore not confuse the user by telling him what your control is not really, nor by giving him wrong indications on how to use it. No indications at all is probably better than wrong ones.
You must of course still use aria-label/aria-labelledby to give your component a label, make it focusable and keyboard usable.
You should also ideally compensate the absence of predefined role by giving precise keyboard usage instructions. For this, keep it rahter short in aria-describedby (which might be read each time the control is focused), and if needed / if the control is quite complex, explain it longer somewhere else with plain text.
IF it's really too complex, you are also allowed to give up, as long as you provide an acceptable alternate input mean giving equal possibilities. For a color chooser, enter RGB value or #XXXXXX code would certainly be acceptable and sufficient alternate input means.
I'm looking for a bit of clarity here. For one of my projects, I wrote a container that holds a bunch of different geometrical shapes. My interface is as such:
Container::AddTriangle(Point, Point, Point);
Container::AddSquare(Point, Point, Point, Point);
and so on and so forth. I like this interface since it does a compile-time check to make sure you have the data that you need. However, in discussions with my team, someone proposed this interface instead:
enum SHAPE { Triangle, Square };
Container::AddShape( std::vector<Point>, SHAPE );
With the argument that it provides cleaner code by only having one function instead of many. While I certainly prefer the first method, I don't have really any argument against the second one. Has anyone encountered this choice before? Is one choice better (or at least traditionally preferred) to the other?
Note: Before someone proposes:
Container::Add( Shape )
I would like to let you know that this is not a good solution to my specific problem. I promise.
I'd go for the first version. Having a single function Add(std::vector<Point>, SHAPE) just adds lots of undefined cases, e.g. what do you do if you want to add a triangle with 10 elements in the vector?
Functions like AddTriangle, AddSquare and so on are cleaner and it's easier to see what gets added in the code. Having a function AddPolygon(std::vector<Point>) could be used for adding generic shapes.
Even if you store your shapes as a std::vector<Point> in the Container class I would still prefer the first version. You can just create the vectors in the AddTriangle/AddSquare functions.
The principal argument against the second one is that it ignores the fundamental utility of having two distinct functions: Triangle and Square are two distinct entities. The code is clear and unambiguous when there are two separate functions with two separate parameter lists.
One function does nothing to simplify the code, for one the vector causes confusion: Why have an enum when you could determine the shape by the size of the vector? What if you want a triangle with 4 points, what does the software do then? Clearly this is not cleaner. Additionally instantiating the vector when calling the function will be significantly more complicated then simply instantiating the points individually.
Why not both? It seems like there are two separate concerns here: the interface and the implementation. The first is a better interface because the parameters are explicit, but if each function is nearly the same, they should all be using the same implementation. In other words, AddTriangle should do nothing but call AddShape(vector, Triangle), while external users of the container should use AddTriangle but not work with AddShape directly.
Can anyone explain why (indeed, if) it's best to abstract the major parts of a canvas game to different layers when using something like Kinetic?
It of course feels like you should, and so far I have been: one layer for the background, one for the player's character, and others.
Then I ran into a situation where I needed a shape of one layer to sit behind a shape on another layer - but moving the entire layer behind the other layer was not an option, so I reluctantly re-coded so the entire game sits on one layer.
To my surprise, though, I can still do everything I need. I can still animate or handle events on individual shapes or groups.
So in short: what advantage does explicit layering bring? What pitfalls might I face with the one-layer approach?
Actually, layers usually give a huge advantage. However, sometimes they are not necessary. Just to give an idea - compare PhotoShop (layers) and MS Paint (no layers). If this gives you the idea then that's it!
If not: layers is an organizational concept. It lets you to deal with data in pieces. They allow:
Apply certain transformations to a whole layer.
Automatically categorize your objects on a per-layer basis, so that you can get
all objects of a layer and work with them pretty easily.
Isolate anything that happens in a layer from happening in other layers.
Disable/enable whole layers.
Much-much more!
As you see, layers, generally, allow such abstractions as encapsulation and, to some extent, polymorphism to be enforced on content organization level. Pitfall that one-layer approach brings is just that - too tight coupling - a beast from the world of permanent chaos that encapsulation and polymorphism fight for the eternity. Nuff said!
If your game contains a lot of different stuff, it might take time to draw everything. Too much in the same layer reduces performance. Although too many layers does so aswell.
Check out: http://www.html5canvastutorials.com/labs/html5-canvas-kineticjs-drag-and-drop-stress-test-with-1000-shapes/
In organizational terms, noncom's answer was spot on. However, as he has noted his answer is more in regards to canvas animations in general, and you are quite correct in pointing out that KineticJS provides it's own tools to offer those same organizational benefits.
So, with organisation irrelevant, all we have is performance. With that said, the main difference is that each 'layer' corresponds to a distinct canvas tag.
The simple answer then, is that having multiple layers allows you to selectively redraw only one canvas tag at a time. Think about it, if you have objects moving on top of a background, do you want to be clearing and redrawing the background every time those objects move?
If you're not using layers, that's what is happening. What you want is a background that only ever gets drawn again when the background changes, that means a layer for the background.
Whether this is actually worthwhile depends highly upon your application, but that's the idea. The point of layers (outside of organisation) is to isolate the required drawing processes to things that actually need to be drawn. With complex animations this can be incredibly important to maintaining decent performance.
Here's a jsperf for reference: http://jsperf.com/layered-canvases/3
With the display list in Actionscript 3.0, I'm often inclined to have children add themselves to their parent because they often already have that reference. That would look like:
_myParent.addChild(this);
or when removing...
this.parent.removeChild(this);
By the wording of the addChild() syntax, this way seems backwards -- the name suggests the parent should be the only one calling that function.
Does anyone else do this?
Or does this seem backwards and confusing?
Perhaps I'm getting myself into situations I shouldn't be in?
It seems like a violation of responsibilities because the parent should be the only one calling its own method and in charge of its own display list.
You'll want to be cautious whenever a child refers to its parent. While it doesn't break any rules associated with Object-Orientation, it does start to make your Composite structure more difficult to maintain and understand.
The Display List in ActionScript 3.0 is designed to use method calls when interacting with children, and events (sometimes bubbling) whenever a child does something that may be interesting to a parent.
This direction helps us keep children ignorant of their position in the hierarchy, and design them more like general purpose (reusable) components. In general, an ActionScript Display List moves from more to less specific as it moves from parent to child. For example, a CreditCardForm might contain a TextInput control.
Though it is not a good practice, this.parent.removeChild(this); is sometimes convenient (depending on your design) - and I remember doing it in the early days of AS coding... then i was advised that its not a good way of doing it and i dnt use it anymore.
Regarding _myParent.addChild(this); -- I don't usually pass the parent object to the constructor/methods of child... I think this practice has its roots in AS2. And yeah, it looks strange/confusing since its not the AS3 way.
It seems bad to me as the state of the parent is its children. So by having reference to child you can change parents state and it breaks the encapsulation.
Let`s think of a simple case when you need to implement drag and drop. It can be done in this way:
Tell child to remove his him from his parent. Then tell child to add him to a new parent. And parents are not even know about that :-).
Tell parent - I need your child. He will remove that child. Then tell to other parent: from now on this child is yours.
The second way seems more reasonable to me, because if you need to reject some children (parent cant have some types of children, or need to do some actions when you are getting new children, like prepare a bedroom, or buy some toys), youll be have to call all this from your child class. And this will require show all your parents implementation for that.
Sure it can be done via generic interface of parent, but I think its much easier to delegate this responsibility to parent and provide child. Every parent will know what he should do to add this child.
_myParent.addChild(this);
Let's break this down...
_myParent
This is a reference to another object, which happens to be the object's parent on the display list. There are many reasons for an object to have a reference to its parent. They are closely related in structure, so likely have reasons to communicate with each other. So, having a reference to the display list parent isn't an issue.
addChild()
Calling one of the parent's public methods isn't an issue. That's what methods are for. If this were a property of the parent, it would be invasive. Calling this method won't directly alter the parent's state. The parent will carry out this function at its own discretion.
this
The fact that the argument in this case happens to be self-referential is a coincidence. If the argument were something trivial such as new Shape(), it would seem less awkward. But, since an object is essentially "adding itself", it seems something like a person lifting himself up by his/her bootstraps. But, this isn't real life; it's computer programming, and it makes sense when read by its syntax.
Actionscript needed to name the function something. The other alternative for getting a child onto the display list could have been addToParent(), which would still have the same awkward effect when trying to add a child from the parent -- _myChild.addToParent(this).
So, while there are no objects being violated in this awkward predicament, there is a more natural way of writing addChild() statements, and that's to add children from parents, instead of the other way around because that's the order laid down by the syntax. So, try to use the natural way, and when that fails, the other way is still okay, just a little awkward.