smell of code - solutions

Laten we beginnen. Het is Gratis
of registreren met je e-mailadres
smell of code - solutions Door Mind Map: smell of code - solutions

1. Chain Constructors (302)

1.1. kiedy

1.1.1. jeśli kod powtarza się w konstruktorach

1.2. w jaki sposób

2. Move Accumulation to Visitor (286)

2.1. kiedy

2.1.1. jeśli bardzo robudowany swich obsługuje dane z wielu interfejsów

2.1.2. kiedy swich pobiera dane z wielu obiektów

2.2. w jaki sposóc

2.2.1. visitor usuwa instrukcje warunkowe i zapewnia większą ogólność kodu

3. Move Accumulations to Collecting Parameters (280)

3.1. kiedy

3.1.1. jeżeli kod gromadzi dane do wspólnej zmiennej

3.2. w jaki sposob

4. Introduce to Null Object (271)

4.1. kiedy

4.1.1. jeśli korzystamy z kodu który wiele razy mam nam nic nie robić

4.1.2. jeśli w rozbudowanych if-ach dużo razy chodzi nam o to aby dostać null

4.2. w jaki sposób

4.2.1. tworzymy klasę przeładowaną pustymi metodami

5. Substitution Algorithm

5.1. kiedy

5.1.1. gdy w systemie robimy coś 1 sposobem i nagle zmieniamy go

5.1.1.1. jedno z takich podejść należy uznać za niespójne

6. Extract class/sub-class

6.1. gdy klasa tworzy zbyt wiele zróżnicowanych egzemplarzy

6.2. gdy klasa jest za duża

7. Replace Type Code with Class (258)

7.1. kiedy

7.1.1. jeśli typ proty decyduje w klasie o logice i nie zapewnia odpowiedniego bezpieczeństwa

8. Replace implicit Language with Interpreter (243)

8.1. kiedy

8.1.1. jeśli wiele metod klasy zapewnia obsługę licznych kombinacji wartości prostych

8.1.2. duża klasa, która w istocie emuluje pewien język

8.1.3. generujemy dziwaczne i w dużej ilości metody mające za zadanie obsługiwać bazę danych

8.2. w jaki sposób

8.2.1. przekształcamy klasę do klasy interpreter

9. Unify interface with Adapter (233)

9.1. kiedy

9.1.1. jeśli przetwarzamy obiekty w inny sposób tylko dlatego że mają inne interfejsy

9.1.2. jeśli dwie klasy mają podobne interfejsy, które moża połączyć w jeden

9.1.3. jeśli istnieje znana metoda do wywoływania zbioru klas, których interfejsy nie są jednolite

9.2. w jaki sposób

10. Replace One/Many Distinction with Composite (203)

10.1. kiedy

10.1.1. jeśli jeden kod przetwarza kolekcję, a jeden pojedyńczy obiekt i są bardzo podobne

10.2. w jaki sposób

10.2.1. composite pagttern

11. Extract Composite (195)

11.1. kiedy

11.1.1. jeśli każda podklasa hierarchii implementuje Composite

11.2. w jaki sposób

12. Form Template Method (188)

12.1. kiedy

12.1.1. do powtarzającego się kodu w procedurach, funkcja w podklasach pewnej hierarchii

12.2. w jaki sposób

13. Replace Conditional Dispacher with Command (177)

13.1. kiedy

13.1.1. rozbudowany switch

13.1.1.1. swich jest zły gdy jest sztywny i skomplikowany

13.1.2. jeżeli klasa realizuje zbyt wiele zachowań w odpowiedzi na bardzo zróżnicowane żądania

13.1.2.1. można dzięki temu kilkakrotnie zmniejszyć rozmiar takiej klasy

13.2. w jaki sposób

13.2.1. rozbijanie switcha na kolekcję obiektów command

14. Replece implicit tree with Composite (165)

14.1. kiedy

14.1.1. jeśli mamy niejawną strukturę drzewiastą i ograniczamy się do typów prostych (jak string)

15. Replace State-Altering Conditionals with State (154)

15.1. kiedy

15.1.1. jeśli bardzo złożone if-y decydują o zmianie stanu obiektu

15.1.2. kiedy typ prosty decyduje o zmianie stanu obiektu

15.1.3. kiedy duża klasa

15.2. w jaki sposób

15.2.1. wynikiem będą klasy reprezentujące poszczególne stany

15.2.2. zmienianie jej stanu poprzez wprowadzenie do rodziny klas State

16. Move Embellishment to Decorator (136)

16.1. kiedy

16.1.1. jeśli wyrażenia warunkowe służą jakiego nietypowego zachowania klasy

16.1.2. jeśli wartości proste istnieją tylko po to aby uzupełnić podstawowe funkcje obiektu

16.2. w jaki sposób

17. Replace Conditional Logic With Strategy (123)

17.1. kiedy

17.1.1. jeśli zbyt długa metoda zawiera instrukcje if, które zmieniają algorytm metody

17.1.2. jeśl rozbudowane instrukcje warunkowe służa do wyboru jednego z wariantów obliczeń

17.1.3. jeśli typy proste decydują o użytych algorytmach i na nich opiera się logika

18. Compose Method (118)

18.1. kiedy

18.1.1. zestaw dobrze nazwanych metod o podobnym poziomie szczegółowości

18.1.1.1. zawsze na początek

18.2. w jaki sposób

18.2.1. metody tak produkowane powinny być wydajne w tym co robią i jak to robią

18.2.1.1. max 10 lini

18.2.1.2. małe

18.2.1.3. proste

19. Inline Singleton (111)

19.1. kiedy

19.1.1. gdy nadużywamy singletonu i dane coraz bardziej zależą od globalnych wartości

19.1.1.1. singletony są kosztowne

19.2. w jaki sposób

19.2.1. tworzymy singleton w klasie i działa sobie on lokalnie a nie globalnie

19.2.2. usuwamy singleton po zakończeniu pracy

20. Extract Method

20.1. kiedy

20.1.1. za długa metoda

20.2. w jaki sposób

20.2.1. znajdujemy fragmenty kodu które można pogrupować w metodę

21. Emcapsulate Composite with Builder (95)

21.1. kiedy

21.1.1. jeśli utworzyliśmy klasę i jej konstrukcja jest zbyt prosta aby faktycznie ułatwić budowanie klientów

21.2. w jaki sposób

22. Introduce Polymorphic Creation with Abstact Factory (88)

22.1. kiedy

22.1.1. jeśli metoda podobnie implementowana w podklasach,a wyznacznikiem jest sposób kreowania obiektu

22.2. w jaki sposób

23. Encapsulte Classes with Factory (81)

23.1. kiedy

23.1.1. gdy udostępnia się klientowi metody i klasy, które w rzeczywistości nie powinien on znać.

23.1.1.1. nie musi ich znać, a gdy one są wpływa to na złożoność systemu

23.2. w jaki sposób

23.2.1. tworzymy fabrykę do produkcji obiektów określonego typy i ją udostępniamy

24. More Creation Knowleadge to Factory (71)

24.1. kiedy

24.1.1. gdy zmieniając jedną metodę okazuje się, że musimy robić modyfikację w wielu miejscach