Ja staram się trzymać zasady "jeden plik - jedna klasa". Jak robię jakiś
większy moduł, to po prostu robię mu podkatalog albo namespace i dzielę
na pliki. A jak to jest z Wami? Pytam, bo naszła mnie taka refleksja po
poprawianiu kodu po kimś (dobrym programiście, po prostu taki ma styl).
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.

Ja implementując coś podobnego wydzieliłbym wszystkie stany do osobnych
plików. Nie do przesady, bo jak coś jest małe, to można to pogrupować,
żeby nie mnożyć bytów ponad potrzeby... no ale jednak.

A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa", czy
raczej "jeden plik - jeden funkcjonalny moduł"?

Z ekstremalnych ciekawostek - spotkałem się z plikiem .cpp 600kB.

Proszę fira i innych świrów o nie udzielanie się w wątku.

--
"zanim nastala era internetu, kazdy wiejski glupek siedzial w swojej wiosce"
http://www.chmurka.net/

do góry

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

do góry

On 2014-02-04, Adam Wysocki <g...@s...invalid> wrote:
> Ja staram się trzymać zasady "jeden plik - jedna klasa". Jak robię jakiś
> większy moduł, to po prostu robię mu podkatalog albo namespace i dzielę
> na pliki. A jak to jest z Wami? Pytam, bo naszła mnie taka refleksja po
> poprawianiu kodu po kimś (dobrym programiście, po prostu taki ma styl).
> 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.
>
> Ja implementując coś podobnego wydzieliłbym wszystkie stany do osobnych
> plików. Nie do przesady, bo jak coś jest małe, to można to pogrupować,
> żeby nie mnożyć bytów ponad potrzeby... no ale jednak.
>
> A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa", czy
> raczej "jeden plik - jeden funkcjonalny moduł"?

W Erlangu moduł da się wpakować tylko do osobnego pliku, więc podział na
pliki jest oczywisty. W Perlu rzadko widuję więcej niż jeden pakiet
zdefiniowany w module, a to pakiety odpowiadają klasom. W Pythonie
podział już wygląda inaczej: jeden moduł często zawiera kilka klas,
a czasem też swobodne funkcje.

Wszystko zależy od języka, zwyczajów danego środowiska programistów i od
konkretnego problemu do rozwiązania.

--
Secunia non olet.
Stanislaw Klekot

do góry

Maciej Sobczak <s...@g...com> wrote:

> 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.

Tu podział nie jest jasny. Teoretycznie są to techniczne detale jakiegoś
rozwiązania, ale to rozwiązanie samo w sobie równie dobrze mogłoby być
oddzielną aplikacją (zaprojektowanie i napisanie tego modułu zajęło ok.
70 MD). Moduł ma też inne pliki (np. helpery są osobno, osobno jest też
bezpośrednia obsługa hardware), ale sam moduł, będący maszyną stanów, jest
w jednym dużym pliku.

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

I tak jest to zrobione. Dla odmiany mój inny automat w tym projekcie (robi
coś zupełnie innego, ale jest podobnie złożony jak ten) ma ze 40 stanów,
pogrupowanych w namespace, każdy stan w osobnym pliku (ale jego małe
podstany w jednym) i nie wyobrażam sobie mieć tego w jednym dużym pliku
i jakoś tym zarządzać...

--
"zanim nastala era internetu, kazdy wiejski glupek siedzial w swojej wiosce"
http://www.chmurka.net/

do góry

mam pomysł, zasrajmy mu wątek, jak ten ciul robi z innymi...

do góry

Adam Wysocki wrote:
> Ja staram się trzymać zasady "jeden plik - jedna klasa". Jak robię jakiś
> większy moduł, to po prostu robię mu podkatalog albo namespace i dzielę
> na pliki. A jak to jest z Wami? Pytam, bo naszła mnie taka refleksja po
> poprawianiu kodu po kimś (dobrym programiście, po prostu taki ma styl).
> 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.
>
> Ja implementując coś podobnego wydzieliłbym wszystkie stany do osobnych
> plików. Nie do przesady, bo jak coś jest małe, to można to pogrupować,
> żeby nie mnożyć bytów ponad potrzeby... no ale jednak.
>
> A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa", czy
> raczej "jeden plik - jeden funkcjonalny moduł"?
>
> Z ekstremalnych ciekawostek - spotkałem się z plikiem .cpp 600kB.
>
> Proszę fira i innych świrów o nie udzielanie się w wątku.
>

oddzielne pliki dla wszystkich klas uzywanych w wiecej niz jednym miejscu

Jesli jakas klasa / struktura powstała dla wygody i jest uzywana tylko
i wyłącznie w innej jednej klasie to nie ma sensu dzielic tego na pliki.

Jesli "cos" moze byc wykorzystane jeszcze gdzies to ląduje w oddzielnym
pliku.


oczywiscie są wyjątki bo pewnych templatów nie da się skompilowac z
głową lub nie da się skompilować w ogóle ja są oddzielnie

do góry

On 2014-02-04 09:07, Adam Wysocki wrote:
> Ja staram się trzymać zasady "jeden plik - jedna klasa".

Przemigrowałem z tej zasady do zasady wywazonej: jedna klasa na plik,
ale czesto w pliku namespace { ... } z kilkoma klasami ktore na 100% nie
będą nigdzie potrzebne (gdyby były to byłby to bład) poza tym plikiem i
ma to zastosowanie głównie w adapterach. Częściowo rozwiązuje to problem
"wykradania" internalnych nagłówków przez miejsca w kodzie które sobie
robią swobodne inkludy a które to wykradanie obecnie odbija się czkawką.

Ogolnie im mniej sztywne zasady tym lepiej. Mam klasę (duzy visitor)
który zajmuje w pliku koło 50kB. Czy warto go podzielić na kilka cpp
kazdy z osobną metodą? Moim zdaniem warto nagiąć zasady i to zrobić.
Ułatwi to czytanie dzieląc kod nie na sztuczne jednostki klas, ale na
logiczne jednostki celu danej metody.

Innymi słowy: jeden plik na ... coś. Niekoniecznie na klasę jesli to
ułatwi czytelność.

PS. Duża ilośc plików cpp z jednoczesną ślepą wiarą w szybkość PH kończy
sie źle ...

do góry

On Tuesday, 4 February 2014 08:07:00 UTC, Adam Wysocki wrote:
> [...]
>
> A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa", czy
> raczej "jeden plik - jeden funkcjonalny moduł"?

Jakiś czas temu gdzieś na SO napotkałem na zasadę Alexa Martelliego
dot. organizacji plików/modułów/pakietów w Pythonie:
logical unit of packaging, czyli kto kogo wymaga i używa.

I mimo, że to Python, staram się to stosować jako zasadę
w organizacji kodu (jakiegokolwiek).
Nawet w C++, modułem może być jeden plik, para .h/.cpp jak lub więcej,

Pozdrawiam,
--
Mateusz Łoskot, http://mateusz.loskot.net

do góry

W dniu 2014-02-05 17:33, Sebastian Biały pisze:
> On 2014-02-04 09:07, Adam Wysocki wrote:
>> Ja staram się trzymać zasady "jeden plik - jedna klasa".
[...]
> Innymi słowy: jeden plik na ... coś. Niekoniecznie na klasę jesli to
> ułatwi czytelność.

W ogólności - klasy w języku programowania nie koniecznie odwzorowują
1:1 elementarne (w sensie logiki aplikacji, a nie implementacji)
odpowiedzialności czy elementy funkcjonalne.

--
Paweł Kierski
n...@p...net

do góry

Mateusz Loskot wrote:
> On Tuesday, 4 February 2014 08:07:00 UTC, Adam Wysocki wrote:
>> [...]
>>
>> A jak Wy to robicie? Trzymacie się zasady "jeden plik - jedna klasa", czy
>> raczej "jeden plik - jeden funkcjonalny moduł"?
>
> Jakiś czas temu gdzieś na SO napotkałem na zasadę Alexa Martelliego
> dot. organizacji plików/modułów/pakietów w Pythonie:
> logical unit of packaging, czyli kto kogo wymaga i używa.
>
> I mimo, że to Python, staram się to stosować jako zasadę
> w organizacji kodu (jakiegokolwiek).
> Nawet w C++, modułem może być jeden plik, para .h/.cpp jak lub więcej,
>
> Pozdrawiam,
>

cała teoria na dwóch stronach
http://en.wikipedia.org/wiki/Cohesion_(computer_scie
nce)
http://en.wikipedia.org/wiki/Coupling_(computer_prog
ramming)

do góry