12

疎結合コードの実際の利点を理解するのに苦労しています。他のさまざまなオブジェクトと連携できる柔軟なものを作成するために、なぜこれほど多くの労力を費やすのでしょうか? 何を達成する必要があるかがわかっている場合は、その目的のために特別にコーディングしてみませんか?

私にとって、これは型指定されていない変数を作成することに似ています。非常に柔軟になりますが、予期しない値が渡される可能性があるため、問題が発生する可能性があります。また、何が渡されているかを明示的に知らないため、読みにくくなります。 .

それでも、強く型付けすることは奨励されているように感じますが、疎結合は悪いです。

編集:疎結合の私の解釈がずれているか、他の人が間違った方法で読んでいると感じています。私にとっての強い結合は、クラスが別のクラスの具体的なインスタンスを参照するときです。疎結合とは、別のクラスが実装できるインターフェイスをクラスが参照する場合です。

私の質問は、クラスの具体的なインスタンス/定義を具体的に呼び出さないのはなぜですか? これは、必要な変数の型を具体的に定義することに例えられます。私は依存性注入についていくつか読んでいますが、疎結合がより良い設計であることを事実として理解しているようです。

4

9 に答える 9

15

まず、リンゴとミカンを比較しているので、これを 2 つの観点から説明してみましょう。型付けとは、値/変数に対する操作の実行方法と、それらが許可されているかどうかを指します。結合は、結合とは対照的に、ソフトウェアの一部 (または複数の部分) のアーキテクチャを指します。両者には直接の関係はまったくありません。

強い型付けと弱い型付け

強く型付けされた言語は (通常) 良いことです。なぜなら、動作が明確に定義されているからです。ウィキペディアから次の 2 つの例を取り上げます。

弱い型付け:

a = 2
b = '2'

concatenate(a, b) # Returns '22'
add(a, b)         # Returns 4

一部の言語では加算または連結に ASCII (おそらく 16 進数、8 進数など) の数値を使用する場合があるため、上記は少し混乱し、あまり明確に定義されていない可能性があります。そのため、間違いの余地がたくさんあります。aまた、元が an なのintegerか aなのかを判断するのは困難ですstring(これは重要かもしれませんが、言語はあまり気にしません)。

強く型付けされた:

a = 2
b = '2'

#concatenate(a, b)     # Type Error
#add(a, b)             # Type Error
concatenate(str(a), b) # Returns '22'
add(a, int(b))         # Returns 4

ここでわかるように、すべてがより明示的であり、変数とは何か、変数の型をいつ変更するかを知っています。

ウィキペディアは次のように述べています。

弱い型付けの利点は、コンパイラーまたはインタープリターが特定の種類の変換を暗黙的に実行するため、プログラマー側の労力が少なくて済むことです。ただし、弱点として主張されている 1 つの欠点は、弱く型付けされたプログラミング システムがコンパイル時に検出するエラーが少なく、テストが完了した後もこれらのエラーの一部が残る可能性があることです。多くの種類の暗黙的な変換をサポートする 2 つの一般的に使用される言語は C と C++ であり、これらは弱い型付けの言語であると主張されることがあります。ただし、これらの言語は、異なる型のオペランドを混在させる方法に十分な制限を課しているため、2 つの言語は厳密に型指定された言語と見なされるべきであると主張する人もいます。

強いタイピングと弱いタイピングには、どちらにも長所と短所があり、どちらも良いとも悪いとも言えません。相違点と類似点を理解することが重要です。

緩いカップリングと密なカップリング

ウィキペディアから直接

コンピューター サイエンスでは、結合または依存関係は、各プログラム モジュールが他の各モジュールに依存する程度です。

カップリングは通常、結合と対比されます。低カップリングは高凝集度と相関することが多く、逆もまた同様です。結合と結束のソフトウェア品質指標は、構造化設計の最初の開発者であり、これらの概念の初期の支持者でもあった Larry Constantine によって発明されました (SSADM も参照)。低結合は、多くの場合、適切に構成されたコンピューター システムと優れた設計の兆候であり、高い結束力と組み合わせると、高い可読性と保守性という一般的な目標をサポートします。

要するに、結合度が低いということは、コードが非常にタイトで、読みやすく、保守しやすいことを示しています。さまざまな部分が相互作用して全体を形成する大規模な API または大規模なプロジェクトを扱う場合は、高結合が優先されます。どちらも良くも悪くもありません。一部のプロジェクトは密結合する必要があります (組み込みオペレーティング システムなど)。他のものは疎結合にする必要があります。つまり、Web サイト CMS です。

うまくいけば、私はここでいくつかの光を当てました:)

于 2010-10-30T05:54:11.683 に答える
7

弱い/動的な型付けは実際には疎結合の概念の論理的な拡張であり、プログラマーが一方を優先して他方を優先しないというのは矛盾していることを指摘するのは正しい質問です。

疎結合はバズワードのようなものになり、多くのプログラマーが不必要にインターフェースや依存性注入パターンを実装したり、または多くの場合、これらのパターンの文字化けバージョンを独自に実装したりして、要件が不定形の将来変化する可能性に基づいています。これにより複雑さが増し、将来の開発者にとってコードの保守性が低下するという事実を隠すことはできません。唯一の利点は、この予期的な疎結合によって、要件の将来の変更が実装しやすくなったり、コードの再利用が促進されたりする場合です。ただし、多くの場合、要件の変更には、UI からストレージまで、システムの十分なレイヤーが含まれるため、疎結合では設計の堅牢性がまったく向上せず、特定のタイプの些細な変更がより面倒になります。

于 2014-05-15T18:28:40.860 に答える
2

強い型付けは、実行時エラーではなくコンパイル時エラーをスローすることにより、見つけにくいバグを防ぐため、優れています。

密結合コードは良くありません。「何を達成する必要があるかを知っている」と思っていても、多くの場合間違っているか、知る必要があることをまだすべて理解していないためです。

つまり、既に行ったことを後でコードの別の部分で使用できることに気付くかもしれません。次に、同じコードの 2 つの異なるバージョンを密結合することを決定する場合があります。その後、ビジネス ルールにわずかな変更を加える必要があり、密結合されたコードの 2 つの異なるセットを変更する必要があります。おそらく、両方を正しく取得できますが、せいぜい 2 倍の時間がかかります...または最悪の場合一方にバグが発生し、もう一方にはバグが発生し、しばらく検出されず、実際のピクルスに陥ります。

または、ビジネスが予想よりもはるかに急速に成長しており、一部のデータベース コンポーネントを負荷分散システムにオフロードする必要がある場合、新しいシステムを使用するために、既存のデータベース システムに緊密に結合されているすべてのものを再設計する必要があります。 .

簡単に言えば、疎結合により、ソフトウェアのスケーリング、保守、および刻々と変化する条件や要件への適応がはるかに容易になります。

編集:疎結合の私の解釈がずれているか、他の人が間違った方法で読んでいると感じています。私にとっての強い結合は、クラスが別のクラスの具体的なインスタンスを参照するときです。疎結合とは、別のクラスが実装できるインターフェイスをクラスが参照する場合です。

私の質問は、クラスの具体的なインスタンス/定義を具体的に呼び出さないのはなぜですか? これは、必要な変数の型を具体的に定義することに例えられます。私は依存性注入についていくつか読んでいますが、疎結合がより良い設計であることを事実として理解しているようです。

ここであなたの混乱が何であるかはよくわかりません。たとえば、データベースを多用するアプリケーションがあるとします。アプリケーションには、データベース クエリを実行する必要がある 100 の異なる部分があります。これで、100 の異なる場所で MySQL++ を使用できます。または、MySQL++ を呼び出す別のインターフェイスを作成して、100 の異なる場所でそのインターフェイスを参照することもできます。

顧客は、MySQL の代わりに SQL Server を使用したいと言っています。

どのシナリオが適応しやすいと思いますか? コードを 100 か所書き直すか、1 か所だけ書き直すか。

わかりました...今、おそらく100の異なる場所でそれを書き直すことはそれほど悪くないと言います.

顧客は、ある場所では MySQL を使用し、別の場所では SQL Server を使用し、さらに別の場所では Oracle を使用する必要があると言っています。

今、あなたは何をしますか?

疎結合の世界では、異なる実装を持つ同じインターフェイスをすべて共有する 3 つの別個のデータベース コンポーネントを持つことができます。密結合の世界では、100 セットの switch ステートメントが 3 つの異なるレベルの複雑さで散らばっていることになります。

于 2010-10-30T05:43:33.733 に答える
1

何を達成する必要があるかがわかっている場合は、その目的のために特別にコーディングしてみませんか。

簡単な答え:何を達成する必要があるかを正確に知ることはほとんどありません。要件が変化し、そもそもコードが疎結合であれば、適応するのは悪夢ではありません。

于 2010-10-30T05:37:04.907 に答える
1

それでも、強く型付けすることは奨励されているように感じますが、疎結合は悪いです。

強いタイピングが良い、または奨励されていると言うのは公平ではないと思います。確かに、多くの人が強く型付けされた言語を好みます。コンパイル時のチェックが付属しているためです。しかし、多くの人は弱い型付けが良いと言うでしょう。「強い」がいいと聞いたからには、「ゆるい」もいいのでは?言語の型付けシステムのメリットは、クラス設計と同様の概念の領域にさえありません。

補足:強い型付けと静的な型付けを混同しないでください

于 2010-10-30T05:55:07.337 に答える
1

強力な型付けは、通常はパフォーマンスを向上させながら、エラーを減らすのに役立ちます。コード生成ツールが変数の許容値の範囲について収集できる情報が多いほど、これらのツールが高速コードを生成するためにできることは多くなります。

型推論と機能のような特性 (perl6 など) または型クラス (haskell) と組み合わせると、強く型付けされたコードは引き続きコンパクトでエレガントになります。

于 2010-10-30T06:19:37.443 に答える
0

派生クラスにある関数で行われた変更により、基本抽象クラスのコードが変更される場合、これは完全な依存関係を示しており、密結合であることを意味します。

コードを再度作成または再コンパイルしないと、依存関係が少なくなるため、疎結合になります。

于 2012-04-10T05:17:55.090 に答える
0

密結合/疎結合 (私にとっては、オブジェクト インスタンスのインターフェイス宣言と割り当て) はLiskov Principleに関連していると思います。疎結合を使用すると、リスコフの原理のいくつかの利点が有効になります。

ただし、instanceof、キャスト、またはコピー操作が実行されるとすぐに、疎結合の使用法が疑わしくなり始めます。さらに、メソッドまたはブロック内のローカル変数の場合、意味がありません。

于 2012-09-02T12:28:17.557 に答える