macOS Classes

Just import the class definition of one class into the class implementation file of the other.

In that case, yes, Module could inherit from Semester. Or they could both inherit from a common abstract superclass.

I would shy away from inheritance in this case since a module is not a semester.
'Prefer composition over inheritance' is the guiding principle here.

I would instead say that a semester contains modules.
Have instances of modules within your semester instead of having module inherit from semester.

Unless I've not understood clearly, in which case please clarify.

I would think a Module would be the static thing here, and it could be taught in any given Semester.

Therefore, any Semester could have a list of Modules that were taught, or, a Module could have a record of all the Semesters in which it was (or will be) taught.

One would then be an attribute of the other, and there would not be any inheritance.

start_date = module.semester().startdate() would fit the above scenario.

If any Module's start / end dates could override a Semester's start / end dates, you could do inheritance, where the Module inherited from the Semester, but now you are starting to get into some language specific implementation. In Java, Semester could be an abstract class that Module pulled in. This would get you to

start_date = module.startdate()

In C++ or Ruby though, it could be argued either way whether Module could be a subclass of Semester. I wouldn't necessarily go the other way around though.

Todd

Are you using Core Data for this application? As long as you are prepared to make it Tiger/Leopard only that would probably be the best way of managing your different object types.

since we're talking design now...

i don't see any direct relationship between a Module and a Semester. just off the top of my head, i'd start with something like:

- a ClassManager would aggregate Modules

- a SemesterManager would aggregate Semesters

- a SemesterScheduler would maintain a relationship between a Semester and the Modules offered during that semester. it would also schedule when those modules occur. note that there would be some kind of helper class (like ScheduledClass) to track the multiple offerings of that Module.

- a StudentManager would aggregate Students, and also keep track of which students are active for a given Semester. it would also map students to ScheduledClasses. helper classes would resolve conflicts w/in a student's schedule, and ensure classes don't overfill. to get fancy, you could implement waitlists for scheduled classes, w/ some cool student priority logic, and allow students in when either someone drops or another of that module is offered.

- likewise, there'd be a FacultyManager to, among other things, assign faculty to ScheduledClasses.

note that plural classes are actually implemented to be singular (i.e. Student, not Students, ScheduledClass instead of ScheduledClasses).

there are many "right" ways to design this, but even more "wrong" ones. again, i'm not imagining a good design that would maintain a direct relationship between Modules and Semesters.

MacDonaldsd said:

I think core data is the way to go on this though, but im a bit scared about adding custom methods to the Classes dealt with by Core Data, and also what core data is taking care of behind he scenes and more importantly what it isn't.

Click to expand...

OK, have you gone through the tutorial on apple.com?

Personally though while creating D&D Manager with Core Data I haven't needed to use Custom Classes at all. (though I have extended NSManagedObject to allow object duplication, but that is fairly advanced.)