Klasa: http://www.unit1.pl/pb-823

Na początku próbowałem przepisać moduł prywatnych wiadomości w stylu proceduralnym. Ze względu na dużą ilość instrukcji warunkowych, gdzie trzeba wysłać odmienne zapytania (z innymi danymi lub parametrami) oraz FAKT, że niektóre moduły mogą też wysyłać prywatne wiadomości do użytkowników, napisałem klasę. Dobra decyzja?

Nie rozwiązuje to problemów całkowicie. Operacje możliwe do wykonania to:
1) Wysłać nową wiadomość
2) zapisać ją do kopii roboczych (nie wysyłać)
3) wysłać zapisaną kopię do użytkownika (tutaj najlepszym wyjściem będzie chyba UPDATE)
4) zapisać wysłaną wiadomość także do folderu "wysłane" (opcjonalnie)
5) zaktualizować kopię roboczą (gdy użytkownik ją zmienia)
6) ?

Jak przepisać klasę, aby wszystkie operacje wykonywało się łatwo, a kod nie stracił na wydajności?

Przykład: aktualizując kopię roboczą, zmieniamy tylko: tytuł, treść, odbiorcę i opcje. Wysyłając ją, zmieniamy status, właściciela i pole "usr" (wtedy zawiera ID nadawcy). Znów 2 zapytania? Czy aktualizować wszystko podczas 1?

W pliku edycji prywatnych wiadomości oprócz instrukcji warunkowych i komunikacji z klasą wykonuję jeszcze kilka operacji, gdzie mogą wystąpić błędy (np. gdy dodaje wiadomość do "wysłanych", a limit jest przekroczony) czy "brak wiadomości". Dlatego dodałem referencję $errRef.

Jak przepisać kod, aby wszystkie operacje (zważając na ich zawiłość, różnice) wykonywało się łatwo, a klasa stała się elastyczna? Może za dużo lub za mało kodu tam umieściłem? Może zamiast proporcji (zmiennych klasy) lepiej użyć tablicy z danymi (do, temat, itp.)? Ostateczność - mogę wykorzystać gotową klasę na zasadach GPL.

nie optymalizuję się kodu zawczasu, na początku może to być trudne... ja nie wiem czemu ale jak widzę że coś może być nie jest optymalne to zaraz chce to poprawić, ale to jest wbrew pozorom karygodne podejście

jest zasada różnie zwana znana jako 80/20, 90/10 czy coś w tych okolicach

co znaczy że jeżeli jakaś ilość kodu wyrażona w procentach (ta druga liczba) zabiera (ta pierwsza liczba) % czasu to wtedy należy ten fragment optymalizować

zapytania wstawienia nowego rekordu i update szukany po id (jeśli on jest kluczem głównym) nawet w duuuużej tabeli wykona się tak szybko że nawet mrugnąć nie zdążysz i nie będzie miało właściwie żadnego wpływu na wydajność

zasadniczo powinno się robić tak:
1. planujesz API, bazę etc
2. piszesz testy (ale to się rzadko komu chce robić)
3. kodujesz
4. masz gotowe -> odpalasz testy
jeśli nie działa idziesz do 3
5. profilujesz -> jeśli są problemy z wydajnością wracasz upewniasz się że projekt jest prawidłowy, idziesz do 3

no powiedzmy że mniej więcej taka kolejność

co do elastyczności tutaj niestety nie ma sztywnych reguł jak pisać żeby było dobrze

ale z moich obserwacji wynika że funkcje w dobrym kodzie są małe... unika się w ten sposób klas, metod, funkcji boskich

metoda taka często może ograniczać się do wywołania 1, 2 funkcji na argumencie i zwrócenie tej wartości, jak przejrzysz pobieżnie kilka kodów jakichś cms-ów, frameworków itp. (dobrych) to też zauważysz taką właściwość

ale trudno powiedzieć kiedy powinna to być 1 funkcja a kiedy 100 linii kodu, w każdym razie jedna funkcja powinna realizować pojedynczą funkcjonalność, proste że jak napisze funkcje która posiada 4 argumenty z tego wszystkie podnosi do kwadratu, pierwsze 2 wyniki zsumuje, kolejne dwa odejme, sume podziele przez różnice a całość spierwastkuje to użyje jej rzadziej niż poszczególnych funkcji sumy, różnicy, potęgi, pierwiastka z osobna...
tak samo jak się buduje dom, to nie robi się papki z metalu, wapnia, cementu, piachu, plastiku i szkła, nie miksuje i nie ustawia na miejscu
tylko kładzie się kolejne cegiełki, robi elektrykę hydraulikę etc
identycznym rozumowaniem trzeba się posługiwać przy projektowaniu, reszta to kwestia doświadczenie, a doświadczenie wynika z prób...

w skrócie: napisz, sprawdź czy możesz to wykorzystać w innych skryptach które będziesz pisał, sprawdź czy skrypt nie muli, ew. profiluj
jeśli wszystko ok to znaczy że napisałeś dobrze...