C# nyelvi eszközök hatékony használata

Question 1

Nyelvi elemek

Answer 1

1. Implicit változó típus (var) használata
2. Readonly a const helyett
3. Cast helyett is/as
4. String.format() helyett interpolált string
5. Kultúra-specifikus esetben FormattableString használata
6. Stringesen leírt API-k kerülése
7. Visszahívások kifejezése Delegate-el
8. Null conditional (? operátor) használata Event Invocation esetén
9. Boxing és Unboxing minimalizálása
10. new modifier használata szülő osztály nonvirtual metódusaira

Question 2

Implicit változó típus (var) használata

Answer 2

Ez nem egy dinamikus típus, hanem a jobb oldal által meghatározott típus.
Ne minden esetben ezt használjuk, mert veszít kódunk az olvashatóságából, a szám típusok veszítenek pontosságukból.
Használjuk akkor, ha nem vagyunk biztosak egy adott változó típusában (pl lokális változó, ami egy db query eredménye).

Question 3

Readonly a const helyett

Answer 3

Readonly-t kell preferálni, mert a const csak szám, string és null lehet. Readonly ezzel szemben bármi, használható vele a new kulcsszó is.
Const fordítási időben rögzül, readonly futásidőben helyben vagy konstruktoron keresztül

Question 4

Cast helyett is/as

Answer 4

Castolás esetén null check és kivétel kezelés is szükséges, míg is/as esetében a visszatérési értéket kell null checkelni. Az is/as operátorok ellenőrzik a futásidő közbeni objektum típusát és nem végeznek rajta műveletet, kivéve a boxing, ha az szükséges.

Question 5

String.format() helyett interpolált string

Answer 5

Olvashatóbb kódot eredményez, a compiler számára is jobb static type check szempontból. String.Format() esetén a compiler nem validálja az argumentumok számát, nehézzé válik azok ellenőrzése. Interpolált string esetén van validáció erre, bármilyen C# expression elhelyezhető benne elágazást és ciklust leszámítva

Question 6

Kultúra-specifikus esetben FormattableString használata

Answer 6

Egy interpolált stringből készíthetünk FormattableString típust, amit utána szabadabban újra felhasználhatunk más kultúrákban is megszokott módon egyszerűen.

Question 7

Stringesen leírt API-k elkerülése

Answer 7

A nameof() operátor előnyben részesítése, mert így az adott változó átnevezését követően minden nameof() ban megjelenésénél is dinamikusan megtörténik az átnevezés

Question 8

Visszahívások kifejezése Delegate-el

Answer 8

A Delegate egy olyan objektum, ami metódus refeneciát tartalmaz, ezért típushoz nem kötött, futásidőben configurálható több vevő értesítésére. Pár beépített példa: .Range(), .Find(), .TrueForAll(), .ForEach() stb.

Question 9

Null Conditional (? Operátor) használata Event Invocation esetén

Answer 9

A null-check legegyszerűbb módja event invocation esetén a ? operátor: kompakt és könnyen olvasható, a complier type-safe Invoke() metódust generál minden delegate-re az event definíciójában. Mindezek mellett ez az operátor szál biztos!

Question 10

Boxing és Unboxing minimalizálása

Answer 10

Kerüljük a system.object típusba más típusú változók pakolását és az erre a típusra való implicit konvertálást. Ez a típus a heap-en jön létre, ekkor egy érték típus konvertálódik referencia típussá

Question 11

new modifier használata szülő osztály nonvirtual metódusaira

Answer 11

A nonvirtual metódusok statikusan kötődnek, a virtuálisak dinamikusan.
Nem kell minden metódust virtuallá tenni a szülő osztályban, csak amiket a leszármazott osztályoknak meg kell változtatnia. A new modifiert akkor használjuk, ha egy szülő osztálybeli metódus új verzióját akarjuk létrehozni ugyanazon a néven
egy leszármazott osztályban!

Question 12

General programming

Answer 12

1. Minimális ÉS elégséges megszorítások definiálása
2. Generikus algoritmusok specifikálása futásidei típus ellenőrzéssel
3. Reláció definiálása beépített interfacekkel
4. Generikus osztályok IDisposable megvalósítása
5. Generikus covariance és contravariance támogatása
6. Delegate-k használata metódus megszorításként a típus paramétereken
7. Ne specifikáljunk generikus szülő osztályban és interfaceben
8. Generikus metódusok használata
9. Klasszikus interfacek implementálása a generikus mellett
10. Minimális interface contract a kiterjesztő metódusokkal
11. Típus specifikus gyűjteményekhez generikus segéd metódusok

Question 13

Minimális ÉS elégséges megszorítások definiálása

Answer 13

A megszorítások azt kommunikálják a compiler felé, hogy a T-től funkcionalitásokat várunk el a system.object funkcionalitásokon felül. Jól definiált megszorítások kevesebb kódot, kevesebb runtime errort és egyéb hibát eredményeznek.
Sok kódot megspórolhatunk, ha egy metódusban nem manuálisan validáljuk a bemenő T paramétereket, hanem pl interface contract-tal tesszük ezt.
~~~
public static bool AreEqual2<T>(T left, T right)
where T : IComparable<T> =>
left.CompareTo(right) == 0;</T></T>

~~~

Question 14

Generikus algoritmusok specifikálása futásidei típus ellenőrzéssel

Answer 14

Futásidőben nem tudjuk még mi lesz T ezért készüljünk fel minden olyan típusra amit máshogy szeretnénk kezelni.
Példa:
~~~
public class GenericAlgorithm<T>
{
public void ProcessData(T data)
{
// Futásidei típusellenőrzés
if (data is int)
{
int intValue = (int)data;
Console.WriteLine($"Process int data: {intValue}");
}
else if (data is string)
{
string stringValue = (string)data;
Console.WriteLine($"Process string data: {stringValue}");
}
else
{
Console.WriteLine("Unsupported data type");
}
}
}</T>

~~~

Question 15

Reláció definiálása beépített interfacekkel

Answer 15

IComparable<T> és IComparer<T> használata, hogy különböző colection-ök az adott T-ből rendezhetőek legyenek.</T></T>

Question 16

Generikus osztályok IDisposable megvalósítása

Answer 16

A megszorítások feladata runtime errorból compile-time errort csinálni, valamint dokumentációt adni az adott osztályt használóknak. Szükséges, hogy implementáljuk az IDisposable interfacet, így rendelkezhetünk a felszabadításról.

Question 17

Generikus covariance és contravariance támogatása

Answer 17

A covariance és contravariance megadja milyen körülmények között konvertálható egy típus egy másik típusra. Amikor lehetséges, tegyük ezeket lehetővé generikus interfacek és delegate-k esetén. Generikus T-nél használjuk az in/out kulcsszókat, hogy jelezzük a compilernek, ha esetleg csak be-, vagy kimeneti T lesz a T (pl out T esetén T nem módosul).

Question 18

Delegate-k használata metódus megszorításként a típus paramétereken

Answer 18

Ha az Osztályunknak akarunk Add() metódust, az IAdd<T> interface megalkotásával kezdjük úgy, hogy az támogassa a Delegate alapú interface contractokat.</T>

Question 19

Ne specifikáljunk generikus szülő osztályban és interfaceben

Answer 19

Ha generikus osztályt/interfacet írunk, a metódusok benne legyenek generikusok, ne típus specifikusak.

Question 20

Generikus metódusok használata

Answer 20

Generikus metódusokat használhatuk nem generikus osztályokban is, de célravezető, ha generikus osztályokban tesszük, így egyszerűbb a kód.

Question 21

Klasszikus interfacek implementálása a generikus mellett

Answer 21

Ha több hasonló típus van, generikusan nehéz jó megoldást adni pl egyenlőség vizsgálatukra. Ilyenkor specializálni kell az egyik típusra, az IEquatable<t>-t implementálni, majd az overrideon belül az is/as kulcsszókkal specializálni.</t>

Question 22

Minimális interface contract a kiterjesztő metódusokkal

Answer 22

Generikus metódus szinten használhatuk interface contractot (where T: valami).

Question 23

Típus specifikus gyűjteményekhez generikus segéd metódusok

Answer 23

Ha típus specifikus gyűjteményeket használunk, írhatunk hozzájuk generikus Min(), Max(), Sum(), Avg(), stb metódusokat.

Question 24

Kivételkezelés

Answer 24

1. Kivételek használata metódus contract hiba jelzésére
2. Using/try-finally használata erőforrás felszabadításra
3. Készítsünk saját exception osztályokat saját use-casekre
4. Garantáljuk a program futását exception esetén:
5. Exception filter használata catch és re-throw helyett
6. Mellékhatások kezelése exception filterrel

Question 25

Kivételek használata metódus contract hiba jelzésére

Answer 25

Egy metódusnál előre beláthatatlan hibák keletkezhetnek melyek megszakíthatják a program normál működését ezért hozzunk létre több publikus metódust melyek nevei arra utalnak, hogy lehetséges, hogy kivétel fog keletkezni, ezzel minimalizálva annak az esélyét hogy a metódust használó személy nem várt hibát fog futásidőben kapni. A TryDoWork() metódus validálja a bemeneti paramétereket és a metódus futásához szükséges belső paramétereket, majd meghívja a Work() metódust, rossz paraméterek esetén nem dob kivételt. A DoWork() metódus meghívja a Work() metódust, de hibát dobunk benne ha valami nem megfelelő. (A Work() metódus privát)
Röviden olyan ha egy olyan metódust írunk amiben keletkezhet kivétel szolgáltassunk olyan metudóst is mellé amely validál, de nem keletkezik kivétel sikertelenség esetén.

Question 26

Using/try-finally használata erőforrás felszabadításra

Answer 26

Használjuk az IDisposable interface Dispose() metódusát using vagy try-finally blokkban, ha a használt típus ezt implementálja. A Dispose() nem távolít el objektumokat a memóriából, ez csak egy hook, ami lehetővé teszi a kezeletlen erőforrások felszabadítását.

Question 27

Készítsünk saját exception osztályokat saját use-casekre

Answer 27

Mivel az a good practice, ha minden lehetséges hibára más catch ágat írunk, így előnyös, ha saját típusainkhoz saját kivétel típusokat is definiálunk. Ezekben érdemes az eredeti hibát is eltárolni, mint inner exception, majd több kontextust hozzáadni a hiba természetéről.

Question 28

Garantáljuk a program futását exception esetén

Answer 28

Strong Guarantee preferálása annyit tesz, hogy egy művelet vagy lefut helyesen, vagy nem változtat a program állapotán. Utóbbi esetben a keletkező hibát úgy kell lekezeni, hogy annak ne maradjon nyoma a futás további részében.

Question 29

Exception filter használata catch és re-throw helyett

Answer 29

Az exception filter egy when(feltétel), ami a catch-hez csatlakozik. Ennek segítségével a több információ áll rendelkezésre debugging közben, valamint jobb lesz a program teljesítménye is.
~~~
try{}
catch (Exception ex) when (ex is MyCriticalException)
{
// Handle critical error
}
catch (Exception ex){ // Handle other exceptions }
~~~

Question 30

Mellékhatások kezelése exception filterrel

Answer 30

Oximoronnak tűnik, de használhatunk olyan filtert, ami mindig hamis, vagy épp mindig igaz. Ennek egyértelmű célja például a hiba logolás valahogy így:
~~~
catch(Exception e) when log(e) {}
~~~
Ezt bármely try-catch blokkba beilleszthetjük első catch ágnak, a futást nem fogja befolyásolni, cserébe információt gyűjt a hibákról.