W dniu wtorek, 4 lutego 2014 09:07:00 UTC+1 użytkownik Adam Wysocki napisał:

> Ja staram się trzymać zasady "jeden plik - jedna klasa".

To dobra zasada. Ale...

> Jak robię jakiś
> większy moduł, to po prostu robię mu podkatalog albo namespace i dzielę
> na pliki.

Też dobrze. Ale...

> A jak to jest z Wami?

Podobnie. Ale...

> Jeden duży plik (tzn. dwa - .h i .cpp), w nich jedna klasa, w tej klasie
> inne klasy (reprezentujące stany), każdy stan ma swoje podstany, które też
> są w tym samym pliku... i to się rozrasta.

To też dobry pomysł.

> Ja implementując coś podobnego wydzieliłbym wszystkie stany do osobnych
> plików.

A ja nie.

Jaka jest rola tych klas w projekcie? Jeżeli one reprezentują jakieś odrębne elementy
logiki programu, to zasługują na osobne pliki, nawet jeśli są małe w sensie linii
kodu. Ale jeśli te klasy są jedynie technicznymi detalami jakiegoś rozwiązania, to
należą tam, gdzie ten rozwiązywany problem.

Powiedzmy, że masz moduł, który czasem coś musi posortować i do tego celu używa
komparatora do funkcji std::sort. Ten komparator, pomimo tego, że jest klasą, jest
jedynie technicznym detalem tego modułu i nie ma sensu dla niego robić osobnego
pliku. Wręcz przeciwnie - on powinien być jak najbliżej tego sortowania.

Ale...

Może też się zdarzyć, że takich komparatorów będzie więcej i będą one przydatne w
kilku miejscach - wtedy jest sens zrobić osobny plik z takimi komparatorami.

Podobnie, jest sens zebrać razem kilka klas, które służą jako wyjątki. Nie ma sensu
robić dla nich osobnych plików.

Podobnie, jest sens zebrać razem klasy reprezentujące różne stany *jednego* automatu.
Bo to jest jeden automat.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com