songs.h

#ifndef _SONGS_H

#define _SONGS_H

#include

#include

#include

using namespace std;

#include "UI.h"

#include "song.h"

class Songs {

/*

Songs represents a collection of compositions, specifically Song objects

A Songs container OWNS the songs within it.

If the container is destroyed it deletes the Song objects it contains

If a song is removed from the container the Song object is deleted from heap space.

*/

public:

Songs();

~Songs(void);

Song * findByID(int anID);

void add(Song & aSong);

void remove(Song & aSong);

void showOn(UI & aView);

void showOn(UI & aView, int memberID);

private:

vector collection;

vector::iterator findPosition(Song & aSong);

};

#endif

recordings.h

#ifndef _RECORDINGS_H

#define _RECORDINGS_H

#include

#include

#include

using namespace std;

#include "UI.h"

#include "recording.h"

class Recordings {

/*

Recordings represents a collection of Recording objects

A Recordings container OWNS the Recording objects within it.

If the container is destroyed it deletes the Recording objects it contains

If a Recording is removed from the container the Recording object is deleted from heap space.

*/

public:

Recordings();

~Recordings(void);

Recording * findByID(int anID);

vector getCollection();

void add(Recording & aRecording);

void remove(Recording & aRecording);

void showOn(UI & aView);

void showOn(UI & aView, int memberID);

private:

vector collection;

vector::iterator findPosition(Recording & aRecording);

};

#endif

users.h

#ifndef _Users_H

#define _Users_H

#include

#include

#include

using namespace std;

#include "UI.h"

#include "user.h"

class Users {

/*

Users represents a collection of compositions, specifically User objects

A Users container OWNS the Users within it.

If the container is destroyed it deletes the User objects it contains

If a User is removed from the container the User object is deleted from heap space.

*/

public:

Users();

~Users(void);

User * findByID(int anID);

User * findByUserID(const string & aUserID);

vector getCollection();

void add(User & aUser);

void remove(User & aUser);

void showOn(UI & aView);

void showOn(UI & aView, const string & memberID);

private:

vector collection;

vector::iterator findPosition(User & aUser);

};

#endif

tracks.h

#ifndef _Tracks_H

#define _Tracks_H

#include

#include

#include

using namespace std;

#include "UI.h"

#include "track.h"

class Tracks {

/*

Tracks represents a collection of compositions, specifically Track objects

A Tracks container OWNS the Tracks within it.

If the container is destroyed it deletes the Track objects it contains

If a Track is removed from the container the Track object is deleted from heap space.

*/

public:

Tracks();

~Tracks(void);

Track * findByID(int anID);

vector getCollection();

void add(Track & aTrack);

void remove(Track & aTrack);

void showOn(UI & aView);

void showOn(UI & aView, int memberID);

private:

vector collection;

vector::iterator findPosition(Track & aTrack);

};

#endif

Part I: Template-based Refactoring of the Application Containers

The solution code provided for Assignment #2 manages four "owning" container classes: Songs, Tracks, Recordings and Users. Examination of these classes will reveal that they are essentially cut and paste copies of each other except for the type of object, or pointer, their elements represent. This is undersirable and will not scale well. In this exercise we want you to replace all four classes with one generic class and thus the songs, tracks, recordings and users objects in the app will all be instances of that generic class.

++++REV 1: Hints:

Use template instead of template when defining templates.

Even though you are putting MyTunesCollection in just a single mytunes_collection.h file still break out the implementation of the method bodies like this:

//mytunes_collection.h

template

class MyTunesCollection {

...

void remove(T & aT);

...

};

template

void MyTunesCollection::remove(T & aT){

typename vector::iterator index = findPosition(aT);

if(index != collection.end()) {

...

}

}

When refering to vector::iterator within your template class the g++ compiler requires that you put the keyword typename in front of it to make it clear that you are just specifying a type here. This is not needed in all C++ compilers but the g++ compiler seems to require it. (Some refer to this as a fix for a C++ parsing compilication in the compiler).

++++end REV1: hints

Part I is based on the work you started in tut 06. Here are the specific requirements:

SR3.1.1) Classes Songs, Tracks, Recordings and Users should be replaced by one generic class: MyTunesCollection.

SR3.1.2) MyTunesCollection should be a generic template class based on C++ templates with the defintition:

template

class MyTunesCollection {

...

};

SR3.1.3) The following code in mytunes.cpp:

//Data collections

Songs songs;

Recordings recordings;

Tracks tracks;

Users users;

should be replaced with:

//Data collections

MyTunesCollection songs;

MyTunesCollection recordings;

MyTunesCollection tracks;

MyTunesCollection users;

or alternatively (depending on your design):

//Data collections

MyTunesCollection songs;

MyTunesCollection recordings;

MyTunesCollection tracks;

MyTunesCollection users;

SR3.1.4) The collections songs, recordings, tracks and users must all be instances of the same generic class and as such the protocol (methods) for the generic class must be appropriate for all the collections to use.

SR3.1.5) In the existing code three of the classes: Songs, Recordings, and Tracks support member lookup by numeric id using a findById() method however Users supports member lookup by a username string id using a method findByUserID(). This discrepency must be resolved in the refactored code. (Come up with one uniform protocol that all the collections can use.)

SR3.1.6) Users should still be able to be found using their username. The client does not want a solution based on giving users a numeric id (like student number). They want to maintain a username like "ajones".

SR3.1.7) [SR2.7] The MyTunesCollection class should implement an overloaded << operator so collection of this type can be output to cout using cout << songs; syntax. (The output should respect the title case requirement DR2.1 from Assignment #2 where ever that applies.)

SR3.1.8) Once completed the refactored code should behave the same as before the refactoring and in particular satisfy the same functional requirements as the solution code does (i.e. the functional requirements from Assignment #2).

SR3.1.9) Contributors: currently each file in the solution code has a banner section like the following.

Part II Your Refactoring Recommendation

In Part II we want you to analyse the code provided, make a refactoring recommendation, and then implement it. Here is your chance beat up on our code for a change.

Thoroughly examine the solution code provided and find something about it that you DON'T like. That is, find something (other than the collections problem from part I) that you think should be refactored. This can be based on the current state of the code or something you think will become a problem as the code scales up or grows in complexity.

Remember refactoring is not about fixing bugs but about reorganizing code that already works. If you are in doubt about your intended refactoring please discuss it with us before you proceed. (If you do find bugs please report them so we can fix them.)

Here are the specific itemized requirements that specify the task. Some of the requirements call for written explanations or pictures. Provide a Part II Analysis document in .pdf format that has the itemized explanations and documentation asked for below. Submit this document file with your code files.

FR3.2.1) Identify the aspect of the code you DON'T like and describe what it is. Provide some sample lines from the provided code to make it clear what you have identified.

FR3.2.2) Provide an explanation of what you find objectionable about the code you've identified and explain why you think it should be refactored.

FR3.2.3) Your refactoring recommendation should be warranted. It should make a real improvement. Don't suggest, for example, replacing a chain of if-else statements with a switch statement instead. Something that trivial is not worthy of being considered a refactoring. (If you are in doubt discuss your planned modifcation with us ahead of time.)

FR3.2.4) Explain your refactoring strategy and how you intend to refactor the code. Provide some sample code or pseudo-code to illustrate your strategy.

FR3.2.5) Provide two UML class diagrams of the classes that will be involved in, or affected b,y your refactoring. They should show the classes involved before and after the refactoring. The diagrams should both show the relationships the classes have to one another. (It is possible that the diagrams will look identical depending on what your refactoring modification is.).

FR3.2.6) The code you submit for this assignment should include your part II refactoring.

FR3.2.7) The code, after your part II refactoring should behave the same as originally (That is, still meet all the functional requirements it did before).

FR3.2.8) Provide a test script called Part2TestScript.txt that you feel illustrates that your refactoring did not alter the intended behaviour of the code. That is, provide a script that executes commands that could have been affected by your refactoring if not done correctly. This is called "Regression Testing" where you provide test cases in which you hope that nothing has changed from before the code change.