Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
sorry to bother but I'm a newbie programmer and has just been starting on c++ course. The reason I asked this question is because I've been hearing on OOP and its relation to class.
So my question is:
Does class actually simplify the programming code just because it groups up all related functions into one single "object" thats called "class" ?
One more thing is that...
Why do we create class inheritance when we could use one class and derive all functions from that one class alone?
Sorry to bother.
Newbie programmer.
"Does class actually simplify the programming code just because it groups up all related functions into one single "object" thats called "class" ?"
The main idea is to encapsulate state (== data) with operations that can be applied to it into a single class type.
Yes, that simplifies programming code, because there are certain interfaces/operations that can be used with this type.
"Why do we create class inheritance when we could use one class and derive all functions from that one class alone?"
Derived classes may introduce different behavior as inherited from their base class. There are many uses when you want to change that behavior, without inventing new function names all the time (or just add numbers to them).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
In object oriented programming terminology, I can simply say:
- Member: I mean to say a member of (this) class (which I'm referring to)
But I don't know what is the correct terminology for this:
- ? : I mean to say a class who has (this thing I'm referring to) as a member
Maybe I can use owner or parent. Any idea?
FWIW the C++ standard calls this "containing object" or "containing class object" in a couple of places. It never formally defines the term though.
I guess you can call the corresponding class "the containing class".
In good old days there was a term nesting used in a variety of ways( nesting scope, nesting namespace, nesting class, nesting function...). I don't know if it is still widely used, but IMHO it does the purpose.
Regards,
FM.
I ended up using this as the most clear:
... classes which own this class as member ...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Should I always add public keyword when inheriting a class? When doing this code:
class Derived : public Base {
}
I think this the right thing to do in 99% cases. Right?
It depends on what model you are looking for.
From Scott Myers - Effective C++ Third Edition (a recommended read, btw):
public inheritance means "is-a". If you write that class D ("Derived") publicly inherits from class B ("Base"), you are telling C++ compilers (as well as human readers of your code) that every object of type D is also an object of type B, but not vice versa
And
private inheritance means "is-implemented-in-terms-of"
Yes, because this matches the inheritance behavior of other object oriented programming languages like C# or Java.
If you would use private instead of public, the properties and methods of the Base class are hidden. This means that the compiler would not allow you to call public methods of the Base class if you have a pointer of the Derived class.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I found this question: When to use abstract class or interface?. But it was asked for Java and C++ is different. There is multiple inheritence so maybe the answers are different too.
When shall I use an interface class ?
If I use the PIMPL idiom then there will be only one member which I only need to forward declare. And if I move the private functions into the PIMPL class then there will be only public and protected functions in a abstract class. So the difference between an abstract class like this and an ˙interface class is that in the interface class there shall be only pure virtual functions. Does it have any advantages over the previously mentioned one ?
Use an interface class when the class hierarchy can be viewed as generic; child classes can be swapped without affecting the calling classes.
For example, there is an std::istream class. Any function or method can treat input as generic if it requires an std::istream. So, one can pass cin or an ifstream to the function. The interface is consistent.
Use the PIMPL idiom when you want to hide the implementation from the interface. Used in library classes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
This link talks about allowing more restrictive access to a derived class method.
Q. What is the reason for allowing this in C++?
Languages such as Java & C# don't allow it. Is it useful in some cases? If so please help me understand.
It has more to do with it never being disallowed. And now it's too late: too much code would break. Do remember that C++ is a considerably older language than either Java or C#.
But the C++ philosophy inspires you to ask "why disallow it?". It could even be useful: some folk exploit it and make overridden methods private. The amount of documentation you should attach to a private method can be significantly less than a public method. This means you don't repeat yourself and are compelled to rely on the public / protected method in a base class for comments.
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 9 years ago.
Improve this question
I have a project that contains several classes. I added to this project several functions that are used by one of the classes, let named MainClass. I put all these functions in a file stuff.h. To use these functions I include the stuff.h file at the beginning of the implementation of the class MainClass. I am wondering if this is a good style of programming or if it would be better to create a new class and add my functions to this class. Then I instantiate this class in the MainClass.
Not so good style. Starting from the fact headers are not actually intended to have real code but declarations of things defined somewhere else.
If your 'external' functions are used only by MainClass why not to do them class methods? Even maybe private so they are only visible inside class? Keep things as encapsulated as you can. If you're trying to follow C++, try not to use 'plain C functions'. It's different language. If you absolutely need plain routines, use namespaces instead. But please try to keep your code inside modules (.cpp), not in headers.
Regarding other classes. It depends if you know why you need other classes. If you don't know why, you don't need them. BTW OOP is not always 'best' approach, especially in things like balance between inheritance and composition. You should understand what you really want to achieve to select proper technique.
Indeed you need good C++ book. Chapters about project composition, compilation process, translation units so you will understand logics behind this. This Q&A site cannot explain you everything. Just give some points.
Good question here for you
I think it would be better to create a new class, or several new classes that are ordered by the different ways the functions will be used. That's more in line with classic OO.