3r3306. 3r3-31.  3r3306. Hello! My name is Ilya, I am an iOS developer at Tinkoff.ru. In this article I want to talk about how to reduce duplication of code in the presentation layer using protocols.
 3r3306.
 3r3306.

What is the problem?

 3r3306. As the project grows, the amount of code duplication grows. This becomes not immediately noticeable, and it becomes difficult to correct past mistakes. We noticed this problem in our project and solved it with one approach, let's call it, conditionally, traits.
 3r3306.
 3r3306.

An example from the life of

 3r3306. The approach can be used with various different architectural solutions, but I will consider it on the example of VIPER.
 3r3306.
 3r3306. Consider the most common method in router - the method that closes the screen:
 3r3306.
func close () {
self.transitionHandler.dismiss (animated: true, completion: nil)
}

 3r3306. It is present in many router, and it is better to write it only once.
 3r3306. Inheritance would help us in this, but in the future, when we have more and more classes with unnecessary methods in our application, or we cannot create the class we need at all, because the necessary methods are in different base classes, large ones will appear Problems.
 3r3306. As a result, the project will acquire a variety of base classes and classes, heirs with unnecessary methods. Inheritance will not help us.
 3r3306. What is better inheritance? Of course the composition.
 3r3306. You can make a separate class for the method that closes the screen and add it to each router in which you need it:
 3r3306.

    struct CloseRouter {
let transitionHandler: UIViewController
func close () {
self.transitionHandler.dismiss (animated: true, completion: nil)
}
}
  

 3r3306. We will still have to declare this method in the Input Protocol of the router and implement it in the router itself:
 3r3306.

    protocol SomeRouterInput {
func close ()
}
class SomeRouter: SomeRouterInput {
var transitionHandler: UIViewController! 3r3306. lazy var closeRouter = {CloseRouter (transitionHandler: self. transitionHandler)} ()
3r3306. func close () {
self.closeRouter.close ()
}
}
  

 3r3306. It turned out too much code that just proxies the call to the close method. Lazy A good programmer will not appreciate.
 3r3306.
 3r3306.

Solution with protocols

 3r3306. Protocols come to the rescue. This is quite a powerful tool that allows you to implement the composition and may contain implementations of the methods in the extension. So we can create a protocol containing a close method and implement it in an extension.
 3r3306. This is how it will look like:
 3r3306.

    protocol CloseRouterTrait {
var transitionHandler: UIViewController! {get} 3r3306. func close ()
}
extension CloseRouterTrait {
func close () {
self.transitionHandler.dismiss (animated: true, completion: nil)
}
}
  

 3r3306. The question arises, why does the word trait appear in the title of the protocol? It's simple - you can indicate that this protocol implements its methods in an extension and should be used as an admixture to another type to extend its functionality.
 3r3306. Now, let's see how the use of this protocol will look like: 3r33294.  3r3306.
 3r3306.

    class SomeRouter: CloseRouterTrait {
var transitionHandler: UIViewController! 3r3306.}
  

 3r3306. Yes that's all. Looks great :). We got the composition, adding the protocol to the class of the router, did not write a single extra line and were able to reuse the code.
 3r3306.
 3r3306.

What is unusual about this approach?

 3r3306. Perhaps you have already asked this question. Using protocols as a trait is a common occurrence. The main difference is to use this approach as an architectural solution within the presentation layer. Like any architectural solution, there should be its own rules and recommendations.
 3r3306. Here is my list:
 3r3306.

•  3r3306.
• Trait's should not keep and change the state. They can only have dependencies in the form of services, etc., which are the get-only properties of  3r3306.
• Traits's should not have methods that are not implemented in an extension, as this violates their concept of 3r-3289.  3r3306.
• The names of the methods in the trait should clearly reflect what they are doing, without reference to the name of the protocol. This will help avoid name collisions and make the code clearer  3r3306.

 3r3306.
 3r3306.

From VIPER to MVP

 3r3306. If you fully switch to using this approach with protocols, the router and interactor classes will look something like this:
 3r3306.

    class SomeRouter: CloseRouterTrait, OtherRouterTrait {
var transitionHandler: UIViewController! 3r3306.}
3r3306. class SomeInteractor: SomeInteractorTrait {
var someService: SomeServiceInput! 3r3306.}
  

 3r3306. This does not apply to all classes, in most cases, the project will remain just empty routers and interactors. In this case, you can break the structure of the VIPER module and smoothly switch to MVP by adding impurity protocols to the presenter.
 3r3306. Something like this:
 3r3306.

    class SomePresenter:
CloseRouterTrait, OtherRouterTrait,
SomeInteractorTrait, OtherInteractorTrait {
3r3306. var transitionHandler: UIViewController! 3r3306. var someService: SomeSericeInput! 3r3306.}
  

 3r3306. Yes, the opportunity to implement the router and interactor as dependencies is lost, but in some cases this is the place to be.
 3r3306. The only drawback is transitionHandler = UIViewController. And according to the rules of VIPER, the Presenter should not know anything about the View layer and about what technologies it is implemented with. This is solved in this case simply - transition methods from the UIViewController are “closed” by the protocol, for example, TransitionHandler. So Presenter will interact with abstraction.
 3r3306.
 3r3306.

Change the behavior of trait

 3r3306. Let's see how you can change the behavior in such protocols. This will be an analogue of replacing certain parts of the module, for example, for tests or a temporary stub.
 3r3306. As an example, take a simple interactor with a method that performs a network request: 3r-3294.  3r3306.
 3r3306.

    protocol SomeInteractorTrait {
var someService: SomeServiceInput! {get} 3r3306. func performRequest (completion: @escaping (Response) -> Void)
}
extension SomeInteractorTrait {
func performRequest (completion: @escaping (Response) -> Void) {
someService.performRequest (completion)
}
}
  

 3r3306. This is an abstract code, for example. Suppose that we do not need to send a request, but we just need to return some stub. Here we go to the trick - create an empty protocol called Mock and do the following:
 3r3306.

    protocol Mock {r3r3306}. 3r3306. extension SomeInteractorTrait where Self: Mock {3r3306. func performRequest (completion: @escaping (Response) -> Void) {
completion (MockResponse ())
}
}
  

 3r3306. Here the implementation of the performRequest method is changed for the types that implement the Mock protocol. Now you need to implement the Mock protocol for the class that will implement SomeInteractor:
 3r3306.

    class SomePresenter: SomeInteractorTrait, Mock {
//Implementation 3r3303.}

 3r3306. For the SomePresenter class, the implementation of the performRequest method in the extension, where Self satisfies the Mock protocol, will be called. It is necessary to remove the Mock protocol and the implementation of the performRequest method will be taken from the usual extension to SomeInteractor.
 3r3306. If you use it only for tests, it is better to have all the code associated with the implementation substitution in the test target.
 3r3306.
 3r3306.  
  Summing up  

 3r3306. In conclusion, it is worth noting the pros and cons of this approach, and when, in my opinion, it should be used.
 3r3306. Let's start with the minuses:
 3r3306.
 3r3306.
If you get rid of the router and interactor, as was shown in the example, then you lose the opportunity to implement these dependencies.
 3r3306.
Another disadvantage is the sharply increasing number of protocols.
 3r3306.
Sometimes the code may not look as clear as when using conventional approaches.
 3r3306.
 3r3306. The advantages of this approach are as follows:
 3r3306.
 3r3306.
The most important and obvious thing is that duplication is greatly reduced.
 3r3306.
Static binding is applied to protocol methods. This means that the definition of the implementation of the method will occur at the compilation stage. Consequently, during the execution of the program, no additional time will be spent on the search for implementation (although this time is not particularly significant).
 3r3306.
Due to the fact that the protocols are small “bricks”, any composition can be easily made from them. Plus karma for flexibility in use.
 3r3306.
Easy refactoring, no comments here.
 3r3306.
You can start using this approach at any stage of the project, since it does not affect the entire project.
 3r3306.
 3r3306. To consider this decision as good or not is a personal matter. Our experience with this approach was positive and allowed us to solve problems.
 3r3306. That's all! 3r3302. 3r3306. 3r3306. 3r33232. ! function (e) {function t (t, n) {if (! (n in e)) {for (var r, a = e.document, i = a.scripts, o = i.length; o-- ;) if (-1! == i[o].src.indexOf (t)) {r = i[o]; break} if (! r) {r = a.createElement ("script"), r.type = "text /jаvascript", r.async =! ? r.defer =! ? r.src = t, r.charset = "UTF-8"; var d = function () {var e = a.getElementsByTagName ("script")[0]; e. ): d ()}}} t ("//mediator.mail.ru/script/2820404/"""_mediator") () (); 3r33300. 3r3306. 3r3302. 3r3306. 3r3306. 3r3306. 3r3306.