Programowanie - temat ogólny

Alex Fortune · 12-04-2016 11:20

Rollercoster napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Masz, poczytaj kogoś mądrzejszego od siebie.
http://typicalprogrammer.com/doing-i...s-and-setters/

co xD
przeciez napisalem wyżej conajmniej parę razy, że gettery i settery to rak z punktu widzenia interfejsu. Ale mówienie, że łamie enkapsulację to imo nadużycie - owszem, implementacja w 99.9999% przypadków działa tak, jakbyś łamał enkapsulację bezpośrednio przez wpisywanie do pola, ale właśnie sam fakt stworzenia metody opakowującej to działanie powoduje, że do łamania enkapsulacji nie dochodzi, a conajwyżej do zbudowania chujowego interfejsu. Also, disclaimer - gettery nie są koniecznie złe, ale trzeba je stosować tam, gdzie faktycznie odpowiedzialnością jest pobieranie danych ( najczęściej jest to Read Model )

A tak w ogóle, to argument pt ,,poczytaj mądrzejszego od siebie" jest argumentem conajwyżej dla gimbusów, ktorzy jarają się wszystkimi "guru" programowania i w życiu nie poddadzą w wątpliwość to, co przeczytają/usłyszą, więc proponowałbym dać spokój sobie z czymś takim xD

Kusterek napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

to jaka jest poprawna wg Ciebie?

Poprawna metoda powinna opisywać co robi i rozwiązywać problemy właściwe dla odpowiedzialności oddelegowanej do danego obiektu. "setCoś" nie rozwiązuje Ci żadnego problemu - ustawiasz tylko dane. Jest to najczęściej związane z tym, że ludzie często popełniają błąd, myśląc, że model "reprezentuje" coś przez dane w nim zawarte, a to nieprawda - reprezentacją modelu są jego zachowania ( czytaj - interfejs ).

Przykładowymi metodami dla, załóżmy, implementacji forum ala torg, byłyby dla mnie ( metody nie są statyczne, podaje tylko interfejs. ) :

Kod :

Context/Browsing/Aggregate/Forum/Forum::lockThread(User lockingUser, ThreadId thread) -> <bronienie inwariantów na forum> -> Context/Moderation/Aggregate/Forum/Thread::lock(User lockingUser) -> <opcjonalna zmiana stanu, emisja zdarzeń domenowych>
Context/Discussion/Aggregate/Thread/Thread::postAMessage(User postingUser, Post postedMessage) -> <bronienie inwariantów na wątku, opcjonalna zmiana stanu, emisja zdarzeń domenowych>

Zwracam uwagę na dwie ultraważne rzeczy:

Nazwy metod, które mówią co ta metoda robi
Metody wykonują realną pracę i nie wybebeszają logiki biznesowej

Bazan · 12-04-2016 11:24

Alex Fortune napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

co xD
przeciez napisalem wyżej conajmniej parę razy, że gettery i settery to rak z punktu widzenia interfejsu. Ale mówienie, że łamie enkapsulację to imo nadużycie - owszem, implementacja w 99.9999% przypadków działa tak, jakbyś łamał enkapsulację bezpośrednio przez wpisywanie do pola, ale właśnie sam fakt stworzenia metody opakowującej to działanie powoduje, że do łamania enkapsulacji nie dochodzi, a conajwyżej do zbudowania chujowego interfejsu. Also, disclaimer - gettery nie są koniecznie złe, ale trzeba je stosować tam, gdzie faktycznie odpowiedzialnością jest pobieranie danych ( najczęściej jest to Read Model )

A tak w ogóle, to argument pt ,,poczytaj mądrzejszego od siebie" jest argumentem conajwyżej dla gimbusów, ktorzy jarają się wszystkimi "guru" programowania i w życiu nie poddadzą w wątpliwość to, co przeczytają/usłyszą, więc proponowałbym dać spokój sobie z czymś takim xD

Poprawna metoda powinna opisywać co robi i rozwiązywać problemy właściwe dla odpowiedzialności oddelegowanej do danego obiektu. "setCoś" nie rozwiązuje Ci żadnego problemu - ustawiasz tylko dane. Jest to najczęściej związane z tym, że ludzie często popełniają błąd, myśląc, że model "reprezentuje" coś przez dane w nim zawarte, a to nieprawda - reprezentacją modelu są jego zachowania ( czytaj - interfejs ).

Przykładowymi metodami dla, załóżmy, implementacji forum ala torg, byłyby dla mnie ( metody nie są statyczne, podaje tylko interfejs. ) :

Kod :

Context/Browsing/Aggregate/Forum/Forum::lockThread(User lockingUser, ThreadId thread) -> <bronienie inwariantów na forum> -> Context/Moderation/Aggregate/Forum/Thread::lock(User lockingUser) -> <opcjonalna zmiana stanu, emisja zdarzeń domenowych>
Context/Discussion/Aggregate/Thread/Thread::postAMessage(User postingUser, Post postedMessage) -> <bronienie inwariantów na wątku, opcjonalna zmiana stanu, emisja zdarzeń domenowych>

Zwracam uwagę na dwie ultraważne rzeczy:

Nazwy metod, które mówią co ta metoda robi
Metody wykonują realną pracę i nie wybebeszają logiki biznesowej

To mi sie podoba! Sam nie czytajac wielkich wywodow doszedlem do tego, ze wole czytac Topic.close() a nie Topic.setStatus('closed'); Bo co to kogo obchodzi co tam sie dzieje w bebechach bazy. Mnie obchodzi tylko tyle ze ma byc zamkniety topic, i gowno mnie powinno obchodzic ile i jakie statusy zmienia.
Zachęcam jak najbardziej :) Ale ja sie chuja znam jestem tylko ~~phpowcem~~ wordpressowcem.

Alex Fortune · 12-04-2016 11:27

Bazan napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

To mi sie podoba! Sam nie czytajac wielkich wywodow doszedlem do tego, ze wole czytac Thread.close() a nie Thread.setStatus('closed');
Zachęcam jak najbardziej :) Ale ja sie chuja znam jestem tylko ~~phpowcem~~ wordpressowcem.

Nic dziwnego - kiedy widzisz taką metodę, spodziewasz się tego co będzie w środku, kod idzie za mapą myślową tego, co modelujemy w głowie kiedy słyszymy, co system ma robić.

Rollercoster · 12-04-2016 11:27

Alex Fortune napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

A tak w ogóle, to argument pt ,,poczytaj mądrzejszego od siebie" jest argumentem conajwyżej dla gimbusów, ktorzy jarają się wszystkimi "guru" programowania i w życiu nie poddadzą w wątpliwość to, co przeczytają/usłyszą, więc proponowałbym dać spokój sobie z czymś takim xD

no no xD

Jednak jakoś bardziej przekonuje mnie 60letni dziadek, który od 40 lat siedzi w programowani niż ktoś kto siedzi dwa lata na etacie i myśli że pozjadał wszystkie rozumy.

Alex Fortune · 12-04-2016 11:29

Rollercoster napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

no no xD

Jednak jakoś bardziej przekonuje mnie 60letni dziadek, który od 40 lat siedzi w programowani niż 'ktoś' kto siedzi dwa lata na etacie i myśli że pozjadał wszystkie rozumy.

To jest Twój problem, że nie poddajesz w wątpliwość tego co obrabiasz :) Ale nie ucz innych źle, kthx

@edit: w zasadzie, możemy sobie darować te śmieszne pojazdy po sobie? Możesz sobie uważać co chcesz, odpowiedzi zostały dane, a osoba, której odpowiedziałeś wybierze sobie co woli. Ja uważam, że mam rację i nie tylko na podstawie tego, że "pozjadałem wszystkie rozumy", ale po dyskusjach z różnymi ludźmi, także tego ,,wielkiego formatu" ( cokolwiek to znaczy xD ), a życie zweryfikuje jak zwykle :D

@edit2: no kurwa nie xD wszedłem w ten artykuł go solidnie przeczytać , a tu:

Every getter and setter in your code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters (also referred to as accessors, accessor methods, and properties) is a sign of a poorly-designed set of classes.

A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible led to more reliable and maintainable code.

Czy to nie jest czasami coś o czym gadam od conajmniej 4 postów? xD

Wielkie Zło · 12-04-2016 21:09

Rollercoster napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Masz, poczytaj kogoś mądrzejszego od siebie.
http://typicalprogrammer.com/doing-i...s-and-setters/

That means that until you prove that you need anything more than a simple attribute access, don’t write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well.

Prychłem, w takim razie polecam zainteresować się assemblerem bo obiekty to też duży narzut.

Alex ma oczywiście rację. Z prostej przyczyny property są lepsze od atrybutów, masz kontrolę nad przepływem danych i zmianą stanu obiektu. Atrybutu nie podmienisz sobie tak prosto ;)
I nie ma się za bardzo czym podniecać, programowanie obiektowe to nie lek na wszystko.

Bazan napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

To mi sie podoba! Sam nie czytajac wielkich wywodow doszedlem do tego, ze wole czytac Topic.close() a nie Topic.setStatus('closed'); Bo co to kogo obchodzi co tam sie dzieje w bebechach bazy. Mnie obchodzi tylko tyle ze ma byc zamkniety topic, i gowno mnie powinno obchodzic ile i jakie statusy zmienia.
Zachęcam jak najbardziej :) Ale ja sie chuja znam jestem tylko ~~phpowcem~~ wordpressowcem.

Plus wprowadzasz abstrakcję, tak przydatną przy dziedziczeniu.

Wracając do C#, to akurat atrybut od property różni się i to dosyć sporo, zarówno jeżeli chodzi o interfejsy bibliotek zewnętrznych, jak i testowanie (atrybutu mockować się nie da), atrybutu nie wrzucisz do interfejsu, i wiele, wiele innych.

dzeejkop · 12-04-2016 21:12

w bitbuckecie gdzie znajde date stworzenia galezi (branch) wie ktos?

Wielkie Zło · 12-04-2016 21:24

dzeejkop napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

w bitbuckecie gdzie znajde date stworzenia galezi (branch) wie ktos?

git reflog --date=local

.

Bazan · 13-04-2016 15:14

Tak sobie właśnie odpalilem cokolwiek o UMLach, pierwszy lepszy link z google: http://brasil.cel.agh.edu.pl/~09sbfr...klas,1,11.html

I tu gosc opisal rodzaje parametrów:

Dostępności:

+ publiczna
- prywatna
# chroniona
~ zakres pakietu

lista_arg: rodzaj nazwa_arg : typ = wart_początkowa

rodzaj definiuje sposób, w jaki metoda korzysta z danego argumentu:
in: metoda może czytać argument, ale nie może go zmieniać
out: może zmieniać, nie może czytać
inout: może czytać i zmieniać

Nie rozumiem tego out. Jak argument moze byc zmieniany a nie moze byc czytany?
I jak to sie pozniej zapisuje w kodzie?
Chodzi po prostu o to ze ma setter a nie ma gettera?
No to i po co w ogole ustawiac jakies pole, jezeli nie mozna tego odczytac xD

No bo in - to jakaś stała, mozesz se ja odczytac i tyle, nie da sie zmienic. Albo taki tymczasowy parametr pobrany z opcji.

Ktory poradnik o UML byscie polecili? Co nieco mialem w szkole, ale nie przykladalem sie :P

konto usunięte · 13-04-2016 15:37

Bazan napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Tak sobie właśnie odpalilem cokolwiek o UMLach, pierwszy lepszy link z google: http://brasil.cel.agh.edu.pl/~09sbfr...klas,1,11.html

I tu gosc opisal rodzaje parametrów:

Nie rozumiem tego out. Jak argument moze byc zmieniany a nie moze byc czytany?
I jak to sie pozniej zapisuje w kodzie?
Chodzi po prostu o to ze ma setter a nie ma gettera?
No to i po co w ogole ustawiac jakies pole, jezeli nie mozna tego odczytac xD

No bo in - to jakaś stała, mozesz se ja odczytac i tyle, nie da sie zmienic. Albo taki tymczasowy parametr pobrany z opcji.

Ktory poradnik o UML byscie polecili? Co nieco mialem w szkole, ale nie przykladalem sie :P

Czytanie parametru 'out' zazwyczaj nie ma sensu - masz go ustawic - nie czytac.

Bazan · 13-04-2016 17:48

A bo ja nie ogarnalem, myslalem ze tu chodzi o klase, a nie o metode.

zmija58 · 14-04-2016 07:28

Witam chce zaczac programowac. Polecono nauczyc mi sie programowania desingu stron oraz pozycjonowania. Od czego polecicie mi zaczac sie uczyc?

Xeanix · 14-04-2016 08:29

a po co? chcesz robić stronki internetowe? zacznij np. od C++

konto usunięte · 14-04-2016 08:58

Xeanix napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

a po co? chcesz robić stronki internetowe? zacznij np. od C++

O ile jest bardzo zdeterminowany, to C/C++ to bardzo dobry wybor. Inaczej, sprobowalbym czegos dalej od maszyny - C#, Javy, Pythona - bron Boze PHPa.

**zakius** · 14-04-2016 09:00

szulak napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Pythona - bron Boze PHPa.

and here we go again

Temat: Programowanie - temat ogólny

Narzędzia tematu

Oceń ten temat

Informacje o temacie

Użytkownicy przeglądający temat

Podobne tematy

Star Wars: The Old Republic - temat ogólny

League of Legends //dla potomnosci: League of Legends - temat ogolny.

Cities XL 2012 - temat ogólny

Dragon Ball Legend temat ogólny

Zakładki

Zakładki

Zasady postowania