K.Maebashi's BBS 投稿フォーム

ハンドル名
件名
Link

>面白そうなので勝手に考えてみました。
>初期の設計として私なら以下のように考えます。
>
>>Shapeにdraw()を付けたら、その時はうまくいったとして。
>>
>>Q1-1)機能拡張でShapeをグループ化できるようにしたとき、ShapeGroupクラスは
>>　どこに位置づけるべきか?
>>
>>Q1-2)機能拡張で「補助線」機能を付けた。補助線は、描画中にだけ使用する機能で、
>>　後工程に回らないからデータとしてファイルに保存しない。
>>
>>A1-1(前橋版)
>>ShapeGroupをShapeのサブクラスにして、draw()をオーバーライドしてその
>>グループに含まれているShapeのdraw()メソッドを再帰的に呼んでやれば
>>描画はできますが、それはやっぱりアレなのでShapeのスーパークラスとして
>>Visibleとかの抽象クラス(またはインタフェース)を作り、ShapeGroupとShapeは
>>そのサブクラスかなあ。
>>たとえば「color」というフィールドは、ShapeGroupには要らないだろうし。
>
>これは、私も(ぱ)さんと同様にします。
>つまり、ShapeGroupとShapeを共にVisibleから継承させて、
>ShapeGroupにVisibleのリストを持たせます。
>そうすればCompositeパターンになり、描画するときは、
>トップからつながってるShapeを全て描画できます。
>
>>A1-2(前橋版)
>>補助線がShapeのコレクションに入らないとすれば、完全に別扱いかなあ。
>>もちろんVisibleを導入し、Visibleのコレクションを作って、Shapeは
>>ShapeコレクションとVisibleコレクションの両方から参照される、という
>>構造でもいいけど、両方のコレクションをメンテするのも面倒だし。
>
>Visibleのサブクラスとして補助線クラス(AuxLine)を追加します。
>AuxLineには、Visibleを集約させて(持たせて)、実際はShapeクラスを
>持ちます。必要な機能をShapeから委譲させます。
>
>結局、新たなクラスをShapeのサブクラスにするのは、
>結合度が強すぎてガチガチになるので、
>ゆるやかな結合で設計しておいた方が良いのかと思います。
>これだけの情報だと情報量が少ないですが、
>もっとうまい設計があったら教えて欲しいです。
>
>>>Q2.案件Ｃ（あるいはＡ”）では「ダチョウ」「ペンギン」を扱う必要が生じた。
>>
>>具体例が思いつきませんが、「描画されないShape」ですよね。
>>
>>void draw() {}
>
>ダチョウ、ペンギンを例外にするのは良くないので、
>上記の実装なら同一扱いできるので良いと思います。
>もしくは、間違ってfly()させちゃいけないのなら
>例外を投げるのもありかなと思います。
>

spamよけのため、ここに「ほげぴよ」と入力してください。

削除パスワード : クリック！