Hermetyczność w praktyce.

Hermetyczność w C# w praktyce - jak stosować ?

Czy istnieje jakiś jeden, z góry uznany w środowisku programistów sposób na organizację kodu w programie?

Chciałbym z góry mieć jakiś schemat/ strukturę kodu, który wspierałby hermetyczność - tak aby poszczególne moduły/ funkcjonalności łatwiej dawały się modyfikować i były bardziej elastyczne w perspektywie całego kodu (w C++ gdy zmieniałem kawałek kodu, cały program się sypał)

PRIMO: W klasie poniżej powinny być wyłącznie metody będące Event Handler'ami dla kontrolek (te standardowe i customized (event += EventHandler())

public partial class Form1: Form {}

SECUNDO: Dla logiki programu (komponent Model w MVC) tworzę osobną klasę (lub wiele klas). Wewnątrz jednej przestrzeni nazw mam zawarte wszystkie klasy (i wewnątrz nich metody), oraz delegaty, interfejsy, struktury, enumeracje

Pytania

1. Czy organizacja plików w screenie poniżej jest godna polecenia/ dominująca?
2. Jak mogę dostać się do środka wybranej klasy, metody, enumeracji itd. (na screenie poniżej - zawsze mnie ciekawiło jak wygląda profesjonalnie napisany kod)
3. Po co w ogóle VS daje możliwość tworzenia własnych folderów w SolutionExplorer ? W jakich sytuacjach używanie folderów jest uzasadnione?
4. Ile powinno być plików .cs (dodawanych jako Solution->lpm->Add->new item -> class) i czym się kierować przy ich tworzeniu/ rozdzielaniu? (póki co mam tylko jeden i nie wiem czy tworzenie większej ilości nie łamie zasady brzytwy Ockhama)

kvsanagi napisał(a):

1. Czy organizacja plików w screenie poniżej jest godna polecenia/ dominująca?

nie wiem o co chodzi

2. Jak mogę dostać się do środka wybranej klasy, metody, enumeracji itd. (na screenie poniżej - zawsze mnie ciekawiło jak wygląda profesjonalnie napisany kod)

chcesz zobaczyć źródła .NET frameworka czy czego? ILSpy / dotPeek możesz zdekompilować kod i podejrzeć w postaci zbliżonej. Możesz zintegrować przez resharpera tak że po naciśnięciu F12 zobaczysz zdekompilowane źródła

2. Po co w ogóle VS daje możliwość tworzenia własnych folderów w SolutionExplorer ? W jakich sytuacjach używanie folderów jest uzasadnione?

żeby móc poukładać sobie logicznie pliki - jeśli mówisz o folderach na solucje to ta opcja nie była dostępna jeszcze do niedawna w wersji express tylko w wersji pro i ultimate. Teraz jest dostępna w wersji community i pozwala na grupowanie projektów (przydaje się gdy projektów w solucji jest kilkadziesiąt, ale zazwyczaj przy domowych projekcikach jest tylko jeden projekt).

4. Ile powinno być plików .cs (dodawanych jako Solution->lpm->Add->new item -> class) i czym się kierować przy ich tworzeniu/ rozdzielaniu? (póki co mam tylko jeden i nie wiem czy tworzenie większej ilości nie łamie zasady brzytwy Ockhama)

każda klasa / enum / struktura to oddzielny plik - w normalnym projekcie jest ich zazwyczaj kilkaset. Układa się je w foldery pokrywające się z namespacem, w jednym folderze nie powinno być mniej niż dwa pliki.
Nie wyobrażam sobie projektu na kilkadziesiąt tysięcy linii kodu w jednym pliku

2. Dekompilacja nie jest potrzebna, wszystko jest publiczne:
   http://referencesource.microsoft.com/
   https://github.com/dotnet/core
   https://github.com/dotnet/corefx

A - jeszcze jedna ważna rzecz. Kod frameworka to nie jest kod, który należy brać za wzór własnych aplikacji. Frameworki pisze się inaczej niż programy użytkowe.

4. Nie przesadzałbym z upychaniem każdego tworu do oddzielnego pliku. Kilka klas i enumów stanowiących jedną prostą hierarchię można trzymać w jednym pliku - byle oczywiście miał sensowny rozmiar.