In Qt there is a class QAbstractTableModel, its an abstract class. Why Qt designers provide an abstract class, and doesn't provide an actual class that can be used for modelling a table. Why the designer made me to subclass the class to use it?
That's because that class is not used for modelling a table, it's an interface that all classes that model a table must adhere to. Qt has a few concrete models that you can reuse, simply look at the "Inherited by" list in the documentation of the base QAbstractItemModel class. Some of these derived classes are concrete, namely those whose names don't start with QAbstract :)
If you want a generic model, you can use a QStandardItemModel.
You'll need to read up about interfaces in C++. An interface implemented using abstract virtual methods is a very common idiom. See e.g. here. In C++11 you can have interfaces that don't use the virtual method idiom, though.
If you ask "why doesn't Qt provide any general-purpose concrete classes that implement that interface", the answer is: because it's an impossible job. Everyone's data source has different implementation details, and Qt can't possibly divine everyone's approach and provide a universal bridge.
The QAbstractTableModel exists to let you create an adapter between your own data model and Qt's data model.
There is universal model implementation such as QStandardItemModel, so you can use this for table, tree or list views as you need.
Related
In classic inheritance, Derived inherits from Base. With mixins, the (technical) base class is usually called the Mixin. What is the proper term for the (technical) class that inherits from the Mixin?
I want to know this so I can name my template parameters accordingly.
The use of a mixin class is an implementation detail that doesn't impact the result as directly as a base/derived relationship in a typical inheritance tree, so I'm not sure it deserves its own name. The one time I used it most successfully there was already an existing base class that was required (MFC's CDialog), so multiple inheritance was used and my mixin wasn't the first one on the list.
If you really have to pick a name, Derived is probably as good as any.
Probably there is no accepted name for that.
Try:
Final
Concrete
Complete
I am making a win32 api program. I first created a base class called WinClass and inherited like a dozen other classes from it. Now I need to create a derived class from two classes inherited from base class WinControl and WinHandler.Since I intend to make many more derived classes out of the original dozen, I'll have to use virtual inheritance on like every class inherited from WinClass.So is there any way to do this without using virtual inheritance?
Learn how to avoid overuse of inheritance at all. For example, read this article
http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/
A good start to learn how to get things done the way you want it (with the correct use of inheritance) is the book "Design Patterns":
http://c2.com/cgi/wiki?DesignPatternsBook
I first created a base class called WinClass and inherited like a dozen other classes from it.
And there's your first problem. If WPF has taught us anything, it should be that inheritance is not necessarily the best model for GUI design.
So is there any way to do this WITHOUT using virtual inheritance?
Yes: don't have WinControl and WinHandler be derived from WinClass. You haven't said what these do, so I can't offer any specific advice about them. Really, it seems like what you need is a "has a" relationship rather than the "is a" relationship that inheritance brings.
Also, there's no need to use boldface for class names. Just use the code tags that StackOverflow provides. Nor is there a need to SHOUT in bold-face.
I'm making a game GUI API where each widget inherits from the Widget class. I was thinking, when others make there own widgets, they might not be fully satisfied with the base class. They might want to add getTheme() for example. Would it be a good idea to make all my widgets virtually inherit from Widget then so that this is possible?
Thanks
Just because the user would add their own methods to a child class doesn't mean you need to use virtual inheritance. You would use it if, in your library, you have a single base class with multiple children, and people could inherit from multiple child classes at once (for example mixin rather than substitution).
To resolve a diamond-shaped inheritance problem. (B and C both inherit from A. What happens to A's attributes in D that itself inherits from B and C?)
A client of your library could see a RedWidget and a FlyingWidget, and might want to combine them into a RedFlyingWidget.
User would have to specify one of the base classes to be virtual when inheriting. But that is not responsibility of a library maker.
OOP flows better with single-implementation inheritance, so that's what I'd use throughout a library.
There are also "upside-down inheritance" trees, as described by Alexandrescu's excellent "Modern C++ Design." They allow clients to pull in more functionality in a form of mix-ins that are called policies.
Programming with policies allows for greater ability to combine functionality, at the expense of syntactical cleanliness. Think STL implementation, for example.
When is virtual inheritance a good idea?
That's a design question.
For your Widgets, I would say Yes, multi-derived classes should have the option to be just 1 Widget.
Whenever there is a possibility that the users of your library are going to use several classes from your library as a base class (ie derive from them), you have to use virtual inheritance. In other words, it is a good idea to use it in your case.
I had faced the problem. In my C++ hierarchy tree I have two branches for entities of difference nature, but same behavior - same interface. I created such hierarchy trees (first in image below).
And now I want to work with Item or Base classes independetly of their nature (first or second). Then I create one abstract branch for this use. My mind build (second in image below).
But it not working. Working scheme seems (third in image below).
It's bad logic, I think...
Do anybody have some ideas about such hierarchy inheritance? How make it more logical? More simple for understanding?
Image
Sorry for my english - russian internet didn't help:)
Update:
You ask me to be more explicit, and I will be.
In my project (plugins for Adobe Framemaker) I need to work with dialogs and GUI controls. In some places I working with WinAPI controls, and some other places with FDK (internal Framemaker) controls, but I want to work throw same interface.
I can't use one base class and inherite others from it, because all needed controls - is a hierarchy tree (not one class).
So I have one hierarchy tree for WinAPI controls, one for FDK and one abstract tree to use anyone control.
For example, there is an Edit control (WinEdit and FdkEdit realization), a Button control (WinButton and FdkButton realization) and base entity - Control (WinControl and FdkControl realization).
For now I can link my classes in realization trees (Win and Fdk) with inheritence between each of them (WinControl is base class for WinButton and WinEdit; FdkControl is base class for FdkButton and FdkEdit). And I can link to abstract classes (Control is base class for WinControl and FdkControl; Edit is base class for WinEdit and FdkEdit; Button is base class for WinButton and FdkButton). But I can't link my abstract tree - compiler swears.
In fact I have two hierarchy trees, that I want to inherite from another one.
Update:
I have done this quest! :)
I used the virtual inheritence and get such scheme (http://img12.imageshack.us/img12/7782/99614779.png). Abstract tree has only absolute abstract methods. All inheritence in abstract tree are virtual. Link from realization tree to abstract are virtual. On image shown only one realization tree for simplicity.
Thanks for help!
C++ supports multiple inheritance, so you can have the union of (2) and (3), making sure that AbstractBase is always declared as a virtual base class.
Without knowing the real meaning and purpose of the various classes, it's difficult to offer any better advice.
It's not clear from the description if this would work for you but typically classes with a common interface would define the interface in AbstractBase and then have concrete instances inherit directly from that (FirstItem, SecondItem).
Why the extra indirection(s) in your examples? What's expected to be in AbstractItem, FirstBase and SecondBase?
For using different implementations of one interface, on could use:
the Bridge Design Pattern
You might couple this with a Factory Design Pattern so as to construct your two implementations differently.
However, it may look too simple for your classes architecture.
But as the comments under your answer say: it is difficult to imagine the job/role of your classes with such names. You should be more explicit, so as we can think of a precise design.
I am working on a collection of classes used for video playback and recording. I have one main class which acts like the public interface, with methods like play(), stop(), pause(), record() etc... Then I have workhorse classes which do the video decoding and video encoding.
I just learned about the existence of nested classes in C++, and I'm curious to know what programmers think about using them. I am a little wary and not really sure what the benefits/drawbacks are, but they seem (according to the book I'm reading) to be used in cases such as mine.
The book suggests that in a scenario like mine, a good solution would be to nest the workhorse classes inside the interface class, so there are no separate files for classes the client is not meant to use, and to avoid any possible naming conflicts? I don't know about these justifications. Nested classes are a new concept to me. Just want to see what programmers think about the issue.
I would be a bit reluctant to use nested classes here. What if you created an abstract base class for a "multimedia driver" to handle the back-end stuff (workhorse), and a separate class for the front-end work? The front-end class could take a pointer/reference to an implemented driver class (for the appropriate media type and situation) and perform the abstract operations on the workhorse structure.
My philosophy would be to go ahead and make both structures accessible to the client in a polished way, just under the assumption they would be used in tandem.
I would reference something like a QTextDocument in Qt. You provide a direct interface to the bare metal data handling, but pass the authority along to an object like a QTextEdit to do the manipulation.
You would use a nested class to create a (small) helper class that's required to implement the main class. Or for example, to define an interface (a class with abstract methods).
In this case, the main disadvantage of nested classes is that this makes it harder to re-use them. Perhaps you'd like to use your VideoDecoder class in another project. If you make it a nested class of VideoPlayer, you can't do this in an elegant way.
Instead, put the other classes in separate .h/.cpp files, which you can then use in your VideoPlayer class. The client of VideoPlayer now only needs to include the file that declares VideoPlayer, and still doesn't need to know about how you implemented it.
One way of deciding whether or not to use nested classes is to think whether or not this class plays a supporting role or it's own part.
If it exists solely for the purpose of helping another class then I generally make it a nested class. There are a whole load of caveats to that, some of which seem contradictory but it all comes down to experience and gut-feeling.
sounds like a case where you could use the strategy pattern
Sometimes it's appropriate to hide the implementation classes from the user -- in these cases it's better to put them in an foo_internal.h than inside the public class definition. That way, readers of your foo.h will not see what you'd prefer they not be troubled with, but you can still write tests against each of the concrete implementations of your interface.
We hit an issue with a semi-old Sun C++ compiler and visibility of nested classes which behavior changed in the standard. This is not a reason to not do your nested class, of course, just something to be aware of if you plan on compiling your software on lots of platforms including old compilers.
Well, if you use pointers to your workhorse classes in your Interface class and don't expose them as parameters or return types in your interface methods, you will not need to include the definitions for those work horses in your interface header file (you just forward declare them instead). That way, users of your interface will not need to know about the classes in the background.
You definitely don't need to nest classes for this. In fact, separate class files will actually make your code a lot more readable and easier to manage as your project grows. it will also help you later on if you need to subclass (say for different content/codec types).
Here's more information on the PIMPL pattern (section 3.1.1).
You should use an inner class only when you cannot implement it as a separate class using the would-be outer class' public interface. Inner classes increase the size, complexity, and responsibility of a class so they should be used sparingly.
Your encoder/decoder class sounds like it better fits the Strategy Pattern
One reason to avoid nested classes is if you ever intend to wrap the code with swig (http://www.swig.org) for use with other languages. Swig currently has problems with nested classes, so interfacing with libraries that expose any nested classes becomes a real pain.
Another thing to keep in mind is whether you ever envision different implementations of your work functions (such as decoding and encoding). In that case, you would definitely want an abstract base class with different concrete classes which implement the functions. It would not really be appropriate to nest a separate subclass for each type of implementation.