Forum PHP.pl

A czym jest i jakie wartości może przyjąć ów $zmienna?

1. Nie ma jednoznacznej odpowiedzi na pytanie null VS wyjątek VS null object VS optional VS jeszcze coś innego. Jest to niemal zawsze zależne od konkretnej sytuacji i od przewidzianego zachowania. Podaj konkretny przypadek użycia - wtedy można zastanawiać się co wybrać.
2. @Pilsener akurat Twoja sugestia odnośnie czegoś takiego:

[PHP] pobierz, plaintext 
if ($sth->hasItem($key)) {
  $value = $sth->getItem($key);
}
[PHP] pobierz, plaintext 

W przypadku zasobów nie będących w bezpośredniej władzy programu (tj. wszystko wykorzystujące sieć, dyski czy ogólnie środowisko systemu) jest po prostu zła i nieprawidłowa - prowadzi do błędów, bo pomiędzy sprawdzeniem (has()), a wykorzystaniem (get()) stan systemu może się zmienić. Tutaj tylko wyjątki dają sensowny interfejs, bo trzeba spróbować pobrać zasób (get()) by w ogóle stwierdzić czy jest on dostępny (has()).

memory_get_PEAK_usage() jak sama nazwa od dokumentacji nie wspominając wskazuje zwraca najwyższe chwilowe zużycie pamięci jaki skrypt/program miał, nie obecne.

1. GC ma prawo zadziałać dopiero z opóźnieniem.
2. Musisz wczytywać wszystkie dane do pamięci przed ich zapisem? Nie możesz tego zrobić strumieniowo?

Nie lepiej, bo obsługa wartości bez znaku jest w wielu platformach mocno utrudniona - z PHP na czele - a niczego Ci nie daje w tym kontekście. Nie mówiąc już o dużych problemach w mieszaniu arytmetyki typów z i bez znaków.To będzie wina złego projektu aplikacji czy bazy danych, nie samej platformy/technologi. Nie przy takich wartościach.
To że jakaś wartość jest dominująca nie powinno być samo w sobie przesłanką do korzystania z wartości domyślnych. Przy czym jest to raczej mało istotna kwestia.1. Symfony nie ma tutaj nic do rzeczy - to specyfika języka.
2. Jeżeli nulle nie mają sensu dla Twojego modelu danych - bardzo częsta sytuacja i w sumie jeszcze częściej mocno pożądana - nie umożliwiaj w ogóle ich podania. Od tego są konstruktory by wymusić podanie odpowiednich danych. Jeżeli zaś danych jest za dużo na konstruktor masz do dyspozycji całą paletę sprawdzonych wzorców budowniczych pozwalających konstruować złożone obiekty.
3. Jeżeli jakieś wartości trzeba ustawić to... to je ustaw.

@rad11 Ale po co tak kombinować?

[PHP] pobierz, plaintext 
$request = new Request(...);
$requestStack = new RequestStack();
$requestStack->push($request);
[PHP] pobierz, plaintext 

Tak długo jak długo nie trzeba używać żadnych mocków powinno się od nich uciekać. Request / RequestStack to bardzo proste obiekty, które spokojnie można tworzyć sobie na potęgę.

@szypi1989 Tutaj testy dają Ci nawet coś więcej niż pewność, że kod działa. Fakt, że jest Ci je tak trudno napisać ładnie obrazuje to, że kod jest - wybacz za bezpośredniość - słabo napisany. Zadaniem Twojej klasy jest zbudowanie odpowiedniego zapytania SQL/DQL na podstawie jakichś kryteriów. No to w takim razie skup się na tym by robił to i tylko to, korzystając z prostych i specyficznych dla tego problemu (zadania) typów danych.

[PHP] pobierz, plaintext 
class AbcSearchCriteria {
  private string $name;
  private string $value;
 
  public __construct(string $name, string $value) { ... }
 
  public getName() { return $this->name; }
  public getValue() { return $this->value; }
}
 
class AbcSearchQueryBuilder {
  public __construct($em, ...)
 
  public buildQuery(AbcSearchCriteria $criter) { ... }
}
[PHP] pobierz, plaintext 

To że w produkcyjnym kodzie te kryteria będą gdzieś, jakoś budowane na podstawie danych z żądania HTTP nie ma znaczenia dla tej klasy - ona ma się skupić na swoim zadaniu czyli budowaniu odpowiedniego zapytania na podstawie odpowiednich kryteriów. Ten kod strasznie łatwo przetestujesz i co więcej może to być wartościowy test! A co z tą kwestią tworzenia obiektu reprezentującego kryteria? To jest inna część kodu - może być inicjowana gdzieś pewnie na poziomie jakiegoś kontrolera, która powinna być poddana osobnemu testowi - który weryfikuje jedynie czy obiekt kryteriów jest prawidłowo tworzony na podstawie obiektu żądania HTTP.

Na dobrą sprawę jest to dosyć proste do zrealizowania.

1. Link powinien zawierać w sobie jakieś ID komentarza, np. http://my-website/resouce-x?findComment=123.
2. Na pow. stronie wykonujesz zapytanie ustalające pozycję danego wiersza w ów liście komentarzy. Zrobisz to korzystając z ROW_NUMBER (w różnych silnikach baz może to widnieć pod inną nazwą). Tutaj przykład: https://stackoverflow.com/questions/1079480...-sql-result-set
3. Mając pozycję jesteś wstanie przekierować na odpowiednią stronę w listingu komentarzy, np. http://my-webiste/resource-x?commentsPage=23

1. 2 116 590 bajtów (2 MiB) czy 2 116 590 kilobajtów (2 GiB)? Wtedy ten limit może mieć znaczenie.
2. Co to za ciąg, co to za dane, że chcesz ich tyle (o ile to faktycznie 2 GiB) wczytywać na raz do pamięci?
3. Jesteś wstanie udostępnić nam SSCCE?

@Damonsson: No przecież to co podałeś to nic innego jak właśnie losowy, nic nie znaczący identyfikator.

Funkcje hashujące nie mają żadnych liter bo do dane binarne. Możesz je sobie co najwyżej zapisać w formie tekstowej.

Równie dobrze może to być po prostu losowy ciąg 32 znaków a-zA-Z0-9, który kompletnie nic nie oznacza. I byłoby to bardzo prawdopodobne jeżeli jest to publiczny identyfikator jakiegoś zamówienia.

Wydaje mi się, że za bardzo skupiasz się w tej chwili na Symfony/Doctrine/innych bibliotekach oraz na problemach których jeszcze nie masz tworząc z relatywnie prostego problemu rozdmuchanego potwora, do którego faktycznie trudno podejść. Wcześniej pisałeś o tym jak już oczami wyobraźni widzisz strukturę i kontrakty pomiędzy obiektami, teraz piszesz o nieistotnych z punktu widzenia tego problemu bzdetach. Zignoruj na chwilę problem obsługi bazy danych czy ogólnie ich składowania. Olej problem wprowadzania danych czyli formularze. Wypnij cztery litery na tworzenie serwisów w kontenerze zależności zrób to manualnie na start.

W skrócie: utwórz sobie prosty, śmieciowy kontroler z jedną akcją jako punkt wejścia do kodu, wpisz do niego ręcznie jakiś stan początkowy dla danych, uruchom kod który ma te dane przetworzyć i na koniec nawet najprostszym Symfonowym dump() wyświetl rezultat by sprawdzić czy otrzymane dane są prawidłowe.

[PHP] pobierz, plaintext 
class DummyController {
    public function runAction(): Response {
        // Dane początkowe
        $staminaCalculator = new JakasDodatkowaUsluga();
 
        $intervalA = new AbcInterval(new DateInterval('PT5M'));
        $intervalB = new RestInterval(new DateInterval('PT1M'));
        $intervalC = ...;
 
        $athlete = new Athlete(endurance = 5, stamina = 10); 
 
        $blocks = ....
        $vcsettings = ...
        $workout = new Workout($blocks, $vcsettings)
 
        // uruchom istotny kod, który w końcu coś robi
        $result = $workout->calculateDuration($athlete, $staminaCalculator); // przykladowo coś takiego
 
        // wyświetl sobie dane by zweryfikować czy calculateDuration() działa prawidłowo
        dump($result);
 
        die('a olać co tam by się chciało dalej dziać - nie ma znaczenia teraz');
    }
}
[PHP] pobierz, plaintext 

Utwórz sobie kilka takich akcji, które pozwolą Ci zweryfikować czy istotny kod Twojej aplikacji działa poprawnie. Jak ten problem będziesz miał rozwiązany będzie można przejść do tematu zapisu jakiś danych do bazy - ale wtedy zobaczysz, że nie będziesz już musiał sobie w ogóle zaprzątać głowy obliczeniami i kod znowu będzie prosty. Później rozwiążesz sobie problem wydobycia danych z bazy czy np. z formularzy - dwa kolejne problemy do osobnego rozpatrzenia. I tak dalej i tak dalej. W tych późniejszych zadaniach Symfony/Doctrine mocno ułatwią Ci pracę, bo te problemy adresują i potrafią rozwiązywać - ale to później. "best practices" mają zastosowanie dopiero w momencie korzystania z elementów Symfony/Doctrine - ale to zaś: później. Pamiętaj też, że nad nimi powinny stać "best practices" pisania kodu samego w sobie, a to już jest mocno niezależne od bibliotek, frameworków czy nawet języków.

PS. Jeśli zamienisz sobie śmieciowy kontroler na klasę testu jednostkowego, a dump() na serię assert() będziesz miał książkowy przykład TDD w stylu AAA. :-)

Nie musisz, ani nawet nie powinieneś tego ujmować w ramach framworka. Jeżeli z jakiegoś powodu FW by Cię do tego zmuszał byłby to słaby FW - Symfony na szczęście taki nie jest, chociaż nieraz po dokumentacjach mocno sugerują takie użycie. Ten fragment kodu raczej się nie powinien przejmować żadnymi encjami czy innymi formularzami, bo jest od nich niezależny. Jeżeli potrzebujesz formularza, utwórz dla niego dedykowaną klasę reprezentującą formularz - nie korzystaj z obiektów domenowych czy innych encji tutaj. Analogicznie z encjami. Klasy z różnych części aplikacji (część domenowa, część dostępu do źródła danych - encje, część związana z obsługą formularzy) nie powinny między sobą dziedziczyć.

Jeśli masz już jakiś fragment zrealizowany możesz go tutaj pokazać i później zacząć się zastanawiać nad następnymi problemami.

1. Nie bój się tworzyć wielu dedykowanych klas do rozwiązywania wielu różnych problemów w aplikacji. Unikaj raczej tworzenia "obiektu pod wszystkie możliwie zadania", bo to się nie sprawdza.
2. Staraj się by raczej detal implementacji warstwy zapisu danych (tutaj: baza danych + doctrine) nie wyciekał do innych warstw aplikacji. Innymi słowy obiekty domenowe same w sobie raczej nie powinny - bo i po co - mieć wiedzy n/t Doctrine'a.
Tutaj musiałbyś lepiej przybliżyć sytuację.
Dużą sztuką jest doprowadzić do tego by skomplikowany problem przedstawić w ujęciu trywialnego kodu. To jest jedna z trudniejszych umiejętności do nabycia.

IMHO zacznij sobie te problemy rozwiązywać po kolei, szybko prototypując. Pomiń na chwilę warstwę zapisu danych do bazy, skup się na problemie. Jak to będzie zrobione będziesz mógł przejść dalej, tj. do zapisu.

1. Przede wszystkim problemem tej klasy jest to, że musiałeś użyć aż trójelementowej listy by opisać co ona w ogóle robi. A robi zdecydowanie za dużo i powinna zostać rozbita na wyspecjalizowane obiekty.
2. Taka trochę ogólna uwaga co do tworzenia całych grafów encji, np. w createNewWorkoutBlock.

[PHP] pobierz, plaintext 
$block=new WorkoutBlock();
$task=new WorkoutTask();
 
$interval=new WorkoutInterval();
 
$rest=new WorkoutInterval();
$rest->setType(WorkoutInterval::TYPE_REST);
$rest->setDuration(10);
 
$task->addInterval($interval); // wylicza m. in. pozycję oraz ustawia dwu/jednostronną referencję
$task->addInterval($rest); // j/w
$block->addTask($task); // j/w
$workout->addBlock($block); // j/w
 
// raczej nie powinno znajdować się to już w tej metodzie, ale jak już to wystarczy
$this->em->persist($block);
$this->em->flush();
 
return $block;
[PHP] pobierz, plaintext 

Tyle wystarczy, logika wyliczania pozycji i innych tego typu rzeczy może spokojnie zostać zamknięta w encji nadrzędnej.
3. Trochę analogicznie jest z klonowaniem. Też przeniósłbym to do metod w ramach encji. Swoją drogą uważaj przy korzystaniu z clone w przypadku encji. Można z tego korzystać, ale niesie to za sobą kilka implikacji (patrz: dokumentacja). Zdecydowanie polecałbym Ci zrobić całość klonowania ręcznie. Zdecydowanie upraszcza i bardziej klarowne staje się wtedy to czy robimy płytką czy głęboką kopię.
4. Encje traktuj tylko jako coś co wykorzystywane jest niemal wyłącznie w komunikacji z bazą danych, nie jako fundament obliczeń dla całej apki (niestety takie podejście jest bardzo popularne w sieci/dokumentacji symfony).
5. Uwzględniając powyższy punkt oraz to co widać w kodzie, wydaje się, że tutaj encje są fajnie zaprojektowane, ale dalsze wyliczenia dla faktycznej logiki aplikacji nie powinny już być wykonywane na nich, ale na wyspecjalizowanych obiektach (nowych klas) z części nazwijmy to domenowej aplikacji. Jaka będzie różnica pomiędzy tymi dwoma zestawami obiektów? Przykładowo te z części domenowej w ogóle nie potrzebują żadnej wiedzy na temat jakiegoś użytkownika, który widzę, że się tam przewija. Nie potrzebują też żadnych właściwości z serii itemOrder - potrzebują, by kolekcje podrzędnych obiektów były po prostu uporządkowane (co PHP-owe tablice zapewniają).
5. getWorkoutDistance - te trzy zagnieżdżone foreache powinny być raczej zastąpione jednym, gdzie źródłem danych będzie jakiś iterator. Co lepsze taki iterator mógłby od razu w momencie swojego tworzenia mieć przekazane jakiego typu interwałów w ogóle (nie)chcemy z niego uzyskać (3 zagnieżdżone foreache z ifem zmieniają się w jednego foreacha). A co jest jeszcze lepsze? Ta metoda w ogóle może być spokojnie przeniesiona do nowej klasy WorkoutZCzęściDomenowej.
6. W angielskim nie ma słówka "brutto". :-P
7. Analogicznie jak z getWorkoutDistance wydaje się, że getEstimatedWorkoutDuration, getWorkoutDuration, getBlockDuration czy getTaskDuration można przenieść do wybranych klas z części domenowej.
8. Te wszystkie duration nie wyrażałbym w intach czy floatach, a w DateInterval. Zdecydowanie lepiej będzie nadawać się do reprezentowania takiej wartości - chociażby ze względu na obsługę jednostek, co wydaje się bezwzględnie konieczne tutaj.
9. Te wszystkie metody z vcsettingsami też wydają się do przeniesienia.
10. Unikaj rzucania wyjątków klasy Exception - użyj bardziej wyspecjalizowanej, a jeżeli takie nie ma (która pasowałaby do danej sytuacji) stwórz swoją.
11. Mam wrażenie, że do wyliczania wielu z tych interwałów/modyfikatorów/temp i innych świetnie mogłoby nadać się podejście bazujące na wzorcu wizytatora (ang. visitor pattern). Tylko z tym wstrzymałbym się na początku, bo kto wie czy nie jest to już właśnie to zbytnie rozdmuchanie o którym wcześniej pisaliśmy.

I tak chyba doszedłem do końca tej klasy, co do której wydaje się, że... może ona spokojnie być kompletnie zaorana! Wtedy też problem z pierwszego punktu sam się rozwiąże.

1. Szczerze mówiąc nie jestem dokładnie pewien czy w pełni poprawnie rozumiem problem (tak patrząc całościowo) - to na start. Nie wiem też czy przykłady jakie podałeś wyczerpują różnorodność detali czy właściwie na tym kończą się ich wariacje. Fajnie jakbyś może pokazał nawet jakąś okrojoną wersję kodu źródłowego (szczególnie $workoutService'u) - nieraz mówi więcej niż jego opis.
2. Bardzo ważne jest to jak bardzo chcesz, czy właściwie jak bardzo potrzebujesz "rozdmuchać" obsługę tego problemu. Chodzi o to by jednak potencjalnie prostego problemu nie zacząć rozwiązywać w niepotrzebnie rozbudowany, skomplikowany i obszerny sposób (takie ang. overengineering).
3. Wstępnie wygląda to tak, że obiekty pod $interval, $vcsettings czy $workout to wyłącznie wory do przenoszenia złożonych danych (DTO), a obliczenia z nimi związane zamiast być blisko danych w postaci metod (jak to jest przewidziane w OOP) są wyniesione gdzieś zupełnie indziej w kodzie.
4. Na początek spróbuj może troszkę odwrócić relację pomiędzy obiektami. Zamiast $workoutService->getDuration($workout, $vcsettings) spróbuj do tego podejść jako $workout->computeDuration($vcsettings??, $workoutService??). Być może te $vcsettings powinny być przekazane już w konstruktorze, a ten drugi argument w ogóle stanie się już niepotrzebny?
5. Ten fragment kodu (związany z samą logiką aplikacji) w miarę możliwości nie powinien mieć nawet świadomości Symfony, Doctrine'a (encji) czy innych frameworków. Dlaczego? Bo takie webowe FW nie chcą rozwiązywać konkretnych problemów, specyficznych dla Twojej aplikacji. Mają dać Ci szybką, solidną i wygodną "otoczkę" niezwiązaną bezpośrednio z celem działania samej apki (tutaj: wyliczania terningów), a związaną z całym tym "syfem" potrzebnym do tego by to gdzieś/jakoś/komuś uruchomić. Pozwól im skupić się na tym co faktycznie potrafią robić, samemu skupiając się mocno na swoim problemie - którego rozwiązanie już leży po Twojej stronie.

Nie wykorzystywać do tego w ogóle Doctrine'owskich encji, bo ich zadaniem nie jest reprezentowanie logiki aplikacji. Utwórz odpowiedni zestaw obiektów i kontraktów pomiędzy nimi do wykonania tych obliczeń/tego zadania. Ta część powinna być jak najmocniej przetestowana, bo tutaj testy są najbardziej wartościowe i faktycznie chronią przed błędami. Następnie utwórz drugi zestaw obiektów i kontraktów/relacji pomiędzy nimi do składowania tych danych w bazie (Doctrine'owskie encje). Na koniec przygotuj coś co pozwoli przenieść dane pomiędzy oboma strukturami. W każdej z tych trzech części skup się tylko na jednym zdaniu. Zazwyczaj tworzenie zewnętrznych usług do wykonywania obliczeń na niepowiązanych obiektach sprowadza się do programowania strukturalnego z wykorzystaniem obiektów/klas jako struktur transportujących dane - innymi słowy tracimy masę dobrodziejstw obiektówki.

Wepchasz to w JSON-a: będzie wolniejsze pod każdym względem: czasu zapisu, odczytu, modyfikacji, miejsca na dysku, czasu odczytu/zapisu przez PHP-a, wprowadzania zmian (będziesz musiał jak sam zaznaczyłeś pisać jakieś magiczne mappery/mergery) czyli ogólnie rzecz biorąc: dewelopmentu. Po co to wszystko? Jeżeli masz zasób, który składa się z relatywnie dużej liczby właściwości... no OK, z reguły jest to oznaka czegoś złego, ale tutaj nie wydaje się tu być przypadkiem. Tylko zlituj się sam nad sobą i stosuj pełne nazwy dla kolumn - to nie lata 80 by długość tego typu nazw miała dla czegoś znaczenie.

Doctrine'owska encja faktycznie będzie miała wtedy 30 właściwości i niech je sobie ma, skoro ona ma na dobrą sprawę odzwierciedlać to co jest w bazie danych. Jeżeli część z tych danych można jakoś sensownie zgrupować też to możesz zrobić przy pomocy @Embeeded. Przecież encję i tak wykorzystuje się tylko na poziomie/w warstwie aplikacji przy bezpośredniej komunikacji ze źródłem danych, także zbyt często z tym potworkiem do czynienia mieć nie będziesz.

Innymi słowy - mając 30 różnych danych (a wszystko wskazuje na to, że masz) musisz prędzej czy później się z nimi w kodzie spotkać i zdecydowanie lepiej mieć każdą z nich jawnie i klarownie zdefiniowaną.

Jeżeli każda z tych ~30 wartości reprezentuje coś innego, coś unikalnego, coś co nie jest jakąś grupą/kolekcją/agregatem danych to każda z nich powinna być osobnym bytem - w przypadku bazy danych: kolumną.
Nie potrzebujesz wykonywać takich operacji teraz do osiągnięcia wymaganego efektu, ale nie zdziw się jak za 5 miesięcy, ktoś Cię poprosi o wycinek danych z marca, albo o ten raport za jakieś 5000 czy 6000 czegoś tam i najszybszym wykonaniem tego nowego zadania będzie napisanie prostej SQL-ki.
No i od tego mamy SELECT * .... ;-)

Tu tkwi sendo problemu. Masz w ogóle jakiś problem wydajnościowy? Co chciałbyś optymalizować? Szybkość dewelopmentu, przyszłe utrzymanie, szybkość pobierania danych, objętość danych na dyskach/w pamięci? Od razu podpowiem, że z sugerowanych "optymalizacji" wszystkie pogarszają wymienione przeze mnie aspekty.
Pamiętaj, że przedwczesna czy mikro optymalizacja to niemal zawsze złe rozwiązanie.

> Ja wiem że pakowanie w szerz to nie jest najlepszy pomysł dla tego słcuam głosu ludu
Ale dlaczego? Jeżeli to są sensowne, różnorodne dane, co to jest w tym złego? Co to są dokładnie za dane? Trzymanie tego w formie jakieś zserializowanej tablicy, JSON-a itp. będzie najprawdopodobniej dużo mniej optymalne pod względem szybkości działania, objętości zajmowanego miejsca na dyskach/w pamięci, nie mówiąc już o jakimkolwiek wyszukiwaniu/filtrowaniu danych.

1. Nie każda warstwa abstrakcji będzie powodowała spowolnienie, jeżeli np. sama w sobie potrafi coś optymalizować, co normalnie by optymalizowane nie było - np. Second-Level Cache z Doctrine'a.
2. Ilość danych w bazie nie ma dla samego Doctrine'a specjalnego znaczenia.
3. Znaczenie będzie miała natomiast liczba wyciąganych przez dane zapytanie danych. Przetworzenie przykładowo 100 000 rekordów z bazy danych przy pomocy "czystego PHP-a" może być znacząco szybsze niż zrobienie tego z wykorzystaniem Doctrine'a ze względu na powolność PHP-a w tworzeniu obiektów jako takich.
4. Musisz sprawdzać jakie zapytania SQL finalnie generuje Doctrine. A że pracując z ORM-em często łatwo się zapomnieć w tym aspekcie stąd opinia n/t "powolnych ORM-ów".

Jedna mała acz bardzo, bardzo istotna uwaga. W MySQL kodowanie UTF8 to utf8mb4, nie utf8 - o tym ostatnim należałoby właściwie zapomnieć.

1. Jeżeli nie masz doświadczenia z szerokopojęta kryptografią nie próbuj robić niczego samemu - nie skończysz na tym za dobrze.
2. https://stackoverflow.com/questions/1820311...ers-have-the-sy
3. W praktyce jeżeli chcesz mieć pewność (czy właściwie większe prawdopodobieństwo), że nikt nie uzyska dostępu do Twojego oprgoramowania nie udostępniaj go. Udostępnij je jako całą usługę, tj. samodzielnie zajmuj się jej utrzymaniem dla poszczególnych klientów.

A możesz napisać co chciałbyś dzięki temu osiągnąć? Bo odnoszę wrażenie, że to nie jest najlepsze rozwiązanie problemu jaki masz.

Na takie pytanie można odpowiedzieć jedynie mając kontekst konkretnego przypadku.
I generalnie rzecz biorąc ta książka bardzo dobrze mówi. Co zatem w przypadku, gdy w kontruktorze potrzebowałbym 23 argumentów? Najprawdopodobniej mamy do czynienia ze źle zaprojektowanym obiektem, który próbuje zajmować się zbyt dużą liczbą rzeczy na raz.
Kontrolery to dokładnie takie same klasy jak wszystkie inne. Nie powinny spinać wszystkiego, bo co jest do wszystkiego to jest do niczego. ;-) Z jakiegoś powodu da się w sieci znaleźć "odczucia", że kontrolery to jakieś specjalne klasy - nie, nie są w żaden sposób wyjątkowe.
Wręcz dokładnie odwrotnie. :-) To własnie klasy/metody z części "logiki biznesowej" potrzebują wykonać całą ciężką pracę w programie, więc to w nich znajdziemy sporo zależności. Inną kwestią jest to, że nadal trzeba trzymać się zasady - im mniej zależności tym lepiej.

W skrócie: musiałbyś podać konkrety przypadek do omówienia (code review) nawet w jakimś pseudokodzie, bo tak to będziemy prowadzić akademicki wywdów.

Przede wszystkim trzeba pamiętać, że wszystkie hasła jakie podałeś, są dosyć... ogólne. We wszystkim trzeba zachować umiar i zdrowy rozsądek. Pokaż kod, który chciałbyś zweryfikować pod kątem zgodności z dobrymi praktykami, będziemy mogli ocenić czy coś wymaga poprawy czy nie.