V předešlém článku jsme uvedli metodu Quick and Dirty Programming. Jak bylo trefně poznamenáno v komentáři od kolegy u předešlého článku, tak není až tak relevantní otázka, kdo se s ní potkal, ale naopak, spíše ať se přihlásí ten, kdo se s touto metodou nikdy nesetkal.
Kde hledat hlavní příčiny tolerance k nečistému kódu a kde je podstata tak časté preference této metody tvorby SW?
Na ukázkovém příkladu z předešlého článku si nyní ukážeme konkrétní praktické postupy řešení situací s nečistým kódem. Ukážeme si efektivní použití testů na čistotu kódu a také postup, jak se nečistého kódu zbavit.
V předešlých článcích jsme si na jednoduchém příkladu vysvětlili jednu z nejčastějších chyb, kterou bychom mohli nazvat jako “zašpinění vnitřní vrstvy”. Podstatou této chyby je umístění evidované informace “příliš nízko”. Údaje o Čtenáři mají být ve Čtenáři (vyšší vrstva) a nikoliv v Osobě (nižší vrstva). Tento příklad má svou výhodu ve své jednoduchosti a průzračnosti (což je výhodou pro vysvětlení), ale musím podotknout, že situace bývají v praxi mnohem “záludnější”.
Uveďme si příklad na podobné téma. Zajímavá je statistika tohoto příkladu: Podle mého odhadu asi 90% vývojářů považuje chybné řešení tohoto příkladu za správné…
V předešlém článku jsme předložili model se studenty, zaměstnanci, osobami, zaznělo zadání ve smyslu “evidujeme půjčování knih” a otázka byla formulována takto: “Kam umístíme všechny požadované údaje o půjčování – zápůjčky, číslo průkazu, atd., v tomto modelu? Do studenta, do zaměstnance anebo do osoby, když i student i zaměstnanec si mohou půjčovat knihy?”
V tomto článku si ukážeme analyticky čisté a správné řešení.
V knize Analytické modelování pomocí UML v praxi (volně ke stažení zde) je uveden jeden názorný příklad vysvětlující určité záludnosti objektového paradigmatu, viz kaptiola 1.3.2, strana 12. Na tomto příkladu si uvedeme jeden z nepříjemných důsledků nedodržování čistoty kódu včetně zajímavé hádanky, která v knize není uvedena.
V této části mini seriálu o interakcích Extend a Include v Use Case Diagramu si ukážeme, jak se tento vztah chápe jako zadání do technologického návrhu a programování.
U jednoho z předešlých článků se objevil jeden natolik důležitý komentář, že jsem se rozhodl odpovědět na něj přímo tímto článkem.
Tento článek je pokračováním předešlého textu, viz zde. Ukážeme si nyní velmi názorný a vysvětlující příklad na použití vztahu Extend.
V mnoha školeních a konzultacích jsem takřka pokaždé narazil na rozepře mezi vývojáři o nasazení vztahu Extend. Jak se má tento vztah používat správně a korektně?
Nedávno mi přišel mail s tímto textem: Dobrý deň, pán Kravál,
V snahe zužitkovať znalosti získané na Vašom školení analytikov a návrhárov našej firmy sme narazili na jeden problém, možno nás budete vedieť nasmerovať k jeho riešeniu. Náš produkt obsahuje rozsiahlu konfiguračnú stránku, kde je možné veľa vecí zapnúť, vypnúť, nastaviť na jednu z možností, niektoré možnosti majú zmysel, iba keď sú zapnuté iné možnosti apod. Konfigurácia sa ukladá do súboru vo formáte kľúč=hodnota (java properties) Pri behu aplikácie sa hodnoty konfigurácie udržiavajú ako hodnoty inštančných premenných singleton objektu, ostatné časti aplikácie sa na ne dopytujú cez getter metódy. Podľa tejto konfigurácie sa potom produkt správa v rôznych situáciách (scenároch). Niektoré kroky sa podľa nastavenia vynechávajú, niektoré idú jednou z možných ciest apod. Ako toto najlepšie namodelovať? Jediné, čo mi napadlo, je case-om priradiť nejaké activity diagramy, ktoré popisujú logiku (vetvenie, algoritmy) v závislosti od nastavenia. Alebo aj samotné nastavenia modelovať ako triedy a ich atribúty? Ako ich potom previazať so scenármi?
V jedné z diskusí na našem serveru se objevil odkaz na zajímavý článek, ve kterém se autor snaží vysvětlit, proč je použití vzoru Singleton nepřípustné a proč jsou Singletony tzv. lháři (v originále “Singletons are Pathological Liars”). V tomto článku si blíže rozebereme tuto problematiku z pohledu tvorby čistého kódu.
Vyzkoušejte si malý test na OOP a Design Patterns. Po zaškrtnutí všech odpovědí si porovnejte svoje odpovědi s řešením, které se odkryje po stisku tlačítka s nápisem Ukázat správné odpovědi. Test se nikde neukládá a ani výsledky se nikam neposílají.
Při jedné konzultaci ve firmě, která vyvíjí technologické systémy, jsme narazili na zajímavý problém k řešení, který nakonec vedl k doporučení zavést logickou vrstvu aplikace a k použití vzoru BRIDGE.
V předešlém článku (viz zde) byl popsán rozdíl mezi prvky typu User Story (zavedené v agilních technikách vývoje) a prvky typu Use Case (zavedené v UML). Současně byl také vysvětlen jejich přímý vztah v souvislosti s vývojem IS.
Následující článek má za cíl ukázat, jak lze rychle a efektivně vyhledávat případy užití procesní školou (BPMN 2.0). Navíc poslouží také jako dobrý příklad na použití prvku v BPMN 2.0 zvaného Parallel Gateway.
Scénáře případů užití (Use Case Scenario) vyjadřují posloupnost kroků programu, ať už budoucího zatím pouze navrženého, anebo již implementovaného a nasazeného u zákazníka. Mohlo by se proto na první pohled zdát, že u popisu algoritmu nemá smysl hovořit o nějakých stavech a tedy s tím souvisejícím nastavením hodnot u scénáře případů užití (podobně jako je tomu u objektů).