Witam. Myślę, że tytuł jest dobry.

Otóż mam pewien problem. Gdy już w końcu uporałem się ze zrozumieniem na czym polegają różnice między klasą, obiektem, metodą, atrybutami pojawił się kolejny problem. Mianowicie, jak projektować klasy dla jakiejś aplikacji? Np. prosty blog. Jakie klasy należy napisać aby ten blog funkcjonował? Wiem, że nie należy pisać wszystkiego w jednym pliku, lepiej stworzyć więcej plików ale kod będzie przejrzysty niż jeden plik z 3 000 liniami kodu. Jednak jak się zabrać do tworzenia takiej aplikacji? Mam edytor UML który domyślnie wspomaga projektowanie struktury tych klas (pewnie posiada więcej możliwości).

Mógłby ktoś pomóc? Mówiąc szczerze oczekuję nie tyle gotowego kodu każdej klasy co opisania jakie klasy są potrzebne i jakie metody - tak abym mógł zrozumieć istotę projektowania a następnie pisania obiektowo.

Jeśli byłby to screenshot z jakiegoś programu UML to byłoby jeszcze lepiej

P.S.
Myślę, że także dotyczy ten temat projektowania aplikacji w innych językach np. Java.

Pozdrawiam i liczę na pomoc

Klasa komentarze:
- dodaj
- usuń
- moderuj
- pokaż

Klasa wpisy
- dodaj
- usuń
- zmień
- wyświetl

Klasa admini/redaktorzy:
- dodaj
- zmień hasło
- usuń
- zaloguj
- wyloguj

Klasa panel:
- łączy pozostałe

Mniej więcej tak. Cała magia polega na wypisaniu sobie zakładanych funkcjonalności, a później napisania klas. Jedna klasa - jedna funkcjonalność. Chyba, że ma wyjść jakaś gigantyczna klasa to lepiej sobie podzielić na mniejsze kawałki.

Pytanie jak przystało na początkującego: klasa panel... jak ma łączyć? Tzn. co ma zawierać ta klasa, jak ma wyglądać? Bo mówiąc szczerze jakoś nie potrafię sobie jej wyobrazić, co ona ma robić... hm?

Pisanie obiektowe to tak naprawdę porządne przemyślenie struktury i zachowania całości. Polega to na tym, że patrzysz na problem jak na film i starasz się znaleźć "aktorów". Każdy z nich ma cechy charakterystyczne i musi grać swoją "rolę". Weźmy przykład proponowanego bloga. Zauważ, że główną role w nim gra Użytkownik. Ma on pewne "prawa". Tak naprawdę można wyszczególnić nawet kilka rodzajów Użytkowników: administrator, piszący, gość. Każdy z nich ma różne uprawnienia ale sa widziani jako odmiana tego samego. Coś takiego nazywa się generalizacją. Znajdziesz to w UML Użytkownik w zależności od tego kim jest ma (lub też nie) określone możliwości. Admin może wszystko, piszący może pisać notatki na okreslony dzień oraz nieco modyfikować swój blog, a gość tylko dodawać komentarze. Dlatego też metody jakimi dysponują to:
Gość - dodaje komentarze, może się zarejestrować lub zalogować
Piszący - to samo co Gość, modyfikuje swój blog, dodaje notki może edytować notki w swoim blogu oraz komentarze napisane przez innych na jego blogu (ale tego akurat mieć nie musi), może się wylogować, zmienić swoje dane
Admin - to samo co Gość i Piszący, może zmieniać komentarze i notki kogokolwiek, może dodawać użytkowników i usuwać lub modyfikować ich dane
Innymi klasami są wpisy i komentarze. Pierwsze są dostępne tylko dla zalogowanych użytkowników, drugie dla ogółu. To co jest istotne to co zawierają i co można oraz Kto może z nimi coś zrobić. Dlatego wpis powinien mieć: datę utworzenia (musimy jakoś podpiąć ją do kalendarza), tekst notki, identyfikator tego, kto ją napisał, unikalny identyfikator. Komentarz w porównaniu do notki jest bogatszy o jedną informację: musi informować jakiej notki tyczy. Obie klasy muszą mieć metody usuwające, jak też umożliwiające dodanie oraz edycję. Powinna także istnieć taka, która umożliwia wyciągnięcie konkretnej lub grupy informacji ze źródła danych (plik czy baza danych). Klasa panel to tak naprawdę klasa widoku. Jeśli nie pozwolisz użytkownikom zalogowanym nic zmieniać to nie potrzebujesz jej. Jeśli pozwolisz na dopasowywanie według ich reguł to tak naprawdę zawiera ona kod szablonu lub jego numer (o ile jakieś udostępniłeś).
Zauważ, że wcale nie dałem do wpisu opcji "moderuj". Dlaczego? Ponieważ to nic innego niż Modyfikuj. Musisz tylko wcześniej sprawdzić czy użytkownik ma odpowiednie prawa do modyfikacji (tylko ten kto napisał notkę lub admini).

Jak widzisz obiektówka to tak naprawdę zdolność przetwarzania realnego świata i jego zależności na model usystematyzowany. Czasem klasy mogą zawierać inne klasy i korzystać z ich metod. Ale to już wszystko kwestia projektu i własnego pomysłu na rozwiązanie problemu oraz to jak my go widzimy. Nie ma bowiem jednolitego rozwiązania. Każdy może widzieć pewne rozwiązania inaczej. Sam nieraz mam z kumplem i szefem burzę mózgów w firmie, bo prezentujemy różne podejścia do tego samego problemu i dopiero zebrawszy kilka pomysłów "do kupy" staramy znaleźć najlepsze rozwiązanie. Czasem lepszy jest mój pomysł, czasem kogoś innego. To już bardziej kwestia doświadczenia. Podam przykład z wczoraj. Aktualnie na etapie przerabiania starego serwisu jesteśmy w firmie i mamy już trochę klas, w tym klasa obiektów, ich kategorii i tagów do obiektu. Jest to tak rozwiązane, że po tym jak szef powiedział: "A da się zrobić to tak, że można dowiedzieć jakie są tagi dla wybranej kategorii w prosty sposób?" wystarczyło mu pokazać diagram klas i powiedzieć: "To banał i jedno proste zapytanie do bazy". Obiektowość jest fajna gdy się rozumie na czym polega. Upychanie wszędzie klas i tworzenie dziwolągów tylko po to, by zrobić coś obiektowo nie zawsze jest sensowne. Nieraz po obcowaniu z projektem dochodzisz do wniosku, że kod działa dobrze, ale 2-3 lub więcej klas jest zbędnych i można je zastąpić jedną, zaś innym razem lepiej rozbić jedną na mniejsze. Potem z doświadczenia będziesz wiedział jakie rozwiązania lepiej się sprawdzają w konkretnych przypadkach.

EDIT: Bym zapomniał... Ja nawet dla bloga nie pisałbym metody dodaj_nowy Zauważ, że dostajesz zawsze dokładnie te same dane co przy edycji. Dlatego metoda dodaj_nowy jest szczególnym przypadkiem edytuj gdy nie podamy Co edytować A jeśli tego nie dostajemy, to znaczy, że to coś, co nie istnieje i dzięki temu wiemy, że do bazy jest nie UPDATE, ale INSERT

Czy spotkaliście się kiedyś z takim rozwiązaniem?

[PHP] pobierz, plaintext 
class News {
 
	      public function __construct($nid) {
		if(isset($_POST['node']) && is_array($_POST['node'])) {
			foreach($_POST['node'] as $key => $value) {
				$this->$key = addslashes($value);
			}
		}
 
		if(isset($nid) && ctype_digit($nid) && $nid > 0 && !isset($_POST['edit'])) {
			$sql = dbquery("SELECT * FROM `node` WHERE `nid` = '".$nid."' ");
			$n = dbobject($sql);
			foreach($n as $key => $value) {
				$this->$key = stripslashes($value);
			}
		}
	}
}
[PHP] pobierz, plaintext 

Czyli przekazując dane z formularza foreach rozbija POSTi zapisuje do bazy, a jeżeli istnieje id pobiera dane do formularza.

Nie do końca to samo, ale wariację tego rozwiązania przeprowadzałem w panelu administratora, który jakiś czas temu popełniłem (w Kohanie). Klasa też była odpowiedzialna za formularz i wywołanie kontrolera standardowo czyli gołe index() było traktowane jak inicjalizacja nowego, czyli pustego de facto. Natomiast wywołanie index(int zmienna) robiło to o czym mówisz, czyli łączyło z bazą i uzupełniało formularz. Żeby nie było to wiem, iż mogłem w kontrolerze w Kohanie napisać metodę nowa w stylu edytuj($zmienna) lub cos w ten deseń i zazwyczaj tak robię, ale wtedy spróbowałem w opisany teraz sposob i też obyło się bez problemów. Przy czym oczywiście reagowałem dodatkowo na obecność zmiennych POST i uruchamiałem w razie tej sytuacji zapis do bazy. Gdy było w wywołaniu pusto to był INSERT, a gdy był parametr to był to UPDATE Tak więc to kwestia podejścia bardziej niż jakiegoś standardu. Ja akurat miałem taki pomysł i go zrealizowałem bez uciekania się do pisania dodatkowych metod w kontrolerze jak robi się zazwyczaj. Ot, taka odskocznia od standardowego podejścia.

EDIT: Napisałem "gołe" wywołanie bo w kontrolerze domyślnie miałem:
i w ciele reagowałem na to co dostawałem jako parametr oraz ewentualny $_POST