O kompatybilności wstecz
2008-10-20 9:47Użytkownicy zawsze lubią, gdy nowe wersje programów współpracują ze wszystkim, z czym współpracowały stare wersje. Niemal każdy system operacyjny zachowuje na przykład kompatybilność binarną w swoich kolejnych edycjach. Dzięki niej programy napisane dla poprzednich wersji systemu mogą działać i z nowszymi wersjami.
W programowaniu pewnym odpowiednikiem takiego zachowania jest kompatybilność źródeł. Objawia się ona tym, że nowa wersja biblioteka daje się używać bez modyfikacji źródeł programu, który korzysta ze starej wersji. Dla jego autora może być to początkowo wygodne, ale na dłuższą metę powoduje też pewne problemy.
Zachowanie zgodności ogranicza bowiem możliwość zmian w interfejsie biblioteki, pozwalając głównie na dodawanie nowych funkcji, klas, metod, itp. To właśnie tutaj leży przyczyna istnienia paru małych absurdów Windows API, jak choćby funkcje z przyrostkiem Ex czy obecne prawie w każdej strukturze pole cbSize, które należy ustawić na jej wielkość.
Usilnie utrzymywana kompatybilność nie pozwala też naprawić ewentualnych błędnych decyzji projektowych. Dlatego czasami warto się od niej uwolnić; choć jest to najpierw bolesne, korzyści zwykle przewyższają koszty. Wystarczy spojrzeć na przykład na DirectX 10, a już zwłaszcza na całą platformę .NET.
-
moriturius:
October 21st, 2008 o 10:50Jesli chodzi o sama kompatybilnosc kodu (tj. “kompiluje sie”) to problem nie jest wielki. Wystarczy w dokumentacji zaznaczyc ze funkcja jest juz stara i odradza sie uzywanie, a w zamian za to jest funkcja X(). Po kilku(nastu) releasach mozna usunac taka funkcje (“przeciez ostrzegalem!” ;) )
Gorzej jesli chodzi o bledy w decyzjach projektowych. Wtedy sprawa sie komplikuje… Ale zawsze mozna sobie z tym poradzic.
-
Charibo:
October 21st, 2008 o 19:31Szkoda, że ludzie od OpenGL-a 3 sobie nie wzięli tego do serca, mimo szumnych zapowiedzi. :)
Recent posts
