Jak dostat do BaseControl službu, aniž by se jí museli potomci zabývat?
- Filip Procházka
- Moderator | 4668
Climber007 napsal(a):
Raději budu mít čistý a přehledný kód, než abych se v něm nevyznal a byl se v prsa, že používám teoreticky správné řešení.
Ten čistý kód právě mít nebudeš. A když budeš používat čisté řešení tak se v něm vyznáš.
- Climber007
- Člen | 105
Filip Procházka napsal(a):
Ten čistý kód právě mít nebudeš. A když budeš používat čisté řešení tak se v něm vyznáš.
Přijde mi přehlednější kupa public properties s inject anotací, než konstruktor od nevidím do nevidím. Sice je každýmu, kdo to uvidí, jasný o co jde, ale na druhou stranu je to nepřehledný. Už jen když chceš pár závislostí odebrat či upravit musíš to udělat na dvou místech. Stejně inject* metody.
- Tomáš Votruba
- Moderator | 1114
@Climber007 Pro mě jde primárně o typ kódu. Někde inject funguje, někde ne = musím přemýšlet, kde jsem a jestli se tady inject nějak nezapíná ⇒ větší chybovost, méně odolné vůči budoucím změnám.
Konstruktor funguje všude :).
Navíc při čtení kódu někým druhým se přidává WTF faktor.
- Climber007
- Člen | 105
@TomášVotruba S tím souhlasím. To zapínaní by mělo být co nejvíc intuitivní. Bohužel konstruktor se někdy použít nedá, viz nadpis vlákna. Duplikovat konstruktor do potomků je zbytečně moc práce na víc, když už máme autowiring, který to umí všechno udělat za nás.
WTF faktor chápu, na druhou stranu, když si otevřu kód jakéhokoliv frameworku, ve kterém denně nedělám, koukám na spoustu věcí taky jako puk.
- Filip Procházka
- Moderator | 4668
Pokud nepoužíváš konstrutor, tak si naflákáš 20 závislostí a ani tě nenapadne, že by to mělo být špatně. Úplně je to na tvé argumentaci vidět, že píšeš třídy co toho dělají moc a tedy potřebují moc závislostí. Jenže problém je, že řešíš důsledek a né příčinu. Důsledek je nepřehledný konstrutor, ten jsi vyřešil. Kdyby jsi vyřešil příčinu, tak máš přehledný konstruktor a čistý kód ;)