🚀 go-pugleaf

On Sunday, December 15, 2019 at 8:06:38 PM UTC+1, Borneq wrote:
> W dniu 2019-12-15 o 19:36, M.M. pisze:
> > On Sunday, December 15, 2019 at 4:03:24 PM UTC+1, Borneq wrote:
> >> Yegor Bugayenko - What's Wrong with Object-Oriented Programming?
> >> https://www.youtube.com/watch?v=GMrjuuczZkQ
> >> EO, the Programming Language: https://github.com/yegor256/eo
> > 
> > Myślałem że programowanie obiektowe to sam lukier. Mogę poprosić o kilka
> > zdań skrótu z sedna tych materiałów?
> 
> Dziedziczenie:
> nie zawsze da się zrobić hierarchię, bo czasem podklasa zależy od dwóch 
> nadklas, a gdy dopuścimy wielodziedziczenie to mamy problem diamentu - 

Sam nie wiem dlaczego dziedziczenia z dwóch klas tak rzadko używam, 
właściwie w tej chwili nie przypominam sobie kiedy użyłem ostatnio.
Nie wypowiem się, bo mam małe doświadczenia z wielodziedziczeniem, widocznie
sporadycznie mi się to przydaje. Za to często stosuję agregację wielu
klas w jednej klasie.


> czasem nie wiadomo, których pól/metod użyć

Nie rozumiem.


> null - trzeba pamiętać że każda obiekt może być albo obiektem albo 
> wadliwą wartością null

Ostatnio zazwyczaj używam referencji zamiast wskaźników na obiekt. Jakoś 
daję rade tak napisać kod, aby wskaźniki były potrzebne bardzo rzadko.
Czemu daję radę? Nie wiem sam, może dlatego że trochę w Javie pracowałem?
Wyjątek od tej reguły stanowią biblioteki, które wewnątrz mają naprawdę
sieczkę wskaźników, makr, ujemnych indeksów, i czego tam jeszcze. Ale taki
kod jest mocno reużywany i szybko wszelkie błędy są wychwytywane. Poza tym
jest z definicji zamknięty na rozwój, szczególnie przez innych programistów.
Oczywiście interfejsy widoczne na zewnątrz biblioteki staram się też zachować
eleganckie i staram się używać bibliotek które w użyciu zapewniają elegancję.
Podsumowując, we 'właściwym kodzie programu' mam  maksymalnie kilka wskaźników 
na 100kb kodu.


> metody statyczne - naruszają enkapsulację, działamy na polach z zewnątrz

Nie wiem dlaczego naruszają. Dla mnie szczyt elegancji i czytelności jest
wtedy, gdy cała klasa jest w dwóch plikach, w nagłówkowym *.h i źródłowym *.cpp.
W 99% udaje mi się ten reżim utrzymać i to bez dużych klas i wielkich plików *.cpp.
Metodę statyczną mogę wstawić do ciała klasy w pliku *.h, albo mogę 
napisać statyczną funkcję nie-składową w pliku *.cpp. Jeśli metodę statyczną
zawarłem w ciele klasy, to czytając kod, od razu wiem, że metody statyczne w
pliku *.cpp nie mogłyby zrobić tego, co robi ta metoda - chociażby ze względów
widoczności w innych plikach. Podobnie jest ze składowymi metodami nie-statycznymi. Więc nawet jakby składowa metoda statyczna nie miała komentarza i
swojej nazwy, a nazwę musi mieć zawsze, to już z samego faktu że jest metodą
statyczną - mogę dużo wywnioskować o tym co autor miał na myśli. Oczywiście
tylko wtedy gdy autor ma podobne podejście do projektowania jak ja. Niestety,
język C++ jest baaardzo elastyczny, nadużywanie czegokolwiek przychodzi łatwo i
potem bolesne skutki odczuwamy w analizie kodu innego autora.


Pozdrawiam