Once again about modularity

Modularity, as Rauf wrote , has many advantages. Let's look at the “right” modularity in the context of software development. In the examples, I specifically interfered with the human and programming languages, so as not to become attached to the implementation of programming languages, but to give the reader an opportunity to think about how it is better to implement this in his language. In spite of the fact that I myself am a supporter of maximum flexibility and modularity, in the article I will show that even here there can be a bust. In any case, the choice rests with the developer. And the developer has a very big responsibility for this choice. What to choose? Make a monolith, and in a couple of years kill yourself on its support, or make it as flexible as possible and spend the employer's money on abstractions that will never come in handy?



Modularity gives us the freedom to reuse code. How exactly, perhaps it is worth considering an example. The application must be able to log into a specific FTP server and pick up the update of internal data (maps, product list, address database, etc.).

The first example:
in the application code, we set up the following instructions: connect, transfer the password, go to the folder, pick up the file. Everything is extremely simple and clear.

An example of the second, somewhat more complicated:
We create a separate class to which we will pass, the host, port, password and path to the file. We will use the class like this:

записать_в_файл(локальный_путь, новое_соединение(хост, порт, пароль, путь).закачать())

Here, the code inside the class is somewhat more complicated, but its use is somewhat simplified, isn't it?

An example of the third, even more complex:
create a connection class, which we will use like this: The

Соединение({конфигурация})

configuration for different connections may be different. Examples:
{protocol: ftp, port: 224, user: vasia, password: secret}
or
[proto->http; domain->example.com; file->foo/bar/1.zip]

It seems that the third example should already tear down the roof for beginners, because here we will have to implement a driver for each protocol, but at any time we can add a driver to a new protocol, for example webdav, ssh, zeroconf, smb, etc., which will allow we do with minimal changes to the client code.

If we go to the direction of even greater flexibility and divide the submodules into sub-sub-submodules, the following is obtained: Until I suffered an even greater flexibility from which you can lose the roof for a long time, I think it’s worth summing up.
c = Connector;
drv = SMTPDriver;
auth = Authenticator;
auth->setCrypt('sha1');
auth->setUser(Application->getCurrentUser());
drv->setAuth(auth);
c->setDriver(drv);
c->connect()->authenticate() OR throw Error;
path = smtpPathDriver('letter:459;attachmend-cid:file.zip');
writeFile('local/path/to/file.zip',c->getFile(path));



In the last example, we have almost maximum flexibility (or modularity), which we can use in almost any application context when it comes to saving a file from the network, but the first example is much simpler and faster to implement. In the end, it all depends on your tasks. If you are creating a universal library, you can also wrap the local file system (drv = LocaFileSystem), but if you just need to update the data in your small application, then the first example is quite suitable.

Conclusion: the silver bullet does not exist, which means that you have to look for a middle ground .