Dlaczego klasy danych są uważane za zapach kodu?

W tym artykule twierdzi się, że klasa danych to „zapach kodu”. Powód:

To normalne, gdy nowo utworzona klasa zawiera tylko kilka pól publicznych (a może nawet garść programów pobierających / ustawiających). Ale prawdziwą mocą obiektów jest to, że mogą one zawierać typy zachowania lub operacje na swoich danych.

Dlaczego obiekt zawiera tylko dane? Jeśli podstawowym obowiązkiem klasy jest reprezentowanie danych, czy dodanie metod działających na danych nie złamałoby zasady pojedynczej odpowiedzialności ?

Nie ma absolutnie nic złego w posiadaniu czystych obiektów danych. Autor utworu szczerze mówiąc nie wie o czym mówi.

Takie myślenie wynika ze starego, nieudanego pomysłu, że „prawdziwe OO” jest najlepszym sposobem na programowanie i że „prawdziwy OO” polega na „bogatych modelach danych”, w których łączy się dane i funkcjonalność.

Rzeczywistość pokazała nam, że tak naprawdę jest odwrotnie, szczególnie w tym świecie rozwiązań wielowątkowych. Czyste funkcje w połączeniu z niezmiennymi obiektami danych to zdecydowanie lepszy sposób na kodowanie.

Nie ma absolutnie nic złego w posiadaniu czystych obiektów danych. Autor ma opinię, której nie podzielają znani mi twórcy oprogramowania.

Zwłaszcza w przypadku mapowania bazy danych na ogół masz klasy jednostek, które zawierają tylko pola przechowywane w bazie danych oraz moduły pobierające i ustawiające. Wikipedia Hibernacja (framework)

Idea dziury w ziarenach Java wykorzystywanych przez wiele narzędzi / struktur opiera się na klasach danych zwanych ziarenkami, które zawierają tylko pola oraz powiązane z nimi funkcje pobierające i ustawiające. Wikipdia JavaBeans

Fazit:
Jeśli ktoś twierdzi, że coś jest „złe” lub „pachnie kodem”, zawsze powinieneś szukać podanych powodów. Jeśli przyczyny nie przekonują, zapytaj kogoś o lepsze powody lub inną opinię. (Tak jak zrobiłeś na tym forum)

Dobry argument, dlaczego Martin Fowler:

„Tell-Don't-Ask to zasada, która pomaga ludziom pamiętać, że orientacja obiektowa polega na łączeniu danych z funkcjami działającymi na tych danych. Przypomina nam, że zamiast pytać o dane dane i działać na podstawie tych danych, powinien zamiast tego powiedzieć obiektowi, co ma robić. To zachęca do przeniesienia zachowania na obiekt, aby przejść do danych ”.

https://martinfowler.com/bliki/TellDontAsk.html

Musisz zrozumieć, że istnieją dwa rodzaje obiektów:

• Obiekty, które mają zachowanie . Powinny one powstrzymywać się od publicznego udostępniania większości / dowolnych członków danych. Spodziewam się tylko bardzo niewielu zdefiniowanych metod dostępu.

  Przykładem może być skompilowane wyrażenie regularne: Obiekt jest tworzony w celu zapewnienia określonego zachowania (w celu dopasowania łańcucha do określonego wyrażenia regularnego i zgłoszenia (częściowych) dopasowań), ale sposób, w jaki skompilowane wyrażenie regularne działa, nie należy do użytkownika biznes.

  Większość klas, które piszę, należą do tej kategorii.

• Obiekty, które są tak naprawdę tylko danymi . Powinny one po prostu ogłosić wszystkich swoich członków publicznie (lub zapewnić im pełny zestaw akcesoriów).

  Przykładem może być klasa Point2D. Nie ma absolutnie żadnego niezmiennika, który należy zapewnić członkom tej klasy, a użytkownicy powinni mieć dostęp do danych za pośrednictwem myPoint.xi myPoint.y.

  Osobiście nie używam takich klas dużo, ale wydaje mi się, że nie ma większego kodu, który napisałem, który gdzieś nie używa takiej klasy.

Osiągnięcie biegłości w orientacji obiektowej obejmuje uświadomienie sobie, że to rozróżnienie istnieje, i nauczenie się klasyfikowania funkcji klasy do jednej z tych dwóch kategorii.

Jeśli kodujesz w C ++, możesz uczynić to rozróżnienie wyraźnym, używając classdla pierwszej kategorii obiektów i structdla drugiej. Oczywiście oba są równoważne, ale classoznacza to, że wszyscy członkowie są domyślnie prywatni, podczas gdy domyślnie structdeklarują wszystkich członków jako publiczni. Który właśnie rodzaj informacji chcesz przekazać.