Advice on class structure

Question

I have a class Student which needs to be persisted in the database. I have methods that create and update these students (CreateStudent, UpdateStudent) and right now, the structure of this Student class is:

public class Student { public int ID { get; set; } public string FirstName { get; set; } }

Now what I am thinking is my CreateStudent accepts a Student object:

public int CreateStudent(Student newStudent);

However, since this student is new, the ID wouldn't be persisted (or shouldn't be persisted) to the database. But it seems unclear to the user of the method that this is how it works. For example, I used CreateStudent but passed a Student.ID of 6, the CreateStudent method would ignore the ID since this is creating a student. However, I am trying to find something that is clearer. What I want to try now is separating the ID to an interface which would only be available when a Student is already existing in the database. Sort of like this:

public IEntity { int ID { get; set; } } public interface IUnknownStudent { string FirstName { get; set; } } public interface IStudent : IUnknownStudent, IEntity { }

Then when using CreateStudent, I pass a IUnknownStudent (no ID). Only when retrieving or updating will I use the implementation with an ID. But I am not sure if this has any problems since its the first time I'm trying it, and I was wondering if the experienced guys here can give some advice about this.

EDIT:

CreateStudent() is on a separate class, StudentLogic.

Doesn't the name CreateStudent just straight-up imply that the student is not created and therefore the ID will be obtained from the database? No need for separate interfaces. Otherwise I guess you will need a IKnownStudent which is more work and silly — user585968
– user585968, Commented Feb 21, 2016 at 3:57
my 2 cents: as a thought experiment, see how far you can get just designing the system with a student record being nothing more than a map of key-value pairs. figure out the minimum set of functions (static methods i suppose) needed to act upon these maps in order to satisfy your program's goals. assume no classes (or interfaces) needed until you reach the point where your design starts to convince you otherwise -- at that point a class or two might bubble up and make a truly convincing case for itself — user2524973
– user2524973, Commented Feb 21, 2016 at 4:18

Trey50Daniel · Accepted Answer · 2016-02-21 04:09:44Z

One thing I see is that you would probably want a separate class for StudentData in which you have the method

public int createStudent(Student s){ //TODO: Implement method here }

The reason that I believe that you should have another class to house the method for createStudent is because that you shouldn't have to instantiate a Student to access the createStudent method. Think of it this way, say I create my class Student

public class Student { public string firstName { get; set; } //rest of class }

When I go to create a Student using the createStudent method inside the class, I would have to say this:

Student s = new Student(); s.createStudent(s);

And that is not really how we want to have to create things, right? That code would be hard to read and understand if you want to keep this updated.

I agree that you'd want to have the ID implemented as a separate class or interface, depending on what you need, and you might want to have a default value for "ID" in the event of an Unknown New Student being created. This way, when you return the ID of the new Student, it's always the same until the user input the new ID for the Student or the next ID was automatically selected. The main thing that I suggest is using a StudentData class to house the createStudent method and house your main function, if you have one. This way, you're using more of an MVC(Model-View-Controller) style of Development, with a Student and their ID as the Model and the View and Controller being handled by the StudentData class. It's just an easy way to structure things once you understand it.

Ok sorry, mu mistake, I'll update the question. The CreateStudent is in another class, StudentLogic. So based on your answer, separating the ID is OK. Let me wait for some more answers, I really want a strong reason on if I am going forward with this.
Okay, I do think having the ID as a separate thing would be okay, but you can also just keep the ID private so that nothing else can alter it. That might be an easier route, depending on what you want to use the id and if it's only an integer value. The only thing you will change if you create the ID as a separate entity, will be that you will have to change the createStudent from public int createStudent(Student s) to public IEntity createStudent(Student s)

Collectives™ on Stack Overflow

Advice on class structure

1 Answer 1

2 Comments

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

2 Comments

Related