C# &.NET. Cvičení Mgr. Filip Krijt.

Transkript

1 C# &.NET Cvičení Mgr. Filip Krijt CHARLES UNIVERSITY IN PRAGUE faculty of mathematics and physics

2 Plán Nežárka.NET Rekapitulace Objektový návrh Technické věci O hledání bugu Zadání další úlohy: Huffmanovo kódování Pokud zbyde čas: Zarovnávání do bloku

3 MVC design pattern Model Retrieves data from Manipulates View Selects Controller Is observed by Interacts with

4 Různé varianty oddělení funkcionality Na úrovni metod drtivá většina Na úrovni tříd Skládáním oficiální řešení Dědičností Proč má v případě Views smysl rozdělení do více tříd? Lepší testovatelnost a rozšiřitelnost Lepší sémantika jeden View odpovídá konkrétní webové stránce Funkcionalita se zapouzdří do dat => větší flexibilita

5 Zajímavé otázky Kam umístit přidání a odebrání do košíku? Má smysl mít IModel, IView a IController? Má smysl mít více Controllerů? Má smysl reprezentovat požadavky samostatnými objekty? Měl by být Controller bezstavový? Kdo by měl vytvářet konkrétní views (ve smyslu volání new)?

6 Stringy a řízení programu Stringy jsou vhodné pro textová data na zobrazení uživateli, ale máloco jiného Propagaci stringů programem je vhodné utnout co nejdříve to jde Tedy např. mít jasně oddělené parsování vstupu a jeho interpretaci Na předávání rozumně omezené množiny příkazů dál do programu je vhodnější výčtový typ (enum) Hlavně kvůli kontrole kompilátorem Enum se hodí i místo intových identifikátorů operací Pro složitější případy např. návrhový vzor Command

7 Krátce k větvení DEMO If a závorky Každý if nám zvedá úroveň odsazení Obecně: Hlubší odsazení než 4 úrovně není dobře Řešení pro if Else if Switch Řešení obecně: Extrakce vnitřků do samostatných funkcí

8 Prostor pro dotazy

9 Cesta k pěknému kódu Přemýšlet v objektech Návrh shora dolů Best practices Kódovací konvence (Coding Style) Self-documenting code Metodiky, heuristiky TDD Test Driven Development SOLID Pět základních principů pro OOP Návrhové vzory

10 Konvence (Coding style) Jména proměnných, závorky, whitespacing Cíl: Nelze poznat kdo psal co, všichni dokážou číst a chápat vše Obecně: Je celkem jedno jak je zvolíte, důležité je to všude dodržovat Nicméně.NET sám o sobě už nějaké konvence má, je tedy dobrý nápad je adoptovat Závorky na nové řádce Velikost písmen v názvech Pojmenovávání IEnumerable, IsEmpty Dodržovat jeden jazyk v kódu Dobře rozmýšlet jména!

11 Pojmenovávání v.net PascalCasing Třídy, rozhraní, metody camelcasing Lokální proměnné, parametry, private prvky třídy Rozhraní mají prefix I (IEnumerable, IDataProvider, IRobot ) Správná slova pro jména Třídy podstatná jména Rozhraní podstatná jména, přídavná jména Metody, funkce slovesa (Insert, Add, Process, Contains) Proměnné a vlastnosti podle datového typu, typicky podstatná jména, občas přídavná či větné fragmenty (HasValue, IsEmpty) SomethingException Pozor na obecná, nic neříkající jména (MyException, Input, Item ) Pozor na zkratky

12 Pár heuristik Pozor na dlouhé metody => Rozbít na menší metody Pozor na duplikaci kódu => Extrakce nové metody, třídy, nebo konstanty Pozor na globální prvky (static) V principu není příliš objektové Main musí být, ale jinak minimum Vizuální rozdělení věcí pomocí konců řádků Odřádkování za metodou, blokem atp.

13 Pár heuristik Pozor na omnitřídy Třída Reader by asi neměla mít metodu WriteLine :) Reader a Writer v jednom => Single responsibility principle, dvě třídy Pozor na nadměrnou delegaci Main(args) { Run(args) }

14 Prostor pro dotazy

15 O hledání bugu V CodExu bude nová úloha Máte se pokusit do deseti minut odladit Chybí celkem podstatná část úlohy :) Cílem je vyzkoušet si, jak dobře/špatně se takový program ladí

16 Základ: Zadání Poučení: Ladit samotný program bez přihlédnutí k zadání nemá smysl Tj. první co hledám když něco nefunguje jsou odchylky od specifikace, až poté bugy Klidně přečíst zadání třikrát :) Se zadáním to nebývá jednoduché Zákazník neví přesně co chce dokud to neuvidí I když to náhodou ví, není to schopen přesně popsat I když to je schopen přesně popsat, zadání se za rok vývoje může drasticky změnit

17 Pex 4 fun Puzzle metody se skrytou implementací Možné díky analýze programu Microsoftí nástroj Pex (typicky používán na generování unit testů) NSWI132 Analýza programů a verifikace kódu (RNDr. Pavel Parízek, Ph.D. D3S)

18 Zadání Huffmana