Home > Enterprise >  How to avoid redundancy in object oriented design
How to avoid redundancy in object oriented design

Time:04-14

I am looking for some pointers on how to build better object oriented programs. Here is a simple example that I am working through:

The relationship between a Student, Teacher, and a Department (within a school).

A Student will sign up for courses within a Department, and will therefore have many teachers. One could think of a Student, like:

class Student {
  public String name;
  public List<Teacher> teachers;

  ...
}

I.e, the student has many teachers. If the code is ever asked, "who is student A's teachers?", we can very easily find out.

A Teacher, on the other hand, might look like:

class Teacher {
  public String name;
  public List<Students> students;
  ...
}

I.e. A teacher cannot exist without students (at least in this basic example). We can easily ask, who does Teacher B teach? And we can easily find out.

Lastly, we can look at what a Department might look like:

class Department {
  public String name;
  public List<Teacher> teachers;
  public List<Student> students;
  ...

i.e. there are both teachers and students within a Department.

Here are where my question come in.

It seems like there is redundancy in this design. If a student does something like sign up for a course in a department, we will add that student both the the Department's student list, AND the teacher's student list. This seems oddly redundant.

Removing them, however, makes some question harder to answer. E.g. Who are all the students in Department C? Which Departments does Student D have teachers in? etc.

I am wondering if there is a fundamental flaw in the way I am modelling this relationship, OR if I need to be more tolerant to this sort of redundancy.

CodePudding user response:

Your objects are views of data. Usually the data is going to be in a database in some relational or hierarchical or other kind of schema, and may be mostly normalized (meaning, not redundant for the most part). In a distributed system with multiple databases we have to accept some redundancy as a cost of doing business.

Regardless, the actual data is where redundancy matters, having a view be redundant compared to other views is not an issue.

CodePudding user response:

If you would store them in a database, you would have:

  • a table STUDENTS with Student data (SID name)
  • a table TEACHERS with Teacher data (TID name)
  • a table DEPARTMENTS with Teacher data (DID name)

and cross tables:

  • a M:N cross table (SID, TID)
  • (DID, TID)
  • (DID, SID)

These cross tables are bidirectional student to teacher and teacher to student. You rightly find that Student listing al their Teachers is redundant. But searching all Teachers having that Student by searching through all Teachers is inefficient.

One remark: Set instead of List would be nicer.

  1. Now if a teacher can only be in one department, things would be more structured.
  2. If you would introduce Course held by one Teacher, things would also be more structured.
  • Related