Cara memodelkan lokasi, istilah akademis, dan kelompok yang berbeda di OO

Saya sedang mengerjakan aplikasi untuk universitas. Masalahnya adalah ini:

Setiap universitas memiliki beberapa program akademik. Setiap program memiliki banyak mata pelajaran (modul). Setiap subjek dapat ditawarkan di lokasi yang berbeda. Tahun akademik dibagi menjadi beberapa istilah dan setiap periode berlangsung selama beberapa minggu. Tidak semua modul ditawarkan di lokasi yang sama setiap semester dan program dapat ditawarkan kepada kelompok siswa yang berbeda dengan tanggal mulai yang berbeda dalam tahun akademik yang sama.

Misalnya, Universitas A memiliki program MBA yang ditawarkan di New York dan London. MBA memiliki 2 modul per jangka waktu (10 minggu) yang ditawarkan di kedua lokasi (Say MBA-NY dan MBA-L). Dimungkinkan dan berdasarkan permintaan, untuk menjalankan program ketiga (dan karenanya modul dalam istilah ini) yang dimulai seminggu kemudian dari asupan normal. Jadi, ada grup MBA-NY lain tetapi dengan timeline yang berbeda. Tetapi, kelompok ini juga merupakan bagian dari istilah yang sama dalam kurikulum MBA (yaitu, kedua kelompok tersebut melakukan Term 2 MBA).

Pertanyaan saya adalah bagaimana memodelkan lokasi, istilah akademik, dan berjalan dalam desain OO. Apakah lokasi, istilah akademik (dan mungkin "berjalan") properti dari objek universitas atau objek program? atau dari objek modul?

Pembaruan: Berdasarkan respons Anda, kesulitan saya adalah memodelkan istilah akademik, kohort, dan jadwal yang berbeda. Ini bukan lokasi yang terlihat lurus ke depan bagi saya. Saya baru saja memasukkannya dalam deskripsi untuk menunjukkan koneksi.

Anda seharusnya tidak memulai dengan berpikir pada objek. Dengan asumsi Anda ingin membangun aplikasi kerja nyata (dan ini bukan latihan pemodelan BS) Anda akan memulai dengan menjelaskan persyaratan, yaitu tugas apa yang harus dapat dilakukan aplikasi, dan dengan merancang model data yang diperlukan untuk mendukung ini. Desain objek lebih rendah dan turun garis setelah desain tingkat tinggi ini.

Pertanyaan tentang lokasi, kurikulum, jadwal dll. Adalah bagian dari pertanyaan merancang model data untuk aplikasi. Jadi Anda tidak harus benar-benar berpikir dalam hal objek atau properti. Anda mungkin harus mendesainnya dalam bentuk diagram en entity-relationship, atau beberapa desain konseptual serupa.

Kemudian ketika Anda memiliki model data dan Anda tahu tugas dan operasi yang harus dilakukan aplikasi, Anda dapat mulai menentukan objek mana yang Anda butuhkan. Tetapi Anda belum ada di sana.

Sepertinya Anda mencoba melakukan desain Berorientasi Objek tetapi dengan hubungan yang mirip dengan Database Relasional. Ini umumnya bukan ide yang sangat bagus - ini adalah ide yang umum , ada di banyak buku pemrograman, dan itu mungkin ide yang buruk. Lihat salah satu dari banyak contoh yang terdokumentasi dari ORIM, Object-Relational Impedance Mismatch, di internet.

Objek adalah kelas perilaku. Perilaku apa yang dimiliki aplikasi Anda?

Misalnya: apakah ini situs web tempat Anda menavigasi dari daftar program ke program dan daftar lokasi dan modul? Tanpa mempertimbangkan pengujian dan masalah ketergantungan injeksi, ini akan mengarah pada sesuatu seperti:

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

dan seterusnya. Isi kelas dimodelkan tentang bagaimana hal-hal muncul di antarmuka, bukan bagaimana itu disimpan dalam DB. Mungkin bertepatan, tetapi itu tidak dijamin.

Perhatikan bahwa metode ini dibangun dengan asumsi aplikasi web, di mana setiap permintaan baru yang Anda ingin jalankan sesedikit mungkin SQL, jadi misalnya Anda lebih cenderung membutuhkan metode "dapatkan lokasi dengan program id " daripada "dapatkan lokasi dengan Program" "Karena Anda tidak ingin dipaksa untuk membuat seluruh instance Program untuk mendapatkan daftar Lokasi.

Demikian pula, Anda harus memiliki metode lain yang diperlukan untuk memanipulasi objek-objek ini.

Tentu saja, jika Anda sedang membangun aplikasi desktop, semuanya berbeda. Misalnya, Anda mungkin dapat membuat instance Program tetap hidup di seluruh interaksi pengguna, dan ini tentu saja mengarah pada struktur berbeda dari pemanggilan metode.

Location adalah objek bisnis yang mudah (meskipun tidak perlu sepele. Anda bisa menggambarkannya dengan geo-posisi (asalkan itu lokasi di bumi) serta namanya, tingginya relatif terhadap permukaan laut (yang mana?), dll.

Termmemiliki hubungan dengan Programmecara yang menggambarkan durasi dan lokasi dan memiliki beberapa kendala (seperti berapa banyak yang dapat Anda miliki). Jadi itu adalah objek bisnis juga.

Tidak yakin apa arti "lari" dalam konteks ini.