I have some Java programs, now I want to find out whether it is modular or not, if it is modular then up to what extent, because modularity can never be binary term i.e. 0 or 1. How do I decide that particular code is modular upto this much extent. I want to know how to make code much more modular?
41840 次
10 に答える
44
モジュール性のいくつかのベンチマーク：
- 特定のタスクを実行するために、同様のコードを何回書き直していますか？
- プログラムの一部を変更する場合、コードをどのくらいリファクタリングする必要がありますか？
- ファイルは小さく、ナビゲートしやすいですか？
- アプリケーションモジュールは、必要に応じて、適切に独立して実行されていますか？
- あなたのコードは最小限に悲惨ですか？関数または変数を1つだけ削除すると、すべての地獄の崩壊が失われますか？クラスの名前を変更すると、20回のエラーが発生しますか？（これを調べるために、アプリケーション内のすべてのホップのトレースを保持するスタッキングメカニズムを実装できます）
- コードは自然言語の使用法にどれくらい近いですか？（つまり、モジュールとそのサブコンポーネントは、正味のソースファイルサイズをあまり気にすることなく、より現実的なオブジェクトを表します）。
その他のアイデアについては、モジュール性に関するこの宣伝文とソフトウェア品質に関するこの宣伝文をチェックしてください。
コードをよりモジュール化することについての懸念については、最初に上記の質問を自問し、それらに対する具体的な回答を取得してから、これを確認する必要があります。
基本的な哲学は、アプリケーションを可能な限り小さなコードフラグメントに分割し、理解しやすくアクセスしやすい多数のディレクトリレイアウトにきちんと配置することです。
アプリケーションの各メソッドは、必要な処理の最小量を超えてはなりません。これらのメソッドをますます多くのマクロレベルのメソッドに組み合わせると、アプリケーションに戻るはずです。
于 2009-09-18T12:29:38.380 に答える
26
キーポイントは
- 関心事の分離
- 凝集
- カプセル化（インターフェース経由で通信）
- 代替性
- 再利用性
このようなモジュール システムの良い例は、ディスク ブレーキやカー ステレオなどの標準的な自動車部品です。車を作るとき、カーステレオをゼロから作りたくないでしょう。また、ブレーキ システムがカー ステレオに影響を与えることも、カー ステレオがブレーキ システムに影響を与えることも望ましくありません。
「特定のコードがこれほどモジュール化されていると判断するにはどうすればよいですか」という質問に答えるために、モジュール性をテストするための質問を作成できます。アプリケーションの他の部分に影響を与えることなく、モジュールを別のものに簡単に置き換えることができますか?
XML パーサーは別の例です。DOM インターフェースを取得したら、その下で使用される XML パーサーの実装 (Apache Xerces や JAXP など) は気にしません。
Java では、別の質問として、 sを介してすべての機能にアクセスできますinterfaceか? インターフェイスは、低カップリングをほとんど処理します。
また、システム内の各モジュールを 1 文で説明できますか? たとえば、カーステレオは音楽やラジオを再生します。ディスクブレーキは車両を安全に減速します。
(これはコンポーネント駆動開発とは何ですか?に書いたものです)
ウィキペディアによると、コンポーネント ベースの開発はコンポーネント ベースのソフトウェア エンジニアリング (CBSE)の別名です。
[それは] ソフトウェア エンジニアリングの一分野であり、その優先事項は、特定のソフトウェア システム全体で利用可能な幅広い機能に関する関心の分離です。
これはやや曖昧なので、詳細を見てみましょう。
個々のコンポーネントは、一連の関連する機能 (またはデータ) をカプセル化するソフトウェア パッケージまたはモジュールです。
すべてのシステム プロセスは個別のコンポーネントに配置されるため、各コンポーネント内のすべてのデータと関数は (クラスの内容と同様に) 意味的に関連付けられます。この原則のために、コンポーネントはモジュラーでまとまりがあるとよく言われます 。
したがって、この定義によれば、コンポーネントは、1 つのことだけを適切に実行する限り、何であってもかまいません。
システム全体の調整に関して、コンポーネントはインターフェースを介して相互に通信します。[...] この原則により、カプセル化されたコンポーネントと呼ばれます。
したがって、これは、優れた API や SOA がどのように見えるべきかという私たちの考えにますます似ているように聞こえます。
提供されるインターフェースはロリポップで表され、必要なインターフェースは UML のコンポーネントの外縁に取り付けられたオープン ソケット シンボルで表されます。
コンポーネントのもう 1 つの重要な属性は、それらが 代用可能であることです。これにより、最初のコンポーネントの要件 (インターフェイスを介して表現される) が後継コンポーネントによって満たされる場合、コンポーネントを (設計時または実行時に) 別のコンポーネントに置き換えることができます。
再利用性は、高品質のソフトウェア コンポーネントの重要な特性です。ソフトウェア コンポーネントは、さまざまなプログラムで再利用できるように設計および実装する必要があります。
コンポーネントをコンポーネントにするのは、代替可能性と再利用可能性です。では、これとオブジェクト指向プログラミングの違いは何でしょう?
オブジェクト指向プログラミング (OOP) の考え方は、ソフトウェアが表す実際のオブジェクトまたは想像上のオブジェクトのメンタル モデルに従ってソフトウェアを作成する必要があるというものです。[...]
対照的に、コンポーネントベースのソフトウェアエンジニアリングは、そのような仮定を行わず、代わりに、電子工学や機械工学の分野と同じように、既製のコンポーネントを接着してソフトウェアを開発する必要があると述べています。
于 2009-09-18T12:32:25.790 に答える
3
コードをよりモジュール化する方法に関する特定の質問に答えるには、いくつかのアプローチがあります。
モジュール化に最適なツールの 1 つは、コードの再利用を見つけることです。コードがまったく同じ (または非常に類似した) ことを複数の場所で実行していることがわかった場合、それはモジュール化するための良い候補です。
他のロジックがどのように構築されているかを知る必要なくそれらを使用するという意味で、ロジックのどの部分を独立させることができるかを決定します。これは、OO の設計で行うことと多少似ていますが、OO のようにモジュール/コンポーネントがモデル化されたオブジェクトに必ずしも対応する必要はありません。
于 2009-09-18T12:38:08.007 に答える
2
ねえ、
こちらの「ソフトウェアをカプセル化する方法 (パート 1)」を参照してください。
http://www.edmundkirwan.com/encap/overview/paper7.html
よろしく、
エド。
于 2009-09-27T16:15:15.730 に答える
1
これは 'osgi' でタグ付けされているので、OSGi 関連の視点を入れることができます。
手短に言えば、完全なスパゲッティ コードからモジュール化への移行は小さなステップで可能です。ビッグバンである必要はありません。たとえば、スパゲッティ コードでさえ、ある種のボロネーズ ロギング ライブラリに依存しているため、ある意味ではすでにモジュール化されており、その中に One Very Big Metball (申し訳ありませんが、モジュール) が含まれているだけです。
秘訣は、大きなミートボールを 1 つの小さなチャンクに分割し、次に少し大きなミートボールに分割してから再帰することです。すべてを一度に行う必要もありません。削除するものがなくなるまで、毎回少しずつ削っていきます。
OSGi に関しては、uber-jar をバンドルに入れることはまだ可能です。実際、ビットを変更せずにこれを行うことができます。その場で Manifest.MF を変更するか、それを別の JAR にラップして、マニフェストで Bundle-ClassPath: metaball.jar を指定します。
それができない場合、BND のようなツールは、必要な適切なデータを生成するのに役立ち、OSGi ランタイムに簡単にドロップできます。ただし、過度に結合されたコードや、クラスローダーをいじくり回すものには注意してください。それらはつまずきます。
于 2009-09-19T17:09:36.880 に答える
0
私があなたの質問を理解していると仮定すると、コードモジュールが機能するためには明らかに相互の依存関係が必要になるため、コードをモジュール化するのは何であるかを知りたいと思います。これが私の答えです：
システムをモジュールに分割でき、それらのモジュールを個別にテストできる場合、それはシステムがモジュール式であることを示す良い兆候です。
于 2009-09-18T12:25:44.393 に答える
0
あなたが言うように、モジュール性は二者択一ではないので、それはあなたの相対的な定義に依存します。
私は言うでしょう：あなたがその機能を実行する必要があるプログラムで与えられたメソッドを使うことができますか？それは、内部で何をしているのかを知る必要がない「ブラックボックス」ですか？答えが「いいえ」の場合、つまりメソッドがそのプログラムでのみ適切に機能する場合、それは真にモジュール式ではありません。
于 2009-09-18T12:25:59.760 に答える
0
モジュール性は、コードを開発している人に関連しています。しかし、一般的なコンセンサスは、モジュラーコードは、元のコードのほとんどを変更せずに簡単に交換できる部分を持つコードであるということだと思います。
IMHO、3つのモジュールABとCがあり、モジュールCを完全に変更または交換したい場合、それを行うのが簡単なタスクである場合は、モジュラーコードがあります。
于 2009-09-18T12:26:32.920 に答える
0
CAPなどのコード分析ツールを使用して、タイプとパッケージ間の依存関係を分析できます。これらは、モジュラーコードを開発しようとするときにしばしば問題となる循環依存関係を見つけて削除するのに役立ちます。循環依存関係がない場合は、コードを個別のjarに分割し始めることができます。
一般に、可能であればインターフェースにコーディングすることをお勧めします。これは通常、コードをより簡単にリファクタリングしたり、さまざまなコンテキストで使用したりできることを意味します。
Springなどの依存性注入フレームワークも、設計のモジュール性に役立ちます。タイプには外部構成プロセスによって依存関係が注入されるため、実装に直接依存する必要はありません。
于 2009-09-18T12:28:39.223 に答える
0
機能ごとにパッケージ化するという考え方は、コードをよりモジュール化するのに役立ちます。
Web で見られる多くの例では、最初にアプリケーションを機能ではなくレイヤーに分割します
- モデル
- データアクセス
- ユーザーインターフェース
ただし、レイヤーではなく、機能に合わせた最上位パッケージを使用してアプリケーションを分割する方がよいようです。
これは、package-by-feature を使用する Web アプリの例です。アプリケーションの実際の機能のリストとして読み取られる最上位パッケージの名前に注意してください。各パッケージには、機能に関連するすべてのアイテムが含まれていることにも注意してください。アイテムはあちこちに散らばっていません。ほとんどの場合、それらはすべて単一のパッケージ/ディレクトリにあります。
通常、このようなアプリの機能の削除は、1 つの操作 (1 つのディレクトリの削除) で実装できます。
于 2009-09-19T00:51:54.533 に答える