W dniu 2012-05-10 02:13, Andrzej Jarzabek pisze:
> On 09/05/2012 16:30, zażółcony wrote:
>>
>> Imo to nie tak ...
>> Tworzenie abstrakcji to nie żadne czary-mary, które sprawiają,
>> że w jednej linijce kodu implementujesz wiele wymagań użytkownika.
>> Jest wiele wymagań - będzie dużo kodu. Chyba że ...
>
> Akurat języki się potrafić dość znacznie tym, jak zwięzły kod można w
> nich pisać, tylko że nie ma to wiele wspólnego ani z wysokopoziomowością
> języka, ani z abstrakcją w kodzie.
>
> Java na przykład jest językiem wysokopoziomowym, a jest mocno rozwlekła.
>
>> Chyba że są to wymagania 'powszechne' a nie specyficzne, zwiazane
>> n. z modą na to, by okienka wyglądały tak samo. Wtedy ktoś Ci
>> to zrobi i powie, jak masz to użyć.
>
> Ale też chyba nie jest takie rzadkie, żeby abstrakcja redukowała ilośc
> kodu przez unikanie zduplikowania. Tyle że z drugiej strony ta sama
> abstrakcja potrafi też zwiększyć ogólną ilość kodu, i według mnie
> średnio raczej zwiększa, niż zmniejsza.

Jest różnie, raz w tę, raz we wtę.
Imo autor wątku zawęził znaczenie/celów stawianych tworzeniu abstrakcji,
zafiksował się na jednym, czyli "zwięzłość kodu". A tych celów/zadań
jest znacznie więcej, wymienię tu dwa, które mi przychodzą do głowy:

1. Podział odpowiedzialności

2. Ochrona kodu przed 'czeskimi' błędami - tak by np. jak najwięcej
błędów było wychwytywanych na etapie kompilacji, a nie w runtimie.

Ad 1.
Podział odpowiedzialności pomiędzy komponenty systemu jest kluczowy
w produkcji złożonego oprogramowania, nad którym np. pracuje wiele
osób. Podział odpowiedzialności/rozdział implementowanych wymagań
pomiędzy komponenty umożliwia z kolei:
- sprawną identyfikację miejsc w kodzie, minimalizację zmian
implementacyjnych, szacowanie ryzyka, ograniczanie ryzyka - kiedy
wymagania się zmieniają (zarządzanie zmianą)
- budowę, zarządzanie, uruchamianie testów jednostkowych
- podział odpowiedzialności wśród ludzi i kontrolę - np. w wydzielonych
podsystemach technicznych maja prawo grzebać tylko niektórzy, jest to
związane z dużym ryzykiem itp itd. Reszta 'klepie' szablonowe procedury
biznesowe
- z tym ostatnim wprost powiązane jest np. zmniejszenie kosztów szkoleń
nowych pracowników, bo nie muszą wiedzieć wszystkiego
- także jest z tym związana łatwiejsza komunikacja programistów z
analitykami/użytkownikami

Ad 2.
Bardzo typowe, czeskie błędy powstają na styku różnych języków
programowania, 'oczywisty' i powszechny przykład: literówki w
zapytaniach SQL schowanych w stringach w językach wyższego poziomu.
Kompilator Javy, choćby się skichał - nie wykryje literówki
w słowie kluczowym "SELECVT". Problem ten rozwiązuje się
na wiele sposobów, np. O/R mapping (cała technologia różnych
abstrakcji), które eliminują konieczność pisania wielu prostych
zapytań i/lub techniki zapisu zapytań SQL za pomocą języka wysokiego
poziomu - patrz np. takie pomysły, jak "Jacle"
http://code.google.com/p/jacle/
Warto zauważyć, że w tym ostatnim przypadku kod wcale nie staje się
zwięźlejszy, a wrecz odwrotnie (BTW. SQL należy do czołówki pod względem
zwięzłości zapisu wymagań.