Wiosenne porządki #2 – Ujednolicanie interfejsu

2008-03-26 21:45

Jedną z bardziej denerwujących cech bibliotek, z jakimi można się zetknąć, jest ich wewnętrzna niespójność pod względem interfejsu. Dotyczy to na przykład drobnych kruczków związanych z postacią wywołań funkcji i metod. Znanym przedstawicielem tego gatunku “kwiatków” są chociażby standardowe funkcje C(++) od zapisu do plików – fprintf i fputs:

  1. int fprintf (FILE* stream, const char* format, ...);
  2. int fputs (const char* str, FILE* stream);

Obie działają podobnie (z dokładnością do formatowania w fprintf), lecz różnią się irytującym szczegółem: miejscem parametru określającego plik (typ FILE*), do którego zapisujemy. Nietrudno się tu pomylić i to niekoniecznie wtedy, gdy korzystamy z obu funkcji w tym samym kodzie.

Podobna niejednolitość jest na szczęście w miarę łatwa do wykrycia i usunięcia – oczywiście pod warunkiem, że mówimy tutaj o bibliotece, której nie wykorzystuje jeszcze nikt postronny. Oprócz niespójnych prototypów funkcji powinniśmy jeszcze zwrócić uwagę na:

  • Nazwy metod wykonujących podobne czynności. Dotyczy to na przykład metod dostępowych, służących symulowaniu właściwości. Powinny one być zgodne z jednym szablonem nazewnictwa, np. Get/SetSomething, IsEnabled, itd. Podobnie metody z nazwami zawierającymi czasowniki “znaczące”, takie jak load, create, read, write powinny przede wszystkim robić to, co owe czasowniki wyrażają.
  • Sensownie dobrane przeciążenia funkcji i parametry domyślne. Wypadałoby bowiem, aby w typowych sytuacjach możliwe było użycie krótszych wywołań z mniejszą ilością parametrów niż wtedy, gdy musimy zrobić coś specjalnego i bardziej skomplikowanego. Zazwyczaj osiągnięcie tego nie jest trudne i sprowadza się do nadania jakimś parametrom rozsądnych wartości domyślnych (przy ich ewentualnym przestawieniu) lub dopisaniu prostych wersji przeciążonych dla danej funkcji.
  • Nazwy parametrów w deklaracjach i definicjach funkcji. W C(++) nie musimy ich pisać w deklaracjach, ale jest to bardzo wskazane, gdyż ułatwia korzystanie z plików nagłówkowych jako swego rodzaju “spisu treści”. Jednak z drugiej strony musimy wtedy dbać, żeby w obu miejscach były one ze sobą zgodne. W przeciwnym razie możemy bowiem napotkać bardzo przykre błędy, jeśli zmienimy kolejność argumentów funkcji tego samego typu.

Nanoszenie podobnych poprawek jest oczywiście dość skomplikowaną operacją, ale wciąż nie ingeruje ona ani w projekt biblioteki, ani – z grubsza – w sposób, w jaki końcowy programista ma jej używać. Mimo to podejrzewam, że w przypadku mojego siln… tj. kodu będzie to dosyć czasochłonne. Całkiem często zmieniałem bowiem swoje upodobania odnośnie kwestii, które wymieniłem powyżej (i których lista nie jest też pewnie kompletna).
Ale cóż, wiosna dopiero się zaczyna, więc czasu – przynajmniej teoretycznie – jest dużo ;-)


Author: Xion, posted under Programming »


2 comments for post “Wiosenne porządki #2 – Ujednolicanie interfejsu”.
  1. moriturius:
    March 27th, 2008 o 6:35

    Podczas pisania AGE miewalem checi zmiany sposobu zapisu niektorych rzeczy, ale staralem sie pisac tak jak bylo, czyli ciagnac tak jak zaczalem ^^

    Wszystko po to aby nie musiec robic wiosennych porzadkow :D

  2. Netrix:
    March 28th, 2008 o 8:19

    Mój kod też zawiera historię, w miarę zdobywania doświadczenia, zmienia się sposób pisania na “lepszy”. Dlatego np. to co wcześniej jest pisane funkcjami, a później już wykorzystywałem polimorfizm. :)

Comments are disabled.
 


© 2019 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.