問題タブ [design-principles]

特定の言語ではなく、一般的な OOP に関する質問があります。私は単純なアプリケーション (Java で) を試していて、実際のシナリオのようにモデル化しようとしていました。リファクタリング中に、1 つのメンバーとオーバーライドされた equals と hashcode を持つ単純なオブジェクトを思いついたことに気付きました。

私の質問は....そのようなオブジェクトを持つのは悪い習慣ですか（ブログなどへの参照は大歓迎です）

リレーショナル データベースの設計では、設計プロセスをガイドする通常の形式があります。neo4j のようなグラフ データベースの設計に適用される同様の原則はありますか?

特に、問題の粒度に戸惑っています。ほとんどの属性が頂点に格納されるグラフ データベースを設計することも (連絡先には属性名、生年月日などがあります)、ほとんどのデータを関係に格納することもできます (接続実際の情報を保持している別の頂点への「名前」関係との接触) または両方を行うことができます (もちろん、一貫性の問題が発生しますが、取得時間が短縮される可能性があります)。

これらの問題は、私が SQL 設計を始めたときの初心者の質問に似ており、問題の多くは経験を積むことによってのみ解決できました。それでも、このトピックの基本について書かれた実用的な本を推薦してもらえますか、それとも一般的な原則がどこにあるかを教えてもらえますか?

インターフェイス、インターフェイス クライアント、および継承をパッケージ化する方法に関して、1 つの問題に遭遇しました。つまり、以下の本で著者は、Light よりも Switch と一緒にコンポーネントとして展開するのに Switachable の方が適していると述べています。

私が理解したいのは、その背後にある理由 (Switch と Switchable の両方が、Switchable と Light ではなく、1 つのコンポーネントにパッケージ化されている) と、可能であれば例です。

両方のシナリオが成り立つ場合もあると思います。その設計に反する例として、IStream と FileStream が 1 つのコンポーネントにあり、ISream クライアントが別のコンポーネントにあるというものがあります。

以下は、C# ch 33、p497 の unclebob のアジャイルからのものです。

Java Webアプリケーションでいくつかのサービスレイヤークラスをリファクタリングした後、私は、単一責任原則（SRP）の順守をやめ、コードの保守性と可読性を維持することが合理的であると自問していました。今、私はこの問題に関するあなたの経験についてあなたに尋ねています。

例：

次のことを行うUserManagerクラスを想定します。

1. データベースからユーザーを検索します
2. 新しいユーザーを作成します
3. 既存のユーザーを操作します

ケースA：これら3つの責任はすべて、タスクを実行するいくつかの方法で構成されています。

→3つのクラスに分けられるのは明らかだろう。

ケースB：これら3つの責任はすべて、1つの方法のみで構成されています。

→この場合、あなたは何を提案しますか？これを3つの小さなクラスに分割するか、UserManagerクラスに残す必要がありますか？

同様の質問

• 保護されているのではなく、いつプライベートメソッドを作成しますか？
• プライベートメソッドまたは保護されたメソッドを使用するのが最適ですか？
• フィールドとメソッドを保護する代わりにプライベートを使用する理由

私の質問

多くの人々は、保護されたメソッドは、使用する理由がある場合にのみ使用する必要があることに同意しています。テスト駆動開発モデルはどのようにこれに組み込まれますか？private（特に偽造オブジェクトに関して。）TDD、現在はBDDの大ファンであり、C＃開発者である友人がいます。彼は、このキーワードをほとんど使用しないと言っていました。彼がそれを言った後、私はそれをフィールドに使い続けましたが、私のすべてのメソッドをデフォルトに設定し始めましたprotected。StackOverflowの一部の人々はprotected、デフォルトで使用する必要があることに同意しています。この質問について検討していただけませんか。protectedデフォルトで使用する最良の理由は何ですか（上記のスレッドはそうしない理由を説明しているため）？

編集：Odedのコメントにprotectedよると、デフォルトでOpen-Closed Principle（クラスは拡張のために開かれ、変更のために閉じられる必要があります）を使用するのはどうですか？

メソッドの理想的なサイズと単一責任の原則について読んだ後、自分のコードをいくつか見ていきます。私は自分のものの多く (>90%) を小さな管理しやすいメソッドに分割できると感じていますが、その後、データまたはフォームの検証に取りかかります。それはいつも本当に大きくて肥大しているように見えます。入れ子になった if ステートメントを使用してデータを検証し、各レベルでエラーや問題を見つけようとする傾向があります。しかし、6 レベル、8 レベル、10 レベル以上の検証を取得し始めると、非常に面倒です。しかし、それをより効果的に分割する方法がわかりません。

私が面倒だと思うが、それを改善する方法がわからないものの例を以下に示します。各レベルには固有のアクションが関連付けられており、すべての条件が true に戻った場合にのみ全体が戻ることができますがtrue、特に 1 か月ほど後にプログラムに戻った後では、これを読むのは困難です。

カードシャッフルを書こうとしていますが、カードをシャッフルしたい方法を知っています。しかし、私はそれを書くための最良のオブジェクト指向の方法を失っています。

かなり一般的な方法は次のとおりです。

• それぞれに 0 から 2,147,483,647 の間のランダムな数値を割り当てます
• 重複するキー値がある場合 (ほとんどありません)、デッキを捨てて、最初からやり直してください。
• カードをセットで収納
• カードのキー値ごとにセットを並べ替える

私の問題は、これを記述する最善の OOP の方法にあります。Card最初に、スーツの値、数値、およびランダムなキーの値を含む というオブジェクトを思いつきました。Deck次に、 a を拡張したという名前のクラスをHashSet用意し、各カードを に格納してHashSetから、キー値で並べ替えます。私が苦労したのは、Cardそもそも 52 個のオブジェクトを「生成」する最も効率的な方法と、セットの順序付け方法です。インターフェイス「SortedSet」を実装しますか?実装する場合、コンパレータをどのように記述しますか?

OOPの設計慣行に基づいた非常に幅広い質問ですが、これが本当にスムーズでオブジェクトベースのソリューションであることを望みます。

乾杯、

ティム。

編集：

みんな助けてくれてありがとう。私の解決策は次のとおりです。

• 4 つのスーツと 13 の可能な値を含む 2 つの Enum (CardValues、CardSuits)
• コンストラクタ引数として CardValue と CardSuit を取る Card クラス。
• TreeMap を拡張する Deck クラス

新しいデッキが作成されシャッフルされると、CardSuit Enum と作成されたカードをループし、そのループ内で CardValue Enum を調べます。これでカードが作成され、次にランダムなキーを生成して TreeMap に配置します。

キーが繰り返される可能性は常にわずかにあるため、最終的なデッキ サイズが 52 でない場合は、新しい InvalidDeckException をスローします。

提案をありがとう、私はこの解決策にとても満足しています.

私は DDD の初心者で、概念に関するいくつかの記事を読んだことがあります。知識が不足している場合はご容赦ください。この例が集約ルートでどのようにモデル化されるべきかについて興味があります。

基本は次のとおりです。従業員、会議、およびコメントがあります。各従業員は、コメントを作成できる会議に参加できます。コメントは、従業員と会議に従って追跡されます。すべての会議と従業員には一意の識別子があります。

従業員に関係なく、会議のすべてのコメントを表示したい場合、最初にその会議に属するすべての従業員を取得してから、コメントを並べ替えて、会議 ID に一致するものだけを表示する必要がありますか?

従業員のリストが必要な場合、それを取得するために会議を通過する必要がないことは確かであるため、会議を集約ルートにすることはできません。それぞれが集約ルートかもしれませんが、コメントは実際には従業員の外では意味がありません。このシナリオへのより良いアプローチ方法についてのアイデアを探しています。

助けてくれてありがとう。

少し従来の（さびた場合）プログラミングのバックグラウンドから来て、私はWebサイトの「ステートレス」な性質を理解するのに忙しいです。それはかなりの考え方の変化です！

私はチームのために小さなWebサイトを作成しました。このサイトでは、日々の仕事のいくつかの側面を追跡するために社内で使用しています。サイトは機能的です、私は何とか思いついたもの、何とか何とか何とかをかなり誇りに思っています。

しかし、私はどこかでそれを悪い方法でやったかもしれないことを示唆する何かを読みました。特に、チームのWebサイトの中央ページがほとんどの作業を行います。それはあなたがどこから来たのかをチェックし、次にいくつかの作業を実行するために「切り替え」（データベースにいくつかの変更を加えます）、そして再びページをレンダリングします。

多くの場合、ページは単に自分自身を呼び出します！私がしているのは、テーブルを表示することです。各行の最後の列には、一連のhtmlフォームがあります。各フォームには、送信ボタンと少なくとも1つの非表示フィールドがあります。「送信」ボタンには、「削除」、「変更」、「アーカイブ」などの名前/値があります。

その場合$_POST['submit'] == "delete"、非表示フィールドで識別される行に対してその関数を実行します。「アーカイブ」のvis。変更の場合、新しいページを開き、デフォルト値でフォームを表示します。ユーザーがフォームを送信すると、メインのPHPページが再度呼び出され、テーブルが表示される前にSQL更新が行われます。

したがって、メインページの先頭近くにある大きな（そして成長している）ケース構造は、ログインボタンを含め、ほとんどの作業を実行します。

このように整理されているように見えますが、2つの質問があります。

1. ユーザーが[戻る]を押したときに[フォームデータを再送信]プロンプトを削除する方法はありますか？このWebサイトでは、ほとんどの場合、戻るボタンはあまり意味がありませんが、ここでは人間を扱っています。他の人がログアウトボタンなどについて同様の質問を投稿しているのに気づきましたが、これまでに見つけた答えは私にはほとんどまたはまったく意味がありません。

2. この悪いプログラミング慣行、特にPHP-calls-itself-from-a-form-actionの概念全体は....？

お時間をいただきありがとうございます！

Python では、定義するクラスの外から任意の属性を割り当てることができます。

ここでの基本的なメカニズムは__dict__、すべての属性の辞書を維持する属性です。

私たちは皆、内部の仕組みをクライアント コードに公開しないように言われましたが、新しいデータを添付することはカプセル化とはまったく関係ありませんよね? このイディオムは Python コードで一般的ですか?

つまり…</h2>

それぞれに、、、などのTweet標準フィールドがあります。 ユーザーのつぶやきリストを返すときに、このユーザーがつぶやきを「お気に入り」に設定しているかどうかを表示します。idtextowner

明らかに、これを取得is_favoriteするには、多対多の関係を照会する必要がありますuser。現在のユーザーに対応するオブジェクトを事前に入力
しても問題ありませんか?Tweetis_favorite

確かにメソッドを公開できましたが、テンプレート内から引数を使用してメソッドを呼び出すことを許可しないDjango テンプレート言語のis_favorite_for(user)制限にぶつかっています。また、テンプレートがメソッドを呼び出すべきではないと思います。

---

これで問題なく動作することはわかっていますが、オープン ソース プロジェクトでそのようなことを行うと、他の開発者が私を軽蔑するようになるのではないかと考えています。

サイドノート：

私は、動的型がごく最近導入された C#/.NET のバックグラウンドから来ており、いくつかのニッチな領域 (相互運用性、IoC フレームワーク、REST クライアント フレームワークなど) を除いて広く適応されていません。