オブジェクト指向について への返答

投稿で使用できる特殊コードの説明。(別タブで開きます。)
本名は入力しないようにしましょう。
投稿した後で削除するときに使うパスワードです。返答があった後は削除できません。
返答する人が目安にします。相手が小学生か社会人かで返答の仕方も変わります。
最初の投稿が質問の場合、質問者が解決時にチェックしてください。(以降も追加書き込み・返信は可能です。)
※「過去ログ」について書くときはその過去ログのURLも書いてください。

以下の返答は逆順(新しい順)に並んでいます。

投稿者 たかくん  (社会人) 投稿日時 2011/12/3 23:39:56
ラオシスさん、どうもです。
るきおさんのオブジェクト指向の解説を見ました。
現実世界の物を対象にするというのは解りやすかったです。
やはり僕は考えすぎてて実態の無い抽象的な事を概念として実装としようとしていたから
無理がでたのだと解りました。
しかし最初のオブジェクト設計の段階でクラスを抽出する場面は現実のソフトウェア開発では
SEは大変でしょうね、クラス設計を間違えたらプロジェクト全体が迷走することになりますからね。
もっと考え方を楽にしないといけませんね。
プログラム作りの中でしっかり練習していきます。
ありがとうございました。
るきおさんにもありがとうです。
投稿者 ラオシス  (中学生) 投稿日時 2011/12/3 20:23:01
追記です。
タグにオブジェクト指向を追加しておきました。
すでにご存じかとは思いますがクリックすればオブジェクト指向のタグが付いているスレが表示されます
るきおさんがオブジェクト指向について解説されているスレもありますので、それもご参考にされては?

メソッドとオブジェクト指向について?
http://rucio.cloudapp.net/ThreadDetail.aspx?ThreadId=293

何度も言いますが、物として考えるので現実世界を想像しながらやるとできるかもしれませんね。
投稿者 ラオシス  (中学生) 投稿日時 2011/12/3 19:48:21
GUI・・・描画対象のフォーム
Game・・ゲームを制御するクラス
と考えてよろしいですか?

>オブジェクト指向は各クラスが独立していないといけないし連携しててはおかしいのです。
今この文に気づきましたが、連携できないと、何もできなくなります。
言うならば海の中の孤島です。

>もちろんGameクラスでGUIクラスの部品をいじる事はしません。
それでしたらGUIクラスでイベントを発生させ、Gameクラスで操作するという形になるのでしょうか。
そうなると逆に複雑になるような気がします。処理はGameクラスに依頼するという考え方がいいと思います。自分で依頼したのに結局自分がするという風になってしまいますから。

>クラス分けという作業は「物」といしうオブジェクトを対象にするほうが自然なのでしょうか..
本来オブジェクト指向は、物として考えて人間にわかりやすくするものなので・・・そのように悩む必要もないと思います。やっていると少しずつ分かってくると思いますよ。極端に言えば動けばそれでいいので。

そういえば早起きですね。羨ましいです・・
投稿者 たかくん  (社会人) 投稿日時 2011/12/3 05:37:51
おはようございます。
ラオシスさんありがとうございます。
これは概念の問題なので正解や不正解もないのですがみなさんならどうしますか?
という質問です。
下記のコードはゲーム講座の第3回キャラクターのクラス化の一部です。
Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick

         'いったん全体を黒で塗りつぶす
         mainGraphics.Clear(Color.Black)

         '登録されているすべてのUnitに対して、MoveとDrawを呼び出す。
         For Each unit As Unit In Units
             If unit.IsAlive Then
                 unit.Move() 'unitの座標更新
                 unit.Draw(mainGraphics) 'unitの描画(この時点では画面には反映されない)
             End If
         Next

         '最新の状態を画面に描画する。
         Me.Invalidate()
     End Sub

たとえば上記のコードを空のGameクラスなる物を作ってメソッド化してフォームクラスと切り離すという事を考えてみて下さい。
フォームクラスではオペレーションクラスなのでただ呼び出すだけです。
もちろんGameクラスでGUIクラスの部品をいじる事はしません。
ラオシスさんならどうします?

Public Class GUI
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Game.Start()
    End Sub
End Class

本当ならこんな事普通はしませんが僕は今「クラスの独立」をテーマにオブジェクト指向を勉強しています。
多分、Gameクラスというのは制御であって動的かつ抽象的なのでこれをクラスにする事自体が不自然なのかもしれませんけどね。
やはり無理が生じるというのは概念自体がおかしいという事なのでしょうか...
クラス分けという作業は「物」といしうオブジェクトを対象にするほうが自然なのでしょうか...
あー、考えれば考えるほどパニックになってきました。
誰かお助けてください。
ラオシスさん、僕の言ってる事解ってもらえました?
投稿者 ラオシス  (中学生) 投稿日時 2011/12/3 00:27:48
文から察すると、それでいいような気もしますが^^;
ゲームを操作するクラスとフォームの連携がうまくいっていないということでしょうか?

>オブジェクト指向は各クラスが独立していないといけないし連携しててはおかしいのです。
>なので独立がかなり難しくなってしまったため頓挫してしまいました

具体例を提示していただけるとありがたいです。
投稿者 たかくん  (社会人) 投稿日時 2011/12/2 20:57:29
今晩は、オブジェクト指向について質問です。
「ゲーム」で限定しての話ですがゲーム全体を制御するクラスはフォームクラスにするのが理想
なのでしょうか?
僕はあるゲームを作る時にフォームクラスをGUIクラスと設定したためにオペレーション専用のクラスになってしまいました。
ここでゲームのメイン制御をするのはおかしいので別でゲームクラスを設定しました。
するとフォームクラスではオペレーションだけなので
Game.Initialize()とかGame.Start()とかの呼び出し専用になってしまったためゲームクラスでのゲームの制御がかなり難しくなったのです。
オブジェクト指向は各クラスが独立していないといけないし連携しててはおかしいのです。
なので独立がかなり難しくなってしまったため頓挫してしまいました。
やはりゲームの制御はフォームでやるのがいいのでしょうか?
よろしくお願いします。