https://training-course-material.com/index.php?action=history&feed=atom&title=WzorceWzorce - Revision history2026-04-24T09:08:40ZRevision history for this page on the wikiMediaWiki 1.45.1https://training-course-material.com/index.php?title=Wzorce&diff=10242&oldid=prevIzabela Szlachta at 22:52, 13 May 20132013-05-13T22:52:31Z<p></p>
<p><b>New page</b></p><div>{{Cat|Refactoring}}<br />
{{Cat|Design Patterns}}<br />
{{Design Patterns Links}}<br />
<br />
<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="true" font="Trebuchet MS" ><br />
;title: Katalog wzorców<br />
;author: Leszek Albrzykowski (NobleProg Ltd)<br />
</slideshow><br />
<br />
<br />
'''Kody źródłowe dla omawianych wzorców: http://svn.nobleprog.com/training/php/Refactoring/'''<br />
<br />
<br />
== Add parameter ⌘==<br />
Parametryzacja metody, pozwala na uniknięcie konieczności jej późniejszych zmian.<br />
== Change Bidirectional Association to Unidirectional ⌘==<br />
Istnieje dwustronna relacja pomiędzy obiektami, ale jeden z nich nie potrzebuje dostępu do funkcjonalności drugiego.<br />
== Change Reference to Value ⌘==<br />
Odwrócenie wzorca "Change Value to Reference".<br />
<br />
== Change Unidirectional Association to Bidirectional ⌘==<br />
Wzorzec odwrotny do "Change Bidirectional Association to Unidirectional"<br />
== Change Value to Reference ⌘==<br />
Istnieje klasa z wieloma, takimi samymi instancjami, które należy zamienić w pojedynczy obiekt. Należy zamienić obiekt (wartość) na referencję.<br />
Dzięki temu rozwiązaniu możemy w klasie korzystać z obiektów zewnętrznych.<br />
<br />
== Collapse Hierarchy ⌘==<br />
Klasa rodzica i dziecka nie różnią się znacząco od siebie. Należy połączyć klasy ze sobą.<br />
TODO: Source<br />
== Consolidate Conditional Expression ⌘==<br />
Kilka warunków sprawdza jeden rezultat. Należy je skonsolidować.<br />
TODO: Source<br />
== Consolidate Duplicate Conditional Fragments ⌘==<br />
Niezależnie od warunku wykonywane są te same czynności. Należy je przenieść poza warunek.<br />
TODO: Source<br />
== Decompose Conditional ⌘==<br />
Instrukcje warunkowe są skomplikowane. Należy zastosować dekompozycje warunków.<br />
TODO: Source<br />
== Encapsulate Collection ⌘==<br />
TODO: Source<br />
== Encapsulate Collection ⌘==<br />
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.<br />
TODO: Source<br />
== Encapsulate Downcast ⌘==<br />
Metoda powinna zwracać wartość obiektu rzutowanego w dół a nie zbytnie uogólnionego. <br />
== Encapsulate Field ⌘==<br />
Istnieją publiczne pola klasy. Należy zastąpić je akcesorami i ustawić jako prywatne.<br />
== Extract Class ⌘==<br />
Rozdzielenie funkcjonalności zdefiniowanej w klasie na dwie niezależne. <br />
== Extract Method ⌘==<br />
Zebranie podobnych funkcjonalności i przeniesienie ich do odpowiedniej metody. <br />
== Hide Delegate ⌘==<br />
Ukrycie przed klientem niektórych szczegółów delegowanego obiektu (zgodnie z paradygmatem enkapsulacji).<br />
== Hide Method ⌘==<br />
Metoda nie jest używana przez klienta bądź inne klasy - należy ją ukryć. <br />
== Inline Class ⌘==<br />
Scalenie funkcjonalności klas, które mają podobną funkcjonalność (np. operują na tym samym obiekcie biznesowym) .<br />
== Inline Method ⌘==<br />
Nazwa metody odzwierciedla jej działanie (jest ponadto czytelna) i nie ma konieczności dekompozycji tej funkcji. Należy scalić metody.<br />
== Inline Temp ⌘==<br />
Wynik działania metody jest przypisywany do tymczasowej zmiennej. W takiej sytuacji należy unikać tworzenia zmiennych tymczasowych. <br />
== Introduce Explaining Variable ⌘==<br />
Należy stworzyć zmienną, której nazwa odzwierciedla jej działanie.<br />
== Introduce Foreign Method ⌘==<br />
Rozszerzenie klasy klienta o metodę, która powinna być dostępna w klasie serwera, ale klasy tej nie możemy modyfikować.<br />
== Introduce Local Extension ⌘==<br />
Konieczne jest rozszerzenie funkcjonalności klasy, której nie możemy modyfikować (dziedziczenie lub wzorzec Dekorator). <br />
== Introduce Null Object ⌘==<br />
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.<br />
== Introduce Parameter Object ⌘==<br />
Metoda przyjmuje parametry, które potrzebne są do wykonania jednej operacji. Zamiast przekazywania dwóch parametrów należy je scalić w jeden. <br />
== Move Field ⌘==<br />
Przeniesienie pola/właściwości do klasy, która częściej będzie je/ją wykorzystywać.<br />
== Move Method ⌘==<br />
Analogicznie do Move Field.<br />
== Parameterize Method ⌘==<br />
Istnieją metody realizujące bardzo podobne zadania. Należy zamienić je na jedną z odpowiednimi parametrami.<br />
<br />
== Pull Up Constructor Body ⌘==<br />
Konstruktory klas dziedziczących mają taką samą funkcjonalność. Należy przenieść konstruktor do klasy rodzica.<br />
<br />
== Pull Up Field ⌘==<br />
Analogicznie do "Pull Up Constructor Body".<br />
<br />
== Pull Up Method ⌘==<br />
Analogicznie do Pull Up Field.<br />
== Push Down Field ⌘==<br />
Odwrócenie wzorca "Pull Up Field".<br />
== Push Down Method ⌘==<br />
Odwrócenie wzorca "Pull Up Method".<br />
== Remove Assignments to Parameters ⌘==<br />
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. <br />
== Remove Control Flag ⌘==<br />
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.<br />
<br />
== Remove Double Negative ⌘==<br />
W warunku występuje podwójna negacja (~~). Należy zastąpić warunek przyrównaniem do prawdy.<br />
<br />
== Remove Middle Man ⌘==<br />
Odwrócenie wzorca "Hide Delegate". <br />
== Remove Parameter ⌘==<br />
Parametr nie jest używane przez metodę. Należy go usunąć.<br />
== Remove Setting Method ⌘==<br />
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ąć.<br />
<br />
== Rename Method ⌘==<br />
Nazwa metody nie oddaje jej działania. Należy zmienić nazwę metody.<br />
<br />
== Replace Array with Object ⌘==<br />
Istnieje tablica przechowująca wiele różnych wartości (również co do typu). Należy zastąpić tablicę obiektem.<br />
<br />
== Replace Conditional with Polymorphism ⌘==<br />
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.<br />
<br />
== Replace Conditional with Visitor ⌘==<br />
TODO<br />
== Replace Constructor with Factory Method ⌘==<br />
Przeznaczenie konstruktora jest niewystarczające. Należy zastąpić tworzenie obiektu metodą fabrykującą zamiast za pomocą konstruktora.<br />
<br />
== Replace Data Value with Object ⌘==<br />
Istnieje zmienna/pole które potrzebuje dodatkowych funkcjonalności bądź właściwości. Należy zamienić tą zmienną/pole obiektem.<br />
<br />
== Replace Delegation with Inheritance ⌘==<br />
Należy, jeśli to możliwe, zastąpić delegację dziedziczeniem.<br />
== Replace Error Code with Exception ⌘==<br />
System korzysta z wewnętrznego mechanizmu zgłaszania błędów (np. oznacza błędy symbolami). Należy zastąpić je wyjątkami.<br />
== Replace Magic Number with Symbolic Constant ⌘==<br />
Należy przenieść stałe wartości do odpowiednich zmiennych.<br />
== Replace Parameter with Explicit Methods ⌘==<br />
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.<br />
== Replace Recursion with Iteration ⌘==<br />
Algorytm korzysta z rekurencji. Należy zastąpić rekurencję pętlą jeśli to możliwe.<br />
== Replace Subclass with Fields ⌘==<br />
Klasy dziedziczące różnią się tylko zmienną. Należy ją przenieść do klasy rodzica.<br />
== Replace Temp with Query ⌘==<br />
Zmienne tymczasowe przechowują rezultat jakiegoś wyliczenia. W takiej sytuacji, wyliczenie to można przenieść do metody, istnieje bowiem możliwość jej wielokrotnego użycia. <br />
== Replace Type Code with State/Strategy ⌘==<br />
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.<br />
== Reverse Conditional ⌘==<br />
Należy zmodyfikować wyrażenie warunkowe jeżeli odwrócenie warunków będzie bardziej zrozumiałe.<br />
== Separate Query from Modifier ⌘==<br />
Metoda jednocześnie pobiera jak i modyfikuje wartości. Należy rozdzielić ją na dwie metody: odpowiednio modyfikującą i pobierającą.<br />
== Split Loop ⌘==<br />
Podczas przebiegu pętli wykonywanych jest zbyt wiele czynności. Należy rozdzielić pętlę na kilka niezależnych.<br />
== Split Temporary Variable ⌘==<br />
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. <br />
== Substitute Algorithm ⌘==<br />
Dany algorytm możliwy jest do zrealizowania w prostszy sposób. Należy zastąpić bardziej skomplikowany prostszym.<br />
== Separate Domain from Presentation ⌘==<br />
Wzorzec mówi o separacji domeny (dziedziny) od prezentacji. Przykładem może być realizacja aplikacji zgodnie ze wzorce MVC/MVP/MVVM.<br />
== Convert Procedural Design to Objects ⌘==<br />
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.</div>Izabela Szlachta