is it wrong to have classes with unfixed size, when you'd want to store them in memory later

Question

In a c# course I'm taking, We are creating a program that has two main classes, say Student and Course. Now we want to store the data of which courses each student takes. Our instructor said it was a bad practice to have a List of courses as a property of student. The reason he gave was that if you wanted to store the data in a file for example, you'll have no way of reading it back.

The solution he gave was to have a third entity, say studentAndCourse, which would contain the student and course's ID. So given the student ID,you could find all the courses that he takes by searching the studentAndCourse list. I wondered If this solution is the convention for handling this problem, and if there are other solutions.

I've learnt c++, and I think the same question applies there: How can you use a vector, or a dynamic array, as a class field and still be able to store the data.

I'd be more than happy with an online tutorial, but I didn't know what search words to use. If this question was already asked, kindly close it and give me the links. thank you!

Looks like you (and/or your teacher) are confusing storage and domain model. In the model, a Student _should_ have a list of Courses. That should be unrelated to how it's stored. — H H, Dec 26 '15 at 18:14
The answer is NO if you are using the standard Net Serialization classes. The serializer's will automatically handle the random sizes. If you were creating you own routines to read/write random data then you need to either length parameters or end of data character like '\0'. The teacher was referring to a completely different issue with the structure of the data (not variable size). Saving data from different classes you need a common key (like an id) so when you read the data back you can join the data by the id. Your teacher gave a very simple answer and there are ways of doing it. — jdweng, Dec 26 '15 at 18:43
@jdweng regarding the last problem, wouldn't it be simpler just to have a list inside Student, containing the IDs of all the courses connected to it? — Person1, Dec 26 '15 at 23:38
Yes, that is a common key approach like what I mentioned which is really a class with a "variable size" since the number of courses vary with each student. So it is not wrong (pardon my double negative) which is the title to this posting. — jdweng, Dec 27 '15 at 09:59

score 0 · Accepted Answer · edited May 23 '17 at 12:04

As already mentioned, how the data is stored can be different from the domain model. One way to model your entities:

Storage / DB

We have student, courses and n:n associations between them (any Student can go to any Course).

Student: StudentId, Name
Course: CourseId, Name
StudentXCourse: XId, StudentId, CourseId

Models / classes (I will use C#ish, as I haven't worked with C++ for a while)

class Student 
{
   int StudentId;
   string Name; 
   IList<Course> Courses;
}

class Course {
   int CourseId;
   string Name;
   IList<Student> Students;
}

So, Student knows its data, but also can have a list of Courses that the Student attends. Similarly, the Course knows its data, but can have a list of Students attending that Course. These lists can be populated on demand (lazy) to avoid loading tons of data.

Defining like this is not strange at all in ORM world (in Entity Framework, they are called navigation properties, as they allow to easily navigate through data).

Thank you! "populated on demand" when will be a good time to populate it? whenever I want an easy access to all the courses of this student? — Person1, Dec 26 '15 at 19:57

is it wrong to have classes with unfixed size, when you'd want to store them in memory later

1 Answers1