Co dolega programowaniu obiektowemu

[Borneq]

Yegor Bugayenko - What's Wrong with Object-Oriented Programming?

EO, the Programming Language: https://github.com/yegor256/eo

[Borneq]

Post by Borneq
Yegor Bugayenko - What's Wrong with Object-Oriented Programming?
http://youtu.be/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

[heby]

Post by Borneq
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?

[M.M.]

Post by Borneq

Post by Borneq
Yegor Bugayenko - What's Wrong with Object-Oriented Programming?
http://youtu.be/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?

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.

Post by Borneq
czasem nie wiadomo, których pól/metod użyć

Nie rozumiem.

Post by Borneq
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.

Post by Borneq
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

[slawek]

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?>> http://youtu.be/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ą nullmetody statyczne - naruszają enkapsulację, działamy na polach z zewnątrz

Zieeeew.

[fir]

Post by Borneq
Yegor Bugayenko - What's Wrong with Object-Oriented Programming?
http://youtu.be/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)

[fir]

Post by fir

Post by Borneq
Yegor Bugayenko - What's Wrong with Object-Oriented Programming?
http://youtu.be/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...

[fir]

Post by fir

Post by fir

Post by Borneq
Yegor Bugayenko - What's Wrong with Object-Oriented Programming?
http://youtu.be/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)

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)

Post by fir
//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...

[fir]

Post by fir

Post by fir

Post by fir

Post by Borneq
Yegor Bugayenko - What's Wrong with Object-Oriented Programming?
http://youtu.be/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)

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)

Post by fir
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)

Post by fir
//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...