Witam. Dopiero wchodzę w programowanie obiektowe i choć oczytałem się już trochę, wiele poradników dostępnych w internecie opisuje obiektowość w sposób teoretyczny nie pokazując jak można go wykorzystać w praktyce dlatego też mam parę pytań, które nie dają mi spokoju.

1. Tworząc klasy powinno się je trzymać w tym samym pliku co całość kodu czy najlepiej jest utworzyć nowy plik zawierający tylko klasy, a następnie je includować w plikach w których będziemy z tych klas korzystać?
2. Jeśli utworzymy klasę to tworzenie do niej obiektów za pomocą np. formularzy jest proste (przynajmniej teoretycznie) natomiast jak zapisywać obiekty do bazy danych? zapisujemy samą nazwę obiektu czy należy zapisać nazwę wraz ze wszystkimi właściwościami tego obiektu? Np. mamy klasę o nazwie prostokąt. Właściwościami będzie bok_a i bok_b. Tworzymy nowy obiekt o nazwie pierwszy_prostokat i nadajemy mu właściwości bok_a=5 i bok_b=10 jak powinien wyglądać rekord gdy zapiszemy ten obiekt do bazy? bo mi przychodzą do głowy taki zapis:

id. || nazwa || bok_a || bok_b
1 || pierwszy_prostokat || 5 || 10

3. Czy nawet w przypadku prostych skryptów warto używać obiektowości? Dajmy na to tworząc księgę gości to ilość kodu niezależnie czy użyjemy kodu strukturalnego czy obiektowego jest niemal taka sama. Jeśli chodzi o czytelność jest też podobnie bo skrypt ogólnie jest prosty. Sposób zapisywania do bazy jest identyczny zmienia się co najwyżej struktura tabeli. Więc nasuwa się pytanie - jak pisać?

Na początek dobra rada jeżeli chodzi o sam proces nauki obiektówki i, w sumie, nauki czegokolwiek - zobaczyć jak to robią inni. Poszukaj jakiś prostych CMS-ów, sklepów itp. napisanych obiektowo i zobacz jak robią to inni.

Jeżeli chodzi o pytania:
1. Najczęstszym modelem jest trzymanie każdej, nawet małej, klasy w oddzielnym pliku.
2. Użyte przez Ciebie pojęcie 'zapisu obiektu do bazy' jest troche mylące, bo zapisujesz tylko jego, i to niektóre, właściwości (w tym przypadku boki). Najlepiej zobrazuje to przykład:

[PHP] pobierz, plaintext 
class Prostokat{
      private bokA;   
      private bokB;
      private nazwa;
 
      public function __construct(a,b,nazwa){
             $this->setBokA(a);
             $this->setBokB(b);
             $this->setNazwa(nazwa);
      }
 
      public function setBokA(a){
             $this->bokA = a;
      }
 
 
      public function setBokB(b){
             $this->bokB = b;
      }
 
 
      public function setNazwa(nazwa){
             $this->nazwa = nazwa;
      }
 
      public function getBokA(){
             return $this->bokA;
      }
 
 
      public function getBokB(b){
             return $this->bokB;;
      }
 
 
      public function getNazwa(){
             return $this->nazwa;
      }
 
      //save zapisuje nam wlasciwosci do bazy
      public save(){
            //zalozmy, ze masz juz polaczenie, wiec tworzysz zapytanie ktore moze wygladac tak:
            $query = "INSERT INTO prostokaty ( nazwa, bok_a, bok_b ) VALUES ($this->nazwa, $this->bokA, $this->bokB)";
            mysql_query($query);
      }
       //load wczyta nam wlasciwosci z bazy, wystarczy podac id wpisu
       public load($id){
           //
            $query = "SELECT  nazwa, bok_a, bok_b FROM prostokaty WHERE id=$id";
            $result = mysql_query($query);
            //itd. 
       }
 
}
[PHP] pobierz, plaintext 

3. Na łatwych skryptach można łatwo przećwiczyć sobie pewne mechanizmy obiektowości jak np. dziedziczenie czy polimorfizm. Osobiście staram sie wszystko pisac obiektowo, ze wzgledu na to, że pozniej
łatwiej jest taki obiekt wykorzystać w innych projektach.

Szukałem skryptów napisanych obiektowo ale na ogół natrafiałem na skomplikowane ogromne skrypty, których samo przeanalizowanie było gorsze niż nauka obiektowości Najbardziej w przykładzie, który napisałeś zainteresował mnie sposób zapisu i odczytu z bazy bo zrobiłeś z tego metody o czym ja raczej bym nie pomyślał. Sposób ten jest o tyle dobry, że bardzo prosto się odczytuje obiekt z bazy. Co do praktyki używania obiektowości nawet w prostych skryptach to masz racje, jest to dobry sposób na potrenowanie tak czy inaczej dzięki wielkie, nie oczekiwałem tak konkretnej odpowiedzi

To ja się podepnę: Do czego można wykorzystać konstruktor? Jak i kiedy z niego korzystać?

Programowanie obiektowe pojawiło się, ponieważ jest bardziej naturalnym przełożeniem rzeczywistości na kod. Dla mnie używanie kodu obiektowego jest pewnego rodzaju dojrzałością programistyczną, chociaż używanie go wszędzie też nie jest rozsądne. Trzeba samemu wiedzieć co i kiedy jest właściwe.

Ja osobiście lubię tworzyć dużo metod tak, by używanie kodu było potem jak najbardziej intuicyjne i wygodne. Przykładowo:

[PHP] pobierz, plaintext 
$article = new Article(12); // w konstruktorach robię pobieranie ID i wczytywanie danych z bazy do pól obiektu
echo $article->getAuthor()->getFullName();
if($article->getAuthor()->isAdmin()) {
   echo 'Autor jest administratorem!';
}
while($news = $article->getAuthor()->getNews()) {
   echo $news->getTitle();
   echo '<br>';
   echo $news->getDate()->getYear();
}
[PHP] pobierz, plaintext 

Napisałem ten kod teraz, naprawdę nigdy tego konkretnego fragmentu nie użyłem. Chodzi o to jak pisać kod, żeby było można wykonywać równie wygodne operacje. Wszystko może być obiektem (u mnie np. daty to obiekty, bo potem bardzo fajnie się na nich operuje).

Nie wyobrażam sobie pisania dużych systemów strukturalnie. OK, samo pisanie sobie wyobrażam, ale potem rozwijanie kodu to masakra.

Croc co prawda nie napisałem jeszcze żadnego praktycznego kodu z użyciem obiektowości bo tak jak pisałem dopiero staram się go dobrze zrozumieć ale zgodzę się, że rozbudowywanie kodu strukturalnego to koszmar tym bardziej, że kod strukturalny miejscami jest bardziej zawiły niż obiektowy, a przynajmniej tak mi się wydaje.

Strukturalny faktycznie strasznie się edytuję. Sam zmieniałem ostatnio strukturę wyświetlania mojego "małego portalu" php i to była masakra. Muszę przejść na obiektowy styl pisania kodu - ktoś poleci jakieś książki traktujące o średnio-zaawansowanym php i pisanie obiektowym?

Lepsze są tutoriale. Zacznij od tutoriala o samej idei OOP nawet jeśli wydaje ci się, że ją znasz.

Co do zawiłości: nie uważam, by kod obiektowy był zawiły. Jest go dużo, ale dobrze napisany jest niesamowicie schludny i poukładany. Pamiętam dzień, kiedy przekonałem się do OOP w PHP - od tego czasu każdy projekt to dla mnie 90% mniej nerwów i irytacji. Pisząc kod, płyniesz. Masz ten komfort, że kod w klasach można [przeważnie] poprawić bez ingerencji w schematy użycia tych klas. A to genialne, bo cały bajzel pojawia się zwykle w strukturach. Dla mnie najlepszą nauką OOP była nauka Javy, chociaż kompilowane aplikacje OOP pisze się nieco inaczej niż interpretowane.

Tutki? Pewnie najlepszy ten z manuala , coś polecasz? Ale i tak jakaś książka mi się przyda, bo chciałbym ruszyć do przodu z php. Zobaczę, może uda mi się mój portal przerobić na wersję obiektową i ciekawe, czy naprawdę będzie to lepiej się prezentować niż obecna wersja. Na razie za każdym razem jak spojrzę na te strzałki "->" to padam.

Kiedyś kochałem czytać książki programistyczne, ale mam o nich coraz gorsze zdanie. Szalę goryczy przelała książka autorstwa samego ojca PHP pt. "PHP5. Programowanie". Byłem w szoku, że sam autor PHP utrwala złe nawyki (np. używanie funkcji empty dla stringów, co uważam za zły nawyk), niekonsekwencję w kodzie i bezsensowne podrozdziały kosztem takich, których brakuje w książce.

A zachwycając się dalej programowaniem obiektowym, to te strzałeczki również polubisz (chociaż Bóg jeden wie dlaczego w PHP nie są to kropki) Kod daje frajdę, bo myślisz o wielu rzeczach jak o żywych obiektach, dzięki czemu zachowujesz konsekwencję. Oczywiście, strukturalnie mógłbyś robić do wszystkiego funkcje, ale to nie to samo.

Czemu strzałeczki, a nie kropki? Może są to wskaźniki na pola, a nie same pola bezpośrednio. Albo zrobiono tak by nie przeciążać już używanego operatora konkatenacji.
$obiekt.pole
$obiekt.$pole
Różnica niewielka, ale trzeba by rozpoznawać po stronie interpretera z czym mamy do czynienia. Łatwiej wprowadzić -> , który jest bardziej jednoznaczny i wiąże się w pewien sposób z obiektami jako odniesienie przez wskaźnik typowe dla choćby takich języków jak C++.

EDIT: Patrząc na zapisy oba popatrz też jak łatwo się pomylić Po prostu brak dolara w jednym miejscu.

Tak samo jak: czemu kropki a nie znak plusa?

[PHP] pobierz, plaintext 
$string = "wyszukiwarka " . "google";
[PHP] pobierz, plaintext 

Mam zamiar dzisiaj napisać pierwszy skrypt za pomocą obiektowości. Żeby było łatwo ale praktycznie padło na księgę gości. Zanim jednak zacznę chciał bym zapytać was czy dobrze ją sobie zaplanowałem, a więc.

1. klasa nazywała by się ksiega
2. właściwości: data, imie, email, strona, numer gg, komentarz
3. metody: zapis(do bazy), wczytaj(z bazy), set(ustawienie wartości dla właściwości)

I tutaj mam jeszcze dwa pytanka. tmka Ty jako pierwszą metodę utworzyłem z konstruktorem dlaczego? i czy ona jest wymagana? W Twoim kodzie ustawianie wartości dla właściwości jest w nowej metodzie np:

Moje pytanie to czy nie lepiej było by w jednej metodzie zawrzeć wszystkie właściwości czyli coś takiego:

Czy jest coś jeszcze o czym powinienem pamiętać przy pisaniu tego skryptu?

No nie jest to takie proste jeśli dorzucimy do tego fakt, że można zastosować coś takiego jak metoda __toString() w obiekcie lub nazwę funkcji jako wartość zmiennej .

Red9skull, konstruktor można wykorzystać na wiele sposobów, na przykład:

[PHP] pobierz, plaintext 
 
class article
{
  private $title, $content, $id;
 
  public function __construct($id = null)
  {
    $this->id = $id;
 
    if (!is_null($id))
    {
      $query = "SELECT * FROM articles WHERE 'id' = $id LIMIT 1";
 
      $result = mysql_query($query);
      //pominę fetch etc...
 
      $this->title = $result['title'];
      $this->content = $result['content'];
    }
  }
 
  public function setTitle($title)
  {
     //parę postów wyżej było
  }
 
  public function setContent($content)
  {
     //parę postów wyżej było
  }
 
  public function save()
  {
     if (!is_null($this->id))
       $query = "UPDATE (et cetera)";
     else
       $query = "INSERT (et cetera";
 
     //parę postów wyżej było
  }
}
 
[PHP] pobierz, plaintext 

Teraz pytanie z mojej strony, raczej z czystej ciekawości bardziej niż z potrzeby odpowiedzi:
Do czego najczęściej używacie destruktorów?

Odpowiedź równe prosta - zwalniania zasobów przydzielonych konstruktorem. Dla wielu wyda się to dziwne, skoro istnieje Garbage Collector.Tu jest jednak pułapka. Wielokrotnie zachodzą sytuacje gdy pewne obiekty zawierają inne obiekty a te z kolei inne obiekty prowadzące do kolejnych. GC potrafi się w takich sytuacjach "wywalić" i zostawić w pamięci śmieci. Po prostu może czegoś nie zgarnąć do usunięcia. Taki zombie... Nie żyje, a jednak jest O ile w PHP nie jest to łatwo zauważalne, tak w językach kompilowanych potrafi napsuć krwi. Szczególnie ważne jest to w dynamicznym przydziale pamięci. Jeśli pole jest tylko wskaźnikiem (adresem elementu) na obszar pamięci, to jego skasowanie powoduje nie usunięcie całej danej z pamięci, ale tylko utratę wskaźnika, bez dotykania tych danych. Jeśli obiekt jest tymczasowym tylko w pętli, to z każdym jej przebiegiem z pamięci ucieka nam obszar równy jej długości. Kilkadziesiąt tysięcy cykli i nagle program zająć może kilkadziesiąt MB, choć używa tak naprawdę kilkuset kilobajtów. Destruktory właśnie odpowiadać mają za zwalnianie pamięci w odwrotnej kolejności niż przydzielał ją konstruktor by uniknąć wycieków. To jest jego główne zadane, ale nie tylko. Często stosuje się parę konstruktor-destruktor do działania na zmiennych statycznych. Takim banalnym przykładem jest licznik obiektów. Konstruktor inkrementuje zmienną statyczną mającą być licznikiem obiektów. Bo przecież do takiej mają dostęp wszystkie obiekty tej samej klasy. Destruktor tę zmienną dekrementuje. Dzięki temu patrząc na zmienną statyczną, wiemy w każdej chwili ile instancji danej klasy siedzi w pamięci.

Muszę się szczerze przyznać że nowością jest dla mnie fakt że PHP może nie radzić sobie ze zwalnianiem zasobów. Nigdy, na swoim przypadku, nie zaobserwowałem czegoś takiego i nigdy też nie stosowałem samodzielnego zwalniania zasobów w destruktorach (bo rozumiem że mówisz o samodzielnym zwalnianiu). Czy mógłbyś podrzucić jakiś przykład takiego zwalniania?

Wystarczy użyć zwykłego unset.

Jak wspomniał Crozin - unset. Co do destruktora to wiele osób odpuszcza sobie pisanie go w przypadku mało skomplikowanych klas. Zazwyczaj bowiem domyślne destruktory bezproblemowo radzą sobie z usuwaniem. Jeśli struktura jest zagmatwana lub niszczenie obiektu powinno zakończyć się określonymi działaniami, to własny destruktor po prostu ratuje tyłek. Nieważne bowiem jak kończy żywot obiekt - destruktor zostanie wywołany i wykona zadaną akcję, przykładowo zapis stanu obiektu do bazy lub pliku w momencie zniszczenia.

Pisałem, pisałem, aż stanąłem w miejscu Niby bez błędu a jednak przesyłane wartości nie trafiają do bazy. Mam dwa pliki. Jeden z klasą, drugi z formularze do dodawania wpisów w prostej księdze gości. Przypominam, że to mój pierwszy skrypt z zastosowaniem obiektowości. Mógł by ktoś zerknąć na moje wypociny i sprawdzić czemu to nie działa?

[PHP] pobierz, plaintext 
<?php
 
class ksiega {
 
	private $_data = null;
	private $_godzina = null;
	private $_imie = null;
	private $_email = null;
	private $_strona = null;
	private $_gg = null;
	private $_wpis = null;
 
	public function ustaw_wartosci($data, $godzina, $imie, $email, $strona, $gg, $wpis) {
 
		$this->_data = $data;
		$this->_godzina = $godzina;
		$this->_imie = $imie;
		$this->_email = $email;
		$this->_strona = $strona;
		$this->_gg = $gg;
		$this->_wpis = $wpis;
	}
 
	public function pokaz() {
 
		return $this->_data.'\n';
		return $this->_godzina.'\n';
		return $this->_imie.'\n';
		return $this->_email.'\n';
		return $this->_strona.'\n';
		return $this->_gg.'\n';
		return $this->_wpis.'\n';
	}
 
	public function save() {
 
		include('dane.php');
		$sql = mysql_connect(SQL_HOST, SQL_USER, SQL_PASS) or
		die("Sprawdź połączenie z serwerem! " . mysql_error());
 
		mysql_select_db(SQL_DB, $sql) or
		die("Sprawdź bazę! " . mysql_error());
 
		$insert = "INSERT INTO wpisy (data, godzina, imie, email, strona, gg, wpis)
		VALUES ('$this->data', '$this->godzina', '$this->imie', '$this->email', '$this->strona', '$this->gg', '$this->wpis')";
		$result = mysql_query($insert) or
		die('Dodanie wpisu nie powiodło się. ' . mysql_error());
	}
 
	public function load_one($id) {
 
		$select = "SELECT * FROM wpisy WHERE id=$id";
		$result = mysql_query($select) or
		die('Załadowanie wpisu z bazy nie powiodło się. ' . mysql_error());
		}
 
	public function load_all() {
 
		$select = "SELECT * FROM wpisy ORDER BY id DESC ";
		$result = mysql_query($select) or
		die('Załadowanie wpisów z bazy nie powiodło się. ' . mysql_error());
	}
}
 
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<html>
<head>
</head>
<body>
 
<?php
 
if(isset($_POST['submit'])) {
 
	include('class/wpis.php');
 
	$data = date("d-m-Y");
	$godzina = date("G:i");	
	$imie = $_POST['imie'];
	$email = $_POST['email'];
	$strona = $_POST['strona'];
	$gg = $_POST['gg'];
	$wpis = $_POST['wpis'];
 
	$nowy = new ksiega;
	$nowy->ustaw_wartosci($data, $godzina, $imie, $email, $strona, $gg, $wpis);
	$nowy->save();
 
	echo 'Dziękuję za dodanie wpisu do księgi gości.';
	exit();
}
 
?>
 
Aby dodać wpis do księgi wypełnij formularz.
<br /><br />
 
<form method="post">
	Autor: <input type="text" name="imie" size="25"><br />
	Email: <input type="text" name="email" size="25"><br />
	Strona www: <input type="text" name="strona" size="25"><br />
	Numer gg: <input type="text" name="gg" size="25"><br />
	Komentarz: <textarea style="width: 250px; height: 150px;" name="wpis"></textarea><br />
	<input type="submit" name="submit" value="Dodaj">
</form>
 
</body>
</html>
[PHP] pobierz, plaintext 

Po pierwsze - użyj właściwego bbcode (nie wal do znacznika code, ale php i na przyszłość odpowiednio css, html czy inne). Poza tym nie wiemy jaki bład Ci sypie, a to też ważna informacja. Ja obstawiam, że funkcja save i błąd zapytania wpisującego do bazy. Ale to tylko przypuszczenie z mojej strony.

[PHP] pobierz, plaintext 
class ksiega {
 
    private $_data = null;
    private $_godzina = null;
    private $_imie = null;
    private $_email = null;
    private $_strona = null;
    private $_gg = null;
    private $_wpis = null;
 
    //...
}
[PHP] pobierz, plaintext 

Zastanowiłbym się nad sensownością powyższego kodu. Czy obiekt klasy ksiega faktycznie posiada takie elementy jak data, godzina itd.? Moim zdaniem nie, księga gości jest kolekcją wpisów, czyli powyższe składowe powinny być raczej w klasie wpis, a klasa ksiega powinna mieć jakąś składową typu tablicowego, w której byłyby obiekty wpisów. Wydaje mi się to sensowniejsze.

Oczywiście pod warunkiem że zakładamy na jednej stronie więcej niż jedną księgę .
Zagiewa -> zrób następująco a potem obejrzyj zapytanie ew. wklej je do phpmyadmina:

[PHP] pobierz, plaintext 
// (...)
public function save() {
 
        include('dane.php');
        $sql = mysql_connect(SQL_HOST, SQL_USER, SQL_PASS) or
        die("Sprawdź połączenie z serwerem! " . mysql_error());
 
        mysql_select_db(SQL_DB, $sql) or
        die("Sprawdź bazę! " . mysql_error());
 
        $insert = "INSERT INTO wpisy (data, godzina, imie, email, strona, gg, wpis)
        VALUES ('$this->data', '$this->godzina', '$this->imie', '$this->email', '$this->strona', '$this->gg', '$this->wpis')";
        echo '<pre>';
        echo $insert;
        echo '</pre>';
        exit;
        //POWYŻSZE 4 LINIE!
        $result = mysql_query($insert) or
        die('Dodanie wpisu nie powiodło się. ' . mysql_error());
    }
// (...)
[PHP] pobierz, plaintext 

Koniecznie pamiętaj jeszcze o mysql_real_escape_string() żeby zabezpieczyć swój skrypt przed atakiem Sql Injection, inaczej każdy bardziej rozgarnięty szesnastolatek zrobi z Twoją bazą danych wszystko co będzie chciał.

Dzięki za przydatne odpowiedzi dotyczące unsetów . W sumie dawno nie robiłem w "czystym" phpie, ostatnio się babram głównie w symfony ale wracam teraz do samego phpa i piszę coś w rodzaju frameworka/silnika i to mi się z całą pewnością przyda.

Chyba nie do końca wiesz o czym piszesz.

thek sorki za te bbcode - już poprawiłem.
phpion mniej więcej rozumiem o co Ci chodzi ale nie był bym w stanie czegoś takiego zrobić haha jak sam widzisz jest to mój pierwszy taki skrypt (miał być prosty) i już są problemy Pytasz czy obiekt posiada takie elementy jak data i czas, tworząc tą klasę uznałem, że tak bo w momencie dodawania wpisu tworzony jest obiekt, do zmiennej jest zapisywany czas i data dodania a cały obiekt z tymi dwiema wartościami trafia do bazy jak dla mnie to ma sens.
Mikz Zrobiłem tak jak mówiłeś i oto co wypluła przeglądarka:

ok wiem, że brak wartości ale czemu? przecież przesyłam wartości, a przynajmniej tak mi się wydaje. Co do funkcji, którą mi podałeś przed atakami SQL Injection to dzięki, później sobie ją przerobie:)
Dobra, poradziłem sobie z tym. Dzięki Mikz za naprowadzenie. Wystarczyło w metodzie save() dodać podkreślenia _ przed zmiennymi/referencjami (tak to właściwie nazwać?) a wygląda to tak:

[PHP] pobierz, plaintext 
public function save() {
 
		include('dane.php');
		$sql = mysql_connect(SQL_HOST, SQL_USER, SQL_PASS) or
		die("Sprawdź połączenie z serwerem! " . mysql_error());
 
		mysql_select_db(SQL_DB, $sql) or
		die("Sprawdź bazę! " . mysql_error());
 
		$insert = "INSERT INTO wpisy (data, godzina, imie, email, strona, gg, wpis)
		VALUES ('$this->_data', '$this->_godzina', '$this->_imie', '$this->_email', '$this->_strona', '$this->_gg', '$this->_wpis')";
 
		$result = mysql_query($insert) or
		die('Dodanie wpisu nie powiodło się. ' . mysql_error());
	}
[PHP] pobierz, plaintext 

Mam jeszcze takie pytanie. Czy w moim kodzie metoda ustaw_wartości działa poprawnie? Wydaje mi się, że tak bo gdy by metoda ta nie ustawiła wartości to metoda save nie mogła by zapisać wartości do bazy mam rację?

Ok, ale odpowiedz sobie na pytanie: co dodajesz do bazy? Księgę czy wpis? Sam zresztą napisałeś:

Jak widzisz dodajesz obiekt wpisu, a nie księgi. Księga zawiera w sobie wpisy (obiekty wcześniej dodanych wpisów). Piszesz o umiejętnościach, że się uczysz: w takim razie od razu ucz się dobrego podejścia, a nie pseudo-obiektowego.

No tak dodaję wpis, więc według Ciebie powinna być klasa o nazwie baza a jej wartościami klasa o nazwie wpis i co jeszcze? jak poprawnie powinno to wyglądać? Tworząc moją klasę wydawało mi się, że dobrze ją zaplanowałem, a obecnie jak wspomniałeś o dwóch klasach, nie mam pojęcia jak one miały by wyglądać aby były poprawne.

To powinno Ci nieco rozjaśnić sytuację:

[PHP] pobierz, plaintext 
class Wpis {
	protected $data;
	protected $tresc;
 
	public function dodaj() {
		// Zapis do bazy danych
	}
}
 
class Ksiega {
	protected $wpisy = array();
 
	public function pobierz_wpisy() {
		// Zapytanie do bazy
 
		foreach ($wpisy_z_bazy as $wpis_jako_tablica) {
			$wpis = new Wpis($wpis_jako_tablica['data'], $wpis_jako_tablica['tresc']);
 
			$this->wpisy[] = $wpis;
		}
	}
 
	public function dodaj_wpis(Wpis $wpis) {
		$wpis->dodaj();
	}
}
[PHP] pobierz, plaintext 

Zagiewa... Popatrz na to tak jak phpion czy ja. Najbardziej elementarny jest wpis i to on zawiera wszystkie wymienione pola. Nazwijmy więc klasę tak, jak naprawdę ona się przedstawia - Wpis. Dopiero wpisy tworzą pewien zbiór, kolekcję, którą nazywamy księgą wpisów. Skoro tak, to klasa Ksiega_wpisow może być implementowana jako tablica obiektów typu Wpis. Jak to by wyglądało w kodzie? tak naprawdę to tylko tak, że jedyną potrzebną klasą byłby Wpis a księga to byłaby zwyczajna tablica i przez to naturalne byłoby działanie w stylu.
$ksiega_wpisow[] = new Wpis;
Można tworzyć dodatkową klasę, która by się zajmowała szerszą grupą wpisów, ale bazowo tak naprawdę potrzeba Ci:
klasa Wpis
Pola: imie, email, strona, gg, wpis, dodano (pole w bazie z ustawionym CURRENT_TIMESTAMP)
Metody: dodaj, edytuj (tak naprawdę dodaj i edytuj można ująć jedną metoda wykorzystując ON DUPLICATE UPDATE), usun, pokaz(zwraca pojedynczy wpis)

Klasa Księga tak naprawdę nie byłaby czymś innym niż:
klasa Ksiega
Pola: lista_wpisow (zwykła tablica przechowująca obiekty klasy Wpis)
Metody: pokaz(zwraca listę iluś wpisów według określonego wzorca wyszukiwania), ewentualne kombinowanie z dodaniem, edycją lub usuwaniem wielu na raz to tak naprawdę to samo co posiada klasa wpis. Duplikowalibyśmy więc metody klasy Wpis lub w skrócie moglibyśmy napisać je jako wywołanie metody obiektu Wpis wielokrotnie.

Zrozumiałem że proponujesz żeby księga była obiektem. Ja bym raczej skłaniał się ku utworzeniu klasy z polami i metodami statycznymi. Wtedy struktura tworzy nam się całkiem sensowna, mamy zbiór metod które zarządzają wszystkimi wpisami, które, tak jak zaproponowałeś, znajdują się w tablicy. Chyba że mówiłeś o czym innym, wtedy zwracam honor.

Edit: Zresztą Twój następny post potwierdza moje przypuszczenie, przy utworzeniu klasy ze statycznymi metodami nie ma potrzeby tworzyć nowej instancji obiektu Ksiega, tylko odwołujemy się tak:

Ksiega::pobierz_wpisy();

lub

Ksiega::dodaj_wpis($wpis);

Więc jeżeli nie mamy na stronie więcej niż jednej księgi lub nie tworzymy jakiejś złożonej biblioteki, wydaje mi się że takie rozwiązanie jest lepsze.

Witam,
ja jeszcze wtrącę się na temat twojego kodu Zagiewa. Pytałeś się czemu u siebie użyłem oddzielnych metod ustawiających i pobierających (setterów i getterów potocznie mówiąc) dla każdego z pól. Dzięki takiemu rozwiązaniu możesz np. zwalidować przesłane dane zanim je zapiszesz do pola obiektu. Oczywiście, możesz to również zrobić w metodzie takiej jak twoja, ale jeżeli pól będzie dużo, to metoda rozrośnie się i będzie mało elegancka. Dodatkowo, gdy zechcesz rozbudować obiekt o dodatkowe pola, bedziesz musiał modyfikować tą metodę, a w obiektówce takie działanie jest niepożądane, bo np. mogłeś już użyć tej metody w wielu miejscach i przy zmianie ilości argumentów będzie trzeba albo poustawiać je w deklaracji metody na jakieś domyślne wartości, albo poprostu modyfikować każde wywołanie. Bardziej eleganckim sposobem jest właśnie zrobienie getterów i setterów, nawet jeżeli pol jest niewiele, poprostu dobrze już mieć taki nawyk.

Jeszcze podam takie małe 'ułatwienie' w pisaniu setterow. Otóż w php można zrobić coś takiego:

[PHP] pobierz, plaintext 
public setDzien($dzien)
{
     $this->_dzien = $dzien;
     return $this;  //zwracamy instancje do 'siebie', 
}
 
public setMiesiac($mies)
{
     $this->_mies= $mies;
     return $this;  //zwracamy instancje do 'siebie', 
}
 
//normalnie ustawienie wyglądałoby tak:
$data = new Data();
$data->setDzien(12);
$data->setMiesiac(4);
 
//przy konstrukcji metod ustawiających które zwracaja instancje do swojego obiektu
//bedzie wygladac to tak:
$data->setDzien(12)->setMiesiac(4);
 
 
[PHP] pobierz, plaintext 

Może dodam jeszcze słowo wyjaśnienia. Gdy wywolasz któregoś z setterów, zostanie zwrócony obiekt dla którego ta metoda została wywołana, następnie możesz 'w locie' wywołać kolejną metode tego obiektu itd. wystarczy zeby metoda zwracala obiekt do ktorego należy, czyli poprostu $this.

Wiem, że już trochę minęło od dnia kiedy założyłem ten temat ale nie miałem czasu Przerobiłem moją klasę według waszych wskazówek i na chwile obecną wygląda ona tak:

[PHP] pobierz, plaintext 
<?php
 
class wpis {
 
	private $_data = null;
	private $_godzina = null;
	private $_imie = null;
	private $_email = null;
	private $_strona = null;
	private $_gg = null;
	private $_wpis = null;
 
	public function ustaw_wartosci($data, $godzina, $imie, $email, $strona, $gg, $wpis) {
 
		$this->_data = $data;
		$this->_godzina = $godzina;
		$this->_imie = $imie;
		$this->_email = $email;
		$this->_strona = $strona;
		$this->_gg = $gg;
		$this->_wpis = $wpis;
	}
 
	public function save() {
 
		include('dane.php');
		$sql = mysql_connect(SQL_HOST, SQL_USER, SQL_PASS) or
		die("Sprawdź połączenie z serwerem! " . mysql_error());
 
		mysql_select_db(SQL_DB, $sql) or
		die("Sprawdź bazę! " . mysql_error());
 
		$insert = "INSERT INTO wpisy (data, godzina, imie, email, strona, gg, wpis)
		VALUES ('$this->_data', '$this->_godzina', '$this->_imie', '$this->_email', '$this->_strona', '$this->_gg', '$this->_wpis')";
 
		$result = mysql_query($insert) or
		die('Dodanie wpisu nie powiodło się. ' . mysql_error());
	}
}
 
class ksiega {
 
	protected $wpisy = array();
 
	public function pokaz() {
 
		return $this->_data.'\n';
		return $this->_godzina.'\n';
		return $this->_imie.'\n';
		return $this->_email.'\n';
		return $this->_strona.'\n';
		return $this->_gg.'\n';
		return $this->_wpis.'\n';
	}
 
	public function load_all() {
 
		include('dane.php');
		$sql = mysql_connect(SQL_HOST, SQL_USER, SQL_PASS) or
		die("Sprawdź połączenie z serwerem! " . mysql_error());
 
		mysql_select_db(SQL_DB, $sql) or
		die("Sprawdź bazę! " . mysql_error());
 
		$select = "SELECT * FROM wpisy ORDER BY id DESC ";
		$result = mysql_query($select) or
		die('Załadowanie wpisów z bazy nie powiodło się. ' . mysql_error());
	}
}
?>
[PHP] pobierz, plaintext 

Jestem wręcz pewien, że można to zrobić lepiej niż obecnie to wygląda więc prosił bym o dalsze wskazówki jak to polepszyć.

Zainteresuj się wzorcem GenericObject oraz GenericObjectCollection i znajdziesz odpowiedź na swoje pytanie. Przy okazji wzorzec fabryki do wykorzystania różnych silników baz danych, słowa kluczowe to: GenericObject, GenericObjectCollection, DatabaseConnection, DatatabaseQuery, DatabaseTransaction, ExceptionFactory

1) Metody z serii "ustawi 123123123 wartości na raz" są bez sensu.
2) Nie da się na raz zwrócić 10 wartości (ksiega::pokaz())
3) Nie uważasz za bezsensowne każdorazowe łączenie się z bazą danych w metodach save()?
4) Data/godzina - do tego nie potrzeba dwóch zmiennych - jedna jest w pełni wystarczająca

Swoją drogą to najlepiej te wszystkie zawiłości opanujesz ucząc się innego języka niż PHP (np. C++). Później nauka większości języków oprogramowania jest bardziej sprawna. Co do twojej klasy to od razu da się zastosować tutaj dziedziczenie np. z ArrayObject PHP (do klasy Księga - de facto jest to kolekcja wpisów, ArrayObject fajnie nadaje się do tworzenia kolekcji) czyli łopatologicznie:

[PHP] pobierz, plaintext 
<?php
 
// Deklaracja klas, dobrym zwyczajem jest umieszczanie każdej klasy w oddzielnym pliku, 
// ja robię tak że jeśli są powiązane i małe to wrzucam je do jednego (np. klasa Ksiega z klasą wpis, klasa MyPDO z klasą SqlObject itd.)
 
class MyPDO extends PDO { //dopisujemy parę funkcji do bazodanowej klasy PDO
	public function insert(SqlObject $insert) {
	   return parent::prepare($insert->insertSqlCode());
	}
 
	public function remove(SqlObject $remove) {
	   return parent::prepare($remove->removeSqlCode());
	}
}
 
abstract class SqlObject { //abstract oznacza że klasa nie może być samodzielnym obiektem, służy jako szablon po którym mogą dziedziczyć inne klasy
	public $table_name = get_class($this); // domyślnie nazwa klasy jest nazwą tabeli, pokraczne rozwiązanie ale nie chce mi się mysleć
 
	public function insertSqlCode() {
		$data = $this->prepareData();
		$insert = "INSERT INTO ".$this->table_name." (".implode(',',array_keys($data)).") VALUES (".implode(',',$data).")";
		return $insert;
	}
 
	public function removeSqlCode() {
		$data = $this->prepareData();
		$remove = "DELETE FROM ".$this->table_name." WHERE ";
 
		// normalnie przefiltrowalibysmy rekordy do usunięcia po kluczu ale klasa Wpis takowego nie ma, filtrujemy wiec po wszystkich polach (naprawde pokraczne)
		$filters = array();
		foreach($data as $name=>$value) {
			$filters[] = $this->table_name.".".$name."='".$value."'";
		}
		$remove .= implode(' AND ',$filters);
 
		return $remove;
	}
 
	protected function prepareData() { //przygotuj dane z pól obiektu, wykluczając zbyteczne
		$data = get_vars_object($this); //pobieramy dane obiektu
		unset($data['table_name']); //usuwamy pole z nazwą tabeli
		return $data
	}
}
 
class Wpis extends SqlObject {
 
	public $table_name = "Ksiega"; // nadpisujemy domyślną nazwę tabeli
 
	protected $_data = null;
	protected $_godzina = null;
	protected $_imie = null;
	protected $_email = null;
	protected $_strona = null;
	protected $_gg = null;
	protected $_wpis = null;
 
	public function __construct($data, $godzina, $imie, $email, $strona, $gg, $wpis) {
 
		$this->_data = $data;
		$this->_godzina = $godzina;
		$this->_imie = $imie;
		$this->_email = $email;
		$this->_strona = $strona;
		$this->_gg = $gg;
		$this->_wpis = $wpis;
	}
 
	public function showHtmlTableRow() {
	   	$resultString = "<tr>";
	 	$data = $this->prepareData() //nieładnie zrobione ale działa ;)
	 	foreach($data as $name=>$value) {
		  $resultString .= "<td class=".$name.">".$value."</td>";
		}
		$resultString .= "</tr>";
		return $resultString;
	}
 
}
 
class Ksiega extends ArrayObject {
   	public $db;
	public $table_name = 'Ksiega'; // kolejna pokraka
 
   	public function __construct($db) {
	   $this->db = $db; // ponieważ moja klasa PDO nie jest singletonem to przekazuję ją jako referencję
	}
 
	function offsetset($index=null, Wpis $value) { //nadpisujemy domyślną metodę klasy ArrayObject
		$this->db->insert($value)->execute(); //dodając wpis do kontenera automatycznie dodajemy go do bazy
		parent::offsetset($index, $value);
	}
 
	function offsetUnset($index) { //przy usuwaniu wpisu z Ksiegi usuwaj tez wpis z bazy
		$wpis = $this[$index];
		if ($wpis) $this->db->remove($wpis)->execute();
                            $wpis = NULL; //nie wiem czy to potrzebne ale dla świętego spokoju lepiej zniszczyć obiekt który nie ma odniesienia w bazie
		parent::offsetUnset($index);
	}
 
	public function retrieveEntriesFromDB() {
	   $sth = $this->db->prepare("SELECT * FROM ".$this->table_name);
	   $sth->setFetchMode(PDO::FETCH_CLASS, 'Wpis'); // zamiast pobierać rekordy jako tablice, tworzymy z nich obiekty klasy Wpis
	   $sth->execute();
	   foreach ($sth as $wpis) {
	      $this[] = $wpis; //dodaje kazdy rekord jako obiekt Wpis do kontenera Ksiega
	   }
	}
 
	public function showEntriesAsHtmlTable() {
		$resultString = "<table>";
		foreach ($this as $entry) {
			$resultString .= $entry->showHtmlTableRow();
		}
		$resultString .= "</table>";
		return $resultString;
	}
}
 
 
// WYKONANIE SKRYPTU
 
$db = new MyPDO($moja_konfiguracja_bazy);
 
$ksiega = new Ksiega($db);
$ksiega->retrieveEntriesFromDB();
echo $ksiega->showEntriesAsHtmlTable();
 
$wpis = new Wpis(date(),time(),'Jasiu','fasola@email.com','abojawiem',32167,'Nowy wpis');
 
$ksiega[] = $wpis // dodajemy wpis do bazy,oraz do kontenera Ksiega, ew. trzeba zastosować "REPLACE" zamiast "INSERT" żeby uniknac dublowania rekordów
 
unset($ksiega[5]); // usuwamy z Ksiegi i bazy wpis numer 5
 
 
?>
[PHP] pobierz, plaintext 

Nie parsowałem powyższego skryptu więc nie wiem czy zadziała. W każdym razie jak zapoznasz się z OOP to zobaczysz że nie da się normalnie pisać w PHP bez niego (ja przynajmniej nie potrafię ). Ale jak naprawdę chcesz być dobry to weź inny język programowania np. C++ lub Javę i tam spróbuj coś napisać. Jak tam dojdziesz do przyzwoitego poziomu to PHP będzie bułką z masłem. Po prostu PHP uczy złych nawyków.

BTW, wcześniej ktoś wspomniał o możliwych wyciekach pamięci w skryptach PHP. Może ja czegoś nie wiem lub nie rozumiem, ale przecież to chyba niemożliwe skoro pamięć jest zwalniana po zakończeniu działania programu. A PHP kończy się wykonywać wraz z końcem skryptu - czyli tak: CGI wywołuje interpreter PHP jako proces - PHP alokuje standardowy rozmiar pamięci, parsuje skrypt i rozpoczyna jego wykonanie, wszelkie wycieki pamięci powstają w obrębie za-alokowanej pamięci (od tego mamy Garbage Collectora), skrypt kończy działanie, PHP zwraca wynik i kończy swoje działanie - pamięć przez niego zajęta jest oznaczana jako wolna. Tak więc skrypt musi być naprawdę kompleksowy i rozbudowany żeby wycieki pamięci mogły odgrywać znaczącą rolę. Dziwię się bo jeszcze nigdy się z problemem wycieku pamięci w PHP nie spotkałem (ani też nie stosowałem destruktorów bez potrzeby).

Ja piszę obiektowo już od 6 miesięcy. Zacząłem gdy zacząłem pisać sklep internetowy. Powiem, że w tej chwili bez obiektowego pisania dużo bym nie zrobił. Jak dotąd, z łatwością mi się pisało wszystkie klasy. Tworzę nie jednokrotnie pliki które mają 700 linijek kodu.

Ja dzięki obiektowemu pisaniu aplikacji, przede wszystkim ułatwiłem sobie edycję. Mam przykładowo klasę produkt i plik produkty. W klasie produkt piszę wszystko co potrzebne, czyli np. dodaj, zmien, usun, sprawdz. A w pliku produkty tylko pobieram dane z formularza i:

[PHP] pobierz, plaintext 
require_once('klasy/produkt.class.php');
$produkt = new produkt;
$produkt -> dodaj($_POST);
[PHP] pobierz, plaintext 

I tyle. W razie jakiś dodatkowych pól, lub innych tego typu po prostu edytuję JEDEN PLIK! A nie jak w strukturalnym plik z formularzem, plik odbierający i plik umieszczający. Przy dużych projektach jest to naprawdę obowiązkowe pisanie aplikacji.

A ja jeszcze dodam, że pisząc obiektowo dostajemy cały "arsenał" narzędzi wspomagających programowanie, od bibliotek, pluginów, dodatków i frameworków zaczynając, a kończąc na prawdziwych kombajnach, gdzie mamy pod ręką zmienne lokalne i globalne, podpowiedzi (typu np. lista dostępnych metod danego obiektu wraz z opisem), przeglądarkę obiektów - można stworzyć prostą aplikacyjkę bez pisania nawet linijki kodu.

IDE jakieś sobie zainstalowałeś? Czu przesiadłeś się na ASPX?

Wszystkie wypowiedzi poza pierwszą linijką są oczywiste, ale myślę, że autor (tak samo jak i ja) chętnie dowiedziałby się co konkretnie miałeś na myśli, czy porobienie settera dla każdego pola, a może ustawienie ich jako publiczne, lub jeszcze jakieś inne rozwiązanie?

To zależy. Settery ułatwiają pracę gdyby trzeba zmieniać kod - wtedy metoda settera zostaje, ale sam setter może dowolnie przekształcać dane. Ale ponieważ PHP nie jest językiem kompilowanym to trzeba zachować umiar - settery do każdej głupoty (gdzie wystarcza public) mają narzut na wydajność. Po prostu musisz się zdecydować czy dana zmienna może kiedyś potrzebować dodatkowej obróbki, czy też nie.

@everth:
Ja nigdy nie korzystam z publicznych składowych klasy. Wszystkie składowe mają swoje gettery i settery. Dlaczego? Mam wówczas pełną kontrolę nad tym, co siedzi w obiekcie. Nawet takie prozaiczne ustawianie imienia robię setterem rzutując przekazywaną wartość na string.

[PHP] pobierz, plaintext 
public function set_name($name) {
	$this->name = (string)$name;
}
[PHP] pobierz, plaintext 

Fakt - jest to czasem upierdliwe bo zanim przejdę do pisania kodu klasy to wcześniej muszę napisać wszystkie settery i gettery (wraz z phpDoc'em). Mam jednak tego pecha, że jestem strasznie pedantyczny pod kątem kodu i wszystko musi być na tip-top .

@phpion: settery/gettery można z automatu generować przez IDE

Co do bezsensowności czegoś takiego (tj. ustawiania wszystkiego przez jedną metodę).
1) Co jeżeli masz już obiekt i chcesz zmienić jedną składową?
2) Zapamiętanie kolejności 10 parametrów to zbędny wysiłek
3) Burdel w kodzie (w momencie gdy chcesz zrobić coś więcej niż tylko przypisać w metodzie wartości argumentów do składowych)
4) Utrudniona dokumentacja
5) Utrudniona rozbudowa kodu (chcąc dodać nową składową musisz w metodzie ustaw wstawić ją na końcu jako opcjonalny argument - inaczej tracisz wsteczną kompatybilność)

Crozin, chodziło mi nie tyle o uzasadnienie co zaproponowanie lepszego rozwiązania

Fakt - ale czasem ustawia się podstawowe właściwości obiektu poprzez konstruktor i ja nie widzę w tym nic złego (jest to nawet czytelniejsze niż 10 wywołań jedno pod drugim) - choć ja wolę przekazywać to za pomocą tablicy a nie zmiennych (gdzieś ktoś napisał że jak funkcja ma więcej niż 2 argumenty to jest do dupy).

@everth: w konstruktorze podaje się wyłącznie argument wymagane do tego by w ogóle dało się utworzyć obiekt. A ta teza, że metoda z więcej niż dwoma argumentami jest do dupy... jest do dupy.

@Crozin:
Netbeans posiada generatory setterów/getterów, Eclipse PDT niestety nie (chyba, że nie potrafię tego znaleźć).

@everth:
Jeśli przesyłasz parametry na hura w postaci tablicy to możesz sobie darować podpowiadanie parametrów w IDE. Podpowiedź, że możesz podać tablicę niewiele da. Osobiście wolę jawnie znać nazwy, znaczenie oraz typy poszczególnych parametrów (szczególnie przy przekazywaniu obiektów).

I tak i nie. Może przez pewne naleciałości z C++ wiem jak cholernie trudno było tropić błędy w funkcjach przyjmujących po 5 i 6 argumentów, nie tędy droga. Dla mnie metoda przyjmuje coś -> przekształca coś, ew. korzystając z właściwości obiektu -> i ew. zwraca coś. Złota zasada - jedna funkcja robi jedną rzecz, dodatkowe argumenty z reguły służą modyfikacji działania funkcji czyli zaprzeczają powyższej zasadzie.
Skoro akceptujesz sytuację z pierdyliardem setterów/getterów to powiedz mi czy dlaczego setter nie może przyjmować więcej niż jedne argument? Przecież setter może być zbudowany tak że przyjmuje argument bazowy oraz zmienne modyfikujące.


Mogę sobie na to pozwolić jeśli ograniczam się do pól które w moim obiekcie i tak są public. Czyli według zasady - nazwa pola => wartość. To i tak łatwiejsze do modyfikacji niż ciąg argumentów.

Zgadza się - jedna funkcja robi jedną rzecz. Ale zauważ, że często przydatne są funkcje "skrótowe", które przyjmą np. 3 parametry i wywołają odpowiednie metody atomowe. Prosty przykład:

[PHP] pobierz, plaintext 
class Page {
	public function render(Page_Header $header, Page_Body $body, Page_Footer $footer) {
		$this->render_header($header);
		$this->render_body($body);
		$this->render_footer($footer);
	}
 
	public function render_header(Page_Header $header) {
		//
	}
 
	public function render_body(Page_Body $body) {
		//
	}
 
	public function render_footer(Page_Footer $footer) {
		//
	}
}
[PHP] pobierz, plaintext 

Czy wg Ciebie przekazanie 3 parametrów do metody render() jest błędne?


Zadaniem settera jest ustawianie wartości składowej obiektu. Skąd więc pomysł by przekazywać do niego X parametrów? Przekazujesz 1 parametr, który jest wartością, która będzie przypisana do składowej.


Już lepszym rozwiązaniem byłoby (zamiast jawnego $this->$var = $value) wywoływać call_user_func(array($this, 'set_'.$var), $value). Wtedy wszystkie ustawienia wartości lecą przez odpowiednie settery.

Polecam, tania i warta swej ceny, ale raczej dla średnio-zaawansowanych i zaawansowanych.

Moim zdaniem jest błędne bo według mnie metoda render powinna być funkcją (void). A parametry powinny być właściwościami klasy Page. Albo inaczej powinna istnieć klasa RenderEngine mająca metodę render która przyjmuje obiekty page lub body lub footer (powinny dziedziczyć po jakimś abstrakcie). Tak mi się wydaje. Ale ponieważ jestem pragmatykiem to akceptuję to jeśli pracuję na czyimś kodzie (nie będę przerabiał całego kodu).

Przykład z setterami jest naciągany. Call_user_func dla mnie ma ograniczone zastosowanie - to taka szybsza wersja eval, a to odstręcza mnie zawsze od stosowania w kodzie (bo wolna, bo trudna w debugowaniu, bo może dawać nieprzewidziane rezultaty, bo może powodować dziury w bezpieczeństwie, bo...). Tak więc to co piszesz, choćby ze względu na wydajność (pomijając czytelność) dla mnie jest wykluczone.

call_user_func i inne/zmienne zmiennych - to nie szybsza wersja evala tylko RefelctionAPI. Co do wolności ich wykonywania to się nie zgadzam - natomiast fakt, faktem debuggowanie utrudniają.

Przykład metody, która wymaga wielu parametrów: ot chociażby metoda rysująca prostopadłościan (x, y, z, width, height, depth) - oczywiście można by to zastąpić dwoma obiektami (Point3D(x, y, z), Cuboid(width, height, depth)) ale takie coś można by podciągnąć chyba pod wszystko. Nie mniej jednak przykład nie przyszedł mi od razu do głowy - bo takich metod się nie stosuje zazwyczaj. Jednak czasami się tak zdarza, że coś potrzebuje tych kilku argumentów - wtedy trzeba zadbać o to by było to maksymalnie logiczne i dobrze udokumentowane.