跳到主要內容

發表文章

目前顯示的是有「design pattern」標籤的文章

Distributed transactions

Table of contents [ hide ] Basic theory  CAP States that any distributed data store can provide only two of the following three guarantees. Consistency Every read receives the most recent write or an error. Availability Every request receives a (non-error) response, without the guarantee that it contains the most recent write. Partition tolerance The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes. Typical architecture of distributed systems When a network partition failure happens, it must be decided  whether to do one of the following: CP: cancel the operation and thus decrease the availability but ensure consistency AP: proceed with the operation and thus provide availability but risk inconsistency. BASE Basically-available, soft-state, eventual consistency. Base theory is the practical application of CAP theory, that is, under the premise of the existence of partitions and copies, through certain syste

Program design template

Table of contents [ hide ] Designing programs is a common job for every engineer, so templates help simplify the job of designing each program. Update History Let everyone know the latest version and update information. background Write down why we need this program and what is the background for building this program. Target Target functionality The goal of the program, what function to achieve, the main module and submodule, and these modules' relationship. Target performance Specific benchmarks such as QPS or milliseconds to evaluate programs. Target architecture Stability. Readability. Maintainability. Extendability. ... Others Target Overall design Design principles and thinking Explain how and why the program was designed. Overall architecture An overall architectural picture. Dependency Module dependencies on other modules or programs. Detail design Program flow design Program flow design diagram. API design The details of the API, and how to interact with the frontend

Reflection

Reflection is an API that is used to examine or modify the behavior of methods, classes, and interfaces at runtime. Reflection is the basis for many advanced features such as annotations, and dynamic proxies. Many frameworks use reflection to implement functions, such as Spring IOC and AOP, ORM mapping frameworks, etc. Pros: Inspection of interfaces, classes, methods, and fields during runtime is possible. Arbitrary calls to methods and properties of objects. Create an instance arbitrarily. Cons: Reflective code is less readable and maintainable. Performance overhead. Break the principle of encapsulation. Example: Abstract factories with reflection can reduce redundant code to keep clean code. see Proxy . reference: https://www.geeksforgeeks.org/reflection-in-java/ https://www.javatpoint.com/java-reflection https://github.com/hollischuang/toBeTopJavaer

Proxy

Table of contents [ hide ] Proxy in design pattern The proxy pattern is a software design pattern, as a wrapper or agent object that is being called by the client to access the real serving object behind the scene. There are two advantages: Provides access control for real objects. Provides additional functionality when accessing real objects. And there are two types of proxy: Static proxy: proxies are created manually. Java example on  GitHub . Dynamic proxy: proxies are created by JDK Proxy or CGLib Proxy with reflection. JDK proxy Before the proxy object is created, it must implement the invoke method of the InvocationHandler, which is invasive to the target object. JDK Dynamic proxy can only proxy by the interface (so your target class needs to implement an interface, which is then also implemented by the proxy class) CGLib proxy The proxy object is created by implementing the intercept method of MethodInterceptor, and the target object does not need to implement this metho