The Pragmatic Programmer の書籍によると、「直交性は DRY 原則と密接に関連しています」。著者が読者に望んでいる方法でそれを理解しているかどうかはわかりません。そこで、上記の質問をします。

たとえば、クラス A とクラス B があるとします。どちらのクラスにも同様のメソッドがあります。DRYの原理を使ってクラスCを作り、クラスAとクラスBからクラスCに同様のメソッドを移動し、クラスCをAとBの親クラスに割り当てました。直交しなくなりましたか?

TransferViaSerialPortとTransferViaWirelessModuleなどの2つの異なるクラスを継承したインターフェイスがありますISendOut（つまり、この2つのクラスにこのインターフェイスを実装します）。OCPを介してデータを送信する方法と、OCPに違反しない方法のどちらかをユーザーが（UIで）選択できるようにソフトウェアを設計するにはどうすればよいですか？「SwitchCase」または「If/Else」ステートメントが必要な場合は、OCPに違反するためです。SerialPortWirelessModule

親子ビュー モデル オブジェクト構造が設定されており、親のオブザーバブルを子から更新する必要があります。私は基本的にそうするための2つのパターンを考え出しました:

1] 親プロパティの参照を子に渡し、子内からプロパティを更新します。

2] 親で子の select メソッドを作成し、親のオブザーバブルをローカルで参照します。

これらのパターンはどちらも私を真っ逆さまに送りません。1 つ目はプロパティ参照全体を子ビュー モデルにプッシュし、2 つ目は子のスコープ外で子の関数を定義します。

この操作をJavaScriptでクリーンでテスト可能な方法で実現する方法について、他のパターンの提案はありますか? それとも、多かれ少なかれこれら 2 つのオプションだけで行き詰っていますか?

の定義は次のStrategy Patternとおりです。

戦略 - アルゴリズムのファミリーを定義し、それぞれをカプセル化し、それらを交換可能にします。戦略により、アルゴリズムは、それを使用するクライアントとは独立して変更できます。

したがって、ストラテジーは機能を 2 つの部分に分けます。1 つは変更されず、もう 1 つは将来変更される可能性があります。

そして、MVC では、次のように述べています。

コントローラーはビューの戦略です

これは、コントローラが変更され、View が将来変更されない可能性があることを意味します。

まだよくわかりません。どちらもこれから変わると思います。

人々がそう言う理由を説明してください。

私はこのトピックについてたくさん検索しましたが、多くの良い (しかし異なる) 結果が得られました。一部の結果はあまり関係がなく、最終的には好みの問題のようですが、良い設計原則に従っているかどうかに興味があります.

これがあまりにも漠然とした質問である場合は、遠慮なく削除してください。

また、これは一例です。ここには、通常とは異なる方法で行うことがかなりありますが、簡単にするために、このようにしました。

コードは長いですが、それを 1 つの新しい PHP ファイルに直接コピー & ペーストして、環境で実行できるはずです。セットアップは必要ありません。

具体的な質問

• これは、例外を使用して呼び出し側で処理する正しい方法ですか?
• これには例外を使用する必要がありますか？
• スケルトンのカスタム例外は正しいですか?

コード

こちらの別ウィンドウでコピーを表示できます。ここに貼り付けます。保存して環境で実行すると、変更なしでそのまま機能するはずです。

注意: 先の長いコード

誰かが単一責任の原則の例を教えてもらえますか? 私はおそらく毎日この規則を破るのではないかと恐れているので、実際には、クラスが単一の責任を持つことが何を意味するのかを理解しようとしています。

重複の可能性:
DateTimes を Long (ティック) としてデータベースに格納する必要がありますか?

ベースの操作を実装するために、それ自体のDateTime.Ticks代わりに使用しても問題ありませんか? たとえば、データベースの列のタイプを からに変更し、値を?ではなくに格納します。DateTimeDateTimeDATETIMEBIGINT1234567891234562012-06-02 14:26:08.727

この場合、変換を処理する必要があることはわかっていますが、いくつかの長所があります。たとえば、保存する日時の範囲に制限はなく、データベースでサポートされている型 {date, datetime, smalldate} などについても心配する必要はありません。

実際には、このアプローチについて次の 2 つの分野で確認したいと思います。

1. 設計原則
2. パフォーマンスの問題

前もって感謝します。

メソッドM1を想定し、M2 強く関連する責任を負う

最初の例:

もしも

• M1andM2はクラス内で定義されますA(したがって、クラスAは非常にまとまりがあります) 。

•クラスのB使用A.M1とクラスのC使用A.M2

それから

•とクラスAの両方に結合されているBC

• の署名を変更する には、M1でのみ変更が必要ですが、では必要ありBません。C

2 番目の例:

もしも

•M1クラス内で定義されているA1(したがってBと結合されているA1)

•M2クラスで定義されているA2(したがって、Cと結合されているA2)

それから

• の署名を変更するには、M1でのみ変更が必要ですが、では必要ありBません。C

a) 私の理解では、最後の例のクラスは、最初の例のクラスよりも結合されていません! または、何か不足していますか？

b）私が知る限り、最初の例のクラスは、次の場合にのみ2番目の例のクラスよりも疎結合です。

• M1の署名を変更するには、 の署名も変更する必要があると想定していM2ますが、そう頻繁に起こるとは思いませんか?!

• または、 と の両方が同じタイプ T1 のデータM1をM2操作する場合、T1 を T2 に置き換えるには、M1とM2?!の両方を変更する必要があります。

• または、密接に関連する責任があるため、変更するM1と変更が必要になるM2可能性がはるかに高いと仮定すると（直接的または間接的に呼び出さなくても）?!M1M2M1M2

• または、密接に関連する責任があるために、一部のクラスが と の両方を必要とする可能性がはるかに高いと仮定すると(そのため、M1とを単一のクラスに持つことで結合が減少します)?!M2M1M2M1M2

c) ( withinとwithinを定義する代わりに) M1and withinを定義すると結合が減少する理由は他にありますか?M2AM1A1M2A2

注 - メンテナンスと再利用が容易なため、凝集性の高いモジュールが必要であることは承知しています。

ありがとうございました

重複の可能性：
（javax.servlet。）SingleThreadModelが非推奨になるのはなぜですか？

サーブレットコンテナは、「一般的に」、サーブレットの1つのインスタンスと、同じインスタンスの異なるスレッドを作成して、複数のリクエストを処理します。（これは非推奨のSingleThreadModelやその他の機能を使用して変更できることは知っていますが、これは通常の方法です）。

インスタンスを作成するよりもスレッドを作成する方が優れているため、この背後にある単純な理由はパフォーマンスの向上だと思いました。しかし、これが理由ではないようです。一方、インスタンスを作成することには、開発者がスレッドセーフについて心配する必要がないという利点はほとんどありません。

私は、スレッドセーフのトレードオフに関するこの決定の理由を理解しようとしています。