Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste
w tym przypadku, jest za duża. Chcę ją podzielić.

Problem polega na tym, że cokolwiek bym nie chciał wydzielić
z tej metody zmienia te zmienne lokalne. Jeżeli zmieniałoby
jedną, nie ma problemu:
x1 = doSth(a,b,c,d,e);

Ale jeżeli zmienia x1, y1 i z1, różnych typów? Najlepsze,
co dotychczas wymyśliłem ucząc się Javy po raz drugi to:

A arrX1 = new A[1]
B arrYZ = new B[] { y1, z1}
doSth(a,b,c,d,e, arrX1, arrZY)
x1 = arrX1[0];
y1 = zrrYZ[0];
z1 = arrZY[1];

Jest jakiś ogólny prostszy sposób? Kombinowałem z EnumMap
automatycznie weryfikującym typy i castującym przez generyki,
ale to już chyba łatwiej mieć 'private static class'
do każdej metody w celu przekazania parametrów "out" lub
"in/out".

Czy C# ma to jakoś lepiej rozwiązane?

Edek

do góry

On Monday, 25 June 2012 20:38:13 UTC+2, Edek Pienkowski wrote:
> Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste
> w tym przypadku, jest za duża. Chcę ją podzielić.

Jeżeli te wydzielone części nie mają wielkiej szansy być wykorzystywane gdzie indziej
to nie ma sensu jej dzielić, chyba że robi się nieczytelna, ale wtedy lepiej trochę
popracować nad kodem i obkomentować co trudniejsze kawałki.

Jeśli jednak jesteś pewien co do podziału, to myślę że lepiej niż tablic użyć
dedykowanych do tego mini klas POD.

AdamK

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Czy C# ma to jakoś lepiej rozwiązane?

Ma Tuple.
http://msdn.microsoft.com/en-us/library/system.tuple
.aspx

PS0: Nie sa idealne (gorsze niz w Pythonie), ale sa.
PS1: I nie C# jeno .NET k..de

AK

do góry

On 25/06/2012 19:38, Edek Pienkowski wrote:
> Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste
> w tym przypadku, jest za duża. Chcę ją podzielić.
>
> Problem polega na tym, że cokolwiek bym nie chciał wydzielić
> z tej metody zmienia te zmienne lokalne. Jeżeli zmieniałoby
> jedną, nie ma problemu:
> x1 = doSth(a,b,c,d,e);

elementarne - zrób klasę i zamień zmienne lokalne na prywatne pola
klasy, a częsci funkcji na funkcje klasy. Potem upraszczaj.


B.

do góry

Dnia Mon, 25 Jun 2012 20:30:49 +0100, Bronek Kozicki napisal:

> On 25/06/2012 19:38, Edek Pienkowski wrote:
>> Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste w tym
>> przypadku, jest za duża. Chcę ją podzielić.
>>
>> Problem polega na tym, że cokolwiek bym nie chciał wydzielić z tej
>> metody zmienia te zmienne lokalne. Jeżeli zmieniałoby jedną, nie ma
>> problemu:
>> x1 = doSth(a,b,c,d,e);
>
> elementarne - zrób klasę i zamień zmienne lokalne na prywatne pola
> klasy, a częsci funkcji na funkcje klasy. Potem upraszczaj.

Powiedz od razu, że mam pisać klasy zamiast metod - jest takich metod
dobre kilka. I nie bardzo wiem, co miałbym upraszczać i dlaczego miałbym
psuć działający kod - upraszczanie poniżej miminum jak empirycznie
stwierdzono nie jest najlepszym pomysłem, a metody nie są już do
uproszczenia. Kopiowanie pól przy rekurencji też mało mnie pociąga.

No ale ok, mogę stworzyć kilka takich klas. Wydajność będzie taka sama,
czyli nie niższa od niskich stanów średnich? A czytelność metody-jako-
klasy?

Edek

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Powiedz od razu, że mam pisać klasy zamiast metod - jest takich metod
> dobre kilka. I nie bardzo wiem, co miałbym upraszczać i dlaczego miałbym
> psuć działający kod

Nie znam Javy prawie wcale, ale...: napisz se (na wzor tego z .NET - to trywialne)
templejta tuple implementujacego interface Tuple i finito.

PS: i przestan truc ciagle o "wydajnosci" bo sie mdlo robi :(
PS1: zabraknie ci tej "wydajnosci" to sie bedziesz wtedy zastanawial

AK

do góry

Dnia Mon, 25 Jun 2012 21:48:21 +0200, AK napisal:

> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>
>> Powiedz od razu, że mam pisać klasy zamiast metod - jest takich metod
>> dobre kilka. I nie bardzo wiem, co miałbym upraszczać i dlaczego
>> miałbym psuć działający kod
>
> Nie znam Javy prawie wcale, ale...: napisz se (na wzor tego z .NET - to
> trywialne)
> templejta tuple implementujacego interface Tuple i finito.
>
> PS: i przestan truc ciagle o "wydajnosci" bo sie mdlo robi :(
> PS1: zabraknie ci tej "wydajnosci" to sie bedziesz wtedy zastanawial

Ja to mało wydajny jestem, ale już od dawna marudzą, że tool startuje
aż w 2 minuty, i to pomimo tego, że wcześniej startował w 6. Ciężkie
życie...

Edek
PS. Ciekawie cytujesz

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Ja to mało wydajny jestem, ale już od dawna marudzą, że tool startuje
> aż w 2 minuty, i to pomimo tego, że wcześniej startował w 6. Ciężkie
> życie...

No to sobie wbij do glowy, ze wlasnie to wychwalene "reczne" malloc jest
_najbardziej kosztowna funkcja w C/C++_.
Wiem, bo kiedys napisalem w asm86 cala biblioteke standardowa TC 2.0

AK

do góry

Dnia Mon, 25 Jun 2012 11:50:48 -0700, Adam Klobukowski napisal:

> On Monday, 25 June 2012 20:38:13 UTC+2, Edek Pienkowski wrote:
>> Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste w tym
>> przypadku, jest za duża. Chcę ją podzielić.
>
> Jeżeli te wydzielone części nie mają wielkiej szansy być wykorzystywane
> gdzie indziej to nie ma sensu jej dzielić, chyba że robi się
> nieczytelna, ale wtedy lepiej trochę popracować nad kodem i obkomentować
> co trudniejsze kawałki.

Częsciej komentuję "co" niż "jak".

>
> Jeśli jednak jesteś pewien co do podziału, to myślę że lepiej niż tablic
> użyć dedykowanych do tego mini klas POD.

To ma taki sam problem, jak wszystkie inne w Javie. Zamieniam 10 linijek
treści na call i 6 linijek kopiowania. Wycinając większy fragment,
zamieniam 50 linijek na call i 15 linijek kopiowania. Nie widzę sensu,
więc chyba zostaną duże metody z fluganiem na brak goto.

Edek

do góry

Dnia Mon, 25 Jun 2012 22:08:42 +0200, AK napisal:
>
> No to sobie wbij do glowy, ze wlasnie to wychwalene "reczne" malloc jest
> _najbardziej kosztowna funkcja w C/C++_.
> Wiem, bo kiedys napisalem w asm86 cala biblioteke standardowa TC 2.0

malloc i inne new mogą mieć zachcianki w rodzaju deframentacji sterty,
to wiadomo, że są na to podatne. Tyle, że to nic w porównaniu z Javą,
startup, operacje na stosie przy rekurencji itp. Niedawno był
chyba tutaj benchmark google kilku języków pod kątem właśnie takich
algorytmów.

Podobno każda klasa to jakieś 4K plus to co compiler, nie zamienię
metod na klasy bez powodu.

Edek

do góry