Chcę w ramach ćwiczenia napisać sobie prosty panel administracyjny na podstawie hierarchi szkolnej. Jako, że OOP ledwo co umiem, a bez praktyki nie ma wyników to chcę sobie to przećwiczyć.

Hierarchia szkolna
Dyrektor, nauczyciel, uczeń. Nie bardzo mam pojęcie jak to rozłożyć w klasach wszystko. Myślałem nad czymś takim

klasa abstrakcyjna osoba, klasa dziedzicząca po osoba Dyrektor, Nauczyciel, Uczeń. Każda grupa ma swoje metody. Np Nauczyciel, zmień ocenę. Kolejne klasy to:
Config (polaczenie z bazą przez PDO)- myślałem nad Singletonem.
login (klasa obsługująca logowanie użytkowników)
register- klasa rejestrująca użytkowników

Myslałem nad 4 tabelami w MYSQl- Dyrektor, Nauczyciel, Uczeń, Uprawnienia. Choć podejrzewam, że rozbicie tego nie ma sensu.

Mógłby mi ktoś to nakreślić? no nie potrafię rozłożyć nawet małego projektu w oparciu o klasy, nie wiem co ma być do czego.

Kurcze, przeczytałem Twojego posta i zobaczyłem obraz siebie sprzed lat... ; )

Zastanawiałem się: "Jak się robi te internety?". Rozmyślałem - jak zabrać się do serwisu? Jakiego języka użyć? Jak to wszystko działa? Jak to się robi? Później gdy już nabrałem pojęcia, wtedy zastanawiałem się jak pisać te aplikacje - liznąłem jako tako kilka języków, wiedziałem co to zmienna, jak robi się pętle, wiedzy z czasem przybywało, a pytań ubywało. ; )

Powiem Ci jedno - musisz dużo czytać i dużo eksperymentować.

Zacznij już teraz. Eksperymentuj, napisz swój system i poprawiaj go. Tylko wtedy dowiesz się jakie zmiany są dobre, a jakie złe.

Poczytaj o zdrowych zasadach programowania, tj. Object Oriented Design i Object Oriented Analysis. Tam jest zawarta wiedza której poszukujesz.

I pamiętaj - kod staraj się pisać w taki sposób, aby łatwo można było go zmodyfikować. To jest cel nr 1 programisty. Jedyna stała w programowaniu to "zmiany". Poczytaj o dobrych zasadach "SOLID".

Jeśli przerobisz te tematy, wtedy będziesz wiedział jak podejść do programowania i nie będziesz szukał "złotej odpowiedzi". Po prostu pamiętaj - tutaj chodzi o to, aby Twój kod trzymał się pewnych zasad. Na koniec doda jeszcze znane powiedzenie, że jeśli dasz 10-ciu doświadczonym programistom jakiś problem do rozwiązania, to otrzymasz 10 rozwiązań - i każde z nich będzie inne i porównywalnie dobre... Niech Ci to da do myślenia. ; )

Poczytaj więc o "SOLID", Object Oriented Design i Object Oriented Analysis. Za dużo musielibyśmy Ci tłumaczyć, abyś zrozumiał jak zabierać się do programowania, bo ten temat jest szeroki i głęboki.

Powodzenia w świecie, gdzie nie ma idealnej odpowiedzi - Welcome, young programmer! ; )




Nie, 4 tabele to złe rozwiązanie.

Zrób jedną tabelę "users", tylko niech użytkownicy mają swoje role i uprawnienia (polecam temat ACL).

Dzięki za rozbudowaną odpowiedź. W kwestii wyjaśnienia jeszcze. to nie jest tak, że nie umiem w ogóle programować. Znam na poziomie konsoli c++, delphi. PHP struktualnie jako tako. Zaś OOP to na razie czarna magia. Nic spróbuję sobie to jakoś rozpisac, poczytać i zobaczymy co wyjdzie z tego

Klasa konfiguracji nic nie ma do połączenia z bazą danych - tym powinien zajmować się jakikolwiek Handler/Adapter czy jak to nazwać. Poza tym zamiast Singletona użyj Dependency Injection - po prostu przekaż obiekt PDO do klasy tej i tej.


"login" i "register" to czynności, a klasy powinny być bytami, stąd też złe nazewnictwo dla podanych klas.

Co do samego rozplanowania praw - poczytaj o ACL.

Czyli Logowanie-rejestracja powinny być odpowiednimi metodami w klasie ?

Kurczę ciezko będzie, no , ale myślę, że jak napiszę coś raz źle, to drugi raz będzie lepiej.

Login i Register możesz mieć w klasie np. Auth.

Co do podziału na Uczeń,dyrektor itp. Klasa Pracownik i klasa Uczeń które dziedziczą po Osoba. Pracowników masz kilka rodzajów np. właśnie Dyrektor, Nauczyciel, Sekretarka itp.
Uczniowie w prawdzie jeden rodzaj ale ma odrębne założenia.

J.w Config to Config, z BD nie ma nic wspólnego.
Wiele można by było pisać. Ale pisz i eksperymentuj i czytaj co koledzy wyżej podpowiedzieli. Poczytaj też trochę o wzorcach architektonicznych.