How to model locations, academic terms and different cohorts in OO

Question

I am working on an app for universities. The case is this:

Each university has several academic programmes. Each programme has many subjects (modules). Each subject can be offered in different locations. The academic year is split into terms and each term lasts for a number of weeks. Not all modules are offered in the same locations each term and programmes can be offered to different groups of students with different start dates within the same academic year.

For example, University A has a MBA programme offered in New York and London. The MBA has 2 modules per term (10 weeks) offered in both locations (Say MBA-NY and MBA-L). It is possible and based on demand, to have a third run of the programme (and therefore of the modules in this term) that starts a week later than the normal intake. So, there is another MBA-NY group but with different timeline. But, this group is, also, part of the same term in the MBA curriculum (that is, the two groups are doing Term 2 of MBA).

My question is how to model locations, academic terms and runs in OO design. Are location, academic terms (and perhaps "runs") properties of the university object or of the programme object? or of the module object?

Update: Based on your responses, my difficulty is to model the academic terms, the cohorts and the different timelines. It's not really the location as it looks straight forward to me. I just included it in the description to show you the connections.

Answer 1

You shouldn't start out by thinking in objects. Assuming you want to build a real working application (and this is not some BS modelling exercise) you would start out by clarify the requirements, i.e. what tasks should the application be able to perform, and by designing the data model necessary to support this. The object design is more low-level and comes down the line after this high-level design.

The question about locations, curriculum, timelines etc. is part of the question of designing the data model for the application. So you shouldn't really think in terms of objects or properties yet. You should probably design it in the form of en entity-relationship diagram, or some similar con conceptual design.

Then when you have the data model and you know which tasks and operations the application should perform, you can start determining which objects you need. But you are not there yet.

Answer 2

It looks like you are trying to do Object Oriented design but with relations similar to a Relational Database. This is generally not a very good idea -- it is a common idea, it's in plenty of programming books, and it's actually probably a bad idea. See any of the many documented examples of ORIM, Object-Relational Impedance Mismatch, on the internet.

Objects are classes of behaviors. What behaviors does your application have?

For example: is it a website where you navigate from a list of programmes to a programme and a list of locations and modules? Without considering any testing and dependency injection concerns, this would lead to something like:

public class Programme
{
  public static List<Programme> All() { ... }
  public static Programme GetById(int id) { ... }
  public List<Location> GetLocations() 
  { 
     return Location.GetByProgrammeId(Id);
  }
  public int Id { get; set; }
}

public class Location
{
   public static List<Location> All() { ... }
   public static List<Location> GetByProgrammeId(int id) { ... }
}

and so on. The contents of the classes are modelled on how stuff appears in the interface, not how it's stored in the DB. It might coincide, but that's not guaranteed.

Note that the methods are built assuming a web application, where each new request you want to run as little SQL as possible, so for example you are more likely to need a "get locations by programme id" method than a "get locations by Programme" since you don't want to be forced to create a whole instance of a Programme in order to get a list of Locations.

Similarly, you should have other methods as needed to manipulate these objects.

Of course, if you are building a desktop applications, things are different. For example, you might be able to keep a Programme instance alive across user interactions, and this of course leads to a different structure of the method calls.

Answer 3

Location is a straightforward business object (though not necessary trivial. You could describe it with the geo-position (provided it's a location on earth) as well as a name, it's height relative to sea level (which one?), etc.

Term has a relation to Programme in a way that it describes its duration and location and it has several constraints (as to how much you can have). So it's a business object too.

Not sure what "run" does mean in this context.