Java design pattern

table of contents

1. Description of design pattern
2. Facade pattern
3. Strategy pattern
4. Summary of design patterns
5. References

Design pattern (overview)

--All 23 patterns that a smart person named GoF thought --Target is an object-oriented language --There are several other types ――We are trying to improve extensibility (mainly) by utilizing Java functions. --Inheritance --Polymorphism --Encapsulation, etc. --The excellent veteran thinks like this! A collection of ideas --Not a concrete implementation method --Understand the idea and apply it to your own program

Design pattern (effective usage)

--Apply the idea and reflect it in your source -≠ Implement according to the pattern --Use only when the effect can be expected -≠ Apply as much as possible -≠ Delusion of the effectiveness of the design pattern --If you use it forcibly, it will have the opposite effect. ――Flexibly decide the application according to the situation -≠ Since the application decision was made at the time of design, it will definitely be reflected in the program.

Design pattern (merits and demerits)

merit

1. Improved extensibility: Utilization of object orientation
2. Improved reusability: Utilization of object orientation
3. Improved readability: Utilization of object orientation and common recognition
4. Improved transmission speed Common recognition

Disadvantages (problems / risks)

1. Deviation from current thought / mechanism (part)
2. Reduced productivity
3. Stick to the pattern
4. Code complexity
5. Misunderstandings and unnecessary discussions due to differences in interpretation (because it is abstract)

Design pattern (utilization timing)

--At the time of class design --At the time of refactoring --At the time of review --Reduced explanation time to reviewers --Only if both sides know the pattern --At the time of programming investigation --Reduced reading time --Improved prediction accuracy --Only if you know the pattern --When modifying programming

Two patterns to be covered this time

--Pickup from the following viewpoints --Easy to understand --Easy to use --A certain effect can be expected --There is an example around you

1. Facade pattern
2. Strategy pattern

Facade pattern (overview)

--Create a class that handles the complicated processing flow on behalf of the client --The client side can perform complicated processing just by calling the Facade class. --Simplified client-side processing --The most commonly used pattern, unknowingly specified to some extent --Very useful for refactoring

Facade pattern (utilization conditions)

--It is necessary to call various classes in a series of processes --It is a general process called by many clients.

Facade pattern (characters)

• Client --Classes that want to perform complicated processing --Call the Facade class
• Facade --Class that accepts complex processing calls --Call the real classes --Real class group --A group of classes that take on a part of complicated processing --Called at the required timing for the Facade class

Facade pattern (image)

Facade pattern (merits and demerits)

merit

1. Improved readability by simplifying the client
2. Simplification of addition / correction / deletion of processing
3. Simplified addition / deletion of clients

Demerit

1. Unnecessary Facade class mass production

Facade pattern (summary)

--Collect complicated processing in one class --Easy to add processing on the client side ――It is relatively easy to apply --If you do not narrow down the usage, useless classes will increase and it will have the opposite effect.

Strategy pattern (overview)

--Subclass the part where processing is switched by conditional branching --Minimum addition to existing source when conditions increase --Very similar to the State pattern

Strategy pattern (characters)

• Strategy --Interface for using strategy --Responsible for process type definition and type reuse
• ConcreteStrategy --Implementation of Strategy ――Responsible for the actual processing
• Context --Class that uses Strategy --Has a Strategy type variable --Call Strategy type processing, but do not understand the actual situation
• Client --Pass the Strategy type to Context --Call the Context process

Strategy pattern (utilization conditions)

--Similar processing is called by conditional branching --Conditions are expected to increase or decrease in the future

Strategy pattern (image / not used)

Strategy pattern (when using image)

Strategy pattern (merits and demerits)

merit

1. Clarified range of influence when adding processing class
2. To not modify existing processing
3. Easy to understand the processing of the entire program

Disadvantages (risks)

1. Code complexity due to unreasonable application

Strategy pattern (summary)

--Used when similar processing runs in conditional branching --The range of influence of existing sources can be narrowed down --Slightly more cumbersome and complicated than Facade --If no additional processing is expected, the effort is greater

Design pattern (summary)

--Leverage object orientation for extensibility and reusability --Improves readability (sometimes) ――Apply the idea instead of using it as it is --Combination is also possible ――With 〇〇 pattern! Communication is quick and easy if you can communicate with just ――Since the original is rough, there is a difference in interpretation ――Some of the books I read this time had different interpretations. --If you overdo it, it is a waste of labor and man-hours.

References (honorific titles omitted)

--Design patterns learned in Java language --Author: Hiroshi Yuki --Thorough capture of Java design patterns --Author: Japan Software Engineering Co., Ltd. --Refactoring Safely improve existing code --Author: Martin Fowler --Translation: Kiminobu Kodama, Masao Tomono, Akira Hirasawa, Takashi Umezawa --Design patterns learned from case studies --Author: Naoki Fukuda

• URL：https://www.ogis-ri.co.jp/otc/hiroba/technical/DesignPatternsWithExample/ ――Dramatic before ◯ Design pattern learned by after-sales --Author: karoten512
• URL：http://karoten512.hatenablog.com/entry/2017/10/21/134048