🚀 go-pugleaf

" Aneta" <aneta_ra@WYTNIJ.gazeta.pl> writes:

[...]

> Ale czym rózni sie np javowe: 
>  
> if ( thisClassAssertsOn && !(x >=0) )  
>          throw new AssertionFailed("X ujemne, rowne " + x);  
>  
> od asercji proponowanych przez Meyera? 

Od pythonowych na pewno różni się czytelnością.
  
> Czy rzeczywiscie w Javie nie ma "Design by Contract", czy tylko
> implementuje sie to w tym jezyku mniej elegancko niż w Eiffelu? 

Jej, warunki wstępne i końcowe można sobie zaimplementować praktycznie
w dowolnym języku, tyle że niektóre języki mają do tego lepsze
wsparcie w składni, a inne gorsze.  DBC jest raczej sposobem tworzenia
programów, niż cechą języka programowania.  No i IMO DBC b. dobrze się
'zgrywa' z duck typing i językami z dynamicznym typowaniem.

-- 
http://www.piotr.dembiński.prv.pl

Aneta wrote (tak! stara dobra wrotka!):

> if ( thisClassAssertsOn && !(x >=0) )  
>          throw new AssertionFailed("X ujemne, rowne " + x);

A czy to się jakoś różni od javowego:

assert bool_expression, message_epression;
?

-- 
Zbigniew Malec Ustronie:104 gg:2756100

On Sun, 20 Nov 2005 12:40:34 +0000 (UTC), " Aneta"
<aneta_ra@WYTNIJ.gazeta.pl> wrote:

>witam 
> 
>Czytam sobie ostatnio "Programowanie zorientowane obiektowo 2-wydanie" 
>Meyera i poznaje tajniki Eiffela ;} Kwestia natomiast dotyczy pewnych 
>mechanizmów opisywanych w tej książce w kontekście Javy. Wg opinii Java 
>dobrze zaimplementowanych asercji i "Design by Contract" nie ma. 
>Ale czym rózni sie np javowe: 
> 
>if ( thisClassAssertsOn && !(x >=0) )  
>         throw new AssertionFailed("X ujemne, rowne " + x);  
> 

Skad ci sie to wzielo?... Assertions w Javie robi sie tak:

public class FooBar
{
  public void m1( int value )
  {
    assert 0 <= value : "Value must be non-negative: value= " +
value;
    System.out.println( "OK" );
  }

A.L.

> Skad ci sie to wzielo?... Assertions w Javie robi sie tak:

Zakladajac że uzywasz Javy >= 1.4. Ja z pewnych wzgledów zmuszona jestem
uzywac 1.3 a tam nie mam czegos takiego jak "assert".

Poza tym nie w tym rzecz. Ja rozumiem że kwestie takie jak warunki wejsciowe,
wyjsciowe i inwarianty klas (czyli rzeczy składające się na "Design by
Contract") to niemal specyfikacja na poziomie języka (samo DBC to w zasadzie
projektowanie). Ale rzecz wlasnie w tym, że Eiffel wspomaga to doskonale na
poziomie składni. Stad moje pytanie, czy Waszym zdaniem asercje i samo DBC
jest w Javie trudniej/mniej elegancko realizowane. 

eh, mam nadzieje że nie przyczepicie się do moich (zapewne) niefortunnych
konstrukcji jezykowych (specyfikacja na poziomie języka itp). Mam nadzieję, że
nie zagmatwalam zbyt mocno.

Pozdr. Aneta

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Sun, 20 Nov 2005 15:32:07 +0000 (UTC), " Aneta"
<aneta_ra@NOSPAM.gazeta.pl> wrote:

>
>> Skad ci sie to wzielo?... Assertions w Javie robi sie tak:
>
>Zakladajac że uzywasz Javy >= 1.4. Ja z pewnych wzgledów zmuszona jestem
>uzywac 1.3 a tam nie mam czegos takiego jak "assert".

Zmuszona przez co/kogo?...
>
>Poza tym nie w tym rzecz. Ja rozumiem że kwestie takie jak warunki wejsciowe,
>wyjsciowe i inwarianty klas (czyli rzeczy składające się na "Design by
>Contract") to niemal specyfikacja na poziomie języka (samo DBC to w zasadzie
>projektowanie). Ale rzecz wlasnie w tym, że Eiffel wspomaga to doskonale na
>poziomie składni. Stad moje pytanie, czy Waszym zdaniem asercje i samo DBC
>jest w Javie trudniej/mniej elegancko realizowane. 

Asercje sa w Jawie elegancko realizowane, ale ich przeznaczeniem nie
jest bynajmniej DBC. 

Jest mniej elegancko reprezentwoane, albowiem nie jest dostaczane
przez jezyk tylko trzeba sobie zrobic samemu. Zreszta, jak to zrobic
pokazuje iContract.

A.L.

On Sun, 20 Nov 2005 11:21:06 -0600, A.L. <alewando@kapturek62.com>
wrote:
 
>Jest mniej elegancko reprezentwoane, albowiem nie jest dostaczane
>przez jezyk tylko trzeba sobie zrobic samemu. Zreszta, jak to zrobic
>pokazuje iContract.
>

iContract zdechl, wyglada na to. 

Jak zrobic DBC w Javie bez iContract jest napisane w ksiazce "Design
by Contract - by Example", Richard Mitchell & Jim Kim, Addison
Wesley, 2002. Widac tam latwo ze to nie rocket science.

A.L.

"A.L." <alewando@kapturek62.com> wrote:

> iContract zdechl, wyglada na to. 

http://csd.informatik.uni-oldenburg.de/~jass/

Od jakiegos miesiaca sie do tego przymierzam. Choc nie wiem czy warto...

Masz jakies doswiadczenia z narzedziami wspomagajacymi DBC w Java'ie ?


mp

> Zmuszona przez co/kogo?... 
 
Przez wymogi zwiazane z projektem. Używamy w jednym z projektów 
specyficznej (starszej) wersji Interbase'a z kilkoma dodatkami. Wszystko 
gra doskonale z Java 1.3 i starszym jdbc. Firma która zrobila te "dodatki" 
supportuje calosc tylko z jdk 1.3. Niestety.  
Ja co prawda nie zajmuje się tam Java tylko administrowaniem bazami - ale 
programowania obiektowego chce się nauczyc ;} 
  
> Asercje sa w Jawie elegancko realizowane, ale ich przeznaczeniem nie 
> jest bynajmniej DBC.  
 
Fakt. Zaczelam sie przegryzać przez III część meyerowskiej biblii ;} 
Przyznaje że filozofia Eiffela duzo bardziej mi odpowiada niż to całe 
smalltalkowe dynamiczne typowanie,"extreme programming" i w efekcie 
"refaktoring z konieczności". Szkoda ze Eiffel jest tak mało popularny. 
 
Pozdr. Aneta 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

" Aneta" <aneta_ra.SKASUJ@gazeta.pl> writes:

[...]

> Przyznaje że filozofia Eiffela duzo bardziej mi odpowiada niż 
> to całe smalltalkowe dynamiczne typowanie,"extreme programming" 
> i w efekcie "refaktoring z konieczności". 

Acha, a co rozumiesz pod pojęciem 'refaktoring'?

Dnia Sun, 20 Nov 2005 18:50:07 +0000 (UTC),  Aneta skrobie:
> Przyznaje że filozofia Eiffela duzo bardziej mi odpowiada niż to całe 
> smalltalkowe dynamiczne typowanie,"extreme programming" i w efekcie 
> "refaktoring z konieczności".

Nie rozumiem.

Refactoring jest rzeczą całkowicie normalną niezależnie od użytego języka
programowania. Faktem jest, że może i moje zdanie ntt. bierze się stąd, że nie
zdarzyło mi się jeszcze używać języka, który by tej zasady nie potwierdzał.

Zazwyczaj zawsze jest tak, że najpierw programi się robi tak, żeby chodził, a
potem dopiero tak, żeby wyglądał. Często jest też tak, że dopiero później
wpadamy na pomysł, jak różne rzeczy można było zrobić lepiej. Dlatego
wspomaganie refactoringu to jest moim zdaniem konkretne narzędzie do
rozwiązania konkretnego problemu, który pojawia się zawsze.

> Szkoda ze Eiffel jest tak mało popularny. 

Dla mnie jest całkowicie niestrawny. Myślę też, że nie jestem jedyny pod tym
względem.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Sun, 20 Nov 2005 18:57:01 +0100, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"A.L." <alewando@kapturek62.com> wrote:
>
>> iContract zdechl, wyglada na to. 
>
>http://csd.informatik.uni-oldenburg.de/~jass/
>
>Od jakiegos miesiaca sie do tego przymierzam. Choc nie wiem czy warto...
>
>Masz jakies doswiadczenia z narzedziami wspomagajacymi DBC w Java'ie ?
>

Nie, oprocz tego ze DBC uzywane ejst do projektowania i dokumentacji
JUnits

A.L.

On Sun, 20 Nov 2005 18:50:07 +0000 (UTC), " Aneta"
<aneta_ra.SKASUJ@gazeta.pl> wrote:

>> Zmuszona przez co/kogo?... 
> 
>Przez wymogi zwiazane z projektem. Używamy w jednym z projektów 
>specyficznej (starszej) wersji Interbase'a z kilkoma dodatkami. Wszystko 
>gra doskonale z Java 1.3 i starszym jdbc. Firma która zrobila te "dodatki" 
>supportuje calosc tylko z jdk 1.3. Niestety.  
>Ja co prawda nie zajmuje się tam Java tylko administrowaniem bazami - ale 
>programowania obiektowego chce się nauczyc ;} 

No dobra, a wlasnego komputera w domu nie masz?.. .Jave, Eiffla i
otoczenie mozna sobie sciagnac z sieci bez zadnuch kosztow.

Uczenei sie Javy 1.3 gdy 1.5 istnieje i to od niejakiego  czasu to
zawracanei glowy.

A.L>

> Acha, a co rozumiesz pod pojęciem 'refaktoring'? 
 
Zmiana/ulepszanie implementacji kodu - bez zmiany jego funkcjonalności. 
Jasne ze wykonuje się to bez względu na jezyk (i rodzaj typizacji), ale 
mam wrazenie ze im wieksza dyscypilna w tworzeniu/projektowaniu kodu - tym 
mniejsza potrzeba refaktoringu.  
 
Pozdr. Aneta  
 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> No dobra, a wlasnego komputera w domu nie masz?.. .Jave, Eiffla i 
> otoczenie mozna sobie sciagnac z sieci bez zadnuch kosztow. 
> Uczenei sie Javy 1.3 gdy 1.5 istnieje i to od niejakiego  czasu to 
> zawracanei glowy. 
 
Jasne że mam... i ucze sie "normalnej Javy" :} Po prostu przyklad który 
podalam pochodził z implementacji opartej na 1.3.  
 
Pozdr. Aneta 
 
 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Sun, 20 Nov 2005 20:23:47 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>Dnia Sun, 20 Nov 2005 18:50:07 +0000 (UTC),  Aneta skrobie:
>> Przyznaje że filozofia Eiffela duzo bardziej mi odpowiada niż to całe 
>> smalltalkowe dynamiczne typowanie,"extreme programming" i w efekcie 
>> "refaktoring z konieczności".
>
>Nie rozumiem.
>
>Refactoring jest rzeczą całkowicie normalną niezależnie od użytego języka
>programowania. Faktem jest, że może i moje zdanie ntt. bierze się stąd, że nie
>zdarzyło mi się jeszcze używać języka, który by tej zasady nie potwierdzał.
>
>Zazwyczaj zawsze jest tak, że najpierw programi się robi tak, żeby chodził, a
>potem dopiero tak, żeby wyglądał. Często jest też tak, że dopiero później
>wpadamy na pomysł, jak różne rzeczy można było zrobić lepiej. Dlatego
>wspomaganie refactoringu to jest moim zdaniem konkretne narzędzie do
>rozwiązania konkretnego problemu, który pojawia się zawsze.
>
>> Szkoda ze Eiffel jest tak mało popularny. 

Eiffel nie jest popularny, bo refactoring w nim robic trudno. W
ogole, bardzo trudni w nim zaplikowac Podstawawy Paradygmat
Programowania: "najpierw kodujemy, potem myslimy a na koncu pytamy o
co klientowi chodzilo". Skad to? ... Ano z "Extreme Programming
HowTo Bible".

A.L.

> Refactoring jest rzeczą całkowicie normalną niezależnie od użytego języka 
> programowania.  
 
Tak, ale jesli jezyk jest statycznie typizowany, oferuje elegancką 
implementacje asercji i niemal zmusza do pisania czytelnego i poprawnego 
kodu - to jakby minimalizuje ilość zarówno błędów jak i malo efektywnych 
konstrukcji w tym kodzie. IMHO oczywiście. 
  
> Dla mnie jest całkowicie niestrawny. Myślę też, że nie jestem jedyny pod 
tym 
> względem. 
 
Ale dlaczego. Jest maly i czytelny. Oferuje ciekawe możliwości 
(programowanie wspólbiezne, kontraktowe, bardzo ciekawie pomyślane  
wielodziedziczenie (nie trzeba zajmowac się wynikajacymi z tego 
konfliktami). Do tego w Eifflu istnieją klasy "odroczone", umozliwiajace 
unieważnianie odziedziczonych metod i zastepowanie ich innymi.  
No i rewelacyjna technologia "Melting Ice" (to już bardziej cecha srodowiska 
pewnie). W programie napisanym w Eiffel'u "rozmrazasz" kawalki systemu i 
możesz takie kawalki testowac jako kod interpretowany (obok "zamrozonych" 
kawalkow) :} 
 
Ma moze na pierwszy rzut oka odrobine rozwlekla skladnie. Ale to ma  
zarowno Ada, Simula (z ktorej sie Eiffel wywodzi) jak i Smalltalk. 
 
Pozdr. Aneta 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> Refactoring jest rzeczą całkowicie normalną niezależnie od użytego języka 
> programowania.  
 
Tak, ale jesli jezyk jest statycznie typizowany, oferuje elegancką 
implementacje asercji i niemal zmusza do pisania czytelnego i poprawnego 
kodu - to jakby minimalizuje ilość zarówno błędów jak i malo efektywnych 
konstrukcji w tym kodzie. IMHO oczywiście. 
  
> Dla mnie jest całkowicie niestrawny. Myślę też, że nie jestem jedyny pod 
tym 
> względem. 
 
Ale dlaczego. Jest maly i czytelny. Oferuje ciekawe możliwości 
(programowanie wspólbiezne, kontraktowe, bardzo ciekawie pomyślane  
wielodziedziczenie (nie trzeba zajmowac się wynikajacymi z tego 
konfliktami). Do tego w Eifflu istnieją klasy "odroczone", umozliwiajace 
unieważnianie odziedziczonych metod i zastepowanie ich innymi.  
No i rewelacyjna technologia "Melting Ice" (to już bardziej cecha srodowiska 
pewnie). W programie napisanym w Eiffel'u "rozmrazasz" kawalki systemu i 
możesz takie kawalki testowac jako kod interpretowany (obok "zamrozonych" 
kawalkow) :} 
 
Ma moze na pierwszy rzut oka odrobine rozwlekla skladnie. Ale to ma  
zarowno Ada, Simula (z ktorej sie Eiffel wywodzi) jak i Smalltalk. 
 
Pozdr. Aneta 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

WYSYŁAJ RAZ!!!
:)

Dnia Sun, 20 Nov 2005 20:54:39 +0000 (UTC),  Aneta skrobie:
> > Refactoring jest rzeczą całkowicie normalną niezależnie od użytego języka 
> > programowania.  
>  
> Tak, ale jesli jezyk jest statycznie typizowany, oferuje elegancką 
> implementacje asercji i niemal zmusza do pisania czytelnego i poprawnego 
> kodu - to jakby minimalizuje ilość zarówno błędów jak i malo efektywnych 
> konstrukcji w tym kodzie. IMHO oczywiście. 

Nie wyobrażam sobie tego.

Jeśli chcę napisać program tak, żeby się przekonać, czy moje założenia były
słuszne, że wstępny projekt, który opracowałem ma szanse się doczekać
implementacji i że nie wystąpi nagle jakieś "a to tak to się nie da", to muszę
pierwszą implementację zrobić po prostu jak najszybciej.

Jak najszybciej, dlatego, że nie mam zamiaru babrać się w pisanie jakiegoś
super-czytelnego, dobrze poukładanego, ładnie wyglądającego i łatwo
rozszerzalnego kodu, jeśli przez przeoczenie jakiegoś drobnego szczegółu cały
kod może się okazać do wyrzucenia. No, może nie cały kod, ale mnie wystarczy,
że ze dwie klasy z 20-stu trzeba będzie napisać od nowa, to znaczy że cała
praca, jaką spędziłem na uporządkowanie tego to była robota głupiego.

I obawiam się, że zupełnie nie mają tutaj nic do rzeczy kwestie robienia
asercji, czy statycznej typizacji. Asercje, które mogę robić odpowiednimi
makrami w C++ (o dowolnym sposobie działania) wcale takie złe nie są,
statyczna typizacja też jest. Ale sposób uporządkowania projektu, wsadzenie
odpowiednich rzeczy w takie-a-nie-inne klasy, tworzenie między nimi
odpowiednich powiązań i odpowiedni podział programu na mniejsze kawałki, to
jest robota, jaką trzeba odłożyć do czasu, gdy powstanie coś, co działa, nawet
jeśli do działania będzie wymagać jakiegoś tymczasowego środowiska.
Oczywiście, że taki podział też się w czasie robienia tej
"protoimplementacji", ale zwykle ulega on później różnym poprawkom.

Refactoring też rzadko jest ukierunkowany na poprawianie błędów i mało
efektywnych konstrukcji. Tego rodzaju praca to jest maintenance, a nie
refactoring.

> > Dla mnie jest całkowicie niestrawny. Myślę też, że nie jestem jedyny pod 
> tym 
> > względem. 
>  
> Ale dlaczego. Jest maly i czytelny.

Nie wiem co to znaczy, że jest mały, pod jakim względem, ani czemu to jest
jego zaleta.

Co do czytelności to jest to rzecz względna. Dla kogoś, dla kogo czytelne są
Pascal, Ada, czy Simula, pewnie jest. Dla mnie nie jest.

> Oferuje ciekawe możliwości (programowanie wspólbiezne,

To w tej chwili oferują już wszystkie języki, a jeśli nie języki, to
biblioteki.

> kontraktowe,

Koncepcja na pewno ciekawa, ja jej jeszcze nie miałem okazji wypróbować.
Myślę, że jest warta spróbowania, ale to znacznie za mało, żeby mnie zachęcić
do takiego języka.

> bardzo ciekawie pomyślane  
> wielodziedziczenie (nie trzeba zajmowac się wynikajacymi z tego 
> konfliktami).

Bardzo jestem ciekaw jak, bo nie bardzo sobie wyobrażam JAKIEKOLWIEK
rozwiązanie tego problemu - o ile mówimy o tym samym. W C++ w szczególności
objawia się to w ten sposób, że w sytuacji gdy dwie klasy bazowe dostarczają
swoje implementacje metody o tej samej sygnaturze, to nie można wywołać metody
na rzecz obiektu klasy pochodnej, jeśli ta klasa nie dostarczy jej swojej
definicji.

Problem jest tutaj już na poziomie teoretycznym i rozwiązanie tego problemu
nie istnieje z przyczyn zasadniczych: jest to sytuacja, która normalnie w
programowaniu obiektowym zajść nie powinna, głównie dlatego, że normalnie w
programownaiu obiektowym nie istnieje wielorakie dziedziczenie. Założenie jest
takie, że obiekt przekazuje klasie otrzymany komunikat, żeby go obsłużyła.
Klasa tego nie umie obsłużyć, więc odsyła do swojej klasy bazowej. W przypadku
wielorakiego dziedziczenia można tu zadać wtedy pytanie: do KTÓREJ bazowej i
dlaczego właśnie do tej?

A jeśli jakoś rozwiążemy ten problem np. poprzez poinformowanie klasy
pochodnej o tym, która klasa bazowa które metody implementuje (co musi się już
wtedy rozciągać na całą hierarchię i tak właśnie jest w C++ i to się właśnie
nazywa "podleganie dziedziczeniu"), to wtedy nam dochodzi właśnie problem
polegający na kolizji uprawnień: dwie klasy chciałyby obsługiwać komunikat o
określonej sygnaturze i która z nich ma owo uprawnienie otrzymać?

> Do tego

No i właśnie nie wiem, co miało w tym zdaniu znaczyć owo "Do tego". Czy miało
to się odnosić do poprzedniego zdania (czyli "Do realizacji tego celu"), czy
też mówi o zupełnie oddzielnej rzeczy (czyli "Ponadto").

> w Eifflu istnieją klasy "odroczone", umozliwiajace 
> unieważnianie odziedziczonych metod i zastepowanie ich innymi.  

Jeśli dobrze rozumiem, to jest to tzw. przysłanianie metod (ang. overriding) i
istnieje w KAŻDYM języku obiektowym.

> No i rewelacyjna technologia "Melting Ice" (to już bardziej cecha srodowiska 
> pewnie). W programie napisanym w Eiffel'u "rozmrazasz" kawalki systemu i 
> możesz takie kawalki testowac jako kod interpretowany (obok "zamrozonych" 
> kawalkow) :} 

Nie no metodologia jest na pewno niezła; każdy dobry sposób debugowania się na
pewno przyda. Z drugiej jednak strony mnie by w zupełności wystarczyła dobra
maszyna wirtualna, która udostępniałaby śledzenie wszelkiego dostępu do
pamięci. Nie musi być to interpretacja kodu, zwłaszcza jeśli nie widzę podczas
testowania większej różnicy.

> Ma moze na pierwszy rzut oka odrobine rozwlekla skladnie. Ale to ma  
> zarowno Ada, Simula (z ktorej sie Eiffel wywodzi) jak i Smalltalk.

Odnoszę wrażenie, że jest to jedna z istotnych przyczyn, dla których wszystkie
te języki zdechły dla przemysłu.

Niech ktoś wymyśli Eiffla o Javopodobnej składni i właduje odpowiednią kasę w
jego wypromowanie, a natychmiast stanie się popularny.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

A.L. <alewando@kapturek62.com> writes:

[...]

> W ogole, bardzo trudni w nim zaplikowac Podstawawy Paradygmat
> Programowania: "najpierw kodujemy, potem myslimy a na koncu pytamy 
> o co klientowi chodzilo". Skad to? ... Ano z "Extreme Programming
> HowTo Bible".

Z tego wynika, że XP to jest podejście od d*y strony ;)

" Aneta" <aneta_ra.SKASUJ@gazeta.pl> writes:

>> Acha, a co rozumiesz pod pojęciem 'refaktoring'? 
>  
> Zmiana/ulepszanie implementacji kodu - bez zmiany jego
> funkcjonalności.  Jasne ze wykonuje się to bez względu na jezyk 
> (i rodzaj typizacji), ale mam wrazenie ze im wieksza dyscypilna 
> w tworzeniu/projektowaniu kodu - tym mniejsza potrzeba refaktoringu.

Sama refaktoryzacja w rozumieniu fowlerowskim (czyli stricte
praktycznym) powinna być prszeprowadzana w sposób zdyscyplinowany 
i systematyczny.  Co do potrzeby refaktoryzacji, to spytaj się sama,
jak często np. zmieniasz w swoich programach nazwy metod i zmiennych.

-- 
http://www.piotr.dembiński.prv.pl

On Sun, 20 Nov 2005 22:23:40 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>WYSYŁAJ RAZ!!!
>:)
>
>Dnia Sun, 20 Nov 2005 20:54:39 +0000 (UTC),  Aneta skrobie:
>> > Refactoring jest rzeczą całkowicie normalną niezależnie od użytego języka 
>> > programowania.  
>>  
>> Tak, ale jesli jezyk jest statycznie typizowany, oferuje elegancką 
>> implementacje asercji i niemal zmusza do pisania czytelnego i poprawnego 
>> kodu - to jakby minimalizuje ilość zarówno błędów jak i malo efektywnych 
>> konstrukcji w tym kodzie. IMHO oczywiście. 
>
>Nie wyobrażam sobie tego.
>
>Jeśli chcę napisać program tak, żeby się przekonać, czy moje założenia były
>słuszne, że wstępny projekt, który opracowałem ma szanse się doczekać
>implementacji i że nie wystąpi nagle jakieś "a to tak to się nie da", to muszę
>pierwszą implementację zrobić po prostu jak najszybciej.
>
>Jak najszybciej, dlatego, że nie mam zamiaru babrać się w pisanie jakiegoś
>super-czytelnego, dobrze poukładanego, ładnie wyglądającego i łatwo
>rozszerzalnego kodu, jeśli przez przeoczenie jakiegoś drobnego szczegółu cały
>kod może się okazać do wyrzucenia. No, może nie cały kod, ale mnie wystarczy,
>że ze dwie klasy z 20-stu trzeba będzie napisać od nowa, to znaczy że cała
>praca, jaką spędziłem na uporządkowanie tego to była robota głupiego.
>
           
Budujemy dom wedle S.v.S.: "Panowie, lac beton! potem poprawimy!"

A.L.

Dnia Mon, 21 Nov 2005 07:16:22 -0600, A.L. skrobie:
> Budujemy dom wedle S.v.S.: "Panowie, lac beton! potem poprawimy!"

Pańskim zdaniem zatem budynki buduje się wedle projektu rysunkowego i zbioru
wzorów określających jego charakterystyki. Żadnych symulacji, żadnych
weryfikacji, żadnego przewidywania. Po prostu robimy projekt i do końca się go
trzymamy.

Ciekawie to wygląda po zaimplementowaniu w tworzeniu oprogramowania. Wygląda
na to, że wszystko musi być zaimplementowane, żeby chodziło od strzału,
niczego nie testujemy, bo nie ma jak, tylko od pierwszego znaku źródła do
ostatniego aplikacja jest "pisana", a potem tylko ją odpalamy i ma działać. W
tym celu musimy zatrudnić super-wybitnych programistów, którzy potrafią
napisać program tak, żeby chodził "od strzału".

Panie AL. Wiesz pan za pewne lepiej ode mnie, że gdyby oprogramowanie tworzyło
się zgodnie z takimi regułami, z jakimi buduje się domy, to:

a) tworzyłoby się go 10 razy dłużej
b) w oprogramowaniu, które powstaje byłoby 10 razy więcej błędów

Liczbę strzeliłem z powietrza oczywiście, chodziło mi tylko o porównanie.

Porównanie z budową domu jest nietrafione z dwóch względów:

1. Domy buduje się wedle tych samych reguł, co 100 lat temu, a ewentualne
zmiany w stosunku do tego to były tylko drobne ulepszenia; wszystko nadal
bazuje na tych samych założeniach - w oprogramowaniu każdy produkt wygląda
inaczej i działa wedle innych reguł.

2. Oprogramowanie można testować kawałkami i w symulowanych środowiskach,
czego raczej nie wyobrażam sobie w przypadku budynków.

Z drugiej jednak strony w przypadku budynków też czasami zdarza się
konieczność robienia poprawek po fakcie. Ale budynków nie da się budować w
taki sposób, żeby można było potem wprowadzić w nich niemal dowolną zmianę.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"