About abstraction, loosely coupled architecture and design in general

    To the good posts "Code in the style of" dump of the stream of consciousness " and " Micro refactoring, which we so often forget about . "

    • Why don't most programmers like to read someone else’s code?
    • Why is refactoring and making changes a serious problem?
    • Why does it happen so often that it’s easier to rewrite from scratch?
    • Why do some programmers call others good or bad words?


    Of course, many of you will find that the answers to these questions below are quite familiar, but take this article as a note, since throwing a link is often still much more comfortable than kicking in the explanations and evidence of the obvious.


    • Noodles
    • Abstraction
    • Loosely coupled architecture
    • Code out of my head?


    Noodles


    A very frequent case is when you and I have an excellent program, which is written in one go, and is already good at working and doing what is needed.

    It would seem that you can rejoice, but there are some circumstances from the harsh real life that are not visible behind the pink glasses.
    1. Any program contains errors. Therefore, it must be accompanied.
    2. Sooner or later, any program needs to be changed. Therefore, it must be accompanied.
    3. Any program or its parts can become components of another program. And the original solutions will have to be accompanied.

    It makes sense to write each program taking into account the fact that someone will accompany it. Other programmers will read your code, and only by your code will they draw conclusions about your moral character. And very often this “other programmer” will be you yourself. Axiom, isn't it?

    Did everyone have to go back to analyzing their own code?

    Consider a typical example - a cool program where all the code is piled up in one heap.



    This happens when in one component at the same time are:
    - final output and data acquisition;
    - data processing of obviously different nature;
    - detailed algorithms in the bodies of nested conditions.

    In fact, it would seem, why put code in a couple of lines in a separate method (function)? For someone it will be surprising, but there is a point in it.

    Abstraction


    The strongest programming technique is abstraction - the separation of the program and all its components into parts.

    • The business logic of the application is distributed according to the class system, based on subject entities, functionality, stages and types of processed-transmitted information (MVC)
    • The application consists of several practically unrelated components. Often they are even written in different languages, and interact through the API. For example, for a thick toy - BL layer, physics, sound, rasterizer. Physics and Graphics - Ogre in C ++, Business Logic, GUI and Sound - Lua or Python. For a website - separate components of a web server, interpreter, CMS in an interpreted language, separate programs for image and video processing, a driver and a database engine.
    • Within one class, the division of actions into different methods (functions) by functional attribute. Private methods are separated, at least in order to designate data processing that is relevant only for the internal purposes of the class, and information of importance and value to the user of the class.




    Loosely coupled architecture


    Loosely coupled architecture is a bear power in programming. Thanks to her, for example, such good things as CodeIgniter, YII, jQuery, Chomium, Half Life, Counter Strike were born - the list is huge.

    The idea of ​​a loosely coupled architecture is that program components at various levels have little or no dependence on each other.

    For example, in a class, one or several, knowingly small number of “dispatch” functions are allocated that call other methods, including private methods of the class, to perform tasks.

    High-level examples are known to all users of frameworks - there are sets of components that you can use or not apply depending on real needs.

    A key element of a loosely coupled architecture is the allocation of a central component.Such a solution may even be a formalized API. Naturally, when developing a new product, the API can and will develop along with the development, and is repeatedly reviewed.



    There is another strength here - it makes sense to devote a large amount of attention to the central component, and thus, time is probably saved for documenting and commenting on the others. By itself, the ability to prioritize saves time.

    A good solution is to use a loosely coupled architecture at various application levels. Then even the most complex Data Flow scheme will be easy to read.



    Code out of my head?


    There is always a temptation to sit down and write a decision in one fell swoop, out of your head. Himself often sin.

    At the stage of writing code, in most cases there are no problems. Problems arise later, which is highlighted at the beginning of the article.

    The main unpleasant consequence of all problems is the loss of time. Often these time losses are huge and fatal in their consequences. And to prevent and minimize them is not so difficult.

    It makes sense to pause and type in Google the phrase "program design". All found methods will be graphic, simple and accessible for understanding and use.



    The meaning is simple:
    - paying more attention to the analysis of the problem,
    - separating the methods (including programming, frameworks, algorithms) from the goals in the analysis,
    - without giving too much priority to any one of the elements in the diagram above (“everything is important to us”),
    ... we save a huge amount of time, money, effort, and also pump our own reputation in the eyes of colleagues.

    Designing programs is no less important and useful stage than mastering PL, getting to know libraries, frameworks and technologies. You can make great strides forward and effectively solve the problems outlined above, paying enough attention to this wonderful aspect of programming.

    Also popular now: