Hej... właśnie poznaję zagadnienie klas i programowania obiektowego.
Nie wszystko jest jeszcze dla mnie jasne, ale oto moje pierwsze dzieło... klasa generująca title i keywords w meta tagach.
Skrytykujcie błędy i dajcie wskazówki, rady jak ją usprawnić.

Nie wiem jak pozbyć się powtórzeń w obu funkcjach... można to zrobić przed funkcjami, tak by zmienne miały charakter globalny?

Z góry, wielkie dzięki, pozdrawiam.

Nie rozumiesz ideii obiektowości. Pomijam fakt stylu pisania gdzie troche dziwnie się to czyta. Do swojego obiektu wstawiasz zapytanie " na sztywno" idea obiektowosci jest tworzenie API które będzie uniwersalne.

edit:

Wiem, że na początku trudno jest zrozumieć obiektowość i pomimo licznych kursów czasami cieżko załapać o co chodzi osobie która pisze strukturalnie. Wyobraź sobie swoja klase która ma generować keyword-y. Prawdziwy obiekt powinien działać tak, że przekazujesz do niego dane czy to z bazy czy pliku a on wykonuje dane zadanie czyli tworzy jakies losowe teksty. W sumie tworzenie keyword-ow to za proste nawet dla klasy ale jak już bardzo chcesz takową napisać to w takiej klasie nie powinno być zapytania do bazy dlaczego ? Ano dlatego ze to klasa która ma generowac keywordy to co zatem robi zapytanie do bazy ? Wyobraz sobie ze chcesz użyc tej klasy w innym projekcie i co wtedy ? Przerabiasz klasa od nowa bo masz jakies zapytanie do bazy. Mija się to z celem dlatego ze wlasnie idea obiektowosci jest elastycznosc. Piszesz klase raz a pozniej wykorzystujesz ja w innych projektach bo dane do klasy przekazujesz przez API.

chyba masz świętą rację cckoles.
Możesz mnie naprowadzić jak to powinno wyglądać, bo za diabła nie mogę tego rozgryźć... - wybacz sztywność, klasy to dla mnie zupełna nowość, ale jestem pojętny

Nie mam pomysłu jak napisać klasę do generowania keywordów bo nie wiem co tam można generować poza tekstem pobranym z bazy ale napisze ci baardzo prosty przykład który może ułatwi ci zrozumienie obiektowowsci.

[PHP] pobierz, plaintext 
<?php
class Meta
{
	public function runGenerator($tekst)
	{
		echo $tekst;
	}
 
 
}
 
$tekst = 'jakis keyword'; // zmienna która zawiera jakies informacje wczesniej pobrane z bazy czy pliku
 
$meta = new Meta();
$meta->runGenerator($tekst); // tworzenie keyworda
?>
[PHP] pobierz, plaintext 

public function runGenerator($tekst) to jest metoda

Klasa oczywiscie jest bez sensu bo nic nie robi ale moze choc troche da ci wyobrazenie jak powinien dzialac obiekt. Taki obiekt jest elestyczny dlatego ze mozesz do niego przekazac dane z bazy, pliku itd.

obiektowośc zostaw na potem, na początek zauważ pewna prawidłowość, przesledźmy taki ciąg myślowy

Używam w zapytaniu $id, pobieram $id z _GET, _GET łyka wszystko z paska adresu ... zatem pozwalam każdemu dowolnie modyfikowac to zapytanie. Dlaczego az tak nie lubię swojej bazy danych ? Pójdę poczytać o walidacji danych wejściowych i funkcji htmlspecialchars

co potem ?

aaa potem używaj obiektowości do woli, najlepiej tam gdzie się przyda a przyda się wszędzie tam gdzie operacje sa potarzalne, gdzie wydaje Ci sie, że lepiej by było gdyby obiekty gadały ze sobą wymieniając się krótkimi komunikatami i przekazywały sobie ujednolicone dane

kilka pojęć
- właściwości: to takie zmienne w obiekcie
- metody: to takie funkcje w obiekcie
- konstruktor: uruchomi sie zawsze gdy tworzysz obiekt danej klasy, dobry do inicjowania właściwości na podstawie parametrów (tak jak wstępna obróbka parametrów funkcji)
- destruktor: dobre do szpanowania przed koleżankami, brzmi poważnie ale na tym etapie wiedzy na niewiele się zda
- getter - metoda pozyskiwania danych z właściwości obiektu, policjant nie ma prawa (w warunkach pokojowych) zabrać Ci prawka, Ty musisz mu je pokazać. Policjant nie robi $kierowca->numer_prawka, policjant robi $kierowca->zapytaj_o_numer_prawka($policjant) a to po to, żeby obiekt $kierowca mógł w swojej metodzie zapytaj_o_numer_prawka($kto) sprawdzić, czy ma odznake i dopiero wtedy podać numer. W ten sposób po uprzednim ustawieniu większości właściwości (danych) jako prywatne sam decydujesz jak i w jakich warunkch obiekt będzie się dzielił danymi z otoczeniem. Wten sposób również możesz ustawić odpowiednio metody dostępowe tak, żeby podawały dane w różnych formatach. Obiekt może mieć właściwość $abonenci przechowujący tablicę a ty sobie napiszesz 4 metody dostepu get_ab_array / get_ab_html_list(ul/ol) / get_ab_str. Które odpowiednio zwracają: tablicę, kod html listy numerowanej lub nie / tablicę w postaci łańcucha z przecinkami, wszystko na podstawie jednej właściwości. itd itd
- setter - metoda zapisu danych do obiektu, koniec z dopisywaniem zabezpieczeń w 5 plikach. Chcesz zapisać trasę i zamiast dawać komus mapę i ołówek, mówisz : nie, ty mów a ja notuję. Nie ustawiasz $mapa->trasa = ... kto wie co tam wyląduje, uruchamiasz metodę $mapa->zapisz_trasę($trasa), co pozwala Ci na sprawdzenie co tam jest zapisywane. Jeżeli dane pochodzą od użytkownika to walidujesz (htmlspecialchars, wyrażenia regularne) dodatkowo mapujesz znane typy danych (strval, intval) i masz pewność, że nie trzymasz złośliwych skryptów i że to co ma byc liczbą zawsze nią będzie

Tips:
- właściwości tablicowe inicjuj pustą tablicą, zagwarantujesz, że jedynym błędem będzie brak danych a nie zły typ danych
- dokumentuj swoje klasy, nawet pusta metoda powinna miec opisane w kilku slowach komentarza co ma robic i jakie dane zwracac, 3 dni później będzie łatwiej wrócić do pracy
- w czasie eksperymentów używaj var_dump do podglądu stanu obiektu
- nie bój się klas pomocniczych, możesz stworzyć grupę funkcji wykonujących operacje z jednej "branży" i trzymać je w jednej klasie a do metod odwoływać się statycznie np. HTMLhelper::array_to_ul($array) gdzie array_to_ul jest metoda klasy HTMLhelper i generuje kod listy z tablicy, HTMLhelper::email_to_link($str) generowanie linka "mailto" itp itd w takim zastosowaniiu obiektowość jest traktowana po macszemu a klasa służy jedynie zwiekszeniu przejrzystości kodu i utrzymania porządku w funkcjach pomocniczych. Po 10tym użyciu będziesz już z marszu widział gdzie są metody helpera i pamiętał co zwracają bez szukania "co ta funkcja właściwie robiła"
- nie dziw się, że obiektowe rozwiązania są często przegadane i mają sporo pozornie zbędnego kodu - ten kod to gwarancja jednolitości, przejrzystości i bezpieczeństwa skryptu
- no i pamiętaj, że nie wszystko musi być obiektowe dopóki nie piszesz kodu Open Source zakładającego współprace z wieloma programistami, lepiej, żeby Twój skrypt był proceduralny ale poprawny niż na siłę obiektowy bez zrozumienia