K.Maebashi's BBS 投稿フォーム
ハンドル名
件名
Link
>>Q1.案件Ｂ（あるいはＡ’と言い換えても）では「こうもり」を扱う必要が生じた。 >>基底クラスを書き換える/書き換えない？派生クラスの実装をどうする？ > >鳥とかこうもりではあんまり具体的でもないと思うので、私は、例によって >ドローツールっぽいものを考えるとします。 > >Shapeにdraw()を付けたら、その時はうまくいったとして。 > >Q1-1)機能拡張でShapeをグループ化できるようにしたとき、ShapeGroupクラスは > どこに位置づけるべきか? > >Q1-2)機能拡張で「補助線」機能を付けた。補助線は、描画中にだけ使用する機能で、 > 後工程に回らないからデータとしてファイルに保存しない。 > >A1-1(前橋版) >ShapeGroupをShapeのサブクラスにして、draw()をオーバーライドしてその >グループに含まれているShapeのdraw()メソッドを再帰的に呼んでやれば >描画はできますが、それはやっぱりアレなのでShapeのスーパークラスとして >Visibleとかの抽象クラス(またはインタフェース)を作り、ShapeGroupとShapeは >そのサブクラスかなあ。 >たとえば「color」というフィールドは、ShapeGroupには要らないだろうし。 > > Shapeのグループ is a Shape > >と言って言えないことはないけど、苦しいし。 > >A1-2(前橋版) >補助線がShapeのコレクションに入らないとすれば、完全に別扱いかなあ。 >もちろんVisibleを導入し、Visibleのコレクションを作って、Shapeは >ShapeコレクションとVisibleコレクションの両方から参照される、という >構造でもいいけど、両方のコレクションをメンテするのも面倒だし。 > >>Q2.案件Ｃ（あるいはＡ”）では「ダチョウ」「ペンギン」を扱う必要が生じた。 > >具体例が思いつきませんが、「描画されないShape」ですよね。 > >void draw() {} > >でよさそうな… > >以上、べたべたに実装よりの解答でした。 >
spamよけのため、ここに「ほげぴよ」と入力してください。
削除パスワード :
クリック！