In our daily development, design patterns accompany each module of the project. Clever use of design patterns can allow us to write more efficient, concise, and beautiful code. However, because of the unfamiliarity with design patterns, many efficient design patterns have not been used well. Now I include some code I wrote, and then talk about some of the things we have made using design patterns in the project during the optimization process. optimization. Of course, it's just a personal opinion. If there is any inadequacy, welcome to make a brick. Let's discuss and grow together.
As a developer, it is very important to have a learning atmosphere and a communication circle. This is my iOS communication group: 638302184, whether you are a novice or a big cow, welcome to join, share BAT, Ali interview questions, interview experience, and discuss technology , Let's communicate, learn and grow together!
1. The choice between using delegate pattern (agent pattern) and block in the project
I saw in the technical exchange group before that the tech gods were arguing about which block and delegate should be used and how to choose. I saw someone saying that the delegate passes a pointer and the block passes a structure. From this point of view, it is indeed a delegate Better, but in our actual development environment, I prefer to make different choices based on specific business scenarios, because delegate is not as good as block in code readability. Specifically, we mainly do The following choices.
First, both delegate and block are encapsulated in the processing of the network request layer. The reason is that in the specific business, the request will be sent in class A, but the corresponding model created by the data we return will only be created in class B. To call, this time we use block to pass the data model, because at this time, the use of proxies may encapsulate two or even multiple layers of proxies, which will undoubtedly make the code readability very poor. If the model is passed more layers, the code will appear very confusing.
Second, in actual development, some complex interfaces will use dispatch_group_t. At this time, if we want to combine network requests, if we send two or more network requests in the same method at this time, this If you want to use delegate to call back the return result, you will generally declare dispatch_group_t as an attribute, use dispatch_group_leave(self.group) in the proxy to get the callback result, and then do unified processing in dispatch_group_notify, I think this is for The memory management of the group becomes unreasonable, so I use block at this time. When the rest is in an interface, I will use the #prama mark method to distinguish a request, and use the proxy method to write the request.
Of course, in addition to the processing of the network request layer, have we made a choice between delegate and block in other places? There must be this. I remember that we encountered it not long ago in the process of developing the live version of the fitness coach. I believe that everyone is familiar with the live interface. If you click on the avatar of the anchor, the avatar of the audience, and the nickname in the comment area will display the user's data pop-up window. of. However, these three parts were divided into three small attempt classes. At that time, my colleagues proposed that each click event should be called back in the form of block, write a manager management class, and uniformly process the pop-up user data. I think many people I thought of such a solution for the first time, but then I used the proxy solution.
The code structure of the scheme is shown in the figure above, which is a simple demo, that is to say, we distinguish the proxy mode. All click events for obtaining user data go through the proxy of baseMethod1, so that all users' click events for obtaining data can go to In a method of the controller, it is no longer necessary to create a manager for this purpose, and there is no need to expose a callback method in each test area. It feels that the simplicity and clarity of the code have been improved, and it is also compatible. Each attempt has its own callback event. Therefore, the choice between the delegate mode and the block is not certain. You must make your own analysis and make a choice based on the specific business scenario.
2. About the use of adapter pattern
I think some students have encountered such a problem in the process of accompanying the growth of the project, which is to convert the data returned by the server into a data model and then pass it into each attempted interface to render the interface, but sometimes the product tells us, My user profile wants one more parameter to be presented. If the interface name is named in the form of multiple parameter names, it will be very troublesome to change many places that have been called. At this time, some friends will say that the incoming parameter of the interface is a class, but if the user data is presented in the same way on multiple interfaces, the data returned by each interface as a whole is different. Next, if the interface uses classes as parameters, it may be necessary to provide a lot of interfaces in the split user data attempt, and then expose them to interface calls. Obviously, this method is also unreasonable. So how to solve it at this time, so the adapter mode appeared. The code structure is as follows
Adapter mode usage
If in the adapter mode, we don't need to define multiple parameters or classes for the interface when we try to pass in the parameters that need to be used in multiple places. At this time, the parameters we define are the data models that conform to a certain protocol. It is enough that the data model returned by each interface conforms to the corresponding protocol. If the product tells us to change the requirements again, we will add the corresponding method in the protocol, and then search for the class that abides by the corresponding protocol to implement this method, and the processing of the interface will become simpler.
Of course, for the use of the adapter, I am just a simple analysis. It is not only used in the adaptation interface. We also use this scheme in some controllers in the real project. Even the adapter protocol has to do the operation of complying with the protocol. In its upper layer, an adapter is created. It needs to be combined with specific business scenarios. However, the adapter can really help us a lot in increasing the readability of the code and simplifying the code. Better use still requires the constant attempts and imagination of the friends~~~
3. About the use of singleton pattern
I think for the vast majority of developers, this development model is all too familiar to us. The reason for talking about the singleton pattern here is that I think singletons may be overused in many projects, and there may be dozens or even more singletons in a project.
We all know that after a singleton is created, it will accompany the entire life cycle of the client, and the singleton will not be released before the end of the program, so from the perspective of memory management, the use of singletons should be paid attention to.
We should know what scenarios we are suitable for using singletons, and in what business scenarios we can avoid using singletons to save our memory space. For example, if you join us for a live broadcast, some students may create a singleton to determine whether the user is in the live broadcast to determine the user's current status, and then restrict some of the user's behavior. In fact, in such a scenario, I think using a singleton is an unreasonable behavior, because in this mode, we can create a class method in the live management class to create a method to store the current state in NSUserDefault. The judgment of the state saves the corresponding memory and avoids the unreasonable waste of memory space. There are many similar distances from here. I hope that students who deal with it improperly can check their own projects and make a better solution.
4. Some other design patterns that may require attention
In addition to the most commonly used design patterns above, the design patterns we commonly use in our projects include factory patterns, observers, strategies and other patterns, as well as intermediary, template, flyweight and other patterns used in some projects.
The first thing I want to say is (observer mode), in the actual development of iOS, I think everyone has used NSNotificationCenter and KVO or FBKVO. But I think not all students know the exact method in which the observer of NSNotificationCenter receives the message. threaded.
In fact, the thread of the method executed after receiving the message is the same as the thread of the post message, so there may be a thread safety problem. Although Apple said in the official document that it has been processed, but in actual development doesn't mean there won't be problems. For details, please refer to this article, which introduces the scene of the problem, and encountered such a situation when using KVO in our project.
As for (strategy mode), I think everyone has used it in daily development, but some of our students don't know this is called strategy~~~ In fact, the use of strategy can really greatly improve the readability of the program, So if you don't know, you must Baidu, I won't introduce it in detail here.
And (mediator mode) I personally feel that it is mainly used for URL jumping in componentized development. Our project has always wanted to make efforts in the direction of componentized development, so we may study this part in depth recently. The results are being shared with children's shoes. There is too much to say, so I won't expand it here.
The use of (template mode) in the project can actually be combined with the adapter mode, so the friends who have studied the adapter must be familiar with this place. If you don’t know much about this, it is really a good suggestion To learn and pay attention, good code quality is important.
Finally, I said (flyweight mode), I said that it is a serious mistake to use it in very few projects, because I believe that every project will have a tableview and its cell reuse pool mechanism is designed based on the flyweight mode. Strictly speaking, the Flyweight model is rarely designed and used by itself in enterprise projects. However, when we need to reuse a large amount of data, considering performance and other aspects, we should consider this mode, and then make corresponding optimizations, there will be unexpected and miraculous effects~~~
Some things that have happened around me recently have changed my attitude. It doesn't matter. Of course, I hope I can grow up with the children's shoes who love iOS development~~~
As a developer, it is very important to have a learning atmosphere and a communication circle. This is my iOS communication group: 638302184, whether you are a novice or a big cow, welcome to join, share BAT, Ali interview questions, interview experience, and discuss technology , Let's communicate, learn and grow together!
The article comes from the Internet. If there is any infringement, please contact the editor to delete it.