obiekty inside-out ?
hubert depesz lubaczewski - 24-12-2006 00:49
obiekty inside-out ?
hej
zasadniczo pytanie jest proste - co sądzicie o koncepcji obiektów
inside-out którą conway przedstawił w "best practices"?
podchodzę do tego "jak do jeża". niby conway to uznany autorytet, ale
jakoś mnie to nie przekonuje. utrudnia pisanie a zabezpieczenie jest
jakieś takie ... nie wiem - iluzoryczne? 2 różne obiekty mogą sobie
bezstresowo nadpisać dane. i nie chodzi o to, że celowo - po prostu
przez nieuwagę programisty. no chyba, że czegoś nie kojarzę za dobrze z
jego wywodów.
ogólnie - wasze opinie o temacie?
depesz
--
http://www.depesz.com/index.php/2006...udzi-do-pracy/
Vava - 24-12-2006 00:49
hubert depesz lubaczewski <depesz@depesz.com> napisał(a):
> zasadniczo pytanie jest proste - co sądzicie o koncepcji obiektów
> inside-out którą conway przedstawił w "best practices"?
> podchodzę do tego "jak do jeża". niby conway to uznany autorytet, ale
> jakoś mnie to nie przekonuje. utrudnia pisanie a zabezpieczenie jest
> jakieś takie ... nie wiem - iluzoryczne? 2 różne obiekty mogą sobie
> bezstresowo nadpisać dane. i nie chodzi o to, że celowo - po prostu
> przez nieuwagę programisty. no chyba, że czegoś nie kojarzę za dobrze z
> jego wywodów.
Ale jak nadpisac dane? Hasze z atrybutami maja zasięg leksykalny w
pakiecie (zwroc uwage na te dodatkowe {}),
a ich klucze sa adresami obiektu - anonimowego skalara
(Class::Std::Utils::ident to Scalar::Util::refaddr)
package Test;
use Class::Std::Utils;
{
my %test;
my %cos_innego;
sub new {
my $class = shift;
return bless anon_scalar(), $class;
}
sub set_test {
my $self = shift;
my $value = shift;
$test{ident $self} = $value;
}
sub get_test {
my $self = shift;
return $test{ident $self};
}
}
1;
IMO nawet celowo trudno to nadpisac i to wlasnie ma byc glowna zaleta
tego, bo nie pozwala dobrac sie
z zewnatrz do wnetrznosci obiektu...
IMO to troche bez sensu - zawsze wychodzilem zalozenia, ze nie wchodze
bez zaproszenia do czyjegos
domu z powodu dobrego wychowania, a nie dlatego, ze beda strzelac ;-P
Gosc, ktoremu brak wychowania i dobiera sie do gospodyni sam jest sobie
winien, jak zlapie trypra...
Nie widze pwodu, by murarz musial sie nim przejmowac i tak dom budowac, by
mu to uniemozliwic ;-P
A jak ktos bedzie musial, to i tak sobie poradzi (widzialem w C
konstrukcje #declare private public)...
IMO obiekty inside-out, poza zwiekszona hermetyzacja nie niosa nic
ciekawego...
Moga sie przydac wtedy, gdy naszego modulu uzywa ktos, kto nie rozumie
zasad obiektowosci i ma na nas
przelozenie finansowe, gdy po wydaniu nowej wersji obiektu jego kod
przestanie dzialac ;-P
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
Vava - 24-12-2006 00:49
Vava <vava-jedenaste-nie-spamuj@plusnet.pl> napisał(a):
;-P
> IMO obiekty inside-out, poza zwiekszona hermetyzacja nie niosa nic
> ciekawego...
No dobra - maja jeszcze jedna zalete - chronia nas samych przy pisaniu
metod obiektu przed literowkami w kluczach glownego hasza...
Dla mni mala zaleta, b staram sie tak obikty tworzyc, by do wewnetrznej
struktury odwolywaly sie tylko akcesory. get_atrybut zazwyczaj robie przez
skopiowanie
i przerobienie set_atrybut, a nazwy kluczy daje zwykle opisowe, wiec ew.
literowki
sie skopiuja i jedynie bedzie wstyd, jak ktos to potem w kodzie znajdzie,
a nadpisanie
innego atrybutu jest malo prawdopodobne...
Tak BTW, to w kilku miejscach sie z Conway'em nie zgadzam... Np. jak dla
mnie:
if (warunek) {
...
}
else {
...
}
jest mniej czytelne od:
if (warunek) {
...
} else {
...
}
Szczegolnie we fragmentach, gdzie warunkowych instrukcji jest sporo...
Poza 'przyzwyczajeniem' mam kontrargumenty dla tego, co pisze w temacie
Conway, ale mnie nadgarstek boli :-(
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
Krzysztof Krzyżaniak - 24-12-2006 00:49
Vava <vava-jedenaste-nie-spamuj@plusnet.pl> writes:
> Vava <vava-jedenaste-nie-spamuj@plusnet.pl> napisał(a):
>
> ;-P
>
>> IMO obiekty inside-out, poza zwiekszona hermetyzacja nie niosa nic
>> ciekawego...
>
> No dobra - maja jeszcze jedna zalete - chronia nas samych przy pisaniu
> metod obiektu przed literowkami w kluczach glownego hasza...
IMO Conway utrudnia rzeczy proste a nie ułatwia skomplikowanych.
> Dla mni mala zaleta, b staram sie tak obikty tworzyc, by do wewnetrznej
> struktury odwolywaly sie tylko akcesory. get_atrybut zazwyczaj robie przez
> skopiowanie
> i przerobienie set_atrybut, a nazwy kluczy daje zwykle opisowe, wiec
> ew. literowki
> sie skopiuja i jedynie bedzie wstyd, jak ktos to potem w kodzie znajdzie,
> a nadpisanie
> innego atrybutu jest malo prawdopodobne...
use Class::Accessor;
> Tak BTW, to w kilku miejscach sie z Conway'em nie zgadzam... Np. jak dla
> mnie:
>
> if (warunek) {
> ...
> }
> else {
> ...
> }
Ja stosuję
if (warunek)
{
...
}
else
{
...
}
Ale to wszystko kwestia przyzwyczajeń.
eloy
--
-------e-l-o-y----------------------------e-l-o-y-@-k-o-f-e-i-n-a-.-n-e-t------
jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej
Dariusz Jackowski - 24-12-2006 00:49
Vava wrote:
>
> get_atrybut zazwyczaj robie przez skopiowanie i przerobienie set_atrybut,
> a nazwy kluczy daje zwykle opisowe
Zacznij używać Class::Accessor lub Class::Accessor::Fast. To tylko 2 linie i
zrobione:
use base qw/Class::Accessor::Fast/;
__PACKAGE__->mk_accessors qw/ala ola/;
--asc
Dariusz Jackowski - 24-12-2006 00:49
hubert depesz lubaczewski wrote:
>
> zasadniczo pytanie jest proste - co sądzicie o koncepcji obiektów
> inside-out którą conway przedstawił w "best practices"?
Najlepsze rozwiązanie to nauczyć współpracowników, żeby zawsze w odwoływaniu
do obiektów korzystali z accessorów. Jeśli już koniecznie musisz coś ukryć w
obiekcie to wystarczy zastosować closure, np.:
{
my $password = 'topsecret';
sub password { $_[0] ? $password = shift : $password }
}
print '$password = '. $password ."\n";
print 'password() = '. password() ."\n";
Używanie InsideOut napewno nie jest wygodne. Bezcelowe będzie używanie
Data::Dumper na takich obiektach, a to w debugowaniu jest bardzo przydatne.
Argument o wykrywaniu literówek jest nietrafiony, bo to samo wykryjesz jeśli
używasz strict && warnings.
Też zawsze stosuję klamry w osobnych liniach, znacznie podnoszą czytelność
kodu.
--asc
Vava - 24-12-2006 00:49
Krzysztof Krzyżaniak <eloy@pawnhearts.eu.org> napisał(a):
>> No dobra - maja jeszcze jedna zalete - chronia nas samych przy pisaniu
>> metod obiektu przed literowkami w kluczach glownego hasza...
>
> IMO Conway utrudnia rzeczy proste a nie ułatwia skomplikowanych.
Eee... Sporo rzeczy w ksiazce jest przydatnych ;-)
> use Class::Accessor;
Nie wczytywalem sie zbytnio, ale niezbyt mi to pasuje ;-)
Jak malo akcesorow, to wile to nie przyspiesza, a jak wiele
takich prostych (samo mapowanie na strukture), to trza sie
zastanowic, czy obiekt jest dobrze zaprojektowany i czy w ogole
problem nalezy rozwiazywac metoda obiektowa...
Ja zazwyczaj w akcesorach (szczegolnie przy ustawianiu wartosc) mam jakies
sprawdzenia argumentow. No i czesto mam konwersje.
Dodatkowo, jak mi kiedys np. przyjdzie do glowy jakies rozdrobnienie
atrybutow przy zachowaniu zgodnego wstecz akcesora do zagregowanej
wartosci,
to bede mial mniej pzerobek ;-)
W koncu istota obiektowosci jest oddzielenie interfejsu od implementacji,
a Class:Accessors wydaje sie mi byc wlasnie silnym ich powiazaniem...
(wszystko powyzej wynikiem 2min czytania dokumentacji do niego jest, wiec
moge sie mylic ;-))
> Ja stosuję
> if (warunek)
> {
> ...
> }
> else
> {
> ...
> }
>
> Ale to wszystko kwestia przyzwyczajeń.
A to tez IMO mniej czytelne...
instr {
...
} instr {
...
}
optycznie wyroznia stanowiace calosc konstrukcje.
Niezaleznie, czy to if {} elsif (){} else{},
czy sort {} grep {} map {}
Od razu widac, co jest caloscia, nie trzeba szukac srednikow w poprzedniej
instrukcji...
Ale to tylko moja opinia ;-P
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
Vava - 24-12-2006 00:49
Dariusz Jackowski <it@is.invalid> napisał(a):
> Argument o wykrywaniu literówek jest nietrafiony, bo to samo wykryjesz
> jeśli używasz strict && warnings.
No nie do konca:
sub set_accessories_name {
my ($self, $name) = @_;
die "zla nazwa" unless /^[A-Z][A-Za-z]+\s+\w*$/;
$self->{accesories_name} = $name;
}
sub get_accessories_name {
my $self = shift;
return $self->{accessories_name};
}
Pozostanie niewykryte przez strict i warnings...
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
Dariusz Jackowski - 24-12-2006 00:49
Vava wrote:
>
>> use Class::Accessor;
>
> Ja zazwyczaj w akcesorach (szczegolnie przy ustawianiu wartosc) mam
> jakies sprawdzenia argumentow. No i czesto mam konwersje.
> Dodatkowo, jak mi kiedys np. przyjdzie do glowy jakies rozdrobnienie
> atrybutow przy zachowaniu zgodnego wstecz akcesora do zagregowanej
> wartosci, to bede mial mniej pzerobek ;-)
Tworzysz metodę o takiej samej nazwie co akcesor, walidujesz dane i robisz z
nimi co chcesz. Jak skończysz odwołujesz się przez SUPER.
--asc
Dariusz Jackowski - 24-12-2006 00:49
Vava wrote:
>
>> Argument o wykrywaniu literówek jest nietrafiony, bo to samo
>> wykryjesz jeśli używasz strict && warnings.
>
> No nie do konca:
[...]
> Pozostanie niewykryte przez strict i warnings...
Zostanie wykryte, tylko później - jak będziesz chciał użyć tego undefa.
--asc
Vava - 24-12-2006 00:49
Dariusz Jackowski <it@is.invalid> napisał(a):
> Vava wrote:
>>
>>> Argument o wykrywaniu literówek jest nietrafiony, bo to samo
>>> wykryjesz jeśli używasz strict && warnings.
>>
>> No nie do konca:
>
> [...]
>
>> Pozostanie niewykryte przez strict i warnings...
>
> Zostanie wykryte, tylko później - jak będziesz chciał użyć tego undefa.
Owszem... Np. 2 tygodnie pozniej i wez czlowieku szukaj przyczyny ;-P
Zeby bylo jasne - nie uwazam, by to byl wystarczajacy powod na przejscie
na inside-out ;-)
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
Vava - 24-12-2006 00:49
Dnia 05-08-2006 o 20:14:27 Dariusz Jackowski <it@is.invalid> napisał(a):
> Vava wrote:
>>
>>> use Class::Accessor;
>>
>> Ja zazwyczaj w akcesorach (szczegolnie przy ustawianiu wartosc) mam
>> jakies sprawdzenia argumentow. No i czesto mam konwersje.
>> Dodatkowo, jak mi kiedys np. przyjdzie do glowy jakies rozdrobnienie
>> atrybutow przy zachowaniu zgodnego wstecz akcesora do zagregowanej
>> wartosci, to bede mial mniej pzerobek ;-)
>
> Tworzysz metodę o takiej samej nazwie co akcesor, walidujesz dane i
> robisz z nimi co chcesz. Jak skończysz odwołujesz się przez SUPER.
Bez sensu ;-) Dwa razy wiecej roboty, u mnie czyste akcesory sa
rzadkoscia...
Wychodze z zalozenia, ze to najlepsze miejsce walidacji i konwersji ;-)
Ostatnio pisze rzeczy glownie na 'drugim koncu' kolejki MQSeries niz jakas
javowa aplikacja, to sprawdzenia i konwersja, to dla mnie podstawa ;-)
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
hubert depesz lubaczewski - 24-12-2006 00:49
On 2006-08-05, Vava <vava-jedenaste-nie-spamuj@plusnet.pl> wrote:
> Tak BTW, to w kilku miejscach sie z Conway'em nie zgadzam... Np. jak dla
> mnie:
a to ciekawe bo to jeden z punktów gdzie też całkowicie go nie rozumiem.
depesz
--
http://www.depesz.com/index.php/2006...udzi-do-pracy/
Krzysztof Krzyżaniak - 24-12-2006 00:49
hubert depesz lubaczewski <depesz@depesz.com> writes:
> hej
> zasadniczo pytanie jest proste - co sądzicie o koncepcji obiektów
> inside-out którą conway przedstawił w "best practices"?
> podchodzę do tego "jak do jeża". niby conway to uznany autorytet, ale
> jakoś mnie to nie przekonuje. utrudnia pisanie a zabezpieczenie jest
> jakieś takie ... nie wiem - iluzoryczne? 2 różne obiekty mogą sobie
> bezstresowo nadpisać dane. i nie chodzi o to, że celowo - po prostu
> przez nieuwagę programisty. no chyba, że czegoś nie kojarzę za dobrze z
> jego wywodów.
>
> ogólnie - wasze opinie o temacie?
BTW przy okazji okołocatalystowych spraw się wykrystalizował moduł OOP o
nazwie Moose (http://search.cpan.org/~stevan/Moose/). Jest to próba
zaimplementowania w perl5 obiektów takie jakie mają istnieć (potencjalnie
oczywiście) w perl6. Wygląda to dosyć ciekawie aczkolwiek nie budowałem na
tym żadnej poważnej aplikacji (poważnej ne 'hello world!')
eloy
--
-------e-l-o-y----------------------------e-l-o-y-@-k-o-f-e-i-n-a-.-n-e-t------
jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[Oracle, Toad] Zaladowanie obiektu w TOAD
=?iso-8859-2?Q?mo=BFliwo=B6=E6_kupienia_zestaw=F3w_obiekt=F3w _ro=B6lin?=
=?ISO-8859-2?Q?Jak_sprawdzi=E6_czy_obiekt_zosta=B3_utowrzony= 3F?=
corel... jak spłaszczyć obiekt z jego obrysem aby stanowiło jedną całość
jak naniesc na obraz skale pokazujaca rzeczywisty rozmiar sfotografowanego obiektu
[swing] Kolorowa ramka/tło w obiektach JTextComponent z ustawionym focusem.
[sybase] Jak w sprawdzić strukturę obiektu (tabeli) w Interactive SQL ???
wyrownanie obiektu wzgledem innego w PS - czy jest taki skrot?
Obiektowy PL/SQL - problem z typem REF
[PG 8.2] - konwencje nazewnictwa =?ISO-8859-2?Q?obiekt=F3w?=
zanotowane.pldoc.pisz.plpdf.pisz.plmarcelq.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
