I want to put all of a classes functions into a "subdomain" (what is the right term for this?), such as the functions part of myClass.functions.function1();
So how should one rewrite this for that purpose?
class MYCLASS {
private:
int data;
public:
int function1();
int function2();
int function3();
};
So that the class could then be used:
MYCLASS myClass;
myClass.functions.function1();
rather than using just myClass.function1();.
You can make these free functions in some descriptive namespace, or you can emplace them inside a nested class. However, both of these imply access to members only through the original class's interface, meaning you will still need some public functions inside the class itself.
Otherwise, it's already clear that these are functions, so I would simply not do this. If you want to because you have loads and loads of functions, then you have too many functions, and your class almost certainly does too many things.
Depending our your design (which needs to be object-oriented but not necessarily) you can define a new namespace or an struct or a class which is called nested classes!
for example:
class A {
public:
int a;
class B {
public:
void do_something();
} bObject;
};
Related
I have this large class that I want to separate into different classes. The reason why it was large because the class had many private variables and functions that are needed to run the program. I was tired of scrolling down the 1000+ lines of code trying to add or edit code. I am wondering if it is possible for the classes to interact with one base class that includes all the private/protected variables it needed to operate, or simply have them as global variables.
I am aware of inheritance as I tried having the separate classes be derived from the base class, by doing something similar to this:
#include <iostream>
class Base {
public:
void sayPrivateVar() {
std::cout << privateVar;
}
protected:
std::string privateVar = "I am a protected variable!";
};
class Derived : public Base {
public:
void manip() {
base->privateVar = "That was updated from a derived class";
}
private:
Base* base;
};
int main() {
Base base;
Derived derived;
derived.manip();
base.sayPrivateVar();
return 0;
}
EDIT: Without creating another object inside a class.
it depends on your class and what you have in it. It is often better not have inheritance because derived classes may then get member variables that they don't need. There are a few other ways you can do. One way would be to group you private variables in different classes and then have member variables in the first class.
E.g.
class X {
int x;
int y;
int angle;
...
};
becomes
class XYVector;
class X {
XYVector v;
};
class XYVector
{
int x;
int y;
int angle;
};
You can continue in this direction and instead of making them concrete class like XYVector above have them as interfaces : to have it more elaborate and flexible check out https://en.wikipedia.org/wiki/Composition_over_inheritance
At any rate: avoid having globally declared variables.
This is a good question and the answer is absolutely. Inheritance is actually a very good solution in this particular context since that is how object code shares it's scope with other classes. One important thing to note here is that how you call your derived class is important because the inherited scope is set along with the derived class (i.e. declaring it public base would inherit the public and protected methods as opposed to declaring it private which would give the derived class even more access!)
What is advantage of implementing inner classes as separate classes with name space in C++?
Will there be any added advantage with Approach-1?
Pros & Cons with both approaches?
Approach-1: using namespace
MyInnerClass.h
namespace inner{
class MyInnerClass
{
public:
MyInnerClass();
virtual ~MyInnerClass();
};
};
MyInnerClass.cpp
#include "MyInnerClass.h"
namespace inner
{
MyInnerClass::MyInnerClass()
{
}
MyInnerClass::~MyInnerClass()
{
}
}
MyOuterClass.h
#include "MyInnerClass.h"
namespace inner{
class MyInnerClass;
};
class MyOuterClass
{
public:
MyOuterClass();
virtual ~MyOuterClass();
private:
inner::MyInnerClass* ptrMyInnerClass;
};
MyOuterClass.cpp
#include "MyOuterClass.h"
MyOuterClass::MyOuterClass()
{
ptrMyInnerClass= new inner::MyInnerClass();
}
MyOuterClass::~MyOuterClass()
{
}
Approach-2: implementing as real inner classes
class MyOuterClass
{
/* Inner Class */
public:
class MyInnerClass
{
public:
MyInnerClass() {}
virtual ~MyInnerClass() {}
};
public:
MyOuterClass();
virtual ~MyOuterClass();
private:
MyInnerClass* ptrMyInnerClass;
};
In larger projects, otherwise will be handicapped, similar objects or classes are categorized into corresponding namespaces for ease of refactoring and readability.
Normally, an object which will be intrinsic to another object only and rarely going to be used otherwise is declared as private inner class. By doing so, the intent is made clearer as the implementation is hidden and the inner object is not exposed.
I only know one advantage of the namespace scheme. With namespaces, you can forward declare classes, while you cannot do the same with inner classes, if the outer class definition is not available. So, with namespaces, you can do this:
namespace Outer {
class Inner;
}
However, you cannot do the same with inner classes, if definition of Outer is not available:
class Outer; // we forward declare Outer
class Outer::Inner; // this doesn't compile
In the same manner, you cannot define Outer::Inner without the definition of Outer.
Because of this I almost never use inner classes (I only use small inner class, when I'm 100% sure the forward declaration is not needed, which is usually the case when the inner class is not public).
Note, there is a 3rd solution, which I usually use: I name "inner" class as something like OuterInner.
For example, if you have an outer class named SomeManager, and you would have a public inner class named Node, I'd use class SomeManagerNode:
class SomeManager;
class SomeManagerNode;
The only difference I know about this method is that SomeManagerNode cannot access non-public members of SomeManager (If Node was an inner class to SomeManager, it could access all members of it). But this can be desirable in certain situations, so it is not a real drawback. But if the access is needed, you can declare SomeManagerNode as a friend of SomeManager.
The only reason to use inner classes is when the inner class is a private implementation detail, which is not used anywhere outside the class.
Let's say i have an abstract class thats main purpose is to store a vector of numbers, called NumberVector. Then, I have two classes that inherit NumberVector that are called SortableNumberVector and SearchableNumberVector. Now, I want to make an adapter class that combines these two, and I make a class called SortableSearchableNumberVector, which inherits both of these. I want the final class to call functions from the inherited classes, but still retain data of it's own. Here's how I have laid it out:
class SortableSearchableNumberVector : public SearchableNumberVector, public SortableNumberVector
{
protected:
vector<int> numbers;
int selectedNumber;
public:
void selectNumber(int index)
{ SearchableNumberVector::setSelected(index); }
void sortNumbers()
{ SearchableNumberVector::sort(); }
}
When I run this, the two class variables are unchanged. What is causing this to happen?
I want have two or more classes inside a shared libary in Qt C++.
What is the way to make a shared library(dll) holding two or more classes?
Do they need to be nested inside a parent class or should I use namespaces?
What is the easiest or elegant method that you would direct me or give an example?
All classes are independent; and I only want to access proper class from the application. There may be many classes; so nested classes inside a single parent class would not be readable really. I thnik there is no partial class support in C++ . Also I am not sure if nested class and the namespaces are the only way to do that(?)
class A
{
public:
A();
void TestA();
};
class B
{
public:
B();
void TestB();
};
Application:
MyLib::A a;
MyLib::B b;
Here I have no idea how to implement MyLib.
For those who are interested with the resolution is simply exporting the class
Q_DECL_EXPORT class A
{
public:
A();
void TestA();
};
I am confused about the concepts of inheritance and polymorphism. I mean, what is the difference between code re-usability and function overriding? Is it impossible to reuse parent class function using inheritance concept or else is it impossible to override parent class variables using Polymorphism. There seems little difference for me.
class A
{
public:
int a;
virtual void get()
{
cout<<"welcome";
}
};
class B:public A
{
a =a+1; //why it is called code reuse
void get() //why it is called overriding
{
cout<<"hi";
}
};
My doubt is about the difference between the code reuse and function overriding.
Lets start with your example.
class A
{
public:
int a;
virtual void get()
{
cout<<"welcome";
}
};
class B:public A
{
a =a+1; //why it is called code reuse
void get() //why it is called overriding
{
cout<<"hi";
}
};
Inheritance: Here you are deriving class B from class A, this means that you can access all of its public variables and method.
a = a + 1
Here you are using variable a of class A, you are reusing the variable a in class B thereby achieving code reusability.
Polymorphism deals with how a program invokes a method depending on the things it has to perform: in your example you are overriding the method get() of class A with method get() of class B. So when you create an instance of Class B and call method get you'll get 'hi' in the console not 'welcome'
Function inheritance allows for abstraction of behaviour from a "more concrete" derived class(es) to a "more abstract" base class. (This is analogous to factoring in basic math and algebra.) In this context, more abstract simply means that less details are specified. It is expected that derived classes will extend (or add to) what is specified in the base class. For example:
class CommonBase
{
public:
int getCommonProperty(void) const { return m_commonProperty; }
void setCommonProperty(int value) { m_commonProperty = value; }
private:
int m_commonProperty;
};
class Subtype1 : public CommonBase
{
// Add more specific stuff in addition to inherited stuff here...
public:
char getProperty(void) const { return m_specificProperty1; }
private:
char m_specificProperty1;
};
class Subtype2 : public CommonBase
{
// Add more specific stuff in addition to inherited stuff here...
public:
float getProperty(void) const { return m_specificProperty2; }
private:
float m_specificProperty2;
};
Note that in the above example, getCommonProperty() and setCommonProperty(int) are inherited from the CommonBase class, and can be used in instances of objects of type Subtype1 and Subtype2. So we have inheritance here, but we don't really have polymorphism yet (as will be explained below).
You may or may not want to instantiate objects of the base class, but you can still use it to collect/specify behaviour (methods) and properties (fields) that all derived classes will inherit. So with respect to code reuse, if you have more than one type of derived class that shares some common behaviour, you can specify that behaviour only once in the base class and then "reuse" that in all derived classes without having to copy it. For example, in the above code, the specifications of getCommmonProperty() and setCommonProperty(int) can be said to be reused by each Subtype# class because the methods do not need to be rewritten for each.
Polymorphism is related, but it implies more. It basically means that you can treat objects that happen to be from different classes the same way because they all happen to be derived from (extend) a common base class. For this to be really useful, the language should support virtual inheritance. That means that the function signatures can be the same across multiple derived classes (i.e., the signature is part of the common, abstract base class), but will do different things depending on specific type of object.
So modifying the above example to add to CommonBase (but keeping Subtype1 and Subtype2 the same as before):
class CommonBase
{
public:
int getCommonProperty(void) const { return m_commonProperty; }
void setCommonProperty(int value) { m_commonProperty = value; }
virtual void doSomething(void) = 0;
virtual ~CommonBase() { }
private:
int m_commonProperty;
};
Note that doSomething() is declared here as a pure virtual function in CommonBase (which means that you can never instantiate a CommonBase object directly -- it didn't have to be this way, I just did that to keep things simple). But now, if you have a pointer to a CommonBase object, which can be either a Subtype1 or a Subtype2, you can call doSomething() on it. This will do something different depending on the type of the object. This is polymorphism.
void foo(void)
{
CommonBase * pCB = new Subtype1;
pCB->doSomething();
pCB = new Subtype2;
pCB->doSomething(); // Does something different...
}
In terms of the code sample you provided in the question, the reason get() is called "overriding" is because the behaviour specified in the B::get() version of the method takes precedence over ("overrides") the behaviour specified in the A::get() version of the method if you call get() on an instance of a B object (even if you do it via an A*, because the method was declared virtual in class A).
Finally, your other comment/question about "code reuse" there doesn't quite work as you specified it (since it's not in a method), but I hope it will be clear if you refer to what I wrote above. When you are inheriting behaviour from a common base class and you only have to write the code for that behaviour once (in the base class) and then all derived classes can use it, then that can be considered a type of "code reuse".
You can have parametric polymorphism without inheritance. In C++, this is implemented using templates. Wiki article:
http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29#Parametric_polymorphism