{"product_id":"110482","title":"The Beauty of Design Patterns ","description":"\u003ccenter\u003e\u003cdiv style=\"text-align:center\"\u003e\u003cimg src=\"https:\/\/tmgdisk01.cafe24.com\/images\/vs\/4172\/sv\/3jYEEJvOPWDW6Z0klqTe6J10JJ1RVv.png?v=1765103779\" style=\"max-width:100%;max-height:10px\"\u003e\u003c\/div\u003e\u003c\/center\u003e\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\u003ccenter\u003e\n\n\u003cdiv style=\"width:95%\"\u003e\n\n\u003cdiv style=\"text-align:center;font-size:30px;font-weight:bolder;line-height:1.6em\"\u003e The Beauty of Design Patterns \u003c\/div\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003cdiv style=\"border-bottom:1px;border-bottom-style:dotted;border-color:;padding-bottom:20px\"\u003e\u003ccenter\u003e\u003ctable align=\"center\" width=\"100%\"\u003e\u003ctbody style=\"border:0px\"\u003e\n\n\u003ctr\u003e\u003ctd align=\"center\" style=\"line-height:1.2em;text-align:center;font-size:18px;color:black;font-weight:bold;padding-bottom:20px;\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\n\n\u003ctr\u003e\u003ctd style=\"text-align:center\"\u003e\u003cimg src=\"https:\/\/image.yes24.com\/goods\/118859035\/XL\" style=\"max-width:100%;height:auto\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\n\n\n\u003c\/tbody\u003e\u003c\/table\u003e\u003c\/center\u003e\u003c\/div\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003cdiv style=\"width:95%;{split_style6}padding-top:20px;padding-bottom:20px\"\u003e\n\n\u003cdiv style=\"text-align:left;font-size:16px;font-weight:bold;padding-bottom:20px\"\u003e Description \u003c\/div\u003e\n\n\u003cdiv style=\"text-align:left;word-break:break-all;font-size:14px;line-height:1.6em;\"\u003e\n\n\u003cdiv\u003e\u003ch5\u003e \u003cb\u003eBook Introduction\u003c\/b\u003e\n\u003c\/h5\u003e\u003c\/div\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\u003cdiv\u003e \u003cb\u003eGoogler's Code Quality Management Secrets Revealed\u003c\/b\u003e\u003cbr\u003e\u003cbr\u003e Googlers, who placed a high value on code quality, went so far as to request corrections to even the smallest period error in the comments attached to the code, and thanks to such strict code quality control, the maintenance cost of the project was greatly reduced. \u003cbr\u003eThis book, a compilation of such experiences, provides detailed instruction on how to write high-quality code across five aspects: object-oriented paradigms, design principles, coding rules, refactoring techniques, and design patterns, based on over 200 real-world project examples.\u003cbr\u003e\n\n\u003c\/div\u003e\u003c\/div\u003e\n\u003cdiv\u003e\u003cul\u003e\u003cli\u003e You can preview some of the book's contents.\u003cbr\u003e \u003cspan\u003ePreview\u003c\/span\u003e\n\n\u003c\/li\u003e\u003c\/ul\u003e\u003c\/div\u003e\n\u003c\/div\u003e\n\u003cbr\u003e\u003cdiv\u003e\u003ch5\u003e \u003cb\u003eindex\u003c\/b\u003e\n\u003c\/h5\u003e\u003c\/div\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e Translator's Preface xiii\u003cbr\u003e Beta Reader Review xiv\u003cbr\u003e Beginning xvi\u003cbr\u003e\u003cbr\u003e \u003cb\u003eCHAPTER 1 Overview 1\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e 1.1 Why Learn Code Design 1\u003cbr\u003e __1.1.1 Writing High-Quality Code 2 \/ 1.1.2 Handling Complex Code Development 2\u003cbr\u003e __1.1.3 Basic Programmer Skills 4 \/ 1.1.4 Skills Required for Career Development 5\u003cbr\u003e __1.1.5 Thinking 5\u003cbr\u003e 1.2 Code Quality Assessment Method 6\u003cbr\u003e __1.2.1 Maintainability 8 \/ 1.2.2 Readability 9 \/ 1.2.3 Extensibility 10 \/ 1.2.4 Flexibility 10\u003cbr\u003e __1.2.5 Conciseness 11 \/ 1.2.6 Reusability 11 \/ 1.2.7 Testability 12 \/ 1.2.8 Thinking 12\u003cbr\u003e 1.3 How to Write High-Quality Code 12 \u003cbr\u003e__1.3.1 Object-oriented 13 \/ 1.3.2 Design principles 13 \/ 1.3.3 Design patterns 14\u003cbr\u003e __1.3.4 Coding Rules 15 \/ 1.3.5 Refactoring Techniques 15 \/ 1.3.6 Thinking 17\u003cbr\u003e 1.4 How to Avoid Overdesign 18\u003cbr\u003e __1.4.1 The original intention of code design is to improve code quality 18\u003cbr\u003e __1.4.2 The principle of code design is that there is a problem in front and a solution behind it 18\u003cbr\u003e __1.4.3 Application scenarios of code design should be applied to complex codes 19\u003cbr\u003e __1.4.4 Continuous refactoring can effectively prevent overdesign 20\u003cbr\u003e __1.4.5 Do not discuss code design outside of specific scenarios 20\u003cbr\u003e __1.4.6 Thinking 21\u003cbr\u003e\u003cbr\u003e \u003cb\u003eCHAPTER 2 Object-Oriented Programming Paradigm 23\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e 2.1 What is object-oriented programming? 23\u003cbr\u003e __2.1.1 Object-Oriented Programming and Object-Oriented Programming Languages ​​23\u003cbr\u003e __2.1.2 Object-oriented programming languages ​​that are not strictly defined 25\u003cbr\u003e __2.1.3 Object-Oriented Analysis and Object-Oriented Design 26 \u003cbr\u003e__2.1.4 Notes on UML 27\u003cbr\u003e __2.1.5 Thinking 28\u003cbr\u003e 2.2 Why Encapsulation, Abstraction, Inheritance, and Polymorphism Emerge 28\u003cbr\u003e __2.2.1 Encapsulation 28 \/ 2.2.2 Abstraction 31 \/ 2.2.3 Inheritance 33 \/\u003cbr\u003e __2.2.4 Polymorphism 35 \/ 2.2.5 Reflections 39\u003cbr\u003e 2.3 How to Perform Object-Oriented Analysis, Object-Oriented Design, and Object-Oriented Programming 40\u003cbr\u003e __2.3.1 Example Introduction and Difficulty Analysis 40\u003cbr\u003e __2.3.2 How to Perform Object-Oriented Analysis 41\u003cbr\u003e __2.3.3 Object-Oriented Design Methods 45\u003cbr\u003e __2.3.4 How to do object-oriented programming 53\u003cbr\u003e __2.3.5 Thinking 55\u003cbr\u003e 2.4 Differences Between Object-Oriented Programming, Procedural Programming, and Functional Programming 55\u003cbr\u003e __2.4.1 Procedural Programming 55\u003cbr\u003e __2.4.2 Comparison of Object-Oriented Programming and Procedural Programming 59\u003cbr\u003e __2.4.3 Functional Programming 62\u003cbr\u003e __2.4.4 Comparison of Object-Oriented Programming and Functional Programming 69\u003cbr\u003e __2.4.5 Thinking 69\u003cbr\u003e 2.5 It looks like object-oriented programming, but it's actually procedural programming 70 \u003cbr\u003e__2.5.1 Abuse of getter and setter methods 70\u003cbr\u003e __2.5.2 Abuse of global variables and global methods 74\u003cbr\u003e __2.5.3 Defining a class by separating data and methods 77\u003cbr\u003e __2.5.4 Thinking 79\u003cbr\u003e 2.6 Does the traditional development approach based on a poor domain model violate OOP? 79\u003cbr\u003e __2.6.1 Traditional Development Methods Based on a Poor Domain Model 80\u003cbr\u003e __2.6.2 DDD Development Method Based on Rich Domain Model 82\u003cbr\u003e __2.6.3 Comparison of Two Development Methods 83\u003cbr\u003e __2.6.4 Why Traditional Development Methods Based on Poor Domain Models Are So Widely Used 90\u003cbr\u003e __2.6.5 Application Scenario 91 of DDD Development Based on Rich Domain Models\u003cbr\u003e __2.6.6 Thinking 92\u003cbr\u003e 2.7 Abstract Classes and Interfaces 93\u003cbr\u003e __2.7.1 Definition and Differences Between Abstract Classes and Interfaces 93\u003cbr\u003e __2.7.2 Meaning of Abstract Classes and Interfaces 97\u003cbr\u003e __2.7.3 Mock Implementations of Abstract Classes and Interfaces 100\u003cbr\u003e __2.7.4 Application Scenarios of Abstract Classes and Interfaces 102 \u003cbr\u003e__2.7.5 Thinking 102\u003cbr\u003e 2.8 Interface-based programming:\u003cbr\u003e Should I define an interface for every class? 102\u003cbr\u003e __2.8.1 Various Ways to Understand Interfaces 103\u003cbr\u003e __2.8.2 Let's put the design philosophy into practice 104\u003cbr\u003e __2.8.3 How can we prevent abuse of interfaces? 108\u003cbr\u003e __2.8.4 Thinking 109\u003cbr\u003e 2.9 Synthesis over Inheritance 109\u003cbr\u003e __2.9.1 Why Inheritance is Deprecated 109\u003cbr\u003e __2.9.2 Advantages of Composition over Inheritance 112\u003cbr\u003e __2.9.3 Deciding Whether to Use Composition or Inheritance 114\u003cbr\u003e __2.9.4 Thinking 115\u003cbr\u003e\u003cbr\u003e \u003cb\u003eCHAPTER 3 DESIGN PRINCIPLES 117\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e 3.1 Single Responsibility Principle 117\u003cbr\u003e __3.1.1 Definition and Interpretation of the Single Responsibility Principle 117\u003cbr\u003e __3.1.2 How to determine if a class has a single responsibility 118\u003cbr\u003e __3.1.3 Whether the class's responsibilities are described in as much detail as possible 121\u003cbr\u003e __3.1.4 Thinking 123\u003cbr\u003e 3.2 Open-Closed Principle 123\u003cbr\u003e __3.2.1 Open when extending, closed when modifying 123 \u003cbr\u003e__3.2.2 Does modifying code violate the Open Closed Principle? 129\u003cbr\u003e __3.2.3 How to achieve openness when extending and closure when modifying 131\u003cbr\u003e __3.2.4 How to flexibly apply the open-closed principle to a project 133\u003cbr\u003e __3.2.5 Thinking 134\u003cbr\u003e 3.3 Liskov Substitution Principle 134\u003cbr\u003e __3.3.1 Definition of the Liskov Substitution Principle 134\u003cbr\u003e __3.3.2 Differences between the Liskov Substitution Principle and Polymorphism 136\u003cbr\u003e __3.3.3 Anti-patterns that Violate the Liskov Substitution Principle 137\u003cbr\u003e __3.3.4 Thinking 139\u003cbr\u003e 3.4 Interface Segregation Principle 139\u003cbr\u003e __3.4.1 Interface as a set of APIs or functions 139\u003cbr\u003e __3.4.2 Interfaces as a Single API or Function 141\u003cbr\u003e __3.4.3 Interfaces in Object-Oriented Programming 142\u003cbr\u003e __3.4.4 Thinking 149\u003cbr\u003e 3.5 Dependency Inversion Principle 149\u003cbr\u003e __3.5.1 Inversion of Control 150 \/ 3.5.2 Dependency Injection 152 \/ 3.5.3 Dependency Injection Framework 153\u003cbr\u003e __3.5.4 Dependency Inversion Principle 154 \/ 3.5.5 Reflection 155\u003cbr\u003e 3.6 The KISS Principle and the YAGNI Principle 155 \u003cbr\u003e__3.6.1 Definition and Interpretation of the KISS Principle 155\u003cbr\u003e __3.6.2 Fewer lines of code are not simpler 156\u003cbr\u003e __3.6.3 Complex code does not necessarily violate the KISS principle 158\u003cbr\u003e __3.6.4 How to write code that satisfies the KISS principle 160\u003cbr\u003e __3.6.5 Differences between the YAGNI and KISS Principles 160\u003cbr\u003e __3.6.6 Thinking 161\u003cbr\u003e 3.7 DRY Principle 161\u003cbr\u003e __3.7.1 Duplication of Code Logic 161 \/ 3.7.2 Functional (Semantic) Duplication 164\u003cbr\u003e __3.7.3 Duplication of Code Execution 165 \/ 3.7.4 Code Reusability 167\u003cbr\u003e __3.7.5 Thinking 169\u003cbr\u003e 3.8 LoD 169\u003cbr\u003e __3.8.1 Thoughts on High Cohesion and Low Coupling 169\u003cbr\u003e __3.8.2 Definition of LoD 171\u003cbr\u003e __3.8.3 Definition Interpretation and First Example Code 171\u003cbr\u003e __3.8.4 Definition Interpretation and Second Example Code 174\u003cbr\u003e __3.8.5 Thinking 177\u003cbr\u003e\u003cbr\u003e \u003cb\u003eCHAPTER 4 Coding Rules 179\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e 4.1 Naming and Annotation 179\u003cbr\u003e __4.1.1 Long and short names 179\u003cbr\u003e __4.1.2 Simplifying Naming Using Contextual Information 180\u003cbr\u003e __4.1.3 Naming Unification Using a Business Glossary 180 \u003cbr\u003e__4.1.4 Naming should be precise but abstract 181\u003cbr\u003e __4.1.5 Things that must be included in comments 181\u003cbr\u003e __4.1.6 More Comments Isn't a Good Thing 183\u003cbr\u003e __4.1.7 Thinking 183\u003cbr\u003e 4.2 Code Style 184\u003cbr\u003e __4.2.1 Appropriate size of classes and functions 184\u003cbr\u003e __4.2.2 Appropriate length of a line 185\u003cbr\u003e __4.2.3 Separating code blocks using blank lines 185\u003cbr\u003e __4.2.4 Indent 4 spaces or Indent 2 spaces 185\u003cbr\u003e __4.2.5 Where should the opening brace be placed? 186\u003cbr\u003e __4.2.6 Class Member Order 186\u003cbr\u003e __4.2.7 Thinking 187\u003cbr\u003e 4.3 Coding Tips 187\u003cbr\u003e __4.3.1 Modularizing Complex Code 187 \/ 4.3.2 Managing Function Parameters 188\u003cbr\u003e __4.3.3 Removing flag parameters from functions 189 \/ 4.3.4 Removing deeply nested code 191\u003cbr\u003e __4.3.5 Explanatory Variables 194 \/ 4.3.6 Reflections 195\u003cbr\u003e\u003cbr\u003e \u003cb\u003eCHAPTER 5 Refactoring Techniques 197\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e 5.1 The Four Elements of Refactoring: Purpose, Target, Timing, and Method 197\u003cbr\u003e __5.1.1 Purpose of Refactoring 197 \/ 5.1.2 Target of Refactoring 199 \u003cbr\u003e__5.1.3 When to Refactor 199 \/ 5.1.4 How to Refactor 200\u003cbr\u003e __5.1.5 Thinking 201\u003cbr\u003e 5.2 Unit Testing 201\u003cbr\u003e __5.2.1 About Unit Tests 201\u003cbr\u003e __5.2.2 Why Write Unit Test Code 204\u003cbr\u003e __5.2.3 How to Design Unit Tests 206\u003cbr\u003e __5.2.4 Why Unit Tests Are Difficult to Write 209\u003cbr\u003e __5.2.5 Thinking 210\u003cbr\u003e 5.3 Code Testability 210\u003cbr\u003e __5.3.1 How to Write Testable Code 210\u003cbr\u003e __5.3.2 Untestable Code 220\u003cbr\u003e __5.3.3 Thinking 222\u003cbr\u003e 5.4 Decoupling 223\u003cbr\u003e __5.4.1 Why Decoupling Is Important 223\u003cbr\u003e __5.4.2 Determining Whether Code Needs Decoupling 223\u003cbr\u003e __5.4.3 Code Decoupling Method 224\u003cbr\u003e __5.4.4 Thinking 227\u003cbr\u003e 5.5 Refactoring Example 227\u003cbr\u003e __5.5.1 Requirements and Development Background of the ID Generator 228\u003cbr\u003e __5.5.2 Usable Level Code Implementation 228\u003cbr\u003e __5.5.3 How to Find Code Quality Issues 230\u003cbr\u003e __5.5.4 Refactoring for Readability 232\u003cbr\u003e __5.5.5 Refactoring to Improve Code Testability 234 \u003cbr\u003e__5.5.6 Refactoring for Writing Unit Test Code 236\u003cbr\u003e __5.5.7 Refactoring for Exception Handling 239\u003cbr\u003e __5.5.8 Thinking 251\u003cbr\u003e\u003cbr\u003e \u003cb\u003eCHAPTER 6: GENERATIONAL DESIGN PATTERNS 253\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e 6.1 Singleton Pattern (1) 253\u003cbr\u003e __6.1.1 Definition of the Singleton Pattern 253 \/ 6.1.2 Implementation of the Singleton Pattern 254\u003cbr\u003e __6.1.3 Application of the Singleton Pattern 259 \/ 6.1.4 Disadvantages of the Singleton Pattern 263\u003cbr\u003e __6.1.5 Alternatives to the Singleton Pattern 266 \/ 6.1.6 Reflections 268\u003cbr\u003e 6.2 Singleton Pattern (2) 268\u003cbr\u003e __6.2.1 Uniqueness of the Singleton Pattern 268\u003cbr\u003e __6.2.2 Thread-Only Singleton Pattern 269\u003cbr\u003e __6.2.3 Singleton Pattern in a Cluster Environment 270\u003cbr\u003e __6.2.4 Multi-Instance Pattern 272\u003cbr\u003e __6.2.5 Thinking 273\u003cbr\u003e 6.3 Factory Pattern (1) 273\u003cbr\u003e __6.3.1 Simple Factory Pattern 274 \/ 6.3.2 Factory Method Pattern 278\u003cbr\u003e __6.3.3 Abstract Factory Pattern 281 \/ 6.3.4 Application of Factory Pattern 283\u003cbr\u003e __6.3.5 Thinking 283\u003cbr\u003e 6.4 Factory Pattern (2) 284\u003cbr\u003e __6.4.1 Differences between DI Container and Factory Pattern 284\u003cbr\u003e __6.4.2 Core Features of the DI Container 284 \u003cbr\u003e__6.4.3 Design and Implementation of the DI Container 287\u003cbr\u003e __6.4.4 Thinking 292\u003cbr\u003e 6.5 Builder Pattern 293\u003cbr\u003e __6.5.1 Creating Objects Using Constructors 293\u003cbr\u003e __6.5.2 Setting member variables using setter methods 295\u003cbr\u003e __6.5.3 Parameter Validation Using the Builder Pattern 296\u003cbr\u003e __6.5.4 Applying the Builder Pattern in Guava 299\u003cbr\u003e __6.5.5 Differences between the Builder Pattern and the Factory Pattern 301\u003cbr\u003e __6.5.6 Thinking 301\u003cbr\u003e 6.6 Prototype Pattern 302\u003cbr\u003e __6.6.1 Definition of the Prototype Pattern 302\u003cbr\u003e __6.6.2 Applying the Prototype Pattern 302\u003cbr\u003e __6.6.3 Implementing the Prototype Pattern 306\u003cbr\u003e __6.6.4 Thinking 310\u003cbr\u003e\u003cbr\u003e \u003cb\u003eCHAPTER 7 Structural Design Patterns 313\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e 7.1 Proxy Pattern 313\u003cbr\u003e __7.1.1 Interface-Based Proxy Pattern 313\u003cbr\u003e __7.1.2 Inheritance-based proxy pattern 316\u003cbr\u003e __7.1.3 Reflection-Based Dynamic Proxy 317\u003cbr\u003e __7.1.4 How to Use the Proxy Pattern 318\u003cbr\u003e __7.1.5 Thinking 320\u003cbr\u003e 7.2 Decorator Pattern: Analyzing the Basic Design Thoughts of the Java IO Library 320\u003cbr\u003e __7.2.1 Unusual Uses of the Java IO Library 320 \u003cbr\u003e__7.2.2 Inheritance-based design 322\u003cbr\u003e __7.2.3 Design Planning Based on the Decorator Pattern 323\u003cbr\u003e __7.2.4 Thinking 328\u003cbr\u003e 7.3 Adapter Pattern 328\u003cbr\u003e __7.3.1 Class Adapters and Object Adapters 328\u003cbr\u003e __7.3.2 Application of the Adapter Pattern 330\u003cbr\u003e __7.3.3 Java Logging and the Adapter Pattern 336\u003cbr\u003e __7.3.4 Wrapper Pattern 338\u003cbr\u003e __7.3.5 Thinking 342\u003cbr\u003e 7.4 Bridge Pattern 343\u003cbr\u003e __7.4.1 Definition of the Bridge Pattern 343\u003cbr\u003e __7.4.2 Solving Explosive Inheritance with the Bridge Pattern 343\u003cbr\u003e __7.4.3 Thinking 344\u003cbr\u003e 7.5 Facade Pattern 344\u003cbr\u003e __7.5.1 Facade Pattern and Interface Design 345\u003cbr\u003e __7.5.2 Applying the Facade Pattern: Improving Interface Usability 346\u003cbr\u003e __7.5.3 Applying the Facade Pattern: Improving Interface Performance 346\u003cbr\u003e __7.5.4 Applying the Facade Pattern: Solving Transaction Problems 346\u003cbr\u003e __7.5.5 Thinking 348\u003cbr\u003e 7.6 Complex Pattern 348\u003cbr\u003e __7.6.1 Directory tree based on composite pattern 348\u003cbr\u003e __7.6.2 Human Tree Based on Complex Patterns 353\u003cbr\u003e __7.6.3 Thinking 356\u003cbr\u003e 7.7 Flyweight Pattern 356 \u003cbr\u003e__7.7.1 Applying Flyweight Patterns in Chess Games 356\u003cbr\u003e __7.7.2 Applying the Flyweight Pattern in a Text Editor 359\u003cbr\u003e __7.7.3 Applying the Flyweight Pattern to Java's Integer 362\u003cbr\u003e __7.7.4 Applying the Flyweight Pattern to Java's String 367\u003cbr\u003e __7.7.5 Differences between the Flyweight Pattern, Singleton Pattern, Cache, and Object Pool 368\u003cbr\u003e __7.7.6 Thinking 369\u003cbr\u003e\u003cbr\u003e \u003cb\u003eCHAPTER 8: BEHAVIORAL DESIGN PATTERNS 371\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e 8.1 Observer Pattern 371\u003cbr\u003e __8.1.1 Definition of the Observer Pattern 371\u003cbr\u003e __8.1.2 Code Implementation of the Observer Pattern 372\u003cbr\u003e __8.1.3 Meaning of the Observer Pattern 373\u003cbr\u003e __8.1.4 Applying the Observer Pattern 376\u003cbr\u003e __8.1.5 Asynchronous Non-Blocking Observer Pattern 377\u003cbr\u003e __8.1.6 EventBus Framework 379\u003cbr\u003e __8.1.7 Implementing the EventBus Framework from Scratch 382\u003cbr\u003e __8.1.8 Thinking 388\u003cbr\u003e 8.2 Template Method Pattern (1) 388\u003cbr\u003e __8.2.1 Definition and Implementation of the Template Method Pattern 388\u003cbr\u003e __8.2.2 The Role of the Template Method Pattern: Reuse 390\u003cbr\u003e __8.2.3 The Role of the Template Method Pattern: Extension 392 \u003cbr\u003e__8.2.4 Thinking 395\u003cbr\u003e 8.3 Template Method Pattern (2) 396\u003cbr\u003e __8.3.1 Callback Principles and Implementation 396\u003cbr\u003e __8.3.2 JdbcTemplate Class 398\u003cbr\u003e __8.3.3 setClickListener() method 401\u003cbr\u003e __8.3.4 addShutdownHook() method 402\u003cbr\u003e __8.3.5 Differences between template method patterns and callbacks 404\u003cbr\u003e __8.3.6 Thinking 405\u003cbr\u003e 8.4 Strategy Patterns 405\u003cbr\u003e __8.4.1 Defining and Implementing the Strategy Pattern 405\u003cbr\u003e __8.4.2 Replacing Branching Decisions with Strategy Patterns 408\u003cbr\u003e __8.4.3 Sorting File Contents Using Strategy Patterns 410\u003cbr\u003e __8.4.4 Misuse of the Strategy Pattern 417\u003cbr\u003e __8.4.5 Thinking 417\u003cbr\u003e 8.5 Chain of Responsibility Pattern 417\u003cbr\u003e __8.5.1 Defining and Implementing the Chain of Responsibility Pattern 417\u003cbr\u003e __8.5.2 Sensitive Word Filtering Based on Responsibility Chain Pattern 423\u003cbr\u003e __8.5.3 Servlet Filter Based on Chain of Responsibility Pattern 426\u003cbr\u003e __8.5.4 Chain of Responsibility Pattern and Spring's Interceptors 430\u003cbr\u003e __8.5.5 Chain of Responsibility Pattern and MyBatis Plugins 432\u003cbr\u003e __8.5.6 Thinking 439\u003cbr\u003e 8.6 State Pattern 439\u003cbr\u003e __8.6.1 What is a Finite State Machine? 439\u003cbr\u003e __8.6.2 Implementing a State Machine Using Branching Decision Methods 442 \u003cbr\u003e__8.6.3 Implementing a State Machine Using Table Lookup Method 443\u003cbr\u003e __8.6.4 Implementing a State Machine with the State Pattern 446\u003cbr\u003e __8.6.5 Thinking 451\u003cbr\u003e 8.7 Iterator Pattern (1) 451\u003cbr\u003e __8.7.1 Definition and Implementation of the Iterator Pattern 451\u003cbr\u003e __8.7.2 Collection Iteration Method 454\u003cbr\u003e __8.7.3 Iterator Problem 456\u003cbr\u003e __8.7.4 Solving the Iterator Problem 458\u003cbr\u003e __8.7.5 Thinking 463\u003cbr\u003e 8.8 Iterator Pattern (2) 464\u003cbr\u003e __8.8.1 Iterator supporting snapshot functionality 464\u003cbr\u003e __8.8.2 Design Thoughts Based on Multiple Copies 466\u003cbr\u003e __8.8.3 Time-Based Design Thoughts 466\u003cbr\u003e __8.8.4 Thinking 470\u003cbr\u003e 8.9 Visitor Pattern 470\u003cbr\u003e __8.9.1 Derivation Process of the Visitor Pattern 470\u003cbr\u003e __8.9.2 Double Dispatch 481\u003cbr\u003e __8.9.3 Thinking 484\u003cbr\u003e 8.10 Memento Pattern 485\u003cbr\u003e __8.10.1 Definition and Implementation of the Memento Pattern 485\u003cbr\u003e __8.10.2 Time and Space Optimization 489\u003cbr\u003e __8.10.3 Thinking 490\u003cbr\u003e 8.11 Command Pattern 490\u003cbr\u003e __8.11.1 Definition of the Command Pattern 490\u003cbr\u003e __8.11.2 Applying Command Patterns to Mobile Game Servers 491\u003cbr\u003e __8.11.3 Differences between Command and Strategy Patterns 494 \u003cbr\u003e__8.11.4 Thinking 494\u003cbr\u003e 8.12 Interpreter Pattern 494\u003cbr\u003e __8.12.1 Definition of the Interpreter Pattern 494\u003cbr\u003e __8.12.2 Evaluating Expressions with the Interpreter Pattern 495\u003cbr\u003e __8.12.3 Developing a Rules Engine with the Interpreter Pattern 499\u003cbr\u003e __8.12.4 Thinking 502\u003cbr\u003e 8.13 Arbitrator Pattern 502\u003cbr\u003e __8.13.1 Definition and Implementation of the Mediator Pattern 503\u003cbr\u003e __8.13.2 Differences between the Mediator Pattern and the Observer Pattern 504\u003cbr\u003e __8.13.3 Thinking 505\u003cbr\u003e\u003cbr\u003e Search 506\u003c\/div\u003e\n\u003cdiv\u003e\u003c\/div\u003e\n\u003c\/div\u003e\n\u003cbr\u003e\u003cdiv\u003e\u003ch5\u003e \u003cb\u003eDetailed image\u003c\/b\u003e \u003c\/h5\u003e\u003c\/div\u003e\n\u003cdiv\u003e\u003cdiv\u003e\u003cimg src=\"https:\/\/image.yes24.com\/momo\/TopCate4176\/MidCate010\/417590834.jpg\" border=\"0\" alt=\"Detailed Image 1\"\u003e\u003c\/div\u003e\u003c\/div\u003e\n\u003cbr\u003e\u003cdiv\u003e\u003ch5\u003e \u003cb\u003eInto the book\u003c\/b\u003e\n\u003c\/h5\u003e\u003c\/div\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e We often say that we should pay attention to code quality and not neglect the code design phase before writing the code.\u003cbr\u003e Underdesigning your code is not good, but overdesigning it is not good either.\u003cbr\u003e In my past work experience, I've had many colleagues, especially engineers with little development experience, who liked to over-engineer their code and abuse design patterns. \u003cbr\u003eThey spend a lot of time designing their code before they even start coding.\u003cbr\u003e For simple requirements or simple code, it is common to apply various design patterns during the development process in the hope that the code will be more flexible and serve as a solid foundation for future expansion.\u003cbr\u003e However, over-designing only increases the complexity of the code, as requirements may not change later.\u003cbr\u003e Therefore, we need to talk about how to avoid overdesign, especially how to avoid overusing design patterns, such as object-oriented programming paradigms, design principles, coding conventions, and refactoring.\u003cbr\u003e\u003cbr\u003e --- p.18\u003cbr\u003e \u003cbr\u003eHowever, most programmers often start writing code right after completing object-oriented analysis and object-oriented design in their head or in simple sketches, and they often optimize and refactor the code while writing it.\u003cbr\u003e Conversely, even if you spend a lot of time on object-oriented analysis and design and draw solid class diagrams and UML diagrams before writing any code, it's impossible to define all the details and interactions at once.\u003cbr\u003e As you write code, you still have to turn it around, refactor it, and repeat.\u003cbr\u003e Ultimately, software development is essentially a process of continuous iteration, patching, problem finding, problem solving, and continuous refactoring.\u003cbr\u003e It is important to understand that it is impossible to strictly complete one step and then move on to the next.\u003cbr\u003e\u003cbr\u003e --- p.55\u003cbr\u003e \u003cbr\u003eThere is a more understandable way to explain the Liskov principle: design by contract.\u003cbr\u003e When designing a subclass, it must follow the behavioral rules of the superclass.\u003cbr\u003e The superclass defines the behavior rules of the function, and the subclass can change the internal implementation logic of the function, but cannot change the original behavior rules of the function.\u003cbr\u003e The behavioral rules discussed here include what the function declares to implement, rules for input, output, exceptions, and any special case descriptions listed in the comments.\u003cbr\u003e In fact, the relationship between superclass and subclass mentioned here could be replaced by the relationship between interface and implementation class.\u003cbr\u003e\u003cbr\u003e --- p.137\u003cbr\u003e \u003cbr\u003eThe factory pattern is used to create objects of different but related types, such as a group of subclasses that inherit the same superclass or interface, where the type of object to be created is determined by pre-specified parameters.\u003cbr\u003e On the other hand, the builder pattern creates objects of the same type with high complexity, but sets optional parameters or creates other objects through customization.\u003cbr\u003e \/ The difference between the two patterns can be easily understood through a classic example.\u003cbr\u003e When a customer enters a restaurant and places an order, the factory pattern can be used to create a variety of foods such as pizza, burgers, and salads based on the customer's selection, and the builder pattern can be used to create a pizza with various toppings selected by the customer, such as cheese, tomatoes, and bacon.\u003cbr\u003e\u003cbr\u003e --- p.301\u003cbr\u003e \u003cbr\u003eWhen applying the Memento pattern, if the object to be backed up is relatively large or the backup frequency is high, the memory occupied by the snapshot will be relatively large, and the time required for backup and recovery will be relatively long.\u003cbr\u003e How can we solve this problem? \/ Each application scenario has its own optimal solution.\u003cbr\u003e For example, the example we looked at in Section 8.10.1 implemented undo functionality using the Memento pattern, but only supported sequential undo.\u003cbr\u003e That is, when you undo, you can only undo the last text you entered, and you don't have to skip it and undo the previously entered text.\u003cbr\u003e In this case, instead of storing the entire text in a snapshot to save memory, you can record only small amounts of information separately. \u003cbr\u003eWhen you get the length of the text you entered when taking a snapshot, you can use a method to cut off that length from the original text.\u003cbr\u003e\n\n\u003c\/div\u003e\n\u003cdiv\u003e --- p.489\u003c\/div\u003e\n\u003c\/div\u003e\n\u003cdiv\u003e\u003c\/div\u003e\n\u003c\/div\u003e\n\u003cbr\u003e\u003cdiv\u003e\u003ch5\u003e \u003cb\u003ePublisher's Review\u003c\/b\u003e\n\u003c\/h5\u003e\u003c\/div\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e \u003cb\u003eImprove code quality with object-oriented programming, design principles, coding conventions, refactoring, and design patterns.\u003cbr\u003e\u003c\/b\u003e\u003cbr\u003e As developers gain experience, they become more driven by the desire to improve the quality of their code.\u003cbr\u003e Unfortunately, however, many companies' development departments are in a rush to create each feature and meet the schedule.\u003cbr\u003e If the code you wrote just works, there's no time or space to look at it again.\u003cbr\u003e But when you maintain code that was hastily created like this, you get frustrated and want to delete all the code and rewrite it.\u003cbr\u003e \u003cbr\u003eSo how do you write high-quality code? Having worked in a development environment (Google) that significantly reduces maintenance costs through strict code quality control, the author recommends first acquiring theoretical knowledge of code design.\u003cbr\u003e Knowledge of code design theory helps improve the maintainability, readability, extensibility, flexibility, conciseness, reusability, and testability of code.\u003cbr\u003e\u003cbr\u003e\u003cbr\u003e Chapter 1 of the book defines what high-quality code is and shows you how to avoid overdesign.\u003cbr\u003e Chapter 2 introduces object-oriented programming, which is the basis of design principles and design patterns, and Chapter 3 introduces important design principles such as the SOLID principle, KISS principle, YAGNI principle, DRY principle, and LoD principle.\u003cbr\u003e \u003cbr\u003eIn Chapter 4, you will learn coding conventions including naming, comments, code style, and coding tips. Chapter 5 covers the four elements of refactoring, unit testing, code testability, and decoupling, and you will learn refactoring techniques with examples.\u003cbr\u003e\u003cbr\u003e Chapters 6, 7, and 8 introduce 22 design patterns, divided into three categories: creation, structure, and behavior.\u003cbr\u003e Chapter 6 introduces creational design patterns, including the singleton pattern, factory pattern, builder pattern, and prototype pattern, and Chapter 7 introduces structural design patterns, including the proxy pattern, decorator pattern, adapter pattern, bridge pattern, facade pattern, composite pattern, and flyweight pattern.\u003cbr\u003e Chapter 8 introduces behavioral design patterns, including the Observer Pattern, Template Method Pattern, Strategy Pattern, Chain of Responsibility Pattern, State Pattern, Iterator Pattern, Visitor Pattern, Memento Pattern, Command Pattern, Interpreter Pattern, and Mediator Pattern.\u003cbr\u003e \u003cbr\u003eAlthough most of the code in this book is written in Java, the content and explanations are not language-specific and can be read by anyone using any programming language.\u003cbr\u003e Recommended for all developers who want to improve their coding skills. \u003cbr\u003e\n\n\u003c\/div\u003e\n\u003cdiv\u003e\u003c\/div\u003e\n\u003c\/div\u003e\n\u003c\/div\u003e\n\n\n\u003c\/div\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003cdiv style=\"width:95%;padding-top:20px;padding-bottom:20px\"\u003e\n\n\u003cdiv style=\"text-align:left;font-size:16px;font-weight:bold;padding-bottom:20px\"\u003e GOODS SPECIFICS \u003c\/div\u003e\n\n\u003cdiv style=\"text-align:left;font-size:14px;line-height:1.6em;\"\u003e\n\n\u003cdiv style=\"width:100%;margin-bottom:5px;line-height:1.6em;font-size:14px\"\u003e - \u003cstrong\u003eDate of issue:\u003c\/strong\u003e May 26, 2023\u003c\/div\u003e\n\n\u003cdiv style=\"width:100%;margin-bottom:5px;line-height:1.6em;font-size:14px\"\u003e - \u003cstrong\u003ePage count, weight, size:\u003c\/strong\u003e 528 pages | 1,014g | 188*245*26mm\u003c\/div\u003e\n\n\u003cdiv style=\"width:100%;margin-bottom:5px;line-height:1.6em;font-size:14px\"\u003e - \u003cstrong\u003eISBN13:\u003c\/strong\u003e 9791192987101\u003c\/div\u003e\n\n\u003cdiv style=\"width:100%;margin-bottom:5px;line-height:1.6em;font-size:14px\"\u003e - \u003cstrong\u003eISBN10:\u003c\/strong\u003e 1192987101 \u003c\/div\u003e\n\n\n\u003c\/div\u003e\n\n\n\u003c\/div\u003e\n\n\n\u003c\/div\u003e\n\n\u003ccenter\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003ccenter\u003e\u003ctable\u003e\u003ctr\u003e\u003ctd style=\"height:10px\"\u003e\u003c\/td\u003e\u003c\/tr\u003e\u003c\/table\u003e\u003c\/center\u003e\n\n\u003cspan\u003e\u003c\/span\u003e\n\n\u003c\/center\u003e\n\n\n\u003c\/center\u003e","brand":"LIBRAIRIE COREENNE","offers":[{"title":"Default Title","offer_id":43893812527146,"sku":"110482","price":48.0,"currency_code":"EUR","in_stock":true}],"thumbnail_url":"\/\/cdn.shopify.com\/s\/files\/1\/0683\/2750\/5962\/files\/81de358b98d6b96b2ae93452b067b608.jpg?v=1765418310","url":"https:\/\/librairie.coreenne.fr\/en\/products\/110482","provider":"LIBRAIRIE COREENNE","version":"1.0","type":"link"}