VIP Service Pattern

    In the previous article, we examined a small pattern to simplify the code of users of services; in this article we will consider a special type of service. This pattern is used in architectures with layers, if the architecture in question does not have layers, then the pattern may not have the desired effect or be harmful at all.

    Architectural layers
    Unfortunately, there are no articles on the hub that describe what layers are, but on the outside there is an article by the primepix habrowser

    The pattern is not tied to programming languages.

    Update: Added an example from real practice.

    Picture to attract attention:




    Imagine the situation, we have a large project that has already been formed and has passed the stage of rapid redesign. The project has layers, everything is implemented technically competently (yes, this happens) and the architecture allows you to implement a subset of the current functionality. Development goes according to plans without excesses and crunches.

    But at some point, an idea or requirement arises in one of the bright goals of designers / investors / creative directors or artists (underline as necessary). This idea does not fit into the current architecture. It may not necessarily be an idea as a new functionality, it can be, for example, support for a custom functional \ mode of one of the suppliers of middleware which gives any advantage, for example, technical.

    What do designers / architects do in this situation? The most correct solution is to refuse new functionality by all available methods, because the best code is code that is not written. Such code is easily maintained and contains a minimum number of bugs. Ways to influence can vary, from pressure by authority to the use of various tricks, for example, allowing yourself to beat Quake .

    The second solution, if the situation allows, is to revise the architecture in working order and, if necessary, redesign it.

    If there is no time for evaluation and redesign, and the solution is required "yesterday", then you have to take the "technical debt". The worst case is that functionality needs to be thrown through several layers.

    Probros functionality:


    The negative consequences of such decisions are known. The upper layers become dependent on the details of the lower layers, intermediary services appear that are needed only to forward functionality, etc.

    This pattern serves as a solution to the problem of littering architecture with probros and their negative impact on the architecture as a whole. The essence of the pattern is to encapsulate all debts in a single service, or a chain of services. Such a service will be a facade to all the technical debts of the system.

    Forwarding Encapsulation:


    It is important to understand that this pattern is not part of the architecture and is needed only to encapsulate temporary solutions, allowing you to buy time for evaluation and redesign without destroying the current architecture.

    Real world example
    Project MMO game. The code base is about 3,000 C # files. The client is written in C #, OGRE (C ++) was used for rendering.

    Fragment of client architecture


    The bottom layer “Render” is the implementation of the render, along with implementations of various effects (animated scenes, particles) and scene objects that support animation (skeletal, morph). Everything related to the display in one form or another was implemented in this layer.

    The Render facade layer was the interface (facade) to the render and contained all the native code wrappers for use in C #.

    The Scene graph layer was a place to simulate objects and their interactions.

    The “Logic” layer simulated objects and mapped logic onto simulation objects.

    In this fragment, other systems that were in these layers are omitted, for example, there is no UI (which also represented C # wrappers for C ++).

    The objects in the graph scene layer were the simplest objects that contained position and orientation. They supported the hierarchy as well as managing abstract animation through identifiers (roughly speaking, start and stop by id).

    After another surge of creativity, designers needed to change the colors of materials depending on the logic in runtime. The motivation was as follows: “There is no time to explain, make us change the color of materials!”, However, in game dev this is a common practice (smiley face).

    To add such functionality, it was necessary to disfigure object interfaces by adding such a specific thing as material and toss it through all layers. And not all objects basically had material, for example, light sources and cameras or composite animation objects, for example, asteroid belts, etc.

    Probros functionality (shown in red)


    There wasn’t enough time to think and especially experiments, so it was decided to temporarily arrange this functionality as an independent service. In this case, even the interface of the object was not affected, a certain implementation of the extension method only in the global context.

    VIP service implementation


    At the same time, at every stage and in every chain of the service, all kinds of paranoid checks were made so that the service did not break the system or become a source of failure.

    Over time, various methods for very tricky widgets and other problematic solutions appeared and disappeared in this service.

    And the functionality of the materials was removed from the service after the implementation of a full-fledged animation graph with support for all aspects of visualization. And the designer indicated the change of materials as part of the animation.



    Pros:
    • Functionality is available immediately.
    • Winning time to work out the right decision
    • Technical debts do not spread throughout the system
    • Quick access to all system debts (for assessing architecture problems)
    • Solutions to a whole class of problems are possible, since solutions to specific problems are delayed.
    • Direct gain if functionality is no longer needed


    Minuses:
    • The pattern is not applicable everywhere


    Thank you all for your understanding!

    Also popular now: