Az iskola olyan mint egy container, nyilvan ott kell legyenek a megfelelo add/remove/retrieve interfeszek.
Ez stimmel.
Kicsit lejjebb meg studentes plane studentID-s verziok: vegyuk eszre, hoyg a student sokkal inkabb tulajdonsag mint class. a gyerek ugye attol student hogy tagja egy iskolanak.
A Tanulo az ebben az esetben a Ssemély egy specialziált osztálya.
Megvan minden tulajdonsága ami egy Személynek, ezen kívül ilyen apró saját tulajdonságai vannak : Szemeszter, kapcsolat szakirányhoz, Mentorhoz/osztályfőnökhöz, kedvezményekhez, jelentkezésekhez, tantárgyi eredményekhez, stb.
Tehát a Tanuló az Iskolának egy Osztály típusú tulajdonsága lesz.
StudentID, ha van ilyen, magaban a beireatkozas aktusaban keletkezik. (Ahogy uj student is, ha erre kulon objektumot keszitunk.)
Ez teljesen korrekt, az adott Személy Jelentkezőből Tanulóba vált.
Ne felejtsd el, hogy amennyiben adatbázist kezelsz, a program egy Egyed - Osztály megfeleltetéssel működik, és egy Rekord az egy Objektumnak felel meg.
Tehát az adott rekordon elvégzendő műveletek megfelelői meg fognak jelenni az adott Egyedet képviselő Osztály műveletei között.
Kicsit belemélyedtem az oktatással kapcsolatos adatbázis és egyéb témákba - diplomamunkám témája: Távoktatási rendszerterv - és valami hihetlen mennyiségű apróság van amivel foglalkozni kell.
Aműgy meg általánosságban igaz az, hogy ha objektumorientáltan csinálsz egy adatbázis kezelő programot, akkor minden kezelt táblához célszerű egy osztályt létrehozni - leszámítva a kapcsoló táblákat.