CakePhp2, organizacja kodu, OOP, SOLID

Witam,

pracuję w projekcie opartym na CakePHP 2, framework jak framework, nie mam możliwości jego zmiany ponieważ system napisany z jego pomocą działa generalnie. Chcę zacząć wprowadzać do niego zmiany, aby kod stał się lepszy, ale jestem początkujący i nie mogę ułożyć sobie w głowie wszystkich konceptów. Do rzeczy...

Mam konfigurator produktu, który składa się z wielu części. I teraz zastanawiam się jak to wszystko poskładać do kupy razem z koncepcjami frameworka. Przykład:

Konfigurator samochodu, na który składa się:
rodzaj siedzenia, kierownica, licznik, lusterka, koła, felgi itd

Każda z tych części to klasa (controller) z przypisaną tabelą.

Jak podejść do złożenia tego do kupy biorąc pod uwagę OOP i SOLID. Teraz to po prostu kontrolery, komponeny i modele, gdzie jest jedna wielka sieczka (pobieranie produktu i zależności czyli uderzenie do bazy zapytaniem z joinami + dociągnięcie tego co trzeba i złożenie do kupy). Chciałbym zrobić jakiś refaktor, poukładać to wszystko...

1. Jak podejść do klas? Chciałbym mieć klasę Product, ale siłą rzeczy już taka klasa istnieje, bo taka jest koncepcja frameworka

2. Czy powinienem wszystkie te zależności przekazać w konstruktorze nawet jeśli jest ich dużo np 15-20 różnych części składowych...?

3. Jak połączyć modele z klasami... Przykładowo mam model Car i chcę utworzyć klasę CarProduct, jak po ludzku połączyć te dwa byty, przekazać to co dostanę z bazy do konstruktora? Czy to nie będzie niepotrzebna nadmiarowość, już sam nie wiem.

4. Może znacie jakiś przykład na githubie, który by względnie dobrze pokazał coś podobnego (ale żeby to nie była aż taka kobyła jak na Sylius)

Generalnie wszystko wygląda prosto na przykładach na blogach, ale im więcej patrzę na kod i o tym myślę to większy mam mętlik w głowie...

Pytanie czy na pewno refaktoryzacja jest dobrym pomysłem, bo z tego co zrozumiałem, to do przepisania masz większość kodu przy czym tracisz czas na poprawianie czegoś, co już działa i dalej opierasz to o przestarzałego frameworka. Na Twoim miejscu poświęciłbym ten czas na naukę czegoś aktualnego np. laravela (jest prostszy od symfony i nawet kod tego forum jest o niego oparty) i przepisywał sobie powoli te stronę.

Oczywiście najlepiej by było przepisać, ale:

1. na bieżąco trzeba system rozwijać, a sam będę to przepisywał miesiącami i musiałbym to robić w dodatkowym czasie
2. przy przepisywaniu powstanie masa nowych bogów
3. traktuje tą refaktoryzację jako duże wyzwanie i pole do nauki
4. nadal pozostaje kwestia jak spiąć założenia frameworka z nazwami klas i tworzeniem instancji etc

W planie jest spięcie tego z najnowszym cakePHP i poprawianie kawałek po kawałku i pisanie niewygasających rzeczy już w cakePHP

Zanim w ogóle zaczniesz ruszać kod: masz napisane testy akceptacyjne (np. z wykorzystaniem Selenium)?

Nie ma nic :) dopiero chcę wprowadzać wszystkie dobre praktyki, dlatego chcę to zrobić małymi kroczkami. Z różnych względów projekt wygoda jak wygląda i chce go naprawić... Tylko potrzebuję trochę pomocy bo jestem juniorem cokolwiek to znaczy. Próbuję sobie to wszystko ułożyć w głowie, ale jeszcze wajcha nie pykła...

I tak wiem, że za to powinien się wziąć ktoś mocno ogarnięty, ale się nie weźmie.

Nie ma nic

W takim razie pierwsza zasada refaktoringu: zacznij od napisania rzetelnych testów :-)

Dzięki temu zobaczysz jak aplikacja funkcjonuje, poznasz wszystkie przypadki skrajne i, przede wszystkim, będziesz mógł spokojnie spać w trackie refaktorowania, ponieważ wszystkie zepsute ficzery zostaną wyłapane przez testy, a nie użytkowników.

dlatego chcę to zrobić małymi kroczkami

To ma sens - dlatego zacznij od testów :-)

Możesz nawet testować całą aplikację w Vagrancie, jeśli wymaga ona stawiania dodatkowych ciekawych zależności, ale stwórz sobie jeden skrypt test.sh, który po uruchomieniu będzie Ci w stanie powiedzieć czy coś zepsułeś.

wiem, że za to powinien się wziąć ktoś mocno ogarnięty, ale się nie weźmie

Refaktor takiej aplikacji będzie dla Ciebie bardzo pożyteczny - tylko trzeba wziąć się za to spokojnie i nie pchać od razu w kod.

Jeszcze tak napomknę bo z moich postów to nie wynika... sporą część tego kodu znam, co prawda trafiłem na prawie działający projekt, ale sporo już dopisałem. Z różnych względów (wiedza, brak czasu/możliwości) musiałem dostosować się do istniejącej sytuacji, większość dobrych programistów już by pewnie uciekła z tego projektu, ale ja go lubię i jak już wspomniałem "lubię sprzątać" :)

Wiem że nikt nie lubi grzebać w czymś napisanym przez kogoś innego, co znacząco od tych zasad pięknego kodu odstaje ale to za co Ty chcesz się zabrać to nie dość że robota dla ogarniętych gości z dużym doświadczeniem, to jeszcze należy znać tego Cake na wylot. Jeśli znasz framework na wylot to spoko. Z frameworkami to nie taka prosta sprawa, zwłaszcza starsze wersje, mają swoje założenia, zrobisz refaktoryzację a potem za rok wrócisz np. do tego projektu, po czym pewnie ponownie stwierdzisz, że to co aktualnie wydawało Ci się OK, wypadało by jednak napisać inaczej. Wiesz bo ja sam jak popatrzę na projekt, który skończyłem rok temu albo dwa lata temu to jednak pewne rzeczy można by zrefaktoryzować. No właśnie, za to mi nie zapłacą...

Dobra Panowie, bo zbaczamy z tematu cały czas... nie potrzebuję odwodzenia i propozycji przepisania softu przez lepszych programistów tylko proszę o nakierowanie jak złożyć w całość logikę biznesową z założeniami frameworka. Czyli jak mam logicznie połączyć klasy skoro framework robi instancje istniejących klas za mnie. Przykład?

Mam klasę Product (która jest modelem ze zdefiniowanymi relacjami i jest połączona z tabelą w bazie). Teraz chciałbym utworzyć swoją klasę Product gdzie mógłbym stworzyć jakies interfejsy, może klasy abstrakcyjne, wstrzyknąć do niej potrzebne zależności. I teraz co... czy jeśli utworzę sobie klasę Product w osobnym namespace a tej z Cake będe używał tylko do pobierania danych to będzie ok? (W założeniu framworka model ma okresloną nazwę). Czy może zacząć zmieniać nazwy modeli na coś w rodzaju ProductRepository?

Na początek chciałbym zacząć po prostu zacząć od wdrożenia namespaceów, PSR4, SOLID, nie chcę przepisywać całej logiki tylko rok po kroczku naprawiać system. Dopisać testy, wydzielić część logiki żeby kontrolery nie miały po 2 tys linii etc. Ale nie chcę tego robić ramach frameworka tylko wydzielić możliwie dużo logiki biznesowej tak aby nie była od frameworka zależna.

Może znacie jakiś przykład apki, która pokazała by mi drogę w praktyce, a nie jest przeinżynierowana i nie jest wpisem z bloga gdzie mam dwie klasy i nic poza tym, nie busi być w CakePHP

Na początek chciałbym zacząć po prostu zacząć od wdrożenia namespaceów

Na początek zacznij od napisania testów.
Nie ruszaj działającego kodu.

Patryk27 napisał(a):

Na początek chciałbym zacząć po prostu zacząć od wdrożenia namespaceów

Na początek zacznij od napisania testów.
Nie ruszaj działającego kodu.

No tak tylko muszę znaleźć jakiś złoty środek bo teraz jest pomieszanie z poplątaniem, wiele odpowiedzialności pomieszanych ze sobą w kontrolerach, Ponad to czytałem trochę ten wątek: Pisanie testów do starego kodu gdzie @Shalom pisze, zeby nie testować klas/metod tylko funkcjonalności... tylko, że ja mam te funkcjonalności pomieszane.

Nie testuj kodu źródłowego, tylko efekty: poczytaj o testach akceptacyjnych i Selenium (czy czymkolwiek innym, co teraz jest modne).

Dzięki, zbadam temat.

Mam klasę Product (która jest modelem ze zdefiniowanymi relacjami i jest połączona z tabelą w bazie). Teraz chciałbym utworzyć swoją klasę Product gdzie mógłbym stworzyć jakies interfejsy, może klasy abstrakcyjne, wstrzyknąć do niej potrzebne zależności.

Wydaje mi się, że framework z definicji narzuca pewien sposób rozwiązywania pewnych spraw i tak też jest w przypadku CakePHP2 . Mając jak piszesz Model -> lecisz z logiką co na nim ma się wykonać w odpowiednim Kontrolerze który odbiera request. Jeśli masz jakieś bardziej złożone zachowania to wydzielasz kod do metod ma modelu lub tworzysz Component / behaviour.