Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #33586 > unrolled thread

Co dolega programowaniu obiektowemu

Back to article view | Back to pl.comp.programming

Contents

  Co dolega programowaniu obiektowemu Borneq <borneq@antyspam.hidden.pl> - 2019-12-15 16:03 +0100
    Re: Co dolega programowaniu obiektowemu "M.M." <mmarszik@gmail.com> - 2019-12-15 10:36 -0800
      Re: Co dolega programowaniu obiektowemu Borneq <borneq@antyspam.hidden.pl> - 2019-12-15 20:06 +0100
        Re: Co dolega programowaniu obiektowemu heby <heby@poczta.onet.pl> - 2019-12-15 21:17 +0100
        Re: Co dolega programowaniu obiektowemu "M.M." <mmarszik@gmail.com> - 2019-12-16 14:51 -0800
        Re: Co dolega programowaniu obiektowemu slawek <x.y@org.org> - 2019-12-30 07:27 +0100
      Re: Co dolega programowaniu obiektowemu fir <profesor.fir@gmail.com> - 2019-12-15 12:29 -0800
        Re: Co dolega programowaniu obiektowemu fir <profesor.fir@gmail.com> - 2019-12-15 12:57 -0800
          Re: Co dolega programowaniu obiektowemu fir <profesor.fir@gmail.com> - 2019-12-15 13:05 -0800
            Re: Co dolega programowaniu obiektowemu fir <profesor.fir@gmail.com> - 2019-12-15 13:13 -0800

#33586 — Co dolega programowaniu obiektowemu

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

[toc] | [next] | [standalone]

#33587

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

[toc] | [prev] | [next] | [standalone]

#33588

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

[toc] | [prev] | [next] | [standalone]

#33589

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?

[toc] | [prev] | [next] | [standalone]

#33600

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

[toc] | [prev] | [next] | [standalone]

#33628

Borneq <borneq@antyspam.hidden.pl> Wrote in message:
> 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ą nullmetody statyczne - naruszają enkapsulację, działamy na polach z zewnątrz



Zieeeew.
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#33590

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)

[toc] | [prev] | [next] | [standalone]

#33591

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...

[toc] | [prev] | [next] | [standalone]

#33592

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...

[toc] | [prev] | [next] | [standalone]

#33593

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...

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web