学习QT（使用C ++），我一直在定义自己的类，而不是QObjects派生。 即使QT教程教你扩展他们的小部件以制作你自己的小部件我不喜欢因为我认为我的代码会更“便携”而且QT固有的更少（如果这样做有意义）以防我切换到另一个图形工具包。
所以我的课程是这样的.-
class mainWindow { QVBoxLayout *winLayout; public: QWidget *winWidget; mainWindow(); }...所以，将主要小部件作为公共成员，并在类中操作所有内容，添加操作我的小部件的方法。
如果我需要Signals和Slots，我会创建一个扩展QObject的类并使用Q_OBJECT宏。
但现在我想知道，我的观念（在开头解释）是否含糊不清？ 您是否认为我可以通过这样做而不是扩展QT自己的小部件来面对任何问题？ 我应该坚持哪种方法？
Learning QT (with C++), I have been defining my own classes, which are not QObjects derivates. Even if QT tutorial teach you to extend their widgets in order to make your own I don’t because I was thinking that my code would be more “portable” and less QT inherent (if that makes sense) in case I switched to another graphical toolkit.
So my classes are something like this.-
class mainWindow { QVBoxLayout *winLayout; public: QWidget *winWidget; mainWindow(); }...so, having the main widget as a public member and everything being operated from within the classes, adding methods to manipulate my widgets.
In case I need Signals and Slots, I make a class extending QObject and use the Q_OBJECT macro.
But now I wonder, is my notion (explained in the beginning) even vaguely right? Do you think that I can face any issues in the future by doing this my way and not extending QT own widgets? What method should I stick to?
最满意答案
你的clas不是一个合适的QWidget，但我不认为这对Qt来说是个问题。 除非你需要访问wigets的一些受保护元素（例如，与事件交互），否则你可以在没有继承qt小部件的情况下进行访问 - 设计的选择就是你的。
继承的唯一原因可能是保存额外QObject占用的内存，但如果您的类在应用程序中没有被广泛使用，那么这应该不是问题。
关于不那么“Qt固有”我只能说将应用程序从一个框架移动到另一个框架通常需要进行大量的更改，独立于你的设计，所以这个问题并没有真正说服我。
另一方面，将公共字段保存在这样的类中通常是个坏主意 - 意外修改会导致难以跟踪错误 - 考虑将winWidget设为私有并添加一些访问方法或许？
当我开始学习qt时，我也厌恶继承QWidgets，但很快我意识到继承更加舒适，主要是因为如果有一天你需要事件交互，你不需要对你的课程进行大量修改。
Your clas is not a proper QWidget, but I don't think it would be a problem to Qt. Unless you need to gain acces to some protected elements of wigets (eg. interact with events) you could go without ever inheriting qt widgets - the choice of design is yours.
The only reason for inheriting might be to save some memory taken by additional QObject, but if your class is not extensivly used in application, this should not be an issue.
About being less "Qt inherent" i can only say that moving application from one framework to another usually needs lots of changes, independently on your design, so this aregument doesn't really convince me.
On tth other hand this is generally bad idea to keep public field in a class like this - accidental modifications will cause difficult to track errors - think about making winWidget private and adding some accesor method perhaps?
When i was beggining to learn qt, I also had aversion to subclassing QWidgets, but soon i realised that it is simply more comfortable to inherit, mostly because you don't need heavy changes to your class if one day you need event-interaction.
更多推荐
发布评论