Pomieszanie klasy ze strukturą

0

Cześć,
przeglądając archiwa youtubowe związane z programowaniem w pewnym momencie dotarłem do ściany, w której pisząc kod patrzysz potem na niego i w sumie widzisz, że nie jest źle, ale to, czego się nasłuchałeś sugeruje Ci z tyłu głowy, że za jakiś czas, to jakie decyzje podjąłeś "kopnie Cię" przy dodawaniu nowych rzeczy, bądź poprawianiu jakiegoś błędu.

Z jednej strony słyszysz, aby "chronić niezmienniki", "najlepiej wszystkie pola do konstruktora", nie robić klas, które muszą mieć jakiś "postconstruktor", zastanawiać się, czy Ty na pewno piszesz klasę, czy strukturę, unikać funkcji void itd.* Niby człowiek wie, że konferencje są po to, żeby coś przedstawić i zaproponować tak bardziej radykalnie, niż ustawa przewiduje, ale głupio by było słuchać tyle godzin i zero refleksji, tak przejść obojętnie.

Przejdę do setna sprawy - otóż zacząłem używać sonara przy pracy z projektem. Napisałem klasę, która ma pola publiczne, a jedyną zmienną prywatną jest połączenie do bazy danych.
Można by rzecz, że klasa robi robotę - z jednej strony, gdy potrzebuję, to komplet pól inicjalizuję w konstruktorze, gdzie faktycznie wtedy potrzeba połączenia do bazy danych klasa sobie ładnie kompletuje brakujące dane, z drugiej strony, dzięki temu, że są publiczne, w innej klasie tworzę sobie vector takich obiektów uzupełniając zawartość obiektu "w locie", porozkładane na kilka małych funkcji, przez zwykły operator= do każdej zmiennej.

No i przy takim wynalazku jest zgłaszany błąd Classes should not contain both public and private data members.

Stąd też pojawił się dylemat w mojej głowie - czy takie pomieszanie klasy ze strukturą jest złe? Czy może po prostu napisać gettery i settery sztuka dla sztuki? A może zignorować to, bo bez kontekstu, który tutaj starałem się możliwie nakreślić jak najbardziej, że nie ma sensu się przejmować i trzeba iść dalej?

źródła:

Dlaczego wątpliwości są w wytwarzaniu kodu w C++, a w źródłach w większości to konferencje Javy? - Pewnie dlatego, że jednak większość "biznesu" tam siedzi, a poza tym chyba kwestia prelegentów i tego jak prezentują.

2

Przejdę do setna sprawy - otóż zacząłem używać sonara przy pracy z projektem. (...) No i przy takim wynalazku jest zgłaszany błąd

Pamiętam jak w jednym projekcie Architekt dodał Sonara i Sonar zapiszczał że ma mnóstwo bugów. MP powiedział że to nowy projekt i trzeba poprawić. Architekt spojrzał w konfigurację Sonara i odkrył ze zdziwieniem że sporo reguł wzajemnie się wyklucza. Pół dnia siedzieliśmy i wyrzucaliśmy niepasujące nam reguły :D

0

wyrzucaliśmy niepasujące nam reguły - tylko, pytanie co w nich było - bo jak tam mi "jęczy", że namespace nie może namierzyć prostym regexem, to też to ignoruję, ale tutaj niby jest poziom Major

Z drugiej strony sam fakt takiego "mieszania" mnie zastanawia - czy można, czy wypada, czy tylko wtedy, kiedy potrzebny jest wyjątek do potwierdzenia reguły?

2

No, ten link z błędem ma odnośniki do Core Guidelines z wyjaśnieniami (1, 1).

Napisałem klasę, która ma pola publiczne, a jedyną zmienną prywatną jest połączenie do bazy danych.
Można by rzecz, że klasa robi robotę - z jednej strony, gdy potrzebuję, to komplet pól inicjalizuję w konstruktorze, gdzie faktycznie wtedy potrzeba połączenia do bazy danych klasa sobie ładnie kompletuje brakujące dane, z drugiej strony, dzięki temu, że są publiczne, w innej klasie tworzę sobie vector takich obiektów uzupełniając zawartość obiektu "w locie", porozkładane na kilka małych funkcji, przez zwykły operator= do każdej zmiennej.

Innym słowy, przy inicjalizacji w locie pozostawiasz prywatne połączenie z baza niezainicjalizowane, co może cię kopnąć w twarz, gdy spróbujesz owego połączenia użyć z innej metody. A gdy tworzysz obiekt bez wszystkich danych to tworzysz i potem wyrzucasz nowe połączenie z bazą, zamiast po prostu skorzystać z jakiegoś już istniejącego, które mógłbyś miast tego przekazać do jakieś funkcji load(db) (z dodatkowym benefitem, że wówczas mógłbyś zamiast prawdziwej bazy wrzucić tu mocka i testować jednostkowo swoją klasę) - wówczas nie potrzebujesz trzymać tego połączenia jako prywatne.

0

Ok, z tej strony ma sens wystawić publicznie połączenie do bazy, ale to wtedy czy jest sens trzymać klasę? Niby mam jedną metodę, która to właśnie jest tylko użyta w tym rozbudowanym konstruktorze, ale pewnie w takiej sytuacji nie ma sensu trzymać jej prywatnej

2
BartoSAS napisał(a):

Dlaczego wątpliwości są w wytwarzaniu kodu w C++, a w źródłach w większości to konferencje Javy?

C++ jest językiem wieloparadygmatowym, a nowoczesne lata przesuwają go w stronę programowania templejtowego. Jako taki

  • nie jest konsekwentnie obiektowy (w praktyce)
  • mniej podatny na te ścieżki myślenia (klas <-> struktur)

No i schodzi w niszę (na własne wieloletnie życzenie). Trochę klepaczy BC++B 6.0, Qt, rasowych programistów C++ jest co kot napłakał - dla kogo te konferecje, chyba przy jednym stoliku kawiarnianym

0

Nie do końca jestem na bieżąco, co z nim robią nowoczesne lata - chciał nie chciał od pon. do pt. siedzę w MFC i C++11, tyle dla siebie, dla sportu rzeźbię w Qt. Więc mogę powiedzieć, że nowoczesność nowoczesnością, ale na koniec dnia trzeba iść spać, a rano wstać i używać starego sprzętu (no ale skoro zarabia, to nie można mieć pretensji do niego?).

To w takim razie nie przejmować się, czy w sumie tę wieloparadygmatowość traktować jako przywilej, który pozwala nam powołać się na różne style (byleby autor wiedział na jakie) i nikt nie może się czepiać na code review [ tak, dziki zachód w repo, nie ma sensownych reguł spisanych co do wytwarzania kodu, na które przystał zespół ]?

2
BartoSAS napisał(a):

To w takim razie nie przejmować się, czy w sumie tę wieloparadygmatowość traktować jako przywilej, który pozwala nam powołać się na różne style (byleby autor wiedział na jakie) i nikt nie może się czepiać na code review [ tak, dziki zachód w repo, nie ma sensownych reguł spisanych co do wytwarzania kodu, na które przystał zespół ]?

Gdzieś głęboko mi sie wydaje, ze wieloparadygmatowość JĘZYKA a wybory architektoniczne PROJEKTU (lub ich brak) to są sprawy w innych wymiarach

2
BartoSAS napisał(a):

To w takim razie nie przejmować się, czy w sumie tę wieloparadygmatowość traktować jako przywilej, który pozwala nam powołać się na różne style (byleby autor wiedział na jakie) i nikt nie może się czepiać na code review [ tak, dziki zachód w repo, nie ma sensownych reguł spisanych co do wytwarzania kodu, na które przystał zespół ]?

Nie wiem jak w C++ ale w Scali która też jest wieloparadygmatowa wybiera się styl w zespole dla projektu (a styl jest zależny od dziedziny problemu i poziomu zaawansowania zespołu). Najpopularniejsze możliwości:

  • Klepiemy klasy jak w Javie i mówimy że to OOP, można nawet kontener zależności użyć
  • Ładujemy Akkę (model aktorów) i robimy ze Scali ułomnego Erlanga/Eliksira
  • Ładujemy bibliotekę Scalaz/Cats i robimy ze Scali ułomnego Haskella
  • Ładujemy bibliotekę ZIO i ... w zasadzie nawet nie wiem jak to nazwać

Ważne żeby w projekcie trzymać jeden uzgodniony styl bo inaczej tą samą rzecz można rozwiązać na miliony sposobów i robi się Spagetti styli

1 użytkowników online, w tym zalogowanych: 0, gości: 1