>>861
オセロなどはオブジェクト指向の勉強に最適ですよ。
例えば、一例として、
「ボード」「ユーザインターフェース」「AI」「ゲームの制御」
という様にクラスを分けることを考え付くでしょう。(これらクラスだとMVCパターンに適用できそうかも)
設計の初期では、我々がゲームをする気持ちになって、我々の意識下にある意味記憶の
ラベル付けしたユニットをそのままオブジェクトとすれば良いでしょう。
次に各オブジェクトにどういう「命令」を出すのかというのを決める必要があります。
「ボード」には石を動かしたり、ある座標の石の色を聞き出したり、etc..の命令が必要でしょう。
このような定義していくときに、UMLのクラス図に書き込んでいくと便利ですね。
書きながらどんな命令が必要かというのを考えるのです。
もちろんソースを書いている途中で必要になるものもあるでしょうから、柔軟な方が良いです。
一方で拡張性についても考えた方が良いでしょう。
たとえば、ユーザインターフェースとしてCUIとGUIを交換できるようにしたいというように考える
かもしれません。
そうなるとユーザインターフェースの親クラスを定義すると良いでしょう。
また、「ボード」と「ゲームの制御」がお互いに命令を出しあう関係(双方向関連)を持ってしまうかもしれません。
こういう場合はデザインパターンのオブザーバパターンを適用すると単方向にすることができます。
ところで、双方向関連がなぜいけないのかというと、クラス同士のつながりがとても強くなってしまうからです。
クラス同士が強く結び付いてしまうと再利用が難しくなって、結局一つのクラスにしてした方が良かった、
ということになりかねません。
しかし、各クラスには意味があって、分ける必要があるのですから、一つにまとめてしまうことは避けるべきです。
(これはコーディングしないと実感が湧かないと思います)

私が設計するときにはこうするだろう、と想像してみました。面倒になってきたのでこれ以上は思考放棄。