O wzorcu MVC, wzorcach projektowych i S jak SOLID


Praca zgodnie z wzorcem Model View Controller zakłada oddzielenie widoku od danych, które są do niego przekazywane oraz z niego pobierane. Zadaniem natomiast kontrolera jest poprawne sparowanie obu. Przepływ danych ma miejsce w obu kierunkach, tj. z widoku do modelu i z powrotem.

  • View – miejsce prezentacji danych oraz ich pobierania – interfejs użytkownika. Może to być konsola, oraz to co się w niej wyświetla, np. jakieś menu tekstowe. Może to być okno aplikacji desktopowej lub formularz na stronie internetowej, w przypadku aplikacji webowej.
  • Model – klasy i metody odpowiedzialne za pracę z danymi, tj. wprowadzanie, utrwalanie, usuwanie oraz ich pobieranie. Ja myślę o tym w ten sposób, że jest to przestrzeń w której utrwalany jest jakiś model danych. No i utrwalony jest w jakiejś strukturze danych, czyli w tablicy, kolekcji, mapie lub bazie danych.
  • Controller – miejsce koordynujące przepływ danych z widoku do modelu oraz z powrotem. Dajmy na to w prostej aplikacji konsolowej mogą to być klasy zawierające metody dokonujące jakichś kalkulacji, bądź manipulacji na danych – tzw. logika biznesowa. Przykładowo pobierasz z widoku od użytkownika liczbę 4, następnie mnożysz razy 2 metodą w kontrolerze, po czym wołasz metodę z modelu i zapisujesz liczbę 8 w tablicy. No i w drugą stronę wołasz z kontrolera do modelu aby pobrać tę ósemkę z tablicy i wyświetlasz ją na ekran. 🙂

Mvc to nie tylko programowanie webowe

Chciałbym się podzielić z innymi początkującymi swoim błędem w jakim tkwiłem w odniesieniu do MVC. Gdy jakiś czas temu zacząłem uczyć się Javy, a może nawet wcześniej gdy się dopiero z nią wąchałem, to poprzez czytanie różnych blogów, artykułów, pewnie o Spring MVC 😉 , wzorzec MVC zblatował mi się na długo z programowaniem tylko webowym. Ukuło mi się w głowie, że to jest coś na przyszłość, jak się będę programowania webowego uczył – nie na teraz. No i to był taki spory błąd, w którym tkwiłem.

Programowanie webowe, to nie jedyne zastosowanie dla MVC, a równie dobrze jest go stosować już od samego początku, gdy piszesz pierwsze rzeczy w konsoli. Twoimi widokami mogą być wtedy komunikaty generowane przez System.out.println(). Kontrolerem jakaś logika dokonująca kalkulacji, lub modyfikująca pobrane obiektem Scanner dane. No i w końcu modelem, choćby tablica i metody pobierające i wrzucające do niej dane. Takie podejście pomoże już na początku na początku nauki, w jakimś stopniu redukować uciążliwy bałagan, który jako początkujący zwykle generujemy.

MVC wzorcem architektonicznym

Każdy kto się interesuje programowaniem musi się wcześniej, czy później spotkać z terminem wzorce projektowe (design pattern). MVC nie jest stricte takim wzorcem ze względu na stopień ogólności jego zastosowania. Jest bardziej wzorcem architektonicznym, określającym ogólną strukturę danej aplikacji oraz sposób przepływu danych. Natomiast wzorce projektowe, to są określone rozwiązania problemów na poziomie klas czy interfejsów, ale istniejące w ramach wzorca architektonicznego.

Cytat:
“Model-View-Controller – wzorzec architektoniczny służący do organizowania struktury aplikacji (…). Może być rozumiany jako złożony wzorzec wykorzystujący idee wzorców prostych:

– Obserwator (w modelu i widoku),
– Strategia (w widoku i kontrolerze),
– Kompozyt (w widoku).”
“Internetowe Bazy Danych” dr inż. Roman Ptak

MVC jest dobry żeby próbować go stosować w pierwszej kolejności, na początku nauki. Później zaś, wraz ze wzrostem stopnia złożoności tworzonych programów, będą to bardziej specyficzne wzorce, oferujące już konkretne rozwiązania projektowe dla danej sytuacji.

Wzorce projektowe systemów obiektowych

Wzorce mają zastosowanie tylko do programowania obiektowego. Wpierw należy więc dobrze rozumieć czym jest klasa, obiekty, zmienne referencyjne. Spójrz, tutaj jest ściąga z rozrysowanymi diagramami klasycznych GoF Design Patterns. Zauważ, że prawie wszędzie używany jest interfejs. Trzeba więc zrozumieć czym on jest, na czym polega jego zastosowanie w Java. To z kolei wiąże się ze zrozumieniem abstrakcji oraz polimorfizmu, gdyż interfejs jest właśnie pewną abstrakcją, która korzysta z wielopostaciowości. Polimorfizm w Java opierający się na mechanizmie późnego wiązania, umożliwia definiowanie typu danego interfejsu, na obiekty klas implementujących tenże interfejs. Możesz przykładowo poprzez zdefiniowanie typu interfejsu wyświetlać zawartość różnych menu, napisanych w różnych klasach, w zależności od tego jakiej klasy obiekt zostanie przypisany do jego typu.

Interfejsy mogą po sobie dziedziczyć, jednak inaczej niż w przypadku klas, gdyż interfejsy mogą wielodziedziczyć. Klasy implementujące dany interfejs mają do dyspozycji również interfejsy, które on rozszerza. Jeden skromny interfejs, z jedną abstrakcyjną metodą, to może być taki “entry point”, prowadzący do bardzo złożonej struktury, tj. wielu interfejsów, i wielu klas implementujących te interfejsy. Utrzymanie takich skomplikowanych struktur, odpowiedzialnych za działanie całych modułów aplikacji, wiąże się ze stosowaniem utartych ścieżek, tj. wypracowywanych przez lata kodowania, wzorców projektowych. Porządkują one całość w taki sposób, że inni doświadczeni programiści potrafią ten porządek dostrzec.

Wiem, jak na dev-wannabe, trochę się może zapędziłem, a bardzo złożone struktury, to na razie nie jest coś, na czym dobrze się znam. Chciałem się tylko podzielić moim obrazkiem, jaki mam w głowie na ten temat. Myślę, że każdy potrzebuje taki większy obrazek całości, aby stopniowo zgłębiać i uszczegóławiać. W ten sposób, w mojej opinii, ludzie po prostu rozumują.

Jeżeli więc masz już jako taki obiektowy background, to bez obaw możesz podejrzeć diagram UML jakiegoś wzorca, wymyślić jakiś prosty przykład zastosowania, czy looknąć za tutorialem, i napisać sobie w ramach ćwiczenia.

Tak sobie też myślę, że w pracy ktoś może powiedzieć zaimplementuj to, i rozważ wykorzystanie wzorca takiego. No i nie chodzi chyba o to żeby wszystkie wzorce pamiętać, ale po prostu umieć skorzystać z takiej wskazówki.

MVC + SRP na dobry początek!

Single responsibility principle, to zasada skrywająca się za literką mnemonika SOLID. Nie chciałbym tu sugerować, że już zgłębiłem znaczenie wszystkich reguł stojących za SOLID a teraz zacząłem ewangelizację. Przeciwnie, jestem dev-wannabe i nic jeszcze nie zgłębiłem, chociaż może mam do tego ciągotki 😉 .

W każdym razie to wiem, że jeżeli już na samym początku, pisząc pierwsze klasy, swoich pierwszych projektów, dołożysz do wzorca MVC praktykę stosowania zasady stojącej tylko za tą pierwszą literką stojącą za SOLID, podziała to bardzo in plus. Oszczędzi frustracji, pomoże, a być może nawet umożliwi, realizację twoich założeń związanych z pisanym programem.

Zasada jednej odpowiedzialności, to sposób na przerośnięte klasy, w których się gubisz, ale ciągle dopisujesz kolejne metody, aby tylko zadziałała następna rzecz, jaką sobie zaplanowałeś. Skupiony na swoich funkcjonalnościach, tworzysz mniej lub bardziej świadomie różne zależności pomiędzy klasami. Stopniowo coraz ciężej iść dalej, a w końcu utykasz, jak buty żołnierzy napoleońskich pod Moskwą 😉 . Doświadczeni programiści zwykle powtarzają, że lepiej jest mieć wiele małych klas, niż mało dużych.

Z takiego, swojego niezbyt bogatego doświadczenia wiem, że na pewnym poziomie ogólności, ta pojedyncza odpowiedzialność może się zgadzać, przykładowo gdy dopiero tworzysz klasę. W trakcie jednak pisania może się okazać, że tak nie jest i trzeba wtedy na bieżąco minimalizować tę odpowiedzialność do meritum.

Nie jestem pewien jednoznacznie dlaczego, ale programowanie w Java od początku kojarzyło mi się z tą rosyjska lalką – matrioszką, tj. że tam w środku coś zawsze jeszcze jest. Na początku wszystko pasuje, jest jedna odpowiedzialność “jak ta lala”. Potem jednak wychodzi, że w środku jest jeszcze inna, a w niej kolejna itd.

Ja tak mam, ale pewnie i inni początkujący mają podobnie, że zawsze chcę aby w pierwszej kolejności działało i jeżeli będzie, to jest radość. W miarę jednak, gdy stopień skomplikowania tego co piszesz nieco wzrośnie, ciężej jest osiągnąć to co się założyło, a tym samym doznać kolejnej radości z programowania. Stosowanie więc uznanych zasad, wzorców porządkujących pisanie kodu, jest od samego początku bardzo wskazane. No a na początek może to być właśnie Model-View-Controler, wraz z S jak SOLID.

Warning! Tego nie pisał programista, ale dev-wannabe, który się uczy tego co pisze. Jak coś poknociłem, chętnie się o tym dowiem.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *