Let be A and B class such that are which inherit of C class. All are in a file.cpp together with method main of the Main class. If I want create a instance of the classe A then ...
file.cpp
class C{
}
class A : public C{
}
class B : public C{
}
class Main{
.
.
.
void main(){
C *c = new A();
}
}
Where a diagram UML is
Now, Suppose I have the same classes but each class in a different file. If I want to instantiate the class A, as above, I would have insert an #include A.h directive in the Main class which would bring up a dependency in my diagram:
My question is: Which case is correct if I wanted to do the same? or I am interpreting wrong the relations UML in C++?
First off, you should not put code in .h files unless you know what you are doing (see inline functions, mainly used for speed)
Then in main.h, you don't need any reference to A. In main.cpp however, you will need to include A.h. Remember that UML is language agnostic, it is used to draw "who talks to who" rather than "who compiles with who".
More often than not, your c++ compiler will generate an output file (with gcc these are .o files, Visual Studio also does this but transparently) for each cpp file. All output files will then be merged together (most of the time) in your application or library and only then will your function be linked together.
You might also want to take a look at forward references. It is to tell the compiler (not the linker) that "this class does exist, you might not know about it right now, but I swear to God, it WILL exist in the linker output blob".
In your particular case, I would draw the class diagram like your second example, regardless of whether you use only one or multiple cpp files. Your Main class DOES know about A.
Now imagine that your C class have methods like
A* C::createA()
{
return new A;
}
B* C::createB()
{
return new B;
}
Then your main class would have
int main()
{
C* instance1 = C::createA();
C* instance2 = C::createB();
}
In that case, your main class would lose all intimate knowledge of A and B, conforming to your first diagram. This would of course create more coupling between A, B and C, which brings its own problems but is closer to a factory pattern
I don't think its required to have the has-a relationships as in the second diagram because it is implied.
A is-a a C, B is-a C and Main has-a C.
Its more about the structure of your design than the includes in your files.
You need to use the composition relationship to show that Main has-a instance of C.
I have never documented which files need to be included, as it is assumed that if you need functionality of a class that lives in another file, you're probably going to need an include.
EDIT: Actually, there is no composition, as it seems you Main class has a methods called main() that creates an instance of the C class, and is not a member itself.
Related
My experience in c++ is very limited, so I excuse if my question is dumb or elementary. Here goes:
When doing larger project in a language like c++, and you possibly have a very big line of inheritance, is it normal practice to include every single derived class in the.. main file, let's say.
Is there some way to circumvent this, or am I missing something banal?
Thank you.
For a C++ program to use a C++ class, it requires the declaration. If the class inherits from base classes, then those declarations are required to process that class declaration. This applies recursively: the entire inheritance tree of the class is required.
If the inheritance graph is so deep and broad (perhaps due to multiple inheritance) that the project decides it is unacceptable, then it has to be restructured. Classes might be able to use aggregation instead of inheritance. So that is to say, instead of:
#include <widget.h>
class foo : public widget { ... };
it may be possible to have;
class widget; // "forward" declaration only; no #include needed
class foo { widget *pwidget; ...}
Now, only the file which implements foo needs the full declaration of widget; the clients of foo which are including "foo.h" don't need it.
But now foo is not a-kind-of widget any longer, which has implications on the code organization. foo still has the widget parts by way of creating an object and holding it. If widget conforms to some abstract interface for widgets, foo may be able to implement that, and delegate to the contained widget.
Another tool in minimizing dependencies is dependency inversion.
I know the official answer for "extension class in C++ like objective-C or c#" is NO. But is there any hack ways to implement this? And what is the cost?
I ask this because my colleague use my parser to generate C++ class files from a special format txt file. They complained that it is difficult to extension the class.
I can't force them to use inheritance, because the class generated is like this:
class A {}
class B : A {}
if my colleague extends A like this:
class C : A {}
then the B class will not benefit from the C class. That means: In our situation, if class C : A, B is meant to inherit from A, then now B should inherit from C now. But it is not possible since the B has hard code to inherit from A. That means, inheritance is not a good option, the truly demand is to extend A.
And using A as a member in a new class is not an option, either. Since our logic is more like a "is-A", not a "has-A", force make A as a member will make the code hard to read.
Currently they directly modify the class header file, and any new member functions is implement in a new cpp file(thanks to C++ class file structure), so if the class changes, the origin cpp file will regenered, they won't care about it, while they use git to merge the new generated header file to the file they have modified.
I can write a parser to scan the header file and do the merge, but write a parser to fully implement C++ standard BNF(http://www.externsoft.ch/download/cpp-iso.html) is difficult.
Currently I decide to use macros, like the mechanism used by flex and bison to replace the action in .y file to the generated c file. But I wondered if there's a easy way.
A common C++ solution is freeFunction(A&) instead of creating class B. Unlike pure OO languages, C++ has free functions which are not class members. Your freeFunction_B(A&) and your colleague's freeFunction_C(A&)` will not interfere.
Obviously this is not a solution when you need to add data members. In that case, there's another option. Leave open the base class:
template<typename BASE> class B : public BASE {
// ...
}
This allows both B<A> and B<C<A>>. Slight downside: C<B<A>> is not the same type as B<C<A>>, which is logical. The members have to be in a certain order in memory, and there are two choices.
(General advice: code generation and C++? That means templates)
As doing a research for some times, I think the term "monkey patch" is the technology what I'm looking for, but it seems only can be implemented with languages which has the reflection feature.
Currently I use "has-a" extension in my code instead of "is-a" to avoid changing the generated code.
I'm a beginner in C++ programming and I've a (stupid, I think) doubt about how to pass an object's class into another class. Suppose we have these two classes:
class A {...}
class B {...}
and I want to use an object from A into B. For example:
class B {
A ab;
[methods prototypes that include the object ab]
method_B (A ab); //for example
...
}
The question is, can I do this? Does it make sense, thinking about object-oriented programming?
Or, I could define an A's object in main() and after that I would call a method from B that would include A's object as argument?
My question is all about how to use object's from another class into another (functionally independent!) without "violating" the object oriented programming rules.
Thank you for any help,
You can do this. Many libraries and languages do this. From OO view you need to need to design class A such that it will expose (public) a minimal and useful inteface to be used but other classes (such as class B).
So, I'm having a problem where:
class A needs to know about class B, class B needs to know about C, and class C needs to know about A.
It's essentially a circle, so I get definition errors. I tried forward declaration, but whatever's on top, doesn't know about what else goes on at the bottom.
How would I go about a situation like this?
Thanks
David
Assuming this is something simple, the comment above by Adam Mihalcin is correct in that the similar question answers it. But I'll code it out anyways.
Assuming you have this (method definitions don't matter) :
class A
{
B* ptrB;
}
class B
{
C* ptrC;
}
class C
{
A* ptrA;
}
Then you can, as Adam linked to, just forward-delcare all 3 of them like this:
class A;
class B;
class C;
And put that block above all 3 of them. The important thing here though is that this is when there are pointers to the other classes, not composition where they're a part of the class. You can use forward-declaration to allow things to compile correctly when dealing with pointers, but not with other data types. So if there was this:
class D
{
B myB;
}
With everything else the same as above, you'd need to have the "real" definition for B above the "real" definition for D. But the rest could be the same. Forward declaration only "works" for pointers.
You MUST break your dependency loop somewhere with a pointer though. If there's never a pointer, then the data structure is "infinite" and thus doesn't work. That's because in my example, a D always contains a B. But what if an A always contained a B, and a B always contained a C, and a C always contained an A? Well that final A needs another B, which needs another C, which... I hope you get the idea. But with pointers, you can loop it. With composition (not pointers) it can't loop around.
If the classes are tightly coupled, then you can do with
Declare the classes with no method implementations, possibly using forward declarations, then implement the methods (possibly in an implementation file).
Otherwise, you can
Factor out the more abstract interface(s) sufficient for the classes to work without knowing full details about each other.
But most probably you have a design level error, and if so, just fix that.
What you can do is forward declare class A in in the header file for class C, then you in the .cpp file, you include the header for class A.
For a reference on how to forward declare class A, take a look at this reference - Forward declarations in C++
most probably, u've just got an design level error.
However, if u have to do this, for example , just try to utilize forward-declare by declaring an empty class A,B without presenting any detail implementation in C's header file. then include A and B's header in C's implementation file when u need to use them.
Remember, u can only use pointer in the declaration of class C.
In your header files use next construction:
#ifndef MYCLASS_HPP__20120410__0747
#define MYCLASS_HPP__20120410__0747
// Your definions of class, struct, etc...
#endif//
And all included file (except self Myclass.hpp) should be in class-header file Myclass.hpp. He must be included in Myclass.cpp file.
I have my class structure as follows
add.h has class add that has method int add(int,int) and add.cpp includes add.h and defines method add above
sub.h has class sub that has method int sub(int,int)
and sub.cpp includes sub.h and defines method sub
now, main.h has class main and it includes add.h and sub.h; main class also has some print methods to print results;main.cpp uses method add and sub to do calculations
My question is, what is the relationship between class main & class add also class main & class sub. Main.h simply includes add.h and sub.h, so is there any name for this relations.
AFAIK It is not inheritance, it is not compositon or aggregation.
You are mixing up the concepts of C++ compilation and class relationships - the two things really have nothing to do with each other. In the event that you want to model the relationships between the C++ source files, you should use a UML Component Diagram, but few people bother with this.
You have 3 independent classes. main will only use add and sub in its implementation. I don't see any relation between them.
As Neil says: the source files (and header files) happen to coincide with the classes here. That means that you don't model the relation between a.cpp and a.h: it's the declaration and the definition of class a, and the fact that they're separated is no design issue, merely a compilation artifact.
In general, when a .cpp file includes a .h file not of it's own class, you can say that the .cpp uses what's in the .h. When class a's declaration needs class b's declaration, probably a is aggregating class b.
In this case, I would say that the (plain, one-directional) relation between main and the 'operations' is to be labeled as 'usage'.
Next to that, it's common to give the sub and add classes a common superclass/interface.