Od jakiegoś czasu na forum.php.pl spotykam się z różnymi zdaniami na temat interfejsów i klas abstrakcyjnych. Argumenty, które czasami się trafiają są chybione.
Zacznijmy od tego, że trzeba potrafić rozróżnić interfejs od klasy abstrakcyjnej, [b]to nie to samo[/b]! Interfejs jest najwyższym poziomem abstrakcji, który definiuje nowy, wolny od implementacji typ. Bez jakiejkolwiek linii kodu, tylko sygnatury metod publicznych. Klasa abstrakcyjna jest już początkiem konkretnej implementacji, zawiera kod ogólny i wymusza w klasach dziedziczących dorzucenie konkretnych metod, które są specyficzne, inne, różne. Mogą trafić się takie przypadki, że klasa abstrakcyjna zawiera 5 metod, a jej pochodne tylko jedną. Czy jest to uzasadnione? Oczywiście. Ta jedna metoda determinuje nowy typ, który jest jawną specjalizacją.
Warto pamiętać, że w chwili gdy mamy klasę abstrakcyjną i kilka jej pochodnych dorzucenie interfejsu jest polisą na życie. Spójrzmy, na praktykę - co się powinno dziać w chwili, gdy pojawiają się kolejne pochodne oraz klasa abstrakcyjna rozrasta się do niebagatelnych rozmiarów? Wyodrębniamy wspólny interfejs (patrz extract interface) i kolejne klasy abstrakcyjne. Bez problemu dorzucamy kolejny typ i lecimy bez przestojów. W chwili gdy uzależnimy się od klasy abstrakcyjnej z jakimkolwiek kodem z biegiem czasu możemy mieć do czynienia z klasami, które zawierają po 10, 20 i więcej metod. Nawigacja po tak rozbudowanym typie jest uciążliwa a zrozumienie kodu wymaga przebrnięcia przez stos metod, które tworzą swoisty labirynt. Rozsądne użycie interfejsów i klas pozwala nam tworzyć złożone ale przejrzyste struktury. Separacja abstrakcji od implementacji określana mianem wzorca projektowego, nazwa mostem (ang. bridge).
Budowa złożonej aplikacji bez użycia interfejsów jest posunięciem wysoce nierozsądnym, ponieważ to właśnie dzięki nim, nawet w językach kompilowanych ze statycznym typowaniem jesteśmy w stanie zyskać nadzwyczajnie elastyczny kod. W aplikacji, która jest rozwijana od dłuższego czasu (powiedzmy, ponad pół roku) to właśnie interfejsy są miejscami zawierającymi definicję poszczególnych warstw. To one powinny być trzonem każdej aplikacji (pomijając warstwę obiektów domenowych, gdzie ich rola nie musi być dominująca). Nawet jeśli koncepcja implementacji obróci się o 180 stopni to nasz interfejs, będący swoistą fasadą, ukryje te zmiany przed osobami, których one nie dotyczą i w niewielkim stopniu interesują.
Dorzucę tutaj przykład pewnego mechanizmu, który jakiś czas temu projektowałem i implementowałem. Jest to uproszczony schemat. Singletonu chciałem uniknąć, ale przesłanki ku jego zastosowaniu były na tyle duże, że pozostał. Duże I na początku nazwy oznacza interfejs, w nawiasach, dużymi literami wzorce.
CODE:
Pod takim hasłem wystartował dziś serwis cPaste.com, alternatywa dla stron oferujących przechowanie kodu źródłowego, bądź zwykłego tekstu. Celem projektu jest stworzenie swoistego notatnika z masą opcji, która umożliwi bezpieczne przechowanie kodu. Aktualnie widnieje testowa wersja cpaste, jednakże w najbliższej przyszłości planowana jest gruntowna modernizacja silnika.
cPaste.com jest aplikacją opartą o Vframe framework napisaną w PHP 5, dane przechowywane są w bazie danych MySQL. Kolorować kod pomaga nam biblioteka GeSHi. Serwis posiada wsparcie AdvAjax, jQuery oraz Interface. Serwis powstał z inicjatywy grupy interaktywnej Vgroup, został zaprogramowany przez Athlan’a. Serwera użyczyła firma Linuxpl.com, którym opiekuje się Spam.
Głównym celem projektu jest umożliwienie szybkiego przesyłania kodów, z możliwością uprzedniego podglądu. Wklejony tekst można pokolorować w dowolnym języku wybierając go z listy. Każdy kod otrzymuje unikalny identyfikator oraz krótki link, dzięki czemu można go łatwo zapamiętać.
Serwis jest jeszcze młody, jednak jego roadmapa jest dość rozbudowana. W planach jest miejsce na dodanie więcej języków, aby strona była dostępna dla wszystkich krajów świata. Przewidujemy dodatkowe opcje takie jak usunięcie kodu po określonej ilości oglądnięć, możliwość ściągnięcia pliku, zabezpieczenie go hasłem oraz personalizację strony wraz z wynikami wyszukiwania wśród naszych kodów.
Projekt tak naprawdę miał sprawdzić wydajność wersji językowych użytych w Vframe framework. Zapraszam do testowania i wyrażania swoich poglądów na temat ewentualnego zmodernizowania projektu. Niedługo wprowadzone zostaną gruntowne zmiany, oczywiście jak znajdę odrobinkę wolnego czasu.
Kanał ATOM
