This article explains a principle very vividly: the SRPsingle principle of self-blame . SRP is the most misunderstood of the five SOLID design principles. Perhaps it is the name. Many programmers take for granted that this principle means that each module should only do one thing based on the name SRP. We often use this principle when restructuring large functions into small functions, but this is only a design principle for the underlying implementation details, not the whole of SRP.
Body: You explain clearly to me that there is already a CALayer, why do you need UIView?
UIView inherits from UIResponder, and its main feature is that it can respond to touch events. And CALayer is actually layer content management. Everyone is doing different things. They are two things. Everyone's existence doesn't affect each other, so it's natural.
But think about it carefully, is it really a BBK reading machine, So Easy? When you carefully figure out the intention behind it, you will find OMG! ! !
UILayer
If UIKit is not from Apple, but from us, what might happen? Yes, maybe UIView and CALayer are combined into a thing called "UILayer". This UILayer is an all-round Layer, which can manage the display content, and can also handle touch events, hanging, right!
Ok! Assuming that UILayer has been so tired a long time ago, it exists in iOS2. It's really smart, and it's so tired from the beginning.
Now, your product manager comes over with a smile. In the iOS3.2 version, gesture recognition should be added. This is easy to handle, just change UILayer and add a gesture recognition.
Your product manager came here again and patted you on the shoulder. How trusting you are, doesn't it? Now that the Block syntax is introduced in iOS4, add a Block version to the previous animation. You think about it, it's easy, just change the source code of UILayer.
Your product manager is here again, oh, he also brought two product girls, and they surrounded you. They are all company celebrities. They are trusted by the public. They are a bit shy.
This time I ask you to add a Big Feature called AutoLayout to iOS6. This is really a big feature. It has to be changed in many places, and it also brings a lot of difficulties to the test. Now the UILayer class has become larger and larger, and the function is as powerful as 3000. The release cannot be postponed. This is again Such an important category, but also to be worthy of the girl's affectionate expectation of you, has to be changed carefully. In the end, you are done. Haha, you are the best employee at the end of the year.
Your product manager is here again, yo, hug your neck, tell you a joke, and invite you to dinner, oh, the product girl is still praising you in the back. Yes, once again at a historic moment, iOS has ushered in the seventh major version of a makeover.
iOS7 has become small and fresh, and physical effects have been added, and even parallax has been added. The product manager is trying to subvert the product design concept and try to change the world again, which is amazing. Then, when you click on the huge UILayer class, it seems to be changed from beginning to end, but so many things need to be changed, time is limited, and the time to finish the test seems to be insufficient, what to do, refactor It's impossible. The annual release cannot be postponed, otherwise, how could the company keep its face in front of the world. But time is not waiting for anyone. Even if programmers encourage you every day, you can't save you. The code you can't control is anymore. At the historical juncture of iOS7, your myth has fallen.
analysis
Therefore, behind this natural SDK, there are decades of design wisdom of Daniel. There should be many doorways in it. This time we analyze UIView and CALayer, and we can get something.
-
Mechanism and strategy separation
-
More immutable
-
Perform their duties
-
Less leakage
1. Separation of mechanism and strategy
One of the main ideas of Unix kernel design is to provide (Mechanism) mechanism instead of policy (Policy). Programming issues can be extracted from the mechanism and strategy parts. Once the mechanism is implemented, it will rarely change, but the strategy will often be optimized. For example, atoms can be regarded as mechanisms, and the composition of various atoms is a strategy. CALayer can also be regarded as a mechanism that provides layer drawing. You can open the header file of CALayer to see. Basically, it has not changed much, while UIView can be regarded as a strategy with many changes. The more the bottom layer, the more the mechanism, and the more stable the mechanism. The separation of mechanism and strategy can make the code that needs to be modified less, especially the underlying code, which can improve the stability of the system.
2. More immutable
How does stability give you? Sturdy? Not deformable? In fact, stability means immutability. The more immutable things a system is, the more stable it is. So the mechanism satisfies this immutable factor. The guiding ideology of building a system is to try to extract immutable things and separate variable things. Water can't make a tall building, only solid concrete can. Fewer modifications means less chance of bugs.
3. Perform their duties
No matter how strong he is, he can't do everything. In case it doesn't work one day, then suddenly he can't do anything. So just based on the principle of risk diversification, there should not be an all-rounder. Each perform its duties and cooperate with each other to minimize the controllable granularity, so that the system can be more stable and easier to modify.
4. Less leakage
The interface should be oriented to the general public. According to the eighty-two principle, 20% of the interface can actually meet 80% of the needs, and the remaining 80% should be hidden behind the scenes. Because less leakage is always safe, isn't it? The remaining 80% of the expert interface can be hidden deep. For example, UIView obscures most of the CALayer interface, and extracts and constructs easier-to-use frame and animation implementations, which makes it easier to get started.
to sum up
I have more or less understood or heard of the single principle of self-blame before. Even if I specifically read the article, inquired about the information, and understood this principle, but in the actual development process, it may not be able to use this principle. Or, let's change to a development language, such as Python. Can we experience this design principle from some Python libraries? Maybe it's also difficult. The reason is that we lack one thing: thinking. We can use tools, but we don't necessarily design tools. The underlying mechanism is the core!
Welcome to pay attention to [The Way of Infinite Testing] public account , reply [Receive Resources]
Python programming learning resources dry goods,
Python+Appium framework APP UI automation,
Python+Selenium framework Web UI automation,
Python+Unittest framework API automation,
Resources and codes are sent for free~
There is a QR code of the official account at the bottom of the article, you can just scan it on WeChat and follow it.
Remarks: My personal public account has been officially opened, dedicated to the sharing of test technology, including: big data testing, functional testing, test development, API interface automation, test operation and maintenance, UI automation testing, etc., WeChat search public account: "Infinite The Way of Testing", or scan the QR code below:
Add attention and let us grow together!