Wzorce
Template:Design Patterns Links
Kody źródłowe dla omawianych wzorców: http://svn.nobleprog.com/training/php/Refactoring/
Add parameter ⌘
Parametryzacja metody, pozwala na uniknięcie konieczności jej późniejszych zmian.
Change Bidirectional Association to Unidirectional ⌘
Istnieje dwustronna relacja pomiędzy obiektami, ale jeden z nich nie potrzebuje dostępu do funkcjonalności drugiego.
Change Reference to Value ⌘
Odwrócenie wzorca "Change Value to Reference".
Change Unidirectional Association to Bidirectional ⌘
Wzorzec odwrotny do "Change Bidirectional Association to Unidirectional"
Change Value to Reference ⌘
Istnieje klasa z wieloma, takimi samymi instancjami, które należy zamienić w pojedynczy obiekt. Należy zamienić obiekt (wartość) na referencję. Dzięki temu rozwiązaniu możemy w klasie korzystać z obiektów zewnętrznych.
Collapse Hierarchy ⌘
Klasa rodzica i dziecka nie różnią się znacząco od siebie. Należy połączyć klasy ze sobą. TODO: Source
Consolidate Conditional Expression ⌘
Kilka warunków sprawdza jeden rezultat. Należy je skonsolidować. TODO: Source
Consolidate Duplicate Conditional Fragments ⌘
Niezależnie od warunku wykonywane są te same czynności. Należy je przenieść poza warunek. TODO: Source
Decompose Conditional ⌘
Instrukcje warunkowe są skomplikowane. Należy zastosować dekompozycje warunków. TODO: Source
Encapsulate Collection ⌘
TODO: Source
Encapsulate Collection ⌘
Metoda zwraca kolekcję. Należy zwracać kolekcję bez możliwości jej modyfikacji (w trybie do odczytu) oraz udostępnić metody pozwalające na dodawanie i usuwanie elementów z kolekcji. TODO: Source
Encapsulate Downcast ⌘
Metoda powinna zwracać wartość obiektu rzutowanego w dół a nie zbytnie uogólnionego.
Encapsulate Field ⌘
Istnieją publiczne pola klasy. Należy zastąpić je akcesorami i ustawić jako prywatne.
Extract Class ⌘
Rozdzielenie funkcjonalności zdefiniowanej w klasie na dwie niezależne.
Extract Method ⌘
Zebranie podobnych funkcjonalności i przeniesienie ich do odpowiedniej metody.
Hide Delegate ⌘
Ukrycie przed klientem niektórych szczegółów delegowanego obiektu (zgodnie z paradygmatem enkapsulacji).
Hide Method ⌘
Metoda nie jest używana przez klienta bądź inne klasy - należy ją ukryć.
Inline Class ⌘
Scalenie funkcjonalności klas, które mają podobną funkcjonalność (np. operują na tym samym obiekcie biznesowym) .
Inline Method ⌘
Nazwa metody odzwierciedla jej działanie (jest ponadto czytelna) i nie ma konieczności dekompozycji tej funkcji. Należy scalić metody.
Inline Temp ⌘
Wynik działania metody jest przypisywany do tymczasowej zmiennej. W takiej sytuacji należy unikać tworzenia zmiennych tymczasowych.
Introduce Explaining Variable ⌘
Należy stworzyć zmienną, której nazwa odzwierciedla jej działanie.
Introduce Foreign Method ⌘
Rozszerzenie klasy klienta o metodę, która powinna być dostępna w klasie serwera, ale klasy tej nie możemy modyfikować.
Introduce Local Extension ⌘
Konieczne jest rozszerzenie funkcjonalności klasy, której nie możemy modyfikować (dziedziczenie lub wzorzec Dekorator).
Introduce Null Object ⌘
Istnieje konieczność sprawdzania czy dany obiekt (lub jego metoda) nie jest pusty (NULL). W przypadku wielokrotnej konieczności sprawdzenia tego warunku, należy wprowadzić pusty obiekt dzięki czemu można uniknąć wielokrotnego porównywania do wartości NULL oraz podejmowania różnych działań jeśli warunek okaże się prawdziwy.
Introduce Parameter Object ⌘
Metoda przyjmuje parametry, które potrzebne są do wykonania jednej operacji. Zamiast przekazywania dwóch parametrów należy je scalić w jeden.
Move Field ⌘
Przeniesienie pola/właściwości do klasy, która częściej będzie je/ją wykorzystywać.
Move Method ⌘
Analogicznie do Move Field.
Parameterize Method ⌘
Istnieją metody realizujące bardzo podobne zadania. Należy zamienić je na jedną z odpowiednimi parametrami.
Pull Up Constructor Body ⌘
Konstruktory klas dziedziczących mają taką samą funkcjonalność. Należy przenieść konstruktor do klasy rodzica.
Pull Up Field ⌘
Analogicznie do "Pull Up Constructor Body".
Pull Up Method ⌘
Analogicznie do Pull Up Field.
Push Down Field ⌘
Odwrócenie wzorca "Pull Up Field".
Push Down Method ⌘
Odwrócenie wzorca "Pull Up Method".
Remove Assignments to Parameters ⌘
W ramach działania jakiegoś algorytmu nadpisywana jest wartość (również typ) zmiennej. W takiej sytuacji, w celu łatwiejszej analizy kodu należy wprowadzić dodatkowe zmienne.
Remove Control Flag ⌘
Istnieje zmienna pełniąca rolę flagi i zmieniająca się w zależności od różnych warunków. Należy używać konstrukcji breake lub return zamiast tej zmiennej.
Remove Double Negative ⌘
W warunku występuje podwójna negacja (~~). Należy zastąpić warunek przyrównaniem do prawdy.
Remove Middle Man ⌘
Odwrócenie wzorca "Hide Delegate".
Remove Parameter ⌘
Parametr nie jest używane przez metodę. Należy go usunąć.
Remove Setting Method ⌘
Istnieje metoda, która pozwala na modyfikację danych, które nie powinny być modyfikowane. Dane te należy przekazywać za pomocą konstruktora a metodę usunąć.
Rename Method ⌘
Nazwa metody nie oddaje jej działania. Należy zmienić nazwę metody.
Replace Array with Object ⌘
Istnieje tablica przechowująca wiele różnych wartości (również co do typu). Należy zastąpić tablicę obiektem.
Replace Conditional with Polymorphism ⌘
Istnieje warunek który podejmuje różne działania w zależności od typu obiektu. Należy utworzy klasy dziedziczące i skorzystać z polimorfizmu.
Replace Conditional with Visitor ⌘
TODO
Replace Constructor with Factory Method ⌘
Przeznaczenie konstruktora jest niewystarczające. Należy zastąpić tworzenie obiektu metodą fabrykującą zamiast za pomocą konstruktora.
Replace Data Value with Object ⌘
Istnieje zmienna/pole które potrzebuje dodatkowych funkcjonalności bądź właściwości. Należy zamienić tą zmienną/pole obiektem.
Replace Delegation with Inheritance ⌘
Należy, jeśli to możliwe, zastąpić delegację dziedziczeniem.
Replace Error Code with Exception ⌘
System korzysta z wewnętrznego mechanizmu zgłaszania błędów (np. oznacza błędy symbolami). Należy zastąpić je wyjątkami.
Replace Magic Number with Symbolic Constant ⌘
Należy przenieść stałe wartości do odpowiednich zmiennych.
Replace Parameter with Explicit Methods ⌘
Istnieje jeden akcesor (lub metoda wykonująca różne działania w zależności od parametru) dla wielu zmiennych. Należy zastąpić go osobnymi akcesorami dla każdej ze zmiennych.
Replace Recursion with Iteration ⌘
Algorytm korzysta z rekurencji. Należy zastąpić rekurencję pętlą jeśli to możliwe.
Replace Subclass with Fields ⌘
Klasy dziedziczące różnią się tylko zmienną. Należy ją przenieść do klasy rodzica.
Replace Temp with Query ⌘
Zmienne tymczasowe przechowują rezultat jakiegoś wyliczenia. W takiej sytuacji, wyliczenie to można przenieść do metody, istnieje bowiem możliwość jej wielokrotnego użycia.
Replace Type Code with State/Strategy ⌘
W zależności od typu (stałej) zmienia się zachowanie obiektu. Nie jest możliwe zastosowanie dziedziczenia i polimorfizmu. Należy użyć wzorca Strategii lub Stanu.
Reverse Conditional ⌘
Należy zmodyfikować wyrażenie warunkowe jeżeli odwrócenie warunków będzie bardziej zrozumiałe.
Separate Query from Modifier ⌘
Metoda jednocześnie pobiera jak i modyfikuje wartości. Należy rozdzielić ją na dwie metody: odpowiednio modyfikującą i pobierającą.
Split Loop ⌘
Podczas przebiegu pętli wykonywanych jest zbyt wiele czynności. Należy rozdzielić pętlę na kilka niezależnych.
Split Temporary Variable ⌘
Do jednej zmienne tymczasowej przypisywane są wyniki działania różnych wyliczeń. Należy utworzyć osobne zmienne dla każdego z wyliczeń wraz z odpowiednią nazwą. Ten wzorzec nie dotyczy zmiennych tymczasowych nadpisywanych w pętlach.
Substitute Algorithm ⌘
Dany algorytm możliwy jest do zrealizowania w prostszy sposób. Należy zastąpić bardziej skomplikowany prostszym.
Separate Domain from Presentation ⌘
Wzorzec mówi o separacji domeny (dziedziny) od prezentacji. Przykładem może być realizacja aplikacji zgodnie ze wzorce MVC/MVP/MVVM.
Convert Procedural Design to Objects ⌘
W przypadku wielu systemów (pomijamy tak specyficzne rozwiązania jak programy pisane np. w Prologu gdzie obiekt ma inne znaczenie niż w ogólnie przyjętym rozumieniu wywodzącym się z OOP) programowanie obiektowe wydaje się najlepszym rozwiązaniem. Część z języków traktuje wszystko jako obiekt. Ze wzorcem tym wiąże się pojęcie "Primitive Obsession", czyli unikanie typów prostych (w szczególności dla obiektów dziedziny). W językach wspierających programowanie proceduralne, funkcyjne i obiektowe znaczenie "Primitive Obsession" może być szczególnie istotne przez wzgląd na "praktyki" programistów.
