もう一度モジュール性について

Raufが書いたように 、モジュール性には多くの利点があります。 ソフトウェア開発のコンテキストでの「正しい」モジュール性を見てみましょう。 例では、プログラミング言語の実装に執着しないように、人間とプログラミング言語に特に干渉しましたが、読者にこれを彼の言語で実装する方が良い方法について考える機会を与えました。 私自身が最大限の柔軟性とモジュール性の支持者であるという事実にもかかわらず、この記事では、ここでもバストが存在する可能性があることを示します。 いずれにせよ、選択は開発者にかかっています。 開発者はこの選択に対して非常に大きな責任を負います。 何を選択しますか？ モノリスを作り、数年でそのサポートで自殺しますか、それとも可能な限り柔軟にし、決して使い物にならない抽象化に雇用主のお金を費やしますか？







モジュール化により、コードを自由に再利用できます。 どのくらい正確に、おそらく例を検討する価値があります。 アプリケーションは、特定のFTPサーバーにログインし、内部データ（マップ、製品リスト、アドレスデータベースなど）の更新を取得できる必要があります。



最初の例：

アプリケーションコードで、次のコンテンツの手順を設定します：接続、パスワードの転送、フォルダーへの移動、ファイルの取得。 すべてが非常にシンプルで明確です。



もう少し複雑な2番目の例：

ファイルへのパス、ホスト、ポート、パスワード、パスを個別に作成します。 次のようなクラスを使用します。



__(_, _(, , , ).())







ここで、クラス内のコードはやや複雑ですが、その使用はやや単純化されていますよね？



3番目の、さらに複雑な例：

次のように使用する接続クラスを作成します。



({})







異なる接続の構成は異なる場合があります。 例：

{protocol: ftp, port: 224, user: vasia, password: secret}





または

[proto->http; domain->example.com; file->foo/bar/1.zip]







3番目の例は、初心者のためにすでに屋根をはがしているように見えます。ここでは、各プロトコルにドライバーを実装する必要がありますが、いつでも新しいプロトコルにドライバーを追加できます（webdav、ssh、zeroconf、smbなど）。クライアントコードの変更。



さらに柔軟性を高め、サブモジュールをサブサブサブモジュールに分割すると、次のようになります。

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));







屋根を長期間失う可能性がさらに高い柔軟性に苦しむまでは、要約する価値があると思います。



最後の例では、ほぼ最大限の柔軟性（またはモジュール性）があります。これは、ネットワークからファイルを保存するときにほとんどすべてのアプリケーションコンテキストで使用できますが、最初の例は実装がはるかに簡単で高速です。 最終的に、すべてはタスクに依存します。 ユニバーサルライブラリを作成する場合は、ローカルファイルシステム（drv = LocaFileSystem）をラップすることもできますが、小さなアプリケーションのデータを更新するだけの場合は、最初の例が非常に適しています。



結論： 特効薬は存在しないため、妥協点を探す必要があります 。