eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingCo dolega programowaniu obiektowemuRe: Co dolega programowaniu obiektowemu
  • 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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: