![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 294 Pomógł: 4 Dołączył: 19.12.2008 Ostrzeżenie: (0%) ![]() ![]() |
Hej. Jakiś czas temu zrozumiałem, że oprócz wiedzy i praktycznie wszelakich z tym związanych możliwościach, to nie tylko to, co programista znać powinien. Są też zasady, (jak standard w3c) których dobrze jest przestrzegać - i tak oto trafiłem na zasady SOLID - aż wstyd się przyznać, że wcześniej ich nie znałem.
Podpowiedzcie mi, na moich chociażby przykładach, jak powinno najlepiej się podchodzić do tematu. 1. Jeśli mamy Single Responsibility. Rozumiem to tak, że każdy obiekt powinien być tak robity, by poszczególne jego składowe, można było wykorzystywać w różnych sytuacjach. By nie tworzyć funkcji typu GetAll(). Czyli jeśli mam np. klasę Faktury. To dobrze, jest ją rozbić na składowe, które są odpowiedzialne za różne rzeczy. Np. czy lepiej to jeszcze bardziej rozbijać, np.: W pierwszym przypadku mam funkcję dedykowaną do szukania faktury SearchInvoice(). W zależności na jakich stronach wyszukuję faktury to piszę zawsze SearchInvoice() i wiem, że ta metoda zwraca faktury. A w drugim przypadku, jest metoda Search() którą mogę wykorzystać do szukania Faktur, ale też do szukania postów, do szukania użytkowników i szukania czegoś jeszcze. W drugim przypadku powstaje duża funkcja, w której jest dużo switch`ów, ale wykorzystywam ją w każdej stronie i nie muszę się zastanawiać co ona robi, a w pierwszym przypadku znowu większa ilość funkcji. Co jest lepsze prawidłowe? 2. Open Closed. Mamy sytuację, że pobieram fakturę. Czyli lepiej jest tworzyć funkcję np. GetInvoicesById(1) , GetInvoicesTrashed(true, array('11', '22')) i tworzy się w tedy duża ilość funkcji, czyli lepszym będzie funkcja jak wyżej, czyli zawsze jako parametr dawać array (lub object) i wtedy nie trzeba dawać defaultowych wartości np.
czy lepiej zawsze się przyzwyczaić i dawać:
3. Co to jest encja tak właściwie? Object czyli zbiór metod, funkcje czyli można powiedzieć metody, a encje? to jakaś wartość funkcji, np:
4. To już pytanie o Laravela. Jak się powinno fachowo generować podstrony i wykonywać routing. Załóżmy narazie prosty przykład, gdzie jest:
Używam laravel 5.1 :-) Z góry dziękuję za wszelkie wskazówki ;-) Nikt nic? |
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 240 Pomógł: 278 Dołączył: 11.03.2008 Ostrzeżenie: (0%) ![]() ![]() |
Dużo masz pytań, postaram się odpowiedzieć na 1 żeby zachęcić resztę społeczności (IMG:style_emoticons/default/smile.gif)
Single Responsibility Cytat Martin utożsamia odpowiedzialność klasy z powodem do jej modyfikacji. Możemy rozważyć moduł, który generuje i drukuje raport. Odpowiada on za dwa procesy, a tym samym mogą wystąpić dwa powody do jego modyfikacji. Po pierwsze, może zmienić się treść generowanego raportu, po drugie ? format, w jakim jest on drukowany. Zasada pojedynczej odpowiedzialności mówi, że oba te procesy powinny być niezależne i zaimplementowane w postaci dwóch oddzielnych klas lub modułów, które komunikują się ze sobą przy pomocy publicznych interfejsów W Twoim przykładzie, żadna z odpowiedzi nie jest dobra. Czyli dla każdej tabeli/modelu musimy tworzyć osobne metody insert, serach itp. chociaż wyglądają tak samo - jedyna zmiana to będzie nazwa tabeli i ew. pól które chcemy zaznaczać, dodawać - odpada. Drugi sposób jest już bardziej w porządku, zakładajac, że metody search, insert itp. są w jakiejś nadrzędnej klasie np. "Model". Cytat W drugim przypadku powstaje duża funkcja, w której jest dużo switch`ów Tutaj jest problem, nie powinno być switcha, tylko ta nadrzędna klasa powinna korzystać z właściwości tej podrzędnej np.
Metoda getTableName w klasie InvoiceTable komunikuje się z klasą SimpleTable za pomocą interfejsu SimpleTableInterface, po to aby klasa SimpleTable wiedziała na jakiej tabeli wykonywać określone zadania. I teraz jeżeli np. - zmienimy rodzaj bazy danych edytujemy tylko klasę DataSource nie ruszając innych rzeczy. - chcemy pobierać faktury po numerze zamiast po ID to edytujemy klasę InvoiceTable dodawająć metode np. getByNumber. - jakaś tam kolejna tabela np. Users przed insert musi hashować hasło - możemy to dodać tylko w tej klasie bez żadnego switch`a. Nie jest to może idealny przykład i jestem pewny, że powyższy kod dało by się rozpisać o wiele lepiej - myślę jednak, że do zrozumienia "Single Responsibility" Ci wystarczy. Ten post edytował markuz 5.05.2016, 18:30:08 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 22.08.2025 - 13:39 |