I'm modeling a college process, in which I have three classes: Student, Subject and Degree

Degrees have their own subjects, students have a list of subjects they have passed, and also students should belong to a single degree plan.

From a design perspective, how should I associate a student with his/her degree?

If student has a reference to his relevant Degree object, then it suddenly could have a lot more responsibility, and I want to manage Separation of concerns properly.

Is there a better alternative?

  • 1
    In the real world, students (mostly) know what degree course they're doing and degree courses (mostly) know what students are taking them! – jonrsharpe May 15 '15 at 18:50
  • Associations between entities should not be based on who knows what in the real worlds. Eg. a grade might be registered in the administration system before it is disclosed to the student. – JacquesB May 16 '15 at 16:27

Asking this question shows that you find your current model not intuitive and I think this is a good feeling. Let me explain an alternative to having only Student, Subject and Degree to you that hopefully feels more intuitive.

While a student might seem to know everything about his degrees, he doesn't. Let's illustrate this with a real world example: Consider a student got a degree for some course. However, the university staff found out and can prove that the student cheated in the final tests. His degree is therefore immediatly declared invalid before he probably even gets to know about that.

The question is: who is responsible for telling if some students degree is existing and also valid?

They are the ones having the responsibility of knowing which student has which (valid) degrees. This could e.g. be an examination office, but it might depend on the university/country.[1]

As you see, we have to model another party in regards of separation of concerns. And same goes for your single degree plan. There certainly is another authority responsible for administration of the students degree plans to make sure every student has only one plan and that this plan is valid.

In a nutshell, students and their degrees are only connected indirect through differend kind of authorities. The students usually know the authorities that are responsible for them (e.g. in code that means they have a reference to this object).

[1]: Just a note of caution: even though there might only be one authority of this kind, don't model this with some singleton pattern. Instead, model it as if there could be more than one authorities and in your actual program only create one instance.


If you want to associate a Student with a Degree, but keep them separate from each other, you can express that relationship with a data structure like a HashMap.

something like (untested, treat this as pseudo code):

HashMap<Student, Degree> enrolment = new HashMap<Student, Degree>();
Student dave = new Student();
Degree masterOfScience = new Degree();
enrolment.put(dave, masterOfScience);
  • Why are you recommending a data structure for a question that is talking high-level class design and relationships? That is an implementation detail. – user22815 May 16 '15 at 16:30
  • @Snowman Because it answers the question how should I associate a student with his/her degree? I think that a class like HashMap that associates an object with another one is high level class design and a relationship. I recommended to take the relationship out of either class and put it into another one. Any attempt to model a relationship will end up being some kind of data structure, with both objects being the data and the association being the structure (for example). A HashMap happens to be an example for that. – null May 16 '15 at 16:53
  • I don't think you understand what "associate" means in this context. Think about a UML diagram and how it models relationships. – user22815 May 16 '15 at 16:54
  • @Snowman in a UML diagram, Student and Degree would not have a direct connection if the association was made via a data structure. If Student would have a reference to his/her Degree there would be a direct connection. The data structure that is not part of either class makes both classes more separate, which is what the question is explicitly asking for. – null May 16 '15 at 17:04

First: What is the program supposed to do? You cannot make decision about architecture without knowing the purpose of the program. Also, ignore advice from people whom you haven't told the purpose of the program :)

Second: Unless you are writing an actual simulation of a college, you probably don't want objects like Student, Subject etc. to have behavior and responsibilities at all. In eg. an administrative program for a college, entities like students and degrees are the data that the system acts upon, not the objects that act in the system. For data entities you should not think about responsibilities, but about what data you need to keep track of in order for the system to fulfill its tasks.

Don't fall into the trap to think that the objects acting in the system should somehow represent real-world objects. This is only the case in simulation software, which is very specific niche. In most software, the objects with behavior (being subject to principles like separation of concerns and single-responsibility) will be things like 'DatabaseConnection', 'UI Control', 'Report Scheduler' etc. which have no correspondence to real-world objects but rather corresponds to the tasks the application is designed to do.


Student, Subject and Degree are not directly related. A StudentDegree would have the knowledge and reach to know about students, subjects and their degree. A subject should not track what each student scored. A StudentSubject should. A student should have one StudentDegree. A StudentDegree has a Student, and many StudentSubjects and Degree. Now you've got the proper relationships so that behavior can be centralized for a student's degree program.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.