On 11/10/2011 20:30, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>> Tylko że jedną z praktyk pisania niezawodnego oprogramowania jest żeby
>> w większych projektach opakować systemowe API w coś bardziej
>> abstrakcyjnego, czy to bibliotekę in-house czy third-party.
>
> Z tym się zdecydowanie nie zgodzę. To jest praktyka pisania oprogramowania
> przenośnego między platformami. Do pisania niezawodnego nie jest to
> wymagane.

Do pisania oprogramowania niezawodnego potrzebna jest abstrakcja i
czytelność kodu. Kod, który sobie po cichu zakłada, że int ma 32 bity ma
niedobory w jednym i drugim.

> Co jeśli poziom abstrakcji API systemowego jest właśnie idealnie dopasowany
> do zadania? Opakowywać go w coś, co ma te same możliwości, ale
> NIESTANDARDOWY interfejs?

Jeśli mówisz o programie, którego najlepszym opisem jest "wywołuje
taką-a-taką funkcję systemową" to może i jest to najlepszy poziom
abstrakcji. Jeśli jednak mówimy o dużych projektach pisanych przez
zespoły, to raczej norma jest taka, że operują na wyższym poziomie
abstrakcji.

> Ja wiem, że mamy trochę inne spojrzenie, ze względu na inne doświadczenia.
> Przechodziłem kiedyś przez taki etap rozwoju, że próbowałem opakowywać API
> systemowe. Z czasam osiągałem taki efekt, że moja "abstrakcja" powielała
> dokładnie to, co dawało API systemowe. Po prostu większość szczegółów API
> systemowego była mi rzeczywiście potrzebna.

Pracowałem przy kilku większych projektach i normą było korzystanie z
biblioteki opakowującej API, chociaż nie takiej, która jest tworzona pod
konkretny projekt: albo były to biblioteki third party, albo robione w
firmie na potrzeby wielu projektów. To, czy korzystają czy nie
korzystają ze wszystkich funkcji API nie ma znaczenia - istotne jest, że
reprezentują wyższy poziom abstrakcji.