Once again about modularity

Modularity, as Rauf wrote , carries many advantages. Let's look at the “right” modularity in the context of program development. In the examples, I deliberately interfered with human and programmer languages ​​in order not to become attached to the implementation of programming languages, but to give the reader an opportunity to think about how this can be better implemented 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 overkill. The choice in any case remains for the developer. And the developer is very responsible for this choice. What to choose? Make a monolith, and after 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 worth considering an example. The application must be able to log in to a specific FTP server and pick up the update of internal data (maps, product list, address database, etc.).
')
First example:
in the application code, we place the instructions for the following content: connect, transfer the password, go to the folder, pick up the file. Everything is extremely simple and clear.

The second example is somewhat more complicated:
We create a separate class to which we will transfer 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 simpler, isn't it?

Example three, even more complicated:
create a connection class that will be used 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 looks like the third example should already break the roof of newbies, because here you have to implement a driver for each protocol, but at any moment we can add a driver to a new protocol, for example webdav, ssh, zeroconf, smb, etc., which will allow us to do the minimum changes in client code.

If we go in the direction of even greater flexibility and divide submodules into sub sub sub modules, we get the following:
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));

While I did not suffer for even more flexibility, from which you can lose the roof for a long time, I think it is worth summing up.

In the last example, we have almost maximum flexibility (or modularity), which we can use in almost any application context, if we are talking about 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 create a universal library, you can wrap up the local file system (drv = LocaFileSystem), but if in your small application you just need to update the data, then the first example is fine.

Conclusion: the silver bullet does not exist, and therefore will have to look for a middle ground .