Come modellare luoghi, termini accademici e diverse coorti in OO

Non dovresti iniziare a pensare negli oggetti. Supponendo che tu voglia costruire una vera applicazione funzionante (e questo non è un esercizio di modellazione BS), inizieresti a chiarire i requisiti, cioè quali compiti dovrebbe essere l'applicazione in grado di eseguire, e progettando il modello di dati necessario per supportarlo. Il design dell'oggetto è più di basso livello e segue la linea dopo questo design di alto livello.

La domanda su posizioni, curriculum, tempistiche, ecc. fa parte della domanda di progettazione del modello di dati per l'applicazione. Quindi non dovresti davvero pensare in termini di oggetti o proprietà ancora. Probabilmente dovresti progettarlo sotto forma di un diagramma di entità-relazione o di un disegno concettuale concettualizzato simile.

Quindi quando si dispone del modello dati e si conoscono le attività e le operazioni che l'applicazione deve eseguire, è possibile iniziare a determinare quali oggetti sono necessari. Ma tu non ci sei ancora.

Sembra che tu stia provando a progettare oggetti orientati agli oggetti ma con relazioni simili a un database relazionale. Questa non è generalmente una buona idea - è un'idea comune , è ricca di libri di programmazione ed è probabilmente una cattiva idea. Vedi uno dei tanti esempi documentati di ORIM, Object-Relational Impedance Mismatch, su Internet.

Gli oggetti sono classi di comportamenti. Quali comportamenti ha la tua applicazione?

Ad esempio: si tratta di un sito Web in cui si naviga da un elenco di programmi a un programma e un elenco di percorsi e moduli? Senza considerare eventuali problemi di analisi e di dipendenza da dipendenza, ciò porterebbe a qualcosa di simile:

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) { ... }
}

e così via. I contenuti delle classi sono modellati su come la roba appare nell'interfaccia, non come è memorizzata nel DB. Potrebbe coincidere, ma non è garantito.

Si noti che i metodi sono costruiti assumendo un'applicazione web, dove ogni nuova richiesta si desidera eseguire il meno possibile SQL, quindi ad esempio è più probabile che sia necessario un "get location by program id "metodo che a" trova percorsi per Programma "poiché non vuoi essere costretto a creare un'intera istanza di un Programma per ottenere un elenco di Località.

Allo stesso modo, dovresti avere altri metodi necessari per manipolare questi oggetti.

Naturalmente, se stai creando un'applicazione desktop, le cose sono diverse. Ad esempio, potresti essere in grado di mantenere attiva un'istanza del programma attraverso le interazioni dell'utente, e ciò ovviamente comporta una diversa struttura delle chiamate al metodo.

Location è un oggetto business diretto (anche se non necessario, banale. Puoi descriverlo con la posizione geografica (purché si tratti di una posizione sulla terra) e un nome, l'altezza relativa al livello del mare (quale? ), ecc.

Term ha una relazione con Programme in un modo in cui descrive la sua durata e posizione e ha diversi vincoli (quanto a quanto puoi avere). Quindi è anche un oggetto aziendale.

Non sei sicuro di cosa "run" significhi in questo contesto.