私はいくつかのmvcフレームワークが実装する「モジュール」の概念を試してきましたが、それは良い解決策のように見えますが、TDDもありますが、私が見逃したデザインパターンのような何かがあるに違いないと思います（私は知っているだけですいくつか）、それは私が制限なしで（コードで）成長できるアプリケーションを構築することを可能にします。
何かご意見は？
編集：モジュールのもう1つの優れた点は、アプリケーションに依存しない方法でモジュールを構築できるため、再利用できることです。
質問する
588 次
1 に答える
3
「ソフトウェアエンジニアリングの事実と誤り」で、RobertL.Glassは次のように述べています。
事実15.スモールでの再利用は十分に解決された問題です。
事実16.大規模な再利用は、ほとんど解決されていない問題のままです。
事実17.大規模な再利用は、関連するシステムのファミリで最適に機能します。
つまり、モジュールを再利用できますが、非常によく似た動作をするアプリケーション間でのみ可能です。モジュールを非常に用途が広く、どのアプリケーションでも再利用できるようにするのは非常に困難です。最終的には、非常に構成可能なモジュールを作成するため、使用が非常に複雑になり、特定のアプリケーションでは役に立たないシナリオを処理するための多くのコードが含まれます。
アプリケーションごとにカスタムモジュールをコーディングすることをお勧めします。これは、各アプリケーションが必要とすることだけを実行し、それ以上は実行しません。これは、リクエストごとにコードが読み込まれるPHPのような言語では特に重要であるため、コードの量はパフォーマンスに大きな影響を与えます。
よりきめ細かい機能を再利用することは異なります。たとえば、ロギングの使用法は、アプリケーションが互いにどれほど異なっていても、アプリケーション間でかなり似ています。これが、ほとんどのフレームワークが汎用のサービススタイルのクラスで非常にうまく機能する理由です。
@A_Varからのコメントを再確認してください：
可能な機能の範囲を事前に知っていれば、クラスを再利用可能にすることができます。したがって、拡張可能である必要がある部分がわかります。これは、すべてのアプリで同様に使用される単純なクラスでは比較的簡単です。ロギングの例について説明しました。これは、Glassが「小さな再利用」と呼んでいるものです。
しかし、私たちは単純なクラスについて話しているのではありません。複雑なモジュール（複数の画面、フォーム、異なるデータベーススキーマなどを処理するための複数のクラスを考えてください）で同じことを行おうとすると、各アプリケーション。汎用モジュールには、アプリごとに個別のモジュールを作成するために必要な合計コードよりも多くのコードが必要になります。
また、ベースモジュールに変更を加えると、それを使用および拡張するすべてのアプリを再テストする必要があるため、テストには非常にコストがかかります。
結局、アプリごとに新しいモジュールを作成する手間が減り、よりきめ細かい再利用可能なコンポーネントを採用することで、できる限りの効率を得ることができます。
于 2010-10-08T07:30:45.803 に答える