The art of programming under Unix (and not only). Part Three, “Composition Rule”

I continue the series of articles on the topic “The Art of Unix Programming ” by Eric Raymond. Earlier, I mentioned the first two rules - modularity and clarity .
Today we will talk about the third rule -

Composition rule: Create programs such that they can be connected with others.

Unfortunately, both in Windows and Unix, the desire of developers to “invent a bicycle”, create and approve their standard, stand out in the market, creates such a number of heterogeneous interfaces that there can be no practical connection of programs.
')
It is very appropriate to recall the concept of service-oriented architecture, SOA. According to it, each program, in fact, a service, has a standard interface, ideally also compatible with existing ones. This approach allows the reuse of components, allows for automated external testing of services. And it is important that in SOA implementation details are hidden - for example, a service can be developed on a more specific task in a programming language.

This approach is more complex and costly to develop, but the flexibility and scalability balance many of these drawbacks. Creating a documented API at a very early stage opens the door to the world for your application: its developers, and not yours, can integrate it with other people's programs, which is why everybody wins.

The more standard protocols and file formats are, the more convenience you bring to end users and your colleagues. The more your program can interact with other systems, the more freedom you will open to users.

In such conditions, among them are their “Kulibins”, which can bring problems. For example, you can remember Gdrive - a virtual Internet disk in which the storage is organized on the basis of the mail service GMail. Obviously, such use of the postal service is to his detriment. Or here's another thing: the IMAP interface in Gmail used to help me quite well to back up local mail in Google mailboxes, at the same time automatically indexing them. I did this using Outlook, simply by copying mail from an account to an account, and then setting up a transfer. Now the “hole” with a massive apload has been closed.

It is very important to find a partner right away who, at the zero point, would pick up your API and participate in its design and, maybe, implementation. This is the only way to “hear” users, and not think out what they need for them.

A big mistake is to develop an API based on the “as long as it was” principle. Without documentation, without uniformity in application, without a single logic that combines various options for its use, without an integrated architecture, the benefits of the service will be very conditional. As negative examples, we can recall omgash CORBA and maykrosoftovsky COM - rather poorly developed technologies for connecting heterogeneous systems. The development of the CORBA specification involved a dozen companies of the first echelon, but it turned out what happened: in my opinion, no sane programmer of his own free will choose this concept today. And COM has a rather narrow application for linking programs in the MS Windows environment, although no one has prevented it from developing from the very beginning to be more universal.

In the Unix world, for the interaction of console programs there is a technology of pipes (pipe), which I already wrote about earlier. The output of one program is directed to the input of another, and on the conscience of the “architect” of such bundles - to dock them correctly with each other. It turns out something like a designer, to collect from which something useful to the specialist’s hands, even without understanding how each of the bricks works. The concept of pipelines is rather primitive, but it is ideal for a wide range of tasks in a narrow subject area. When trying to shift it to everything, problems arise because the wrong “tool” is chosen. Microsoft, for example, added objectivity to powershell in its implementation of the pipes, which could potentially make them super flexible. But simple solutions, as they say, "rule". And where is this powershell now ...

In conclusion, I want to return to the beginning: create programs with open interfaces, think about it from the very beginning of their development. Creating a program that operates in its own formats and does not know how to communicate with its own kind is the last century.

" Previously: the rule of clarity

Continued: the rule of separation "