Difference between revisions of "Project A2 20141 - OOP344"

From CDOT Wiki
Jump to: navigation, search
(The Big Picture: Update)
m (The Big Picture: wip)
Line 47: Line 47:
  
 
= The Big Picture =
 
= The Big Picture =
This assignment is about creating a basic commandline GUI system. It is meant to show the student how OOP can be used effectively to design a system. The basic setup for this system are the 6 classes iFrame, CFrame, CField, CLabel, CLine, CButton and the supplemental class CDialog provided already implemented as a part of the spec. Let's look at the role of each of these.
+
This assignment is about creating a basic console GUI system. It is meant to show the student how OOP can be used effectively to design a system. The basic setup for this system are the 6 classes iFrame, CFrame, CField, CLabel, CLine, CButton and the supplemental class CDialog provided already implemented as a part of the spec. Let's look at the role of each of these.
  
 
== iFrame ==
 
== iFrame ==

Revision as of 17:39, 7 March 2014


OOP344 | Weekly Schedule | Student List | Teams | Project | A1 | A2 | A3 | Student Resources

Introduction

The basic information of A2 is on the BTP300 site linked here. A number of issues have been found within the assignment spec and so a series of changes is required in order for the spec to produce a correct assignment. The changes are listed here. In addition, we are also listing a number of clarifications and suggestions that you may find helpful while implementing this assignment. Those will follow the spec code changes.

Spec Code Changes

cfg.h

  • Instead of #defining NULL in cfg.h, instead #include <cstdlib> at the top of cfg.h. eg:
#ifndef __CFG_H__
#define __CFG_H__
#include <cstdlib>

...

#endif

CFrame

Functions to be removed

The following two functions should be removed from the specification completely. Let me be extra clear: DO NOT PUT THEM IN YOUR CFrame HEADER, DO NOT CODE THEM, DO NOT USE THEM!

  • CFrame::display
  • CFrame::edit

CField

Updated Functions

  • The function CField::edit currently accepts 4 parameters and is not virtual.
    It should be updated as follows to be consistent with its child classes:
    • pure virtual
    • should not accept any parameters
    • should return int (it already does)

CLine

Constructors

Both constructors should accept a bool* and NOT a bool for insert mode. Updated descriptions follow:

Constructor 1

Receives 8 values.
...

  • bool* - the insert mode for the line field

...

Constructor 2

Receives 7 values.
...

  • bool* - the insert mode for the line field

...

The Big Picture

This assignment is about creating a basic console GUI system. It is meant to show the student how OOP can be used effectively to design a system. The basic setup for this system are the 6 classes iFrame, CFrame, CField, CLabel, CLine, CButton and the supplemental class CDialog provided already implemented as a part of the spec. Let's look at the role of each of these.

iFrame

iFrame is an interface class that describes a widget that has a frame. We can easily spot interface classes by looking for the "i" at the beginning of their name. A widget is basically a window component such as a label, a button, a field, or even a full window. Since it is an interface, iFrame's job is to declare a set of functionality that every framed object can publicly perform. We call this type of design design by contract because we can think of any class inheriting from iFrame to be contractually obligated to fulfill what iFrame has promised.

In this case, iFrame declares that any object instanced from a class derived from iFrame can draw itself, hide itself, and move.

CFrame

CFrame is iFrame's child and implements iFrame's core responsibilities. The "C" in CFrame stands for "concrete" (even though it is technically abstract! More on this later).