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.

Mowa o funkcjach systemowych, a nie zakładaniu ile bitów ma int. Trudno mi
sobie wyobrazić, aby ktoś korzystał z tego założenia, mając do dyspozycji
alternatywę w postaci int32_t.

>> 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.

Bardzo jest dla mnie zagadkowe, że tak wiele osób uważa, iż interfejs
opracowywany i testowany przez kilka dziesięcioleci koniecznie wymaga
opakowania w jakąś abstrakcję, bo inaczej korzystać z niego nie należy...
Nie wiem jak jest z interfejsami windowsowymi, bo z nimi doświadczenie
miałem znikome, ale interfejsy POSIX-owe są bardzo dobre. Abstrakcja w
postaci deskryptora pliku - coś wspaniałego.
Również dla krytykowanych przez niektórych uniksowych sygnałów daje się
czasem znaleźć fajne zastosowanie, gdzie bez sygnałów program byłby dużo
bardziej zawiły.

Oczywiście w każdym API dałoby się wskazać jakieś wady, ale na jakiej
podstawie miałbym przypuszczać, że zrobiona w dużo krótszym czasie
abstrakcja będzie istotnie lepsza?

Dla ścisłości: nie mam nic przeciwko takim abstrakcjom, jak np. baza danych
- tam rzeczywiście nie używa się systemowego API do komunikacji
międzyprocesowej, tylko API udostępnionego przez twórcę bazy danych. Ale ja
tego nie nazwałbym "opakowywaniem systemowego API", tylko zrobieniem modułu
wykorzystującego systemowe API.
Dla mnie "opakowywanie systemowego API" to takie wynalazki jak np. QSocket z
Qt. Dla programów międzyplatformowych - może ma sens. Dla programów na jedną
platformę - żadnego. Interfejs udostępniany przez system (POSIX) jest
lepszy. Testowałem też kiedyś Boost::Asio - nieczytelny w porównaniu z tym,
co można zrobić korzystająć bezpośrednio z POSIX. I ciężki do integracji,
jeśli program ma reagować jednocześnie na zdarzenia innego typu.

>> 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.

Czy wyższy poziom abstrakcji w sensie np. baza danych zamiast bezpośredniego
czytania z plików i synchronizowania przy pomocy fcntl/flock? czy tylko
pozbierane kilka funkcji systemowych do kupy i pozamykane w obiekty?