問題タブ [class-design]

Visual Studioでクラスデザイナをよく使用する人はいますか？

2005年のModelingPowerToysをダウンロードしましたが、これまでに見たものに感銘を受けました。MSDN Class Designerブログはしばらく更新されていないようですが、それでも非常に便利に見えます。

クラスデザイナは基本的なアプリケーションをすばやく構築する方法ですか、それとも紙で作業してからコーディングを開始する必要がありますか？

ありがとう

クラスとその関係を設計するとき、または単にペンと紙を設計するときに、どのソフトウェアを使用しますか?

DB レイヤーのクラスに静的関数しかないプロジェクトや、メンバー関数にアクセスするためにそれらのクラスをインスタンス化する必要がある他のプロジェクトを見てきました。

どちらが「より良い」で、その理由は何ですか?

大学では、数多くの設計およびUML指向のコースを受講しており、UML を使用してソフトウェア プロジェクト、特にユース ケースマッピングに利益をもたらすことができると認識していますが、それは本当に実用的なのでしょうか? 私はいくつかの共同作業用語を使用しましたが、UML は業界ではあまり使用されていないようです。プロジェクト中に時間をかけて UML 図を作成する価値はありますか? また、クラスのヘッダー ファイルを見た方が速いだけなので、クラス図は一般的に役に立たないことがわかりました。具体的には、どの図が最も役に立ちますか?

編集:私の経験は、10 未満の小さな開発者プロジェクトに限られています。

編集：多くの良い答えがあり、最も冗長ではありませんが、選択されたものが最もバランスが取れていると思います.

C＃ジェネリック以前は、IEnumerableを実装したコレクションベースを作成することで、誰もがビジネスオブジェクトのコレクションをコーディングしていました。

IE：

そして、そこからビジネスオブジェクトコレクションを導き出します。

ジェネリックリストクラスを使用して、代わりにそれを使用する人はいますか？私は2つのテクニックの妥協点を使用していることに気づきました。

これを行うのは、リストを渡すだけでなく、強く型付けされた名前が好きだからです。

あなたのアプローチは何ですか？

オブジェクト指向の方法で干し草の山の針検索を実装する場合、基本的に3つの選択肢があります。

どちらが好きですか、そしてその理由は何ですか？

3番目のオブジェクトの導入を回避するため、2番目の選択肢を好む人もいます。ただし、少なくとも「現実の世界」をモデル化することが目標である場合は、3番目のアプローチがより概念的に「正しい」と感じざるを得ません。

この例のサーチャーなどのヘルパーオブジェクトを導入することはどのような場合に正当であると思いますか。また、いつそれらを回避する必要がありますか。

どのクラス設計が優れているか、またその理由は?

また

多くの異なる方法 (モード) でシリアライズおよびデシリアライズする必要があるかなり大きなオブジェクト グラフがあります。一部のモードでは、特定のプロパティを逆シリアル化したい場合と、そうでない場合があります。将来のモードでは、プロパティのオプションが yes または no よりも多くなる可能性もあります。問題は、これらのモードをどのように実装するかです。

アプローチ A (逆シリアル化コンストラクターと ISerializable.GetObjectData を使用):

逆シリアル化コンストラクターを使用してグラフの各オブジェクト自体をシリアル化すると、逆シリアル化のさまざまなモードすべてに対して多くのスイッチが得られます。ただし、このアプローチの利点は、すべての逆シリアル化ロジックが 1 つの場所にあることです。新しいプロパティを追加する場合は、ISerializable.GetObjectData と逆シリアル化コンストラクターを変更するだけで済みます。もう 1 つの利点は、公開される可能性のある内部状態をオブジェクトが考慮できることです。最も重要な欠点は、データオブジェクト自体が可能なすべてのシリアル化モードについて知る必要があることです。新しいモードが必要な場合は、データ オブジェクトを変更する必要があります。

アプローチ B (デシリアライゼーション ファクトリ クラス/メソッド):

別のアプローチは、シリアライゼーションとデシリアライゼーションを外部で行うモードごとに、ある種のデシリアライゼーション ファクトリ クラス/メソッドを用意することです (例: GraphSerializer.SerializeObjectTypeX(ObjectTypeX objectToSerialze)。ここでの利点は、新しいモードが必要なときはいつでも新しいFactory Class/Method と Dataobject は、導入されたすべてのシリアライゼーション モードで混乱することはありません. ここでの主な欠点は、すべての異なるモードに対して同じシリアライゼーション コードを何度も書かなければならないことです. 2 つのモードが単に異なる場合1 つまたは 2 つのプロパティですが、グラフ全体の完全なロジックを再度実装する必要があるため、データ オブジェクトに新しいプロパティを追加するときは、すべてのファクトリ クラスを更新する必要があります。

したがって、この IMHO の一般的な問題に対するより良いアプローチがあるのではないかと思います。それとも .NET のベスト プラクティスでしょうか? それとも、間違った視点から全体にアプローチしているだけなのでしょうか?

私はめったに継承を使用しませんが、継承されたクラスのカプセル化を壊すと思うので、使用する場合は保護された属性を使用しません。

保護された属性を使用していますか? 何に使うの？

Webサイトのナビゲーション階層を設計しています。これはノードのツリーです。ノードはWebページを表します。

ツリー上のいくつかのノードは特別です。それらの名前が必要です。

そのようなノードは複数あります。それぞれが、異なるロゴ、スタイルシート、またはレイアウトを持つページを持つサブツリーの「ルート」です。さまざまな部門について考えてみてください。

色分けされたサブツリーを含むサイトマップhttp://img518.imageshack.us/img518/153/subtreesfe1.gif

このタイプのノードには何という名前を付ける必要がありますか？