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

do góry

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?

Pozdrawiam

do góry

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 -
czasem nie wiadomo, których pól/metod użyć
null - trzeba pamiętać że każda obiekt może być albo obiektem albo
wadliwą wartością null
metody statyczne - naruszają enkapsulację, działamy na polach z zewnątrz

do góry

On 15/12/2019 20:06, Borneq wrote:
> 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 -
> czasem nie wiadomo, których pól/metod użyć
> null - trzeba pamiętać że każda obiekt może być albo obiektem albo
> wadliwą wartością null
> metody statyczne - naruszają enkapsulację, działamy na polach z zewnątrz

Pfff a już myslałem że warto poświęcić chwilkę a tu ktoś znowu odkrywa
Podlasie bo nawet nie Amerykę.

Cóż, ilość argumentów youtubowych za i przeciw programowaniu obiektowemu
chyba idzie w miliony. Moze to już religia vs inna religia?

do góry

W dniu niedziela, 15 grudnia 2019 19:36:12 UTC+1 użytkownik M.M. napisał:
> 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?
>

rzucilem na to okiem ale te argumenty tam nie sa nieststy zbyt kluczowe, sa to pewne
dalsze argumenty opowiadajace jak praktyczny OOP rozmija sie z teoretycznym OOP
(zakladajac troche blednie ze teoretyczne oop jest dobre - zalezy co by to mialo byc)
i jest kilka smiesznych cytatow znanych figur, ze np OOP jest solidnym sposobem do
pisania sphagetti code, czy tez jest sposobem na pisanie solidnego sphagetti (co jest
prawdą jesli rozumiec solidny dosyc metaforycznie)

bardziej poprawnym argumentem na krytykowanie dlaczego opp to szit jest moim zdaniem
powiedzenie ze oop to sposob na tworzenie 'boilerplate' code i ze nie upraszcza tylko
gmatwa - a jeszze dokladniej mowiac to w OOP jest zle co oddziela go od programowanie
modulowego i hipermodulowego (hipermodulowe to moj wlasny wynalazek) bo modulowosc
(taka jak np w postaci .dll jest pozbawiona tych fundamentalnych wad)

[jeszcze dopowiadajac co jest zle w OOP wiaze sie z ciaganiem wskaznikow bo normalnie
jesli chcesz dzilic kod na jednostki (metodami modulowymi i hipermodulowymi) nei
potrzebujesz ciagac zadnych wskaznikow i wtedy jest ok)

do góry

W dniu niedziela, 15 grudnia 2019 21:29:46 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 15 grudnia 2019 19:36:12 UTC+1 użytkownik M.M. napisał:
> > 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?
> >
>
> rzucilem na to okiem ale te argumenty tam nie sa nieststy zbyt kluczowe, sa to
pewne dalsze argumenty opowiadajace jak praktyczny OOP rozmija sie z teoretycznym OOP
(zakladajac troche blednie ze teoretyczne oop jest dobre - zalezy co by to mialo byc)
i jest kilka smiesznych cytatow znanych figur, ze np OOP jest solidnym sposobem do
pisania sphagetti code, czy tez jest sposobem na pisanie solidnego sphagetti (co jest
prawdą jesli rozumiec solidny dosyc metaforycznie)
>
> bardziej poprawnym argumentem na krytykowanie dlaczego opp to szit jest moim
zdaniem powiedzenie ze oop to sposob na tworzenie 'boilerplate' code i ze nie
upraszcza tylko gmatwa - a jeszze dokladniej mowiac to w OOP jest zle co oddziela go
od programowanie modulowego i hipermodulowego (hipermodulowe to moj wlasny wynalazek)
bo modulowosc (taka jak np w postaci .dll jest pozbawiona tych fundamentalnych wad)
>
> [jeszcze dopowiadajac co jest zle w OOP wiaze sie z ciaganiem wskaznikow bo
normalnie jesli chcesz dzilic kod na jednostki (metodami modulowymi i
hipermodulowymi) nei potrzebujesz ciagac zadnych wskaznikow i wtedy jest ok)

kiedys podawalem jak rozne rzeczy wygladaja w paradygmacie ktory nazywam
hipermodulowym (mojego autorstwa/odkrycia/wymyslu):




void main()
{
Character alan, barry; //dwa moduly

alan.hp = 100; //zdrowie potaci
alan.hit_strength = 10; //sila ciosu

barry .hp = 110;
barry.hit_strenght = 9;

alan hit barry;
//spowoduje barry.hp-=alan.hit_strength

}

gdzie definicja modulu Charater


module Character
{
int hp;
int hit_strenght;

void hit(Charater whom)
{
whom.hp -= hit_strength;
}
}

roznice miedzy OOP 'niby nie takie duze' ale jednak ogromne...

do góry

W dniu niedziela, 15 grudnia 2019 21:57:06 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 15 grudnia 2019 21:29:46 UTC+1 użytkownik fir napisał:
> > W dniu niedziela, 15 grudnia 2019 19:36:12 UTC+1 użytkownik M.M. napisał:
> > > 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?
> > >
> >
> > rzucilem na to okiem ale te argumenty tam nie sa nieststy zbyt kluczowe, sa to
pewne dalsze argumenty opowiadajace jak praktyczny OOP rozmija sie z teoretycznym OOP
(zakladajac troche blednie ze teoretyczne oop jest dobre - zalezy co by to mialo byc)
i jest kilka smiesznych cytatow znanych figur, ze np OOP jest solidnym sposobem do
pisania sphagetti code, czy tez jest sposobem na pisanie solidnego sphagetti (co jest
prawdą jesli rozumiec solidny dosyc metaforycznie)
> >
> > bardziej poprawnym argumentem na krytykowanie dlaczego opp to szit jest moim
zdaniem powiedzenie ze oop to sposob na tworzenie 'boilerplate' code i ze nie
upraszcza tylko gmatwa - a jeszze dokladniej mowiac to w OOP jest zle co oddziela go
od programowanie modulowego i hipermodulowego (hipermodulowe to moj wlasny wynalazek)
bo modulowosc (taka jak np w postaci .dll jest pozbawiona tych fundamentalnych wad)
> >
> > [jeszcze dopowiadajac co jest zle w OOP wiaze sie z ciaganiem wskaznikow bo
normalnie jesli chcesz dzilic kod na jednostki (metodami modulowymi i
hipermodulowymi) nei potrzebujesz ciagac zadnych wskaznikow i wtedy jest ok)
>
> kiedys podawalem jak rozne rzeczy wygladaja w paradygmacie ktory nazywam
hipermodulowym (mojego autorstwa/odkrycia/wymyslu):
>
>
>
>
> void main()
> {
> Character alan, barry; //dwa moduly
>
> alan.hp = 100; //zdrowie potaci
> alan.hit_strength = 10; //sila ciosu
>
> barry .hp = 110;
> barry.hit_strenght = 9;
>
> alan hit barry;


przy okazji tutaj wyzej to allan hit barry jak ktos by sie upieral moglby zapisac

alan.hit(barry)

(w poprawionym c przekazujesz struktury moduly przez adres implicite, tak ze barry
nie idzie przez wartosc) ale tez w poprawionym c doszedlem do koncepcji ze
te kropki nawiasy i przecinki mozna dawac opcjonalnie do wyboru dla programisty
n zamiast pisac

print(1,2,3);
moze alternatywnie pisac
print 1,2,3
print(1 2 3)
albo
print 1 2 3

tak ze z tego wynika ze mozna pisac najprawdopodobniej w uproszczeniu

barry hp = 110
barry hit_strenght = 9

alan hit barry

jak ktos chce porownac roznice miedzy tym a jakims OOPem w jawie czy c++ to moze
sobie porownac w tym alebo w bardziej skomplikowanych wypadkach

(dodam ze w u mnie mozna z modulow robic tablice np

Character soldier[100];

soldier[3] hit soldier[4];

i reszte sztuczek z traktowaniem modulow w pelni jak typy wbudowane (np int i reszta)




> //spowoduje barry.hp-=alan.hit_strength
>
> }
>
> gdzie definicja modulu Charater
>
>
> module Character
> {
> int hp;
> int hit_strenght;
>
> void hit(Charater whom)
> {
> whom.hp -= hit_strength;
> }
> }
>
> roznice miedzy OOP 'niby nie takie duze' ale jednak ogromne...

do góry

W dniu niedziela, 15 grudnia 2019 22:05:19 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 15 grudnia 2019 21:57:06 UTC+1 użytkownik fir napisał:
> > W dniu niedziela, 15 grudnia 2019 21:29:46 UTC+1 użytkownik fir napisał:
> > > W dniu niedziela, 15 grudnia 2019 19:36:12 UTC+1 użytkownik M.M. napisał:
> > > > 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?
> > > >
> > >
> > > rzucilem na to okiem ale te argumenty tam nie sa nieststy zbyt kluczowe, sa to
pewne dalsze argumenty opowiadajace jak praktyczny OOP rozmija sie z teoretycznym OOP
(zakladajac troche blednie ze teoretyczne oop jest dobre - zalezy co by to mialo byc)
i jest kilka smiesznych cytatow znanych figur, ze np OOP jest solidnym sposobem do
pisania sphagetti code, czy tez jest sposobem na pisanie solidnego sphagetti (co jest
prawdą jesli rozumiec solidny dosyc metaforycznie)
> > >
> > > bardziej poprawnym argumentem na krytykowanie dlaczego opp to szit jest moim
zdaniem powiedzenie ze oop to sposob na tworzenie 'boilerplate' code i ze nie
upraszcza tylko gmatwa - a jeszze dokladniej mowiac to w OOP jest zle co oddziela go
od programowanie modulowego i hipermodulowego (hipermodulowe to moj wlasny wynalazek)
bo modulowosc (taka jak np w postaci .dll jest pozbawiona tych fundamentalnych wad)
> > >
> > > [jeszcze dopowiadajac co jest zle w OOP wiaze sie z ciaganiem wskaznikow bo
normalnie jesli chcesz dzilic kod na jednostki (metodami modulowymi i
hipermodulowymi) nei potrzebujesz ciagac zadnych wskaznikow i wtedy jest ok)
> >
> > kiedys podawalem jak rozne rzeczy wygladaja w paradygmacie ktory nazywam
hipermodulowym (mojego autorstwa/odkrycia/wymyslu):
> >
> >
> >
> >
> > void main()
> > {
> > Character alan, barry; //dwa moduly
> >
> > alan.hp = 100; //zdrowie potaci
> > alan.hit_strength = 10; //sila ciosu
> >
> > barry .hp = 110;
> > barry.hit_strenght = 9;
> >
> > alan hit barry;
>
>
> przy okazji tutaj wyzej to allan hit barry jak ktos by sie upieral moglby zapisac
>
> alan.hit(barry)
>
> (w poprawionym c przekazujesz struktury moduly przez adres implicite, tak ze barry
nie idzie przez wartosc) ale tez w poprawionym c doszedlem do koncepcji ze
> te kropki nawiasy i przecinki mozna dawac opcjonalnie do wyboru dla programisty
> n zamiast pisac
>
> print(1,2,3);
> moze alternatywnie pisac
> print 1,2,3
> print(1 2 3)
> albo
> print 1 2 3
>
> tak ze z tego wynika ze mozna pisac najprawdopodobniej w uproszczeniu
>
> barry hp = 110
> barry hit_strenght = 9
>

drobna uwaga czy te pola ktore sa wartosciami mozna by tez inicalizowac jak

barry hp(110)
barry hit_strenght(9)

alan hit barry

co czaem mogloby byc moze lepsze bo ten znak = wydaje sie czasem ordynarny

jest tez opcja

barry hp 110
barry hit_strenght 9
alan hit barry

i sam chyab jestem zdanie ze pewnie nalezy to zostawuc do wyboru dla programisty, w
zaleznsoci od stylu pisania jaki mu sie podoba

tez niby to przypomina troche c++ gdzie
o ile pamietam mozna pisac

int x(10);

//choc o ile pamietam nie mozna int x 29

ale mam nadziej ze widac ze tutaj test to co pisze zrobione w supelnie innym
'architektonicznym' konkekscie, wiec niektore zbieznosci sa tu raczej jakby jedynie
przyadkowe (co nawet widac imo)


> alan hit barry
>
> jak ktos chce porownac roznice miedzy tym a jakims OOPem w jawie czy c++ to moze
sobie porownac w tym alebo w bardziej skomplikowanych wypadkach
>
> (dodam ze w u mnie mozna z modulow robic tablice np
>
> Character soldier[100];
>
> soldier[3] hit soldier[4];
>
> i reszte sztuczek z traktowaniem modulow w pelni jak typy wbudowane (np int i
reszta)
>
>
>
>
> > //spowoduje barry.hp-=alan.hit_strength
> >
> > }
> >
> > gdzie definicja modulu Charater
> >
> >
> > module Character
> > {
> > int hp;
> > int hit_strenght;
> >
> > void hit(Charater whom)
> > {
> > whom.hp -= hit_strength;
> > }
> > }
> >
> > roznice miedzy OOP 'niby nie takie duze' ale jednak ogromne...

do góry

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

do góry