Programming desgin

Hello,

I have a class Document and a class Form. I want Document class to have access to form class.
These are my two approaches -

Approach 1:
Approach 1 project found here.
mainwindow.cpp

Code:

---

...
// Inside MainWindow init method
    Document* document = new Document();
    setCentralWidget(document->currentForm());
...

---

document.cpp

Code:

---

...
Document::Document()
{
    form = new Form();
}
 
Form* Document::currentForm()
{
    return form;
}
...

---

Approach 2:
Approach 2 project found here.
mainwindow.cpp

Code:

---

...
// Inside MainWindow init method
    Form* form = new Form();
    setCentralWidget(form);
    Document* document = new Document();
    document->setCurrentForm(form);
...

---

document.cpp

Code:

---

...
void Document::setCurrentForm(Form* currentForm)
{
    form = currentForm;
}
...

---

which design should I use?
I want to follow Qt's design patterns.

Thanks

I would pass the document to the form, i.e. make the UI depend on the data/logic.

Something like

Code:

---

Document *document = new Document;
Form *form = new Form(document);
// or
form->setDocument(document);

---

Cheers,
_

Thanks anda_skoa

Quote:

---

I would pass the document to the form, i.e. make the UI depend on the data/logic.

---

I would even take this a step further and make the coupling between document and form as loose as possible. I would set it up so that the document knows absolutely nothing about the form; instead, when something in the document changes that the UI should know about, the document should emit a signal that tells about the change. Likewise, it might be better if the form also doesn't know anything about the document - it listens for signals about what has changed, and in turn, if the user edits something one the form that should be saved in the document, the form should emit a signal containing the changed items.

With this kind of loose connection, the form doesn't need a document pointer, nor does the document need a form pointer. Something in the middle (the MainWindow, for example) sets up all the connections between document and form signals / slots. I think you could classify this as an example of a bridge pattern in design patterns parlance.

Such a fully disconnected setup does not always work and even if it works it can make it very complex.

It basically becomes fully asynchronous, e.g. if the form needs something it has to emit a request signal and doesn't know when or even if the document is going to answer.
A bit like a web app, but in a single local process.

A one directional dependency can make things considerably easier to code and understand, e.g. like Qt's views and models.
The view (and delegates) can make direct calls the model but the model doesn't know anything about the view (or delegates).

Cheers,
_

Yes, this can also be true. Decoupling to this extent almost always comes at the cost of higher complexity. In simple apps it is probably overkill.

I find decoupling like this to be most useful when the UI is large, with many views and dialogs. These don't all need to know about the details of the underlying "document"; in fact most of them only deal with a small part of the document's contents. So in general, MainWindow might be the only part of the UI that knows all about the document; when it needs to post a dialog, it pulls out the relevant subset of information, initializes the dialog with it, and then pushes the changed information back into the document at the end. If the document or dialog change, MainWindow is the only one who needs to know the details.