C# Design – Handling Multiple Collections in C#

cdesignobject-oriented

I'm currently trying to learn C# and want to enhance my understanding of Object Oriented Programming (OOP). I'm hoping to accomplish this by experimenting with a small program that keeps track of my school assignments/information. I've constructed classes relating to my Institutions, Semesters(Terms), Courses, and Assignments. My question is whether or not I have created and implemented my classes correctly in regards to the information they represent. My thinking suggests that my classes should not inherit from one another in a parent/child like fashion because they are physically unrelated. However accessing objects through multilevel lists seems impractical (I think).. Is there a better way of doing this that doesn't force me to access object by iterating through collections, but still implements OOP best practices?

Program Source Code

Entry Point / Main

static void Main(string[] args)
{
    List<Institution> Institutions = new List<Institution>();
    Institutions.Add(new Institution("My college"));
    Institutions[0].AddNewTerm("2016", "Spring");
    Institutions[0].Terms[0].AddNewCourse("Math 210");
    Institutions[0].Terms[0].Courses[0].AddNewAssignment("Chapter 1");
    MessageBox.Show(Institutions[0].Terms[0].Courses[0].Assignments[0].Name);
}

Class List

Institution

class Institution
{
    public string Name { get; set; }
    public List<Term> Terms { get; set; }

    public Institution(string UP_Name)
    {
        this.Name = UP_Name;
        this.Terms = new List<Term>();
    }

    public void AddNewTerm(string NewTermYear, string NewTermSeason)
    {
        Terms.Add(new Term(NewTermYear, NewTermSeason));
    }
}

Term

class Term
{
    public string Name { get; set; }
    public string Year { get; set; }
    public string Season { get; set; }
    public List<Course> Courses { get; set; }

    public Term(string NewSeason, string NewYear)
    {
        this.Season = NewSeason;
        this.Year = NewYear;
        this.Courses = new List<Course>();
        this.Name = (this.Season + " " + this.Year);

    }

    public void AddNewCourse(string NewCourseName)
    {
        this.Courses.Add(new Course(NewCourseName));
    }
}

Course

class Course
{
    public string Name { get; set; }

    public List<Assignment> Assignments { get; set; }

    public Course(string UP_Name)
    {
        this.Name = UP_Name;
        this.Assignments = new List<Assignment>();
    }

    public void AddNewAssignment(string NewAssignmentName)
    {
        Assignments.Add(new Assignment(NewAssignmentName));
    }

}

Assignment

class Assignment
{
    public string Name { get; set; }

    public Assignment(string UP_Name)
    {
        this.Name = UP_Name;
    }
}

Best Answer

It's not bad for a newbie. You're right to be concerned about accessing objects through multilevel lists. Also, hard coding the indexes will hurt you eventually (but it's OK for now).

You might try changing AddNewxxx() to return what was added. For example, if you change Term's AddNewClass to

public Course AddNewCourse(string NewCourseName)
{
    Course result = new Course(NewCourseName);
    this.Courses.Add(result);
    return result;
}

in your Main() function you'll be able to do something like

var mathCourse = Institutions[0].Terms[0].AddNewCourse("Math 210");
mathCourse.AddNewAssignment("Chapter 1");
mathCourse.AddNewAssignment("Chapter 2");

and so on.

Be patient; there is a lot to learn.

Related Solutions

C# class architecture for REST services

Why not make it easy on your self - both decision-wise and implementation-wise - and just use one of the many frameworks that already exist to consume Web API's, like RestSharp or Hammock.

Java Design Patterns – How to Use Decorator and Factory Together to Extend Objects

Yes, SpecialTable can be produced by the same factory (and by the same factory method) that produces Table. This not a problem, as long as SpecialTable provides at least the methods guaranteed by the Table interface (which it does).

This sort of situation makes sense when objects returned from the factory have some guaranteed behaviour/functionality (interface Table), and some optional stuff (interface SpecialTable).

So, in order to make use of the optional extra abilities/stuff available on some concrete objects returned by the factory, you have a few choices:

use polymorphism (recommended)
make use of instanceof (or similar), which can be used to check for interface compliance/exact typing (avoid this if possible!)

Using polymorphism

An example to illustrate: suppose SpecialTable has extra data and an extra widget 'blarg' which appears on the UI representing special tables. Do you really need the code which uses SpecialTable to know that it needs to add 'blarg' to the UI? Or can you just have your external code ask the thing of type Table to add its necessary UI components to some UI container? Then the calling code doesn't care what exact type the thing is -- SpecialTable deals with it, adding the 'blarg' to the container itself. This pattern can be described as the delegate pattern (also sometimes also known as strategy pattern).

Using instanceof (type checking)

Example of instanceof use:

// Table and SpecialTable are interfaces
Table table = TableFactory.instance().getDefaultTable();

if (table instanceof "SpecialTable") {
  SpecialTable specialTable = (SpecialTable)table;
  specialTable.specialMethod();
}

table.normalMethod();

Note that when you define your SpecialTable interface you can declare it as extending the Table interface and then only list the extra methods.

Your factory will be producing concrete objects of either type. So you might have a concrete class called BoringTable which implements Table, and a concrete class called ExcitingTable which implements SpecialTable.

Beware instanceof!

It's generally better to avoid things like 'instanceof' (or generally speaking, ifs of any kind which depend on what type an object is). You should favour polymorphism instead. By this I mean having multiple different classes, of a common type, enclosing different behaviour in their implementation code.

Ask yourself this: does the class using something of type Table (which might also be of type SpecialTable) need to care if it's a special table or not? Can you not hide that distinction in some sort of implementation of the SpecialTable -- have it do something different, something extra, that plain old Table does?