I want to review my OOP concept

hi!

i am expecting to have interview for a company in next few days. i want to revise my oop concepts.

Can any one of you point me to a *great* site, which help me in reviwing my concepts and test them.

Thanks

I don't know any great sites, but while we're waiting for somebody else's input, maybe you (or anybody else) can answer this question that I ask prospective employees:


Assume you have an inheritance hierarchy where Shape is the base class. You have derived classes like Rectangle, Oval, and Triangle. Now you've been assigned to add a Square class. What are the potential places within the hierarchy that you could place Square, and what types of things would you look at to determine the best place to put it?

This might be an incomplete answer, but I'll try anyway.

You can place them under here:

- Shape
- Rectangle

Things I'd take a look at:

- The protected member functions of the superclass. At the end, It would probably be Rectangle because Shape is more general. If Shape for example has a member variable called 'nSides', Rectangle would probably already have nSides defined as 2.

Is this correct, or am I missing something ?

I believe the idea was for hYph3n to answer, bud.

Actually, the idea was for anyone to answer. I just didn't want to respond until others (including hYph3n) had a chance to discuss it as well.

QuietWhistler, there is no "correct" answer. What you said is not wrong, although there is a lot more to it than what you stated in your post. I'll leave it at that for now.

Also, please don't forget the original question:

Quote:

---

Can any one of you point me to a *great* site, which help me in reviwing my concepts and test them.

---

lol. who else ever idea it was ... does not matter.

Well you can place it both under Shape and Rectangle class. However, it depends on the implementation of thse 2 classes.

if you place it under the Rectangle class then you must have to PUT ANGLES to 90 degree while initilization of the SQUARE object ... and it must be done in constructor. there are some other modification that you'll do ... like you'll only have length of one side.

If you have only these 3 type of class then you must put it under Rectangle. However, you can have Shape > Parrallalogram > Rectangle > Square ... i guess this heirarchy is the best.

What you people say?

The basic idea for public inheritance is the IS-A relationship. Class B should be publically derived from class A if and only if an instance of class B is an instance of class A.

In this example, most people's first instinct is to say that a Square is a Rectangle, so you should therefore derive Square from Rectangle. From a mathematical point of view this is true, all squares are considered rectangles.

However, in designing your inheritance hierarchy in code, you don't want to blindly follow the real-world interpretations of what fits the IS-A principle. Instead, you want to know whether the objects fit the IS-A principle within the code design. In other words, does the potential derived class work like the base class in all situations? Looking at code that uses the base class, can you drop in the derived class and have it still work as expected?

So in our example, you want to look at the code and determine whether the Square really will work just like a Rectangle in the existing code. What if the Rectangle class has a Widen(int) method that takes a value that the width of the rectangle will be increased or decreased by? There would be existing code that takes a Rectangle reference or pointer and calls Widen, expecting the width of the rectangle to increase or decrease. Could that code expect the same effects if the actual type of the Rectangle reference or pointer was really the derived Square class? Probably not, since you cannot widen a square without affecting its length. In that case, perhaps placing Square under Shape and next to Rectangle would be more appropriate.

When listening to interviewees answer this question, the first level of understanding that I look for is the understanding of the IS-A relationship and how you want to avoid public derivation unless the it models IS-A. Many people know this, even if they don't express it in those terms. The second level of understanding I look for is how well they know what determines IS-A. Most people fresh out of school have only a basic understanding, and think in terms of real-world relationships, or in terms of specifics like which member variables can be re-used or which methods need to be overridden.

The ideal response would be an understanding of the idea that you use dynamic polymorphism so that existing code that uses the base class doesn't have to be changed as you create derived classes. It would avoid the common tendency (that is not always accurate) to derive a class in order to avoid rewriting code in the potential base class that does almost everything you want. So if someone were to say that they would derive from either Shape or Rectangle depending on how well Square would implement those interfaces without changing the expected behavior, I would be quite happy.

For more reading on this check out C++ Coding Standards by Sutter and Alexandrescu, Item 37. Not surprisingly, it seems they used the same Square/Rectangle example I used here, and probably explained it much better than I did. While you're looking at that, make sure to read the rest of the book too. I'd be interested to hear whether anybody disagrees with this philosophy or wishes to expand upon the topic.