-
X-Received: by 2002:ac8:2e6a:: with SMTP id s39mr1770387qta.349.1576536676596; Mon,
16 Dec 2019 14:51:16 -0800 (PST)
X-Received: by 2002:ac8:2e6a:: with SMTP id s39mr1770387qta.349.1576536676596; Mon,
16 Dec 2019 14:51:16 -0800 (PST)
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!goblin2!goblin3
!goblin.stu.neva.ru!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews
.com!g89no9949535qtd.0!news-out.google.com!w29ni1717qtc.0!nntp.google.com!g89no
9949529qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: pl.comp.programming
Date: Mon, 16 Dec 2019 14:51:16 -0800 (PST)
In-Reply-To: <5df6841b$0$17343$65785112@news.neostrada.pl>
Complaints-To: g...@g...com
Injection-Info: google-groups.googlegroups.com; posting-host=159.205.157.250;
posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj
NNTP-Posting-Host: 159.205.157.250
References: <5df64b3a$0$505$65785112@news.neostrada.pl>
<8...@g...com>
<5df6841b$0$17343$65785112@news.neostrada.pl>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2...@g...com>
Subject: Re: Co dolega programowaniu obiektowemu
From: "M.M." <m...@g...com>
Injection-Date: Mon, 16 Dec 2019 22:51:16 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 91
Xref: news-archive.icm.edu.pl pl.comp.programming:214571
[ ukryj nagłówki ]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
Najnowsze wątki z tej grupy
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-11-25 Karty przedpłacone (podarunkowe) Google Play - pytanie do korzystających
- 2024-11-26 wina Tóska
- 2024-11-26 Rewolucja/Rewelacja!
- 2024-11-25 grupa ożyła ;)
- 2024-11-24 Być jak Clint
- 2024-11-24 Rura kanalizacja konceptu Franke = problem
- 2024-11-25 Wrocław => Lead Java EE Developer <=
- 2024-11-25 Warszawa => Business Development Manager - Network and Network Securit
- 2024-11-25 Kraków => Programista Full Stack (.Net Core) <=
- 2024-11-25 Lublin => Senior PHP Developer <=
- 2024-11-25 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=
- 2024-11-25 Warszawa => ECM Specialist / Consultant <=
- 2024-11-25 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-11-25 Warszawa => Senior Frontend Developer (React + React Native) <=
- 2024-11-25 Lublin => Inżynier Serwisu Sprzętu Medycznego <=