🚀 go-pugleaf

Hej!

Kłóciłem się kiedyś z kumplem, który twierdził, że podprocedury są w  
języku zupełnie zbędne, że potrzeba ich zastosowania świadczy o  
design-flaw i że nie istnieje taka funkcja (którą chciałbym napisać jako  
podprocedurę), która nie może przydać się w przyszłości (co miało być  
argumentem za tym, żeby podprocedurę umieścić jako prywatną lub chronioną  
metodę w klasie - zwiększając tym samym zakres jej widoczności).

Napotkałem jednak sytuację, która wydaje się przeczyć powyższej  
argumentacji.

Otóż mam dwie listy do przetworzenia. Większość elementów występuje w obu  
listach, ale część jest tylko na jednej lub drugiej, np.

A - A
B - C
C - D
E - E

Algorytm musi przetworzyć wszystkie elementy, przy czym jeśli element  
występuje w obu listach, przetwarzany jest jako para, zaś jeśli tylko na  
jednej, to jest uzupełniany nullem. Czyli metoda przetworzy następujące  
pary:

(A, A)
(B, null)
(C, C)
(null, D)
(E, E)

Oczywiście elementy lewo- i prawostronne są rozróżniane. Mniejsza zresztą  
o sposób działania algorytmu.

Proces przetwarzania pary kompletnej od pary uzupełnionej nullem różni się  
dosyć znacząco, natomiast różnica pomiędzy przetworzeniem (<obj>, null), a  
(null, <obj>) jest niewielka i sprowadza się do jednej zmiennej typu  
wyliczeniowego, która przyjmuje różne wartości, w zależności od tego, czy  
null jest po lewej, czy po prawej stronie.

Naturalnym wydaje się - żeby uniknąć jednej, wielgachnej metody w połowie  
napisanej na zasadzie copy'n'paste - ubrać przetwarzanie pary oraz  
niepełnej pary w osobne metody. Kłopot polega jednak na tym, że metody te  
potrzebują kompletu parametrów przekazanych głównej metodzie, a nawet  
czasem dodatkowych informacji przechowywanych w zmiennych głównej metody.  
Gdybym mógł napisać podprocedurę, nie byłoby problemu, ponieważ  
podprocedury (np. w Delphi) mają pełny dostęp do wszystkich zmiennych i  
parametrów procedury czy metody, w której są zagnieżdżone. Wystarczyłoby  
więc przekazać tylko samą parę oraz informację o wspomnianej zmiennej  
wyliczeniowej i problem z głowy.

W C# niestety tak się nie da zrobić. Jeśli chciałbym zagrać zgodnie z  
regułami sztuki, musiałbym napisać dwie "podmetody" z długaśną listą  
parametrów (albo ubrać parametry w osobny obiekt, tyle że IMO powoli  
robiłaby się z tego sztuka dla sztuki). Alternatywą dla nieistniejących  
podmetod mogłoby być ubranie metody wraz z "podmetodami" w klasę i  
przechowywanie parametrów wywołania metody w polach tej klasy. Ale klasę  
taką trzeba byłoby tworzyć dla każdej listy par, a tych może być dużo  
(liczba idzie na pewno w tysiące, jeśli nie więcej, a algorytm jest  
rekurencyjny, więc ponowne używanie instancji klasy raczej odpada).

Jak więc estetycznie rozwiązać ten problem bez użycia podprocedur?

Pozdrawiam -- Spook.

-- 
! ._______. Warning: Lucida Console sig!    //)    !
! || spk ||    www.spook.freshsite.pl      / _ """*!
! ||_____||        spook at op.pl         / '  | ""!
! |  ___  |   tlen: spoko_ws gg:1290136  /. __/"\ '!
! |_|[]_|_|  May the SOURCE be with you! \/)     \ !