Mam pare pytań co do filozofji pisania funkcji ( w obiektach albo i nie ).
1. Jak tworzyć funkcje odpowiedzialne za jakieś zadania. Niektórzy wolą małe funkcje (dużo) i każda miałaby swoje specyficzne zadanie. Innie inaczej. Ja osobiście właśnie pisze coś małego i wykorzystuje do tego tzw. system jednofunkcyjno-wielofunkcyjny. Tzn. mam jedną dużą funkcję do której przekazuje maskę bitową tego, co chcę zrobić oraz dane w tablicy. Oczywiście pare masek sobie zpredefiniowałem. Dokładniej wygląda to tak:[php:1:ae2c1cb336]<?php

define( "_MESG_CTL", bindec( "100000000" ) ); // Maska definiujaca maski klasy "mesg"
define( "_MESG_CTL_ALL", bindec( "1" ) ); // Wszystkie wiadomosci dla x
define( "_MESG_CTL_ONE", bindec( "11" ) ); // Pierwsza wiadomosc dla x
define( "_MESG_CTL_ADD", bindec( "111" ) ); // Dodaj wiadomosc dla x od y
define( "_MESG_CTL_DEL", bindec( "1100" ) ); // Skasuj po pokazaniu
define( "_MESG_CTL_GET", bindec( "10100" ) ); // Zwroc wiadomosci dla x
define( "_MESG_CTL_SHOW", bindec( "110100" ) ); // Pokarz wiadomosci dla x
define( "_MESG_CTL_FROM", bindec( "1000100" ) ); // Pobierz wszystkie wiadomosci dla x od y
define( "_MESG_CTL_INFO", bindec( "100000100" ) ); // Tylko powiadom, cze spelnione sa kryteria

define( "MESG_GET", _MESG_CTL ^ _MESG_CTL_ALL ^ _MESG_CTL_GET ^ _MESG_CTL_DEL ^ _MESG_CTL_FROM );
define( "MESG_SEND", _MESG_CTL ^ _MESG_CTL_ADD ^ _MESG_CTL_FROM );
define( "MESG_PRESENT", _MESG_CTL ^ _MESG_CTL_SHOW ^ _MESG_CTL_INFO );
?>[/php:1:ae2c1cb336]Tak wogóle to to ma być system komunikacyjny. I teraz jak już mówłem mam jedną funkcję, która za pomocą tego co dostanie w masce wymaga odpowiedniej tablicy z danymi. Myślicie, że można to lepiej rozwiązać? Jeżeli tak to piszcie, po to tutaj ten temat .
2. Jak dzielić funkcje? W moim przypadku jest jedna funkcja która rozdziela zadania a potem je wywołuje w pomniejszych funkcjach, tzn, że w całym obiekcie jest tylko jedna funkcja publiczna. Nie wiem czy to dobrze, ale zainspirowały mnie funkcje typu ioctld z unixów. Jeszcze się zastanawiałem, czy nie umieścić wszystkiego w funkcji głównej, ale uznałem, że dla czytalności lepiej nie.
3. Przekazywanie danych. Jak już powiedziałem przekazuje dane za pomocą masek bitowych oraz tablicy argumentów. Uważacie, że to dobrze? Według mnie jest to dobry pomysł, ponieważ można każdą maskę przerobić oddzielnie.

Taki krótki temacik, ale chciałbym nim tylko zainicjować dyskusję na ten temat.

Ad.1
Ja preferuje tworzenie funkcji tylko do specyficznych zastosowan. Takie, ktore nie rabia nic poza specyficznymi zadaniami, dla ktorych zostaly napisane. To jest takze zgodne z technika reuseable.
Czytalem ciekawe stwierdzenie na ten temat... "Jezeli nie mozesz okreslic jednej nazwy dla funkcji, znaczy to, ze robi ona za duzo rzeczy"

Ad.2
Co do rozdzielania w obiektach to ja mam inny sposob. Otoz po pierwsze OOP ma na celu zgrupowanie metod w jedna calosc. Czyli stworzenie obiektu, ktory posiada metody razem jakos ze soba "polaczone".
Co do PPP (public/private/protected) to metody w obiekcie powinny byc podzielone na interfejs - publiczne - i pryvatne/chronione. Publiczne maja za zadanie stworzenie interfejsu do obslugi obiektu, a prywatne do dzialania na wewnetrznych danych. Czyli zasada enkapsulacji.

Ad.3
Mysle, ze to jest dobre rozwiazanie ale w praniu dopiero wyjdzie czy jest optymalne do tego zastosowania.


P.S.
Ciekawie sie zapowaida ten system komunikacji :9

Myślę że czym funkcje będą obszerniejsze tym bliżej będzie im do kodu strukturalnego. Takie jest moje zdanie.

Co do rodzielania funkcji, to nie wiem jak by to wyglądało w praktyce, ale czy nie lepiej jak funkcje same wywołują te potrzebne...? (czy też metody)

Co do masek to się nie znam... :wink: Jak mógłby mnie ktos nakierować na jakiej materiały albo wyjasnienia, byłbym wdzięczny...

Mam już nowe zdanie . Uważam, że trzeba robić funkcje odpowiedzialne za odpowiednie zadania. W ten sposób jest dużo łatwiej.
Ale co do przekazywania argumentów to jestem dalej za tylko dwoma argymentami, czyli maskami oraz tablicą parametrów (zależnych od maski).
Bo można zrobić na dwa sposoby:
pierwszy_mój_preferowany.php ( ):[php:1:00e5f604ff]<?php

//wywolanie funkcji get( ... );
$objMesg->get( _MESG_CTL ^ _MESG_CTL_FROM ^ _MESG_CTL_ALL ^ _MESG_CTL_DEL, array( 'from' => /* module name */, 'to' => /* module name */ ) );

?>[/php:1:00e5f604ff]
drugi.php[php:1:00e5f604ff]<?php

$objMesg->get( /* all */ TRUE, /* From inforamtion */ TRUE, /* notify only */ FALSE, /* delete after */ TRUE, /* module name from */, /* module name to */ );

?>[/php:1:00e5f604ff]Takie jest teraz moje spojrzenie

ps. Seth, skąd wiedziałeś?

ja preferuja maksymalna modularyzacje. staram sie, aby dana funckja byl odpowiedzialna za jedna tylko rzecz. wszystko co w kodzie da sie przrobic na funkcje - przerabiam - tak ze w skrypcie glownym zostaje mi tylko sterta intrukcji warunkowych, przypisan oraz wywolan roznych funkji.

jezeli chodzi o nazewnictwo, to w miom przypadku stosuje nazwy, ktory dokladnie okreslaja co dana funkcja robi, a jesli jest wykorzystywana tylko przez jeden skrypt, to dodatkowo w jeje nazwie zapisana jest nazwa skryptu, ktorego jest czescia skladowa np.

registerCheckUserDatas(); - funkcja jest czescia register.php a sluzy do sprawdzania poprawnosci danych wpisanych przez uzytkownika w formularzu rejestracyjnym.

moje zdanie jest jednoznaczne: maksymalna modularyzacja kodu, przetrzymywanie kazdej z funkcji w osobnym pliku; wszystkie moduly trzymamy w jednym katalogu. dzieki duzej modularyzacji w przypadku, gdy cos nie dziala, od razu wiemy, ktory modul jest "winny", a ze jest to zazwyczaj bardzo maly modulik, to juz w nim samym latwiej odszukac blad.