-
61. Data: 2012-06-29 05:15:00
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: " M.M." <m...@W...gazeta.pl>
Edek Pienkowski <e...@g...com> napisał(a):
> Powiedzmy, Ĺźe mam metodÄ ktĂłra ma ze 30 zmiennych i, co oczywiste
> w tym przypadku, jest za duĹźa. ChcÄ jÄ podzieliÄ.
Ciekawe na czym polega istota problemu, bo jak rozumiem z powodu
zwykłego podziału na pod-procedury na forum byś nie pisał.
Ja często po prostu nie dzielę. Nie dzielę gdy są spełnione dwa warunki:
1) Nie ma ani jednego kawałka wspólnego kodu. Mowa tutaj o trudnym kodzie, w
którym łatwo o błąd. Jeśli są małe wspólne fragmenty kodu, ale kod jest
trywialny to też nie dzielę.
2) Gdy jedna duża procedura robi jedno dobrze wydzielone zadanie. Na tyle
dobrze, że nie wyobrażam sobie aby w przyszłości zaszła potrzeba podziału.
Owszem czasami się mylę i źle oceniam na początku że nie będzie potrzebny
podział. Jednak są to sytuacje na tyle trudne, że nawet jakbym podzielił
od razu, to i tak bym to zrobił w sposób nieułatwiający późniejszą pracę
nad kodem.
A co do problemu dużej ilości parametrów, to można po prostu upakować w
strukturę albo klasę. Wtedy do każdej pod-procedury przekazujesz całą
klasę i goocio.
Pozdrawiam
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
62. Data: 2012-06-29 08:07:01
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: Edek Pienkowski <e...@g...com>
Dnia Fri, 29 Jun 2012 03:15:00 +0000, M.M. napisal:
> Edek Pienkowski <e...@g...com> napisał(a):
>
>> Powiedzmy, Ĺźe mam metodÄ ktĂłra ma ze 30 zmiennych i, co oczywiste w
>> tym przypadku, jest za duĹźa. ChcÄ jÄ podzieliÄ.
> Ciekawe na czym polega istota problemu, bo jak rozumiem z powodu
> zwykłego podziału na pod-procedury na forum byś nie pisał.
Głównie chodziło mi o przekazywanie parametrów w Javie.
>
> Ja często po prostu nie dzielę. Nie dzielę gdy są spełnione dwa warunki:
> 1) Nie ma ani jednego kawałka wspólnego kodu. Mowa tutaj o trudnym
> kodzie, w
> którym łatwo o błąd. Jeśli są małe wspólne fragmenty kodu, ale kod
> jest trywialny to też nie dzielę.
Ta nie ma wspólbych fragmentów, co najwyżej podobne.
> 2) Gdy jedna duża procedura robi jedno dobrze wydzielone zadanie. Na
> tyle
> dobrze, że nie wyobrażam sobie aby w przyszłości zaszła potrzeba
> podziału.
> Owszem czasami się mylę i źle oceniam na początku że nie będzie
> potrzebny podział. Jednak są to sytuacje na tyle trudne, że nawet
> jakbym podzielił od razu, to i tak bym to zrobił w sposób
> nieułatwiający późniejszą pracę nad kodem.
Ja podobnie, czasami jak metoda jest logiczną całością może być większa
i nie rozdzieram nad tym szat.
>
> A co do problemu dużej ilości parametrów, to można po prostu upakować w
> strukturę albo klasę. Wtedy do każdej pod-procedury przekazujesz całą
> klasę i goocio.
Lubię to, co kompilator Javy robi lokalnie dla metody.
1. final. Można mieć zmienną "final" lokalną dla bloku
2. Zagnieżdżone bloki
3. Dla zmiennych lokalnych kompilator nie ustawia domyślnych
wartości. Robi za to prosty dataflow i jeżeli jakaś ścieżka
wykonania aż do użycia zmiennej nie zawiera przypisania
do zmiennej wartości, to w Javie jest to błąd czasu kompilacji.
Dla prostych przypadków to nic nie daje, ale to fajne zabezpieczenie.
W C++ robię mało błędów, ale niezainicjalizowana zmienna to jeden
z najczęściej występujących problemów. Oczywiście można
zawsze czymś inicjalizować, chociażby nullem, ale w tych
przypadkach null to tak jak niezainicjalizowana więc w Javie
można nie przypisywać od razu wartości i polegać na kompilatorze.
Stosując obiekt na dane lub wydzielając kod metody do klasy traci
się wszystkie te właściwości.
Edek