Unikanie klas - "BOGÓW"

Dla przykładu: klasa łącząca się z baza danych nie powinna renderować HTMLa.

Głębsze przykłady przychodzą do głowy patrząc na klienty XML-RPC i SOAP (dotyczy to również niektórych z klientów RSS). Z jednej strony dobre jest to, że dostarczają "gotowce" funkcjonalności, które są łatwe w użyciu. Wiele z nich łączy obsługę wiadomości XML-RPC/SOAP z użytecznością klienta HTTP, używając coś na wzór pojedynczej metody wykonywującej żądanie HTTP.

Kilka problemów, które wiążą się z tym: Jak kompletny jest klient HTTP? Czy może łączyć się z serwerem proxy, które wymaga hasła? Czy potrafi łączyć się z serwerem SSL? Czy potrafi rozumieć sesje i cookie? Czy obsługuje cachowanie? Pomieszczenie tego wszystkiego wewnątrz pojedynczej funkcji klasy spowoduje wiele problemów. Mało tego, SOAP został zaprojektowany, nie tylko do przesyłania przez HTTP, ale również poprzez SMTP (e-mail).

Będzie lepiej jeśli klient HTTP będzie oddzielną klasą, przekazywaną jako obiekt do klienta SOAP/XML-RPC (lub RSS). Jeśli natomiast chcemy zrobić, aby nasze klasy połączeń sieciowych nadawały się do wielokrotnego użytku, możemy pomyśleć o stworzeniu kilku klas: NetoworkClient (nie powiązanej z żadnym protokołem), HTTPClient_1_0 i HTTPClient_1_1 (współpracujących odpowiednio z wersjami 1.0 i 1.1 protokołu HTTP - różnice między wersjami są znaczące i powinny być traktowane jako osobne problemy) oraz SMTPClient. Współpracowałyby one na takiej zasadzie:

Teraz klient SOAP może używać SMTP lub HTTP. Jeśli API klas TCPClient jest dobre, to powinnien być możliwy prosty start, poźniej gdy bedziemy potrzebowali dodatkowej funkcjonalności, takiej jak współpraca z serwerem proxy, to po prostu ją dodamy - bez zmiany jakiekolwiek z klientów usług sieciowych.

Wracając do Eclipse, ciekawym rozwiązaniem jest separacja wyników pobranych z bazy danych od samego połączenia z nią. Pozwala to na proste przekazywanie wyników do innych klas, zamiast operować na "nieporęcznym" obiekcie zawierającym połączenie (obiekt Eclipse DatabaseResult posiada połączenie jako właściwość).