Kod:
sealed class FolderFilesMappings : Dictionary<string, IEnumerable<string>> { // brak specyficznej implementacji czy rozszerzen }
Powyższy kod przedstawia klasę, która jest wrapperem dla słownika. Rozwiązanie na pierwszy rzut oka wygląda ładnie ale osobiście zastanowiłbym się nad sensem pisania dodatkowej klasy, która tak naprawdę nic nie robi. Klasy powinny zawierać jakieś dane lub logikę. Powyższy fragment nie rozszerza funkcjonalności – wyłącznie daje opisową nazwę i skraca składnie – pisanie za każdym razem powyższej definicji słownika jest po prostu niewygodne.
Innym problemem jest fakt, że poniższa metoda nie zaakceptuje czystego słownika jako parametr:
internal class Program { private static void ProcessData(FolderFilesMappings mappings) { // logika tutaj } private static void Main(string[] args) { var data = new Dictionary<string, IEnumerable<string>>(); ProcessData(data); // blad kompilacji } }
W zasadzie FolderFilesMappings to zwykły słownik dlatego rozsądne wydaje się, aby metody akceptowały również bazowy słownik jako parametr wejściowy.
Jeśli podklasa nie dodaje żadnego pola, zachowania wtedy lepszym rozwiązaniem jest użycie klauzuli using. Ma to sens zwłaszcza, gdy klasa jest używana wyłącznie w jednym pliku – wtedy zupełnie nie ma sensu na pisanie kolejnej klasy. Przykład:
using System.Collections.Generic; using FolderFilesMappings = System.Collections.Generic.Dictionary<string, System.Collections.Generic.IEnumerable<string>>; internal class Program { private static void ProcessData(FolderFilesMappings mappings) { // logika tutaj } private static void Main(string[] args) { var data = new Dictionary<string, IEnumerable<string>>(); ProcessData(data); } }
Dzięki using można używać skróconej formy FolderFilesMapping ale jeśli to koniecznie, również można operować na czystym słowniku. Klauzula using to czysty skrót – na etapie kompilacji wszystkie wystąpienia FolderFilesMapping zostaną zastąpione definicją słownika. Nie ma sensu tworzenia nowej klasy tylko po to aby służyła ona jako zwykły skrót.
Moim zdaniem po kolekcjach nie powinno się dziedziczyc. Jest to związane z faktem że w tych klasach i tak niewiele da się nadpisać więc zmiana zachowania takiej klasy jest trudna. Nowe metody można dodawać przez ExtenssionMethods. Przy tworzeniu własnych klas tego typu jestem zwolennikiem wzorca dekorator.