i want to implement an Algorithm class which uses some utility classes.
but one class may need member variable or function of other utility class. So instead of
composition is it better to use inheritance as below ?
class A{
public:
void setA(int var){ a = var;}
int a;
};
class B{
public:
void foo(int var){
if (var==1){
//bla bla...
}else{
//bik bik...
}
};
class Algo : public A , public B{
public :
void run(){
setA(1);
foo(a);
}
};
Your class Algo should only inherit from A and B if it is a true IS-A relationship to A and B. If you are just wanting to use functionality from A or B, consider composition instead (or at least private inheritance).
For example, if I want to create a class, and that class needs to do some logging, then my class HAS-A logger, but it's not the case that it IS-A logger. Thus I wouldn't want to inherit from logger, but use composition instead.
In your case it doesn't make sense to use inheritance because Algo isn't a A or B, it merely uses them.
Inheritance is meant to express an "is a" relationship and should adhere to the Liskov substitution principle. Can you say Algo is an A and Algo is a B? In general I feel it's a bad idea for a derived class to muck with the base classes private variables (you may set them as protected but they should probably be private). You can always write getters and setters. You can get into trouble with multiple inheritance in so many ways and I think your approach while convenient now will lead you to program in a less maintainable way. I try to reserve inheritance for when I need to treat classes polymorphically, in most other cases I prefer composition.
I like this concept of inheritance:
Commonly thought of as a way to "reuse existing code" by creating a new class that inherits from another existing class. This way you can extend the functionality of an existing class w/o touching the existing class's code. But Herb Sutter has a bit of a different take on the use of inheritance--"Inherit, not to reuse, but to be reused. Don't inherit publicly to reuse code (that exists in the base class); inherit publicly in order to be reused (by existing code that already uses base objects polymorphically)." [C++ Coding Standards, p. 64]. He also says "In correct inheritance, a derived class models a special case of a more general base concept." [ibid, p. 66]
http://cpp.strombergers.com/
so if you don't need to reuse code polymorphically, or to make more special case for base, better use a composition.
Don't pick inheritance over composition as long as you do not need polymorphism. In your case, as you don't have and virtual functions in classes A and B that needs to be changed in class Algo, composition may be a better design choice.
Related
I have a function public void myFunction(foo); and public void myFunction(foo, bar); in my parent class. I want these functions included in my derived class, but privately. You can declare it in the derived class' private section by using BaseClass::myFunction(). Note that it doesnt take any parameters in the function. But if there are two implementations of myFunction like I have in my case, it won't work since it can't distinguish between the two functions. How do I implement both functions privately?
Based on what you've said in your comment about your professor's instruction to use inheritance, more than whether it's a good design choice, I think you are expected to use private inheritance.
Private inheritance is a valid feature of C++, but its often not a good design choice. I wont go into that, I'm not recommending it in general, I'll leave you to look it up elsewhere on SO, but also recommend Scott Meyer's books effective C++ & more effective C++ which covers this.
(protected inheritance on the other hand is very unusual)
In your question you seem to be starting from public inheritance and trying to make some inherited functionality private via using. This is a bad design choice as mentioned in comments. It violates the Liskov substitution principle. Since PUBLIC inheritance implies is-a, we can imagine the code that creates a base class reference to an object of the derived type, what then is supposed to happen when we try to call the hidden functionality with that base class reference?
Derived d;
Base& b = d;
b.HiddenFunction(); // calling the function on d even though you thought you hid it
If instead you use private inheritance you can then use using to publicise those privately inherited functions which are safe to expose on the derived class.
class OrderedLinkedList : private LinkedList
{
public:
using LinkedList::ItemCount; // expose some specific base functionality
};
If using doesn't do the job due to overloaded functions, then you can add just those overloads that you want to provide and implement them just by calling the base function. In such cases, if you need to clarify whether to call the base or derived version you can prefix the function name with the class name e.g.
void SomeFunction()
{
// call base version, not this derived version recursively
NameOfBaseClass::SomeFunction();
}
Within the derived class implementation, the public and protected members of the (privately) inherited base class are accessible without the need to do anything like add a using.
Private inheritance is not an is-a relationship like public inheritance since we cannot refer to the derived objects as references/pointers to the base. Private inheritance is "implemented-in-terms-of".
Since private inheritance is not an is-a, one cannot substitute such derived objects for the base and as such the liskov substitution principle just doesn't apply.
I give the following examples to illustrate my question:
class B;
class A
{
public:
class B *pB;
};
class B
{
public:
void perform(A &obj)
{
}
};
In the above two classes. class A has a pointer to class B. class B has a function that will work on class A object. Though it can compile, I was wondering whether this is not a good practice for designing two classes as they are intertwined. If this is bad design, do you have some ideas to avoid it? Thanks.
Having two concrete classes rely directly on one another can get you into trouble.
It is often better to "program to an interface".
There is a long discussion here under the title "Program to an interface, not an implementation", which draws out why decoupling matters
In your example, void perform(A &obj) could instead take an abstract base class that A derives from. It might be worth having an interface that A uses in it's member variable too, but there' no suggested usage in your example to go on.
Why is this "better"? For starters, it will make you think about encapulsation - and what specifically the interface should be exposing.
It will also allow you to use different conrete instantions of the class, say for testing purposes.
If you use an interface, you can change the conrete classes separately... there are many advantages.
Well there is enough information about this subject. For example this thread was very clear to me: Difference between private, public, and protected inheritance
Except one point; Why is it useful?
Use public inheritance to reflect an is-a relationship. This is the main use for inheritance, especially in combination with virtual functions. It allows re-use of interface, not just of old code by new code, but also re-use of new code by old code! (because of virtual function dispatch at runtime).
In exceptional circumstances, use private inheritance to reflect an is-implemented-in-terms-of relationship. This is a commonly overused pattern, often the equivalent goal can be reached through composition (having the would-be base class as a data member). Another drawback is that you can easily have multiple inheritance of the same base class (twice or more removed) leading to the so-called Diamond Problem.
Avoid using protected inheritance, it suggest that your class interface is client-dependent (derived classes versus the world). Often this is due to classes having multiple responsiblities, suggesting a refactoring into separate classes is appropriate.
The answer to this question concerns class interfaces and data encapsulation, rather than language capabilities.
The use cases of protected and private inheritance are rather limited, since there are often other options available which better solve the problem (such as using composition, rather than inheritance). However, there are times when you necessarily must inherit from some type (for example to interface with a third-party library), but you would strongly prefer (for reasons related to user interface of your class) to hide most members inherited from the base class from the users of your new type. A typical scenario would be when you need your type to have the member functions of a certain class for internal use, but it would break the logic of your new type if it was called from outside the class itself.
In these situations, you need to use private or protectedinheritance (depending on whether the interface should be similarly restricted to further derived classes or not.
Bear in mind, however, that this is all just about (strongly) hinting to the users of your class how they should use it. You're adapting its public interface to hide certain features which were public in its base class. This doesn't strictly speaking prevent people from accessing these members, since anyone can still cast a pointer to your derived class to a pointer to the base, and reach the "hidden" resources that way.
It's all about Data Encapsulation.
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
Encapsulation concept
It is good to protect your classes 'internal' data from other classes. Benefits include:
other classes have to go through the known proper access mechanisms (e.g. methods) to access your class and can't monkey around with the internals of your class directly (and hence potentially put your class into some unknown and broken state)
you can change the inner workings of your class and know that other classes won't break as a result
reducing visible external points of contact with a class makes your classes simpler to use and understand
Having the option of using protected instead of private also makes your code easier to extend through subclassing.
Private: private members of a class can be accessed only from class functions, constructors, and destructors. The client who will use your class will be unable to access them. So, if for example you are implementing a list class and you want to keep track of the list's size, then you should have a private variable (listSizeP for example). You do this because you don't want the client to be able to modify the size of the list without inserting elements.
Public: public members can also be accessed by the client. In the list example mentioned above, functions like insert and erase should be public.
Protected: protected members of a class, like private members, can be accessed only from class functions, but they can also be accessed by classes inherited by this class(actually it depends on the way the derived class inherits the base. If it is not public inheritance, then the derived class cannot access the private members of the base class. That's why the most common way of inheriting is public inheritance). Example:
#include <iostream>
using namespace std;
class Base {
public:
int num;
public:
Base(int x=0) : num(x) {}
};
class Derived : public Base {
public:
Derived(int x=0) : Base(x) {}
void tell() { cout << "num: " << num << endl; }
};
int main() {
Derived D(4);
D.tell(); // would cause error if num was private
return 0;
}
I was reading Scott Meyers' Effective C++ (third edition), and in a paragraph in Item 32: Make sure public inheritance is "is-a" on page 151 he makes the comment (which I've put in bold):
This is true only for public inheritance. C++ will behave as I've described only if Student is publicly derived from Person. Private inheritance means something entirely different (see Item 39), and protected inheritance is something whose meaning eludes me to this day.
The question: how should I interpret this comment? Is Meyers trying to convey that protected inheritance is seldom considered useful and should be avoided?
(I've read the question
Difference between private, public, and protected inheritance as well as C++ FAQ Lite's private and protected inheritance section, both of which explain what protected inheritance means, but hasn't given me much insight into when or why it would be useful.)
Some scenarios where you'd want protected:
You have a base class with methods where you know you never want to expose the functionality outside, but you know will be useful for any derived class.
You have a base class with members that should be logically used by any class that extends that class, but should never be exposed outside.
Thanks to multiple inheritance you can play around with base classes' inheritance type and construct a more diversed class with existing logic and implementation.
A more concrete example:
You could create a few abstract classes that follow Design Pattern logic, lets say you have:
Observer
Subject
Factory
Now you want these all to be public, because in general, you could use the pattern on anything.
But, with protected inheritance, you can create a class that is an Observer and Subject, but only protected factory, so the factory part is only used in inherited classes. (Just chose random patterns for the example)
Another example:
Lets say for example you want to inherit from a library class (not that I encourage it). Lets say you want to make you own cool extension of std::list<> or a "better" shared_ptr.
You could derive protectedly from the base class (which is designed to have public methods).
This will give you the option to use your own custom methods, use the class' logic, and pass the logic to the to any derived class.
You could probably use encapsulation instead, but inheritance follows the proper logic of IS A
(or in this case IS sort of A)
He isn't exactly discouraging protected inheritance, he just says that he hasn't found any good use for it. I haven't seen anyone either elsewhere.
If you happen to find a couple of really useful use cases, you might have material to write a book too. :-)
Yup, there aren't many uses for protected or private inheritance. If you ever think about private inheritance, chances are composition is better suited for you. (Inheritance means 'is-a' and composition means 'has-a'.)
My guess is that the C++ committee simply added this in because it was very easy to do and they figured, "heck, maybe someone will find a good use for this". It's not a bad feature, it doesn't do any harm, just that no one has found any real use for it yet. :P
Yes and no. I myself think that protected inheritance is a bad feature too. It basicly imports all the base class's public and protected members as protected members.
I usually avoid protected members, but on the lowest levels requiring extreme efficiency with a compiler with bad link-time optimization they are useful. But everything built on that shouldn't be messing with the original base class's (data) members and use the interface instead.
What I think Scott Meyer is trying to say, is that you can still use protected inheritance if it solves a problem, but make sure to use comments to describe the inheritance because it's not semantically clear.
I don't know if Meyers is advising us to refrain from using protected inheritance, but it seems you should avoid it if Meyers is on your team, because at least he won't be able to understand your code.
Unless your co-workers know C++ better than he does, you should probably also stay away from protected inheritance. Everybody will understand the alternative, i.e. using composition.
I can imagine however a case where it could make sense: You need access to a protected member in a class whose code you can't change but you don't want to expose an IS-A relationship.
class A {
protected:
void f(); // <- I want to use this from B!
};
class B : protected A {
private:
void g() { f(); }
};
Even in that case, I would still consider making a wrapper with public inheritance that exposes the protected base members with public methods, then compose with these wrappers.
/*! Careful: exposes A::f, which wasn't meant to be public by its authors */
class AWithF: public A {
public:
void f() { A::f(); }
};
class B {
private:
AWithF m_a;
void g() { m_a.f(); }
};
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
suppose i have a class engin and i inherit a class car from engin class
class engin
{
public:
engin(int nobofcylinders);
void start();
};
class car:private engin
{
public:
car():e(8){}
void start()
{
e.start();
}
private:
engin e;
};
now the same can be done by the composition, the question is which approch would be best and is mostly used in programming, and why???????
Composition is to be preferred for two main reasons:
the thing(s) being composed can have names
you can compose more than one thing of the same type
I prefer to think of inheritance as derived is a kind of base, that basically means public inheritance. In case of private inheritance it more like derived has a base, which IMHO doesn't sound right, because that's IMHO the work for composition not inheritance of any kind. So, since private inheritance and composition essentially mean same thing logically, which to choose? With the example you posted, I'd most certainly go for composition. Why? I tend to think of all kinds of inheritance as a kind of relationship, and with the example you posted, I can't think of a situation where I could say a car is kind of an engine, it simply isn't. It's indeed like a car has an engine, so why would a car inherit from an engine? I see no reason.
Now, indeed there are cases where it's good to have private inheritance, namely boost::noncopyable, with it's ctor/dtor being protected, you'd have hard time instantiating it, and indeed since we want our class to have a noncopyable part, that's the only way to go.
Some style guides (e.g. google c++ style guide) even recommend to never use private inheritance, for reasons similar to what I already written - private inheritance is just a bit confusing.
If you want to compare private inheritance with composition, read http://www.parashift.com/c++-faq-lite/private-inheritance.html#faq-24.3. I don't think private inheritance is good.
A Car has-an Engine, but a Car is-not-an Engine, so it should be better done with composition.
Inheritence is useful for "is-a" relationships, e.g. a Bus is-a Car, a Car is-a vehicle, etc.
Composition is useful for "has-a" relationships, e.g. a Car has Wheel-s, a Car has-an Engine, etc.
So a logical code should be like
class Car : public Vehicle {
Engine engine;
Wheel wheels[4];
...
};
Private inheritance, despite the name, isn’t really inheritance – at least not from the outside (of the class), where it matters.
For that reason, different rules apply. In C++, private inheritance is said to model an “is implemented in terms of” relationship. Thus, a priority queue which is implemented in terms of a heap, could look like this:
template <typename T, typename Comp = std::less<T> >
class priority_queue : private heap<T, Comp> {
// …
};
Personally, I don’t see the advantage of this pattern, and Neil has already stated that in most cases, composition actually has the advantage over private inheritance.
One advantage exists, though: since it’s such an established pattern, the meaning of a private inheritance is immediately clear to a seasoned C++ programmer; the above code would tell them that the priority queue is implemented in terms of a heap – which wouldn’t be obvious if the class just happened to use a heap as one of its members.
Private inheritance tends to get used in C++ primarily for policy classes. The classical example is allocators, which determine how a container class manages storage internally:
template <typename T, typename A = std::allocator<T> >
class vector : private A {
// …
};
No harm done. But once again, this could also have been done using composition.
Usually, composition is to be preferred (others gave the major reasons), but private inheritance allows things which can't be done by composition:
zero-size base class optimization (a base class of size zero will not increase the size of a class, a member of size zero will), that't the reason behind its use for policy classes which often have no data members
controlling initialization order so that what is composed is initialized before a public base
overriding a virtual member in what is composed
with private virtual inheritance, ensuring that there is only one composed thing even if one do it in several bases
Note that for the later two uses, the fact that the base class exist can be observed in a descendant.
Composition is used more than private inheritance. The general rule I follow and would recommend is that unless you have a specific reason to use private inheritance you should use composition.
Composition has many benefits over private inheritance:
You can have more than one instance of a particular class.
You don't pollute your class' namespace with a bunch of private functions that don't make sense for your class.
You can give names to the parts of your object
Your class is less coupled to the classes it's composed of than it is to a class it inherits from
If you discover you need to swap out an object that you've included by composition during the lifetime of your object, you can, with private inheritance you're stuck.
There are a lot of other benefits to composition. Basically, it's more flexible and cleaner.
There are reasons to use private inheritance though. They are very specific reasons, and if you think they apply, you should think carefully about your design to make sure you have to do it that way.
You can override virtual functions.
You can get access to protected members of the base class.
You need to pass yourself to something that wants an object of the class you're inheriting from (this usually goes hand-in-hand with overriding virtual functions).
And there are a few rather tricky ones as well:
If you use composition for a class that has 0 size, it still takes up space, but with private inheritance it doesn't.
You want to call a particular constructor for a virtual base class of the class you're going to privately inherit from.
If you want to initialize the private base before other base classes are initialized (with composition, all the variables in your class will be initialized after all your base classes are).
Using private virtual inheritance to make sure there's only one copy of a thing even when you have multiple base classes that have it. (In my opinion, this is better solved using pointers and normal composition.)
Private inheritance means
is-implemented-in-terms of. It's
usually inferior to composition, but
it makes sense when a derived class
needs access to protected base class
members or needs to redefine
inherited virtual functions.
Unlike composition, private
inheritance can enable the empty base
optimization. This can be important
for library developers who strive to
minimize object sizes.
Scott Meyers "Effective C++" Third Edition.
Base classes are evil.
In my mind, good OO design is about encapsulation and interfaces. The convenience of base classes are not worth the price you pay.
Here's a really good article about this:
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html