Làm thế nào để mô hình hóa các địa điểm, thuật ngữ học thuật và các đoàn hệ khác nhau trong OO

Tôi đang làm việc trên một ứng dụng cho các trường đại học. Trường hợp là thế này:

Mỗi trường đại học có một số chương trình học tập. Mỗi chương trình có nhiều môn học (mô-đun). Mỗi môn học có thể được cung cấp ở các địa điểm khác nhau. Năm học được chia thành các điều khoản và mỗi nhiệm kỳ kéo dài trong một số tuần. Không phải tất cả các mô-đun được cung cấp ở cùng một địa điểm mỗi học kỳ và các chương trình có thể được cung cấp cho các nhóm sinh viên khác nhau với ngày bắt đầu khác nhau trong cùng một năm học.

Ví dụ, Đại học A có chương trình MBA được cung cấp tại New York và London. MBA có 2 mô-đun mỗi kỳ (10 tuần) được cung cấp ở cả hai địa điểm (Say MBA-NY và MBA-L). Có thể và dựa trên nhu cầu, để có một chương trình thứ ba (và do đó là các mô-đun trong thuật ngữ này) bắt đầu muộn hơn một tuần so với lượng tiêu thụ thông thường. Vì vậy, có một nhóm MBA-NY khác nhưng với dòng thời gian khác nhau. Nhưng, nhóm này cũng là một phần của cùng một thuật ngữ trong chương trình MBA (nghĩa là hai nhóm đang học kỳ 2 của MBA).

Câu hỏi của tôi là làm thế nào để mô hình hóa các địa điểm, thuật ngữ học thuật và chạy trong thiết kế OO. Là vị trí, thuật ngữ học thuật (và có lẽ "chạy") thuộc tính của đối tượng đại học hoặc của đối tượng chương trình? hoặc của đối tượng mô-đun?

Cập nhật: Dựa trên phản hồi của bạn, khó khăn của tôi là mô hình hóa các thuật ngữ học thuật, đoàn hệ và các mốc thời gian khác nhau. Nó không thực sự là vị trí vì nó nhìn thẳng về phía tôi. Tôi chỉ đưa nó vào phần mô tả để cho bạn thấy các kết nối.

Bạn không nên bắt đầu bằng cách suy nghĩ trong các đối tượng. Giả sử bạn muốn xây dựng một ứng dụng hoạt động thực sự (và đây không phải là một bài tập mô hình hóa BS), bạn sẽ bắt đầu bằng cách làm rõ các yêu cầu, tức là ứng dụng nào có thể thực hiện và bằng cách thiết kế mô hình dữ liệu cần thiết để hỗ trợ việc này. Thiết kế đối tượng ở mức độ thấp hơn và đi xuống sau thiết kế cấp cao này.

Câu hỏi về địa điểm, chương trình giảng dạy, mốc thời gian, vv là một phần của câu hỏi thiết kế mô hình dữ liệu cho ứng dụng. Vì vậy, bạn không nên thực sự nghĩ về các đối tượng hoặc tài sản chưa. Bạn có thể nên thiết kế nó dưới dạng sơ đồ mối quan hệ thực thể hoặc một số thiết kế khái niệm tương tự.

Sau đó, khi bạn có mô hình dữ liệu và bạn biết ứng dụng và hoạt động nào mà ứng dụng sẽ thực hiện, bạn có thể bắt đầu xác định đối tượng nào bạn cần. Nhưng bạn chưa ở đó.

Có vẻ như bạn đang cố gắng thực hiện thiết kế Hướng đối tượng nhưng có quan hệ tương tự như Cơ sở dữ liệu quan hệ. Đây thường không phải là một ý tưởng hay - đó là một ý tưởng phổ biến , nó có rất nhiều sách lập trình và thực sự có lẽ đó là một ý tưởng tồi. Xem bất kỳ ví dụ nào trong số nhiều ví dụ được ghi lại về ORIM, Sự không phù hợp đối tượng quan hệ đối tượng, trên internet.

Đối tượng là các lớp hành vi. Ứng dụng của bạn có những hành vi gì?

Ví dụ: đó có phải là trang web nơi bạn điều hướng từ danh sách các chương trình đến chương trình và danh sách các vị trí và mô-đun không? Nếu không xem xét bất kỳ mối quan tâm tiêm thử nghiệm và phụ thuộc, điều này sẽ dẫn đến một cái gì đó như:

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

và như thế. Nội dung của các lớp được mô hình hóa về cách thức các công cụ xuất hiện trong giao diện, chứ không phải cách nó được lưu trữ trong DB. Nó có thể trùng khớp, nhưng điều đó không được đảm bảo.

Lưu ý rằng các phương thức được xây dựng giả sử một ứng dụng web, trong đó mỗi yêu cầu mới bạn muốn chạy càng ít SQL càng tốt, vì vậy, ví dụ bạn có thể cần một phương thức "lấy vị trí theo id chương trình " hơn là "lấy vị trí theo Chương trình "Vì bạn không muốn bị buộc phải tạo toàn bộ phiên bản của Chương trình để có được danh sách Địa điểm.

Tương tự, bạn nên có các phương thức khác khi cần thiết để thao tác các đối tượng này.

Tất nhiên, nếu bạn đang xây dựng một ứng dụng máy tính để bàn, mọi thứ sẽ khác. Ví dụ, bạn có thể giữ một cá thể Chương trình tồn tại qua các tương tác của người dùng và điều này tất nhiên dẫn đến một cấu trúc khác nhau của các cuộc gọi phương thức.

Location là một đối tượng kinh doanh đơn giản (mặc dù không tầm thường. Bạn có thể mô tả nó với vị trí địa lý (với điều kiện là vị trí trên trái đất) cũng như tên, chiều cao của nó so với mực nước biển (cái nào?), v.v.

Termcó một mối quan hệ Programmetheo cách mà nó mô tả thời lượng và vị trí của nó và nó có một số ràng buộc (như bạn có thể có bao nhiêu). Vì vậy, nó cũng là một đối tượng kinh doanh.

Không chắc chắn "chạy" có nghĩa là gì trong bối cảnh này.