In reading the clean architecture of the course, you will find writers often mentioned recompile redeploy, these terms are related to a statically typed language it seems relevant, such as Java, C ++, C #. In the python language I use frequently, these concepts do not exist. So, when reading of doubt there will be a variety of principles "clean architecture" is mentioned, such as SOLID, whether dynamically typed language - the same applies - such as python?
SOLID is the guiding principle of OOP, more guidance should be a variety of design patterns, GOF classic Design Patterns: Elements of Reusable Object- Oriented Software is also in C ++, for example, then these classic design patterns how many are suitable for dynamic languages such as python do? This article documents shallow thinking on these issues, if there are cognitive wrong place, also please feel free.
This article addresses: https://www.cnblogs.com/xybaby/p/11767100.html
SOLID
SOLID is the guiding principle of the module (module) design, consisting of the following five principles
- SRP (Single responsibility principle): single responsibility principle, a module is only one reason for modification
- OCP (Open / closed principle): Open - Closed Principle, open extension, modification closed
- LSP (Liskov substitution principle): Richter Alternatively principles, must be able to replace them subtype base type
- ISP (Interface segregation principle): Interface Segregation Principle, you must rely on is actually used to
- DIP (Dependency inversion principle): Dependency Inversion Principle, rather than rely on an interface to achieve (the top without knowing the underlying implementation)
ISP
First look of the ISP, the interface segregation principle, "clean architecture" This is recognition of the principle of a language-dependent
This fact could lead you to conclude that the ISP is a language issue, rather than an architecture issue.
Why, ISP mainly to solve the unnecessary recompilation and redeployment "fat Interface" cause, as follows:
Use1 to op1use the results in a modification of OPS, leading to User2 User3 have to be recompiled. In dynamic languages is not such a problem to recompile existing:
In dynamically typed languages like Ruby and Python, such declarations don’t exist in source code. Instead, they are inferred at runtime. Thus there are no source code dependencies to force recompilation and redeployment
DIP
DIP (Dependency Inversion Principle) is the core of SOLID, OCP in fact dependent on the DIP. It can be said, DIP is the core of "clean architecture" of.
"Clean architecture" consists of two parts:
- well-isolated components
- dependency rule
What is the "Dependency rule" it? Let low-level detail to rely on high-level policy. For example, the business logic (business rule) compared to data storage (database) due to a higher level, although it is logical to use the database business logic, but for maintainability, scalability, gotta get database to rely on the business architecture rule, as shown in FIG.
As can be seen from the chart, in order to achieve this purpose, in a static language, we will declare an interface, called both sides rely on this interface. As the figure above database interface, let business rule and database have to rely on this interface, and this database interface and business rule in one component, which achieved a lower level to allow database-dependent high-level business rule.
In the statically typed languages (such as Java, C ++), the fact is the use of run-time polymorphism this feature makes it possible to run - time rather than at compile - to change the behavior of software, of course, in order to achieve this purpose, it is necessary to declare a virtual base class or interface (Java Interface).
And in python, originally run time to seek value, but also because ducking type, so without prior declaration interfaces or compel inherited interfaces
Dependency structures in these languages（dynamic typed languages） are much simpler because dependency inversion does not require either the declaration or the inheritance of interfaces.
From a statically typed language to dynamically typed language, in fact, a lot of things omitted
- Virtual functions is omitted, as template method mode
- Omitted virtual base classes, interfaces, such as DIP, strategy mode
python Dependence and dependency inversion
In python, how dependent count, count how dependent upside down?
'''my.py'''
import other
class My(object):
def f(self):
other.act()This piece of code by importmake module mydepends on the module other,
'''my.py'''
class My(object):
def __init__(self, actor):
self._actor = actor
def f(self):
self._actor.act()So here, my and other dependent relationship it? No, where are they there have been no other. Due to the dynamic type plus ducking type, no need explicit interface definitions, just follow the relevant agreement (contract) can be. And this contract, no way to force bound by the code, what kind of interface to the caller needs, the caller should have what kind of behavior can only be described by the document (or unit tests).
For expression of the contract, the above code should be added docstring
'''my.py'''
class My(object):
def __init__(self, actor):
'''Param: actor，该对象需要具备接收0个参数的act方法
'''
self._actor = actor
def f(self):
self._actor.act()python extensive use similar protocols, such as context management, iterator protocol. Although it is convenient, but also have higher expectations for programmers, because at least have to have docstring fly. If you need to impose constraints that can be considered using the abc 's.
Design Patterns
First, the statement that is mentioned in this article design patterns, generally refers to Design Patterns: Elements of Reusable Object- Oriented Software classic design patterns described in this book.
Long before seen a saying, "++ design patterns to make up for static languages defective" ++, was not by thinking you'll accept it, and I humbly think that this is the truth. Recently really think about this question, we found this argument biased and incomplete.
First, throw a question: design pattern is related to the language it (Language-specific) ? Some type of programming language to design mode, while other programming languages do not need? Or that require different programming language design pattern is not the same?
What is the design pattern here, "Design Patterns" described as a simple and elegant solution to a specific class of problems in software design.
Describes simple and elegant solutions to specific problems in object-oriented software design
In other words, certain design patterns to solve a particular problem routine, or methodology. Routine is a response to a question, after a theoretical or proven, effective methods and procedures. Methodology can not solve the problem, you may need to try a lot of trial and error to obtain a solution (not a large probability of the optimal solution), the solving process is time consuming and inefficient. Therefore we can say, methodology (model) to accelerate the process of problem solving.
For example, programmers are a lot of things to do every day: a meeting, write code to handle bug, to be charged himself. How to arrange it? This question may have to think for themselves bruised and battered, but already there is a mature methodology - Eisenhower matrix - available for use ah.
We often say, standing on the shoulders of giants, routine, methodology is the shoulders of giants.
The same is true design patterns.
Design Patterns and dynamic languages
"Design Patterns" book, written in 1994, the author mentions the goal of writing this number is the record of these proven experience . As mentioned earlier, the design pattern is a solution for a class of problems, then presents a design pattern, something always involves the following content (including but not limited to):
- What is the problem to be solved
- The solution is what it looks like
- Solutions defects and application scenarios
- Detailed steps solutions
- For the same problem, there are no other solutions, their advantages and disadvantages
Of course, first of all have to take this model a name aptly, the importance of naming can not be questioned. At least ensure that the expression of communication between programmers in the same issue, regardless of whether the communication is peer to peer, or through code. Name (terminology, definitions) will reduce the cost of communication.
After "Design Patterns" written two years, in 1996, Peter Norvig do share a " Design Patterns in Dynamic Programming ", pointed out that due to the less restrictive language level, there is a dynamic language, GOF most of the design patterns in Lisp or Dylan has a simpler implementation, and some even simply no need to pay attention
16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern
16 of 23 patterns are either invisible or simpler
So what patterns become "invisible", which is "simpler" of it?
"Design Patterns" in talking about design patterns divided into three categories
- Creational: ways and means of object instantiation
- Structural: mutual composition of classes or objects (the Facade DP is Structural)
- Behavioral: how classes or objects interactand distribute responsibilities among them
Because in a dynamically typed language, category (class, type) and method (function) are first-class citizens, so Creational patternsin dynamically typed languages such as Python, it becomes "invisible".
Due to the dynamic type, ducking type, a number Creational patternssuch as "Observer", "Visitor" to become "simpler". It should be emphasized that easier does not mean there is no sense that this mode of existence, such as observer mode, or subscribe - publish, on behalf of the design principle of loose coupling, are in all levels of design needs.
For this design pattern reflect higher principles, ideas, and we should use the model to help think and communicate, but do not stick boilerplate code, specific language. StackExchange this parallelism sentence on the very appropriate:
- I might say that I have a visitor pattern, but in any language with first class functions it will be just a function taking a function. Instead of factory class I usually have just a factory function.
- I might say I have an interface, but then it's just a couple of methods marked with comments, because there wouldn't be any other implementation (of course in python an interface is always just comments, because it's duck-typed).
- I still speak of the code as using the pattern, because it's a useful way to think about it, but don't actually type in all the stuff until I really need it.So back to the question, design patterns are language-dependent it (language-specific)?
My answer is, part of the design pattern is related to language, part of the design model is not language-dependent, specific to a particular pattern may also be changed.
Why, rigorous, we can only say that the problem is related to design patterns - relates to a particular problem. The core is that the question under what circumstances is indeed a problem. Moreover, with the development, will die an old problem, new problems will arise.
Specific to the programming language, you should be thinking about a problem is not language-dependent. In the statically typed languages, such as C ++, the object has a type, type determines its behavior, then in order to run multi-state, you have to have a virtual base class, but also do OCP, which requires a variety of Creational Patterns. But in a dynamically typed language, this is no longer a problem, so you no longer have the corresponding mode.