COMPLETE EXTENSIVE Summary for COS3711

UML diagrams & class design:
Syntax:




Syntax for variable and parameters: - NameVar : Type
Syntax for functions: Basically the same except it has () with parameters in
them. E.g. +FuncName(parameter list): return Type
Note: Parameters must also be name: Type
Note: Constructors don’t have type
When we inherit then child class point to parent:




Arrow points to parent class.

,When they say client they mean a class that will manage all the other classes.
Client can be class, function or just code (driver program).




Assuming that PhoneReader is class that
reads in Phone’s from a file and convert them to QList of Phone objects.


Example:

,Note if they say data members should not have to be repeated in sub-classes
means that they should be under protected.
The Reader and Writer objects can either use FilmList object or QList<Film>(i.e.
read function can return FilmList(in this case this case) or it can return
QList<Film>. But always try for FilmList
Example:




Answer

Example:




 MyPrepaid and MyContract inherit from Contract
 ContractList contains (diamond) Contract.
 Contract inherits from QObject
 Note the # sign is protected specifier.
Note:
This arrow is for inheritance:

,This arrow is for associations:




Design patterns:
 Serializer pattern
 Saves the state of an object and state is to be output to a Device,
i.e. a File, or Console window. In memento, state is saved to a list.
 Creating separate classes responsible for reading and writing of
objects.
 Pattern’s job is to store and load the state of class objects.

, o Here our objects are FilmList’s which we trying to read and write.
o Note: The reader don’t have constructor or filename member, you
pass name with read() function. The writer have constructor and
filename member. You specify filename when you create writer
Client:

,Reader and writer classes definition and implementation:
Writer:

,Reader:




**For practice change this to when Film has 2 members

, MVC design pattern
o Used to separate application’s concerns
o This pattern specifies that an application consists of data model,
presentation information and control information. These must be
separated.
o Model: is the application object that carries data.
o View: is the screen representation of the model
o Controller: defines a way the user interface reacts to user input
o Advantages:
MVC patterns says that the Model (responsible for maintaining
the data), the view (responsible for displaying data) and the
controller (responsible for handling events that impact both data
and model) be kept separate classes.
 Extensibility: This separation enables views and controllers
to be added or removed without requiring changes to the
model which allows for additional functionality to be added.
 Maintainability: Separating the model, view and controller
code means that we can focus on managing them
separately instead of managing all of them at once. This
makes it easier to maintain.
 Reusability: The MVC pattern allows us to reuse code by
enabling substitution of one model for another, or one view
for another.
o d

, Implementation:
Model: Responsible to retrieve data and to set the data.
// Model is responsible for data get and set
class Model {
public:
Model(const string &data) {
this->SetData(data); Set data in constructor
}
Model() { } // default constructor
string Data(){
return this->data;
}

void SetData(const string &data) {
this->data = data;
if (this->event != nullptr) { // data change callback event
this->event(data);
}
}
// register the event when data changes.
void RegisterDataChangeHandler(DataChangeHandler handler) {

, this->event = handler;
}
private:
string data = "";
DataChangeHandler event = nullptr;
};



View: Responsible to present data to users. Use the model to represent
thus must have Model instance
#pragma once
#include <iostream>
#include "model.h"
// View is responsible to present data to users
class View {
public:
View(const Model &model) {
this->model = model;
}
View() {}
void SetModel(const Model &model) {
this->model = model;
}
void Render() {
std::cout << "Model Data = " << model.Data() << endl;
}
private:
Model model; //model instance
};
Controller: Can ask Model to update data thus have object of Model in this
class. Can ask View to change it’s presentation, thus it also have instance of
View
// Controller combines Model and View
class Controller {
public:
Controller(const Model &model, const View &view) {
this->SetModel(model);
this->SetView(view);
}
void SetModel(const Model &model) {
this->model = model;
}
void SetView(const View &view) {
this->view = view;
}
// when application starts
void OnLoad() {
this->view.Render();
}
private:
//instance of view and model
Model model;
View view;
};
Client: Uses the pattern.