Wanted Advise on project concept
-
ADDENDUM
Duplicating projects is not much fun - most of the "copy / search and rename" is prone to errors...
Would adding another constructor to existing "Serial terminal" make more sense?
This is a working one
and it builds "serial options"TERMINAL_MainWindow::TERMINAL_MainWindow(QWidget *parent) : QMainWindow(parent), m_ui(new Ui::TERMINAL_MainWindow), m_status(new QLabel), m_console(new Console), m_settings(new SettingsDialog), //! [1] m_serial(new QSerialPort(this))My primary task is to have communication between PC and "radio" .
I am pretty much a hacker and try to reuse somebody else code as much as feasible.
At present I have a working code - "Serial terminal" - it allows communication via USB with a test gear - Vector Network analyzer.I have spent much time futzing with QT Bluetooth examples code and I am pretty much in position to reuse "Serial terminal" to change from USB serial to " Bluetooth (serial) terminal".
Since QT Bluetooth examples code is actually spread between two sub-projects files I am asking for an advise on how to proceed.
Should I create another sub-project with QT Bluetooth examples code compiled as libraries or
should I create a new class , using QT Bluetooth examples code , and add it to a copy of existing , working "Serial terminal"?At present I have no need to communicate between "Serial terminal" and "Bluetooth (serial) terminal".
I personally prefer to make duplicate of working code instead of modifying it - relatively safer that way.
BUT I am open to other opinions.
PS
This is my hobby , not for public usage project, any "Linux security issues " are of no consequences to me.
-
If you are following OO C++ concepts properly in your design then you should subclass your existing utilities to add functionality...that presupposes that you well defined your operations interfaces. The goal of any elite OO programmer is to NOT have to modify existing classes, but to only subclass or instantiate.
-
If you are following OO C++ concepts properly in your design then you should subclass your existing utilities to add functionality...that presupposes that you well defined your operations interfaces. The goal of any elite OO programmer is to NOT have to modify existing classes, but to only subclass or instantiate.
@Kent-Dorfman Since
I am not native English speaker
and "I grew up" with "K@R"What is the purpose of confusing the issue using "subclass" when the
"original " C++ (OOP?) ) term is"inheritance " ?
Or is this called "programming ( coding ) progress " ?
Cheers
-
K&R is a book about C. C has no classes or inheritance (unless you ugly fake it), so the term doesn't originate from there.
C++ is multiparadigm language. OOP is just one of supported styles. So is functional, data oriented and others. C++ was inspired by a lot of languages before it, like Simula, Smaltalk, Modula-2 and others. Different people related to different languages used different terms to mean the same things. It's just your normal word soup. Get used to it as it's not going away.
Subclassing, inheriting and deriving means the same thing.
Subclass, child class and derived class means the same thing.
Superclass, parent class and base class means the same thing.As for the original question - my personal opinion is that neither copying nor modifying existing projects is a good application design method. I would say you should rather design your app first, list steps needed to implement exactly what you had in mind and then implement it step by step, verifying at each step if it matches your design. You can use examples and code snippets for each step, but mostly as a guidance and not as the basis for everything.
Copy/pasting and modifying entire example projects as pieces of your software is not a good way to write an application. Renaming stuff and gluing together things that were never meant as anything more than simple examples of some API usage is a way to make so called "spaghetti code" that's only good for throwing away.