オブジェクト指向システムの設計 [無断転載禁止]©5ch.io
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2016/05/19(木) 22:07:47.87ID:9fCVrsOw0412デフォルトの名無しさん
2016/05/22(日) 17:51:02.87ID:WwOYSBmy機能はたくさん欲しいのはわかったｗ
設計は、機能の多さとは比例しない。
棋譜データクラス（さっきから2次元配列クラスと読んでるもの）を
作ってそれらのメソッドを実装しろ。
0413デフォルトの名無しさん
2016/05/22(日) 17:52:51.72ID:sxeEi6BC1機能1クラスなんて言ってないからちゃんと読もうね。
で、俺を批判するのに頑張るよりお前の考えるクラス構成を出したほうがよっぽど評価されるぞ。
頑張れ！
0414デフォルトの名無しさん
2016/05/22(日) 17:53:50.83ID:WwOYSBmyそうしない理由を聞きたいんだが？ｗ
お前は理由もなく、設計と評して、
過剰なモジュール分割をしようとしているに過ぎない。
目的が設計になってる。
だから設計が必要だって結論になってる。
俺はこんな部分に設計はいらないと最初から言ってる。
だから設計が出ないのは当たり前。
設計というのはフレームワーク部分に使うものなんだよ。
通常の開発はフレームワークを使うから、設計はほぼ不要になる。
一体俺からなにを聞こうとしてるんだ？ 最初から無いと言ってるだろ。
無いと言ってるのに、無いに等しい物を言ったら、そのレベルとか心外だわｗ
0415デフォルトの名無しさん
2016/05/22(日) 17:54:20.75ID:sxeEi6BC0416デフォルトの名無しさん
2016/05/22(日) 17:56:04.18ID:WwOYSBmy> で、俺を批判するのに頑張るよりお前の考えるクラス構成を出したほうがよっぽど評価されるぞ。
すでに出しただろ？
将棋のAIのアルゴリズムが難しいからと言って
ソフトウェアの設計も難しくなるわけじゃない。
将棋の設計は簡単。ほんの少ししか無い。
だからほんの少ししか言えることはない。
お前は、むやみに複雑にしているようだがなｗ
自分で機能をあれこれ言って、
それを自分で設計できないでいるんだろ？
お前が、自分で出した機能を設計できない時点で
そこに設計はないという証拠になってるんだがｗ
0417デフォルトの名無しさん
2016/05/22(日) 17:56:41.71ID:WwOYSBmy> 機能が拡張しそうな箇所を意識して設計するのも設計上の大切な指針だね。
だから思考ロジック部分を分離しただろｗ
0418デフォルトの名無しさん
2016/05/22(日) 17:57:12.46ID:sxeEi6BC> そうしない理由を聞きたい
ストラテジーパターンとか適用できそうだね。
> 設計はいらない
>>390
0419デフォルトの名無しさん
2016/05/22(日) 17:57:57.65ID:WwOYSBmy> ストラテジーパターンとか適用できそうだね。
それ俺が言ったセリフだｗｗｗ
パクるなよwww
0420デフォルトの名無しさん
2016/05/22(日) 17:58:01.83ID:6l64NX2q変わらないもの共用化できるものは分離して共通化した方がいいだろ
＞そんなの一瞬で思いつちゃったｗ 棋譜データを記録すれば再現できる。
それをどこにどう持たせるの？
あとそれをどう決めてもいいけど、どう決めたかを自分にも他人にもわかる形で
残さないといけないね。単純でコード見ればわかるってんならそれでもいいけど。
0421デフォルトの名無しさん
2016/05/22(日) 17:59:25.73ID:WwOYSBmy> 1つのベースクラスに、それらのデータを入れておき、
> 継承したクラスで、ロジックだけを実装する。
これがストラテジーパターンになってるの気づいてないの？
0422デフォルトの名無しさん
2016/05/22(日) 17:59:46.97ID:sxeEi6BC>>407はどう考慮したんだ？
そもそも機能拡張がありそうな点を意識するって知ってた？
実力を証明するには設計案を提示するしかないぞ。
0423デフォルトの名無しさん
2016/05/22(日) 18:01:00.43ID:sxeEi6BC>>403に
局面を管理してる部分は局面の点数化と手を考えるロジックが変わっても変更する必要はない
とかあるだろうし。
って書いてあげたのに…。
0424デフォルトの名無しさん
2016/05/22(日) 18:04:19.72ID:WwOYSBmy> 変わらないもの共用化できるものは分離して共通化した方がいいだろ
そのための設計って単純だよな？
> それをどこにどう持たせるの？
少なくとも思考ロジック部分じゃないな。
どの将棋ソフトウェアでも共通で使えるものなんだから。
だから今の話、思考ロジック部分の設計（？）には登場しない。
将棋ソフトフレームワークと呼べるものを作って、
対局データを記録できる機能があるならば、
対局クラスとかの中だろう。
で、やっぱり思考ロジックの "外" の話なんだよ。
0425デフォルトの名無しさん
2016/05/22(日) 18:06:05.23ID:WwOYSBmy> 局面を管理してる部分は局面の点数化と手を考えるロジックが変わっても変更する必要はない
局面を管理してる部分は2次元配列クラスだと言ったんだがｗ
局面をもっと便利に管理したいならば、
この2次元配列クラスを拡張してメソッドでも追加しろよｗ
この程度の話、設計と呼べるレベルじゃないよ。
え？普通そうするよね？ レベルの話だ。
0426デフォルトの名無しさん
2016/05/22(日) 18:06:17.27ID:6l64NX2qああ、思考ロジックの中の話なんか
思考ロジックを外と分離するための話かと思ってた
0427デフォルトの名無しさん
2016/05/22(日) 18:11:47.45ID:sxeEi6BC将棋のルール的なロジック
駒がどこに効いてるか？
駒が移動できる場所は？
駒の位置は？
と
点数化
手の選択
を一緒くたにしちゃうのは汚いクラス設計だとしか思わん。
お前は機能の違いについてセンスがまったくないから
これ以上話しても無駄だからもういいや。
少しはましな設計を思いついたら書き込んでくれ。
0428デフォルトの名無しさん
2016/05/22(日) 18:14:56.13ID:WwOYSBmyだから、ベースクラスを継承すればいいっていっただろ。
なんでこの程度のことを大げさに考えてるんだ？
0429デフォルトの名無しさん
2016/05/22(日) 18:18:27.84ID:sxeEi6BCベースクラス？？
そんなのどこにあんの？
クラス構成聞いてるのに出てないのに突然持ち出されてもさあ…。
ごちゃごちゃ言い訳してる暇があるならまともなクラス構成を提示しろ。
提示できないのに「俺はすごいぞお」って言い張っても滑稽。
0430デフォルトの名無しさん
2016/05/22(日) 18:21:40.13ID:WwOYSBmy> そんなのどこにあんの？
>>406にあるけど・・・？
0431デフォルトの名無しさん
2016/05/22(日) 18:23:12.23ID:sxeEi6BCちょうど今電王戦見てるから将棋ソフトで考えてみるとさ。
駒クラスがあって王・飛車とかは駒のサブクラスにしようかって感じだろ。
盤面情報と思考ロジックはどんな感じのクラスにするのがいいだろう？
ってどうなんだろう？
こんな感じのところと将棋ソフトで言えば手の思考ロジックの分割みたいな
領域で悩むことが多い。
0432デフォルトの名無しさん
2016/05/22(日) 18:26:05.60ID:sxeEi6BC？？？
だから>>427の機能が全部ぶちこまれたクラスがあんでしょ？
違うなら違うで何を考えているのか明示しないとお前の考えてることなんて分かるかよ。
実際のプロジェクトでもドキュメントがなきゃこんな感じになって
ぐだぐだになるから設計書が必要だと実感できてよかったな。
0433デフォルトの名無しさん
2016/05/22(日) 18:28:39.50ID:sxeEi6BC間違った。
具体的な質問はこっちだった。
盤面をクラスとして作るべきか、思考ルーチンの中で使われる情報に過ぎないのか？
って疑問がまず出てくるけどどう判断する？
違うクラス構成でもいいけど。
0434デフォルトの名無しさん
2016/05/22(日) 18:29:02.46ID:WwOYSBmyどうも ID:sxeEi6BC って
最初から、完全なものを作らないとだめって思ってるみたい。
要求に対して変化させる能力（仕様変更能力）がないんじゃないか？
一番プレーンな状態からやって、○○したくなったら
それにあわせて変化させれば良いんだよ。
最初から必要になるかわからないものまで作る必要はない。
（ただし考慮は必要。考えるだけでやらなくていい）
思考ロジックの話でも、最初はクラス一つでいいだろ。
で、あとから共通化がどうとか言ってきたから、
俺は、ベースクラスにまとめれば？って答えた。
それだけのことだよ。後から何か言われたら、それに対応させて変化さえればいい。
それができないのはいろんなものを一緒くたにしてやろうとしてるからで
俺は役割に応じて分ける（最初から分けるのではなくて、分けていく）って
考え方をしてるので、大幅な設計変更は発生しない。
ただ単に実現したいことを実現するシンプルな方法（これを正しく判断できるのが経験なのだろう）を
選んでいくだけのことなのに。さっきから「そうするだけじゃん」の連続だよｗ
0435デフォルトの名無しさん
2016/05/22(日) 18:30:13.36ID:WwOYSBmy> だから>>427の機能が全部ぶちこまれたクラスがあんでしょ？
だからなんの理由で分けるんだよｗ
「役割」考えれば、一つにするのが正しいだろ。
まったく最初から複雑にしてるんじゃねーよ。
0436デフォルトの名無しさん
2016/05/22(日) 18:30:39.58ID:JaLdteXYこの短い間にもこれだけの応酬があったってことか
やっぱりシステム開発には対話が必要なんだな
横着してドキュメントで済ませようとすると破綻する事がよくわかった
0437デフォルトの名無しさん
2016/05/22(日) 18:32:15.49ID:EaQ4G/f7複数のクラスがあるとしてソースを見る人間と
いやいやこんなもんクラス1つで十分ですよって人間と
混ざって開発することもあんだしね
0438デフォルトの名無しさん
2016/05/22(日) 18:32:23.86ID:WwOYSBmyどっちでも良い。最初はシンプルに作れ。
後で機能が欲しくなったことを想定してるのなら、その機能を言え。
その機能を実現するように変えるだけだからさ。
クラス設計なんて条件で変わるものなのに、
後出しで条件加えんなよ。
仕様としては単に将棋出来ればいいだけだろ？
0439デフォルトの名無しさん
2016/05/22(日) 18:34:07.77ID:sxeEi6BC>>390
同じことを何度も言わせるな。
どうしようもない設計からスタートさせてくれって言う設計者はいらない。
>>435
こりゃだめだｗ
0440デフォルトの名無しさん
2016/05/22(日) 18:34:18.62ID:EaQ4G/f7ちなみに実際の開発で後出しかどうかなんてドキュメントも書いてないのに
主張できんの?
0441デフォルトの名無しさん
2016/05/22(日) 18:36:52.59ID:8h3SPrnH将棋のコマって全体を表現するときの1要素、データに過ぎないじゃないの
コマの状態や全体を評価して処理するのは別のプログラムーアルゴリズム
コマが主体性をもって勝手に無双するなら関係があるかも知れないけど
コマの種類ー行動範囲ー状態(手ゴマ、版面での位置、成金など)の一覧で表現できる単純な1要素
肝は、それら要素を含む版面全体を評価処理する部分じゃないか
版面のリストデータを評価する関数部分かな
0442デフォルトの名無しさん
2016/05/22(日) 18:38:05.06ID:sxeEi6BCこれが後出しってさあ…。
まず、>>358
で将棋ソフトって言われたら簡単に予測できる。
実際の客なんてこっちが聞かなきゃ説明しないことなんて山ほどあるぞ。
もう語れば語るほど経験のなさが露呈するだけだからやめとけ。
0443デフォルトの名無しさん
2016/05/22(日) 18:39:04.38ID:WwOYSBmy> 複数のクラスがあるとしてソースを見る人間と
> いやいやこんなもんクラス1つで十分ですよって人間と
そんなふうに考えてるやついないぞｗ
実際には複数のクラスに分かれているのを見て、
拡張性を考えた設計だなって読み取れる人と
なんでそうなってるのかわからない。
分ける理由もわからない。っていう技術力の低いやつだけだ。
0444デフォルトの名無しさん
2016/05/22(日) 18:40:13.61ID:WwOYSBmy> どうしようもない設計からスタートさせてくれって言う設計者はいらない。
シンプルな設計からスタートさせてくれって話なんだが？
なんでシンプル＝どうしようもない設計なんだ？
根本的にお前おかしい。
世の中のありとあらゆるソフト見てみろよ。
最初はどれもシンプルだろ。
0445デフォルトの名無しさん
2016/05/22(日) 18:41:15.88ID:WwOYSBmy> で将棋ソフトって言われたら簡単に予測できる。
じゃあ、将棋ソフトっていうからさ、
予測してみ。
もちろん実際の客（俺）が考えてるものの予測だ。
余計なもの作るなよｗ
0446デフォルトの名無しさん
2016/05/22(日) 18:42:12.34ID:WwOYSBmy> 将棋のコマって全体を表現するときの1要素、データに過ぎないじゃないの
普通はその通り。
俺からすれば、普通そうするよね？の当たり前の連続でしか無い。
これを設計なんて感じたこともねーわｗ
0447デフォルトの名無しさん
2016/05/22(日) 18:42:22.89ID:sxeEi6BC駒の動けるマスとか成りルールとかはクラスに持たせてもいい気がするなあ。
たいした情報じゃないからクラスにするまでもないけど。
ルールをどうやってクラスに割り当てるかも悩ましいな。
実装方法の候補はいくつか簡単に思いつくけど、どれを選択するかの基準は難しい。
0448デフォルトの名無しさん
2016/05/22(日) 18:42:52.06ID:sxeEi6BC0449デフォルトの名無しさん
2016/05/22(日) 18:45:23.45ID:WwOYSBmyだからそんなの将棋ソフトの機能に合わせて
ごく普通に作ればいいだけだろｗ
今は超シンプルな将棋ソフトの話なんだから
複雑なクラスにする必要はない。
機能が増えたらそれを実現するように変えればいいだけ。
最初っからいろいろやろうとするから
お前は混乱して、何も手を付けられなくなってるんだよ。
0450デフォルトの名無しさん
2016/05/22(日) 18:48:50.87ID:WENufHUBID:WwOYSBmyが逃げ回ってるようにしか見えないね
将棋ソフトって考慮時間が必要なくらい中身が複雑なものだから
ベースクラスと継承クラスの2つのシンプル実装で済むはずがない
将棋に勝つソフトではなくて
ルール通りにコマを進めるソフトぐらいならそれでもできるかもしれんが…
0451デフォルトの名無しさん
2016/05/22(日) 18:49:31.70ID:8h3SPrnHシンプルな問い合わせで有益な回答がもらえる状態
今回の将棋の場合、コマの種類ごとにクラスとオブジェクトを作って
版面データに配置して、飛車さん何処に動けますか？、何かコマは取れますか？
次の一手で取られるような危険な状態ですか？って問い合わせて
その情報を利用して版面全体を評価判断するプログラムーアルゴリズムが別途必要
だけど、この処理にコマのクラスとかは必須ではない
版面データを一桝ずつ調べて評価しても別にかまわない
0452デフォルトの名無しさん
2016/05/22(日) 18:51:31.18ID:6l64NX2q設計の話をしているなら最終的な結果をある程度イメージしたクラス構造を提示してって話になるが、
プロセスの話をしているなら、将棋のAIなんてロジックによって処理の内容もデータの持たせ方も
変わる可能性があるから、設計やドキュメント作成をしっかりやろうとすると戻り作業の負荷が大きくなるので
>>434でいいってことになる。
0453デフォルトの名無しさん
2016/05/22(日) 18:53:08.67ID:sxeEi6BC書かれている内容は同意なんだけどどちらかの方法を選択するわけじゃん。
そのときの指標ってどんなんだろ？って話がしたい。
将棋の場合に限定せずに、例えばそんな場合にって感じで。
0454デフォルトの名無しさん
2016/05/22(日) 18:55:00.41ID:sxeEi6BC俺はクラス構成について意見聞きたい。
そう書いたのは流れたんだろうけど。
0455デフォルトの名無しさん
2016/05/22(日) 19:11:48.08ID:8h3SPrnH内部関数に知的判断をさせて答えを取り出す
小さな知的データベースみたいな振る舞いをさせた時が使うとき一番楽ができる
struct の内部手続きの管理を容易にするのがクラスだって部分に焦点を当てると
クラス内部のメンバ変数を利用した処理で知的判断が完結できる場合だと思う
アルゴリズムーデータ構造ー＞プログラム この関係がクラス内で完結する場合
一番力を発揮するんじゃないかな
C++始めて2週間だけど言ってみるｗ
0456デフォルトの名無しさん
2016/05/22(日) 19:13:56.11ID:fKm+A9/1自社で作成しなければならない部分は将棋盤のMVCと将棋AIサービスのACLだけ
この案件は規模が小さすぎるから設計するまでもなくフレームワークを使って手短に仕上げて終わりかな
0457デフォルトの名無しさん
2016/05/22(日) 19:21:02.25ID:WwOYSBmy> 将棋ソフトって考慮時間が必要なくらい中身が複雑なものだから
竹内関数も考慮時間が必要なぐらいですが、
設計は難しいですか？
なんで再帰処理に時間がかかるだけなのに
設計の話が出てくるんだよｗ
0458デフォルトの名無しさん
2016/05/22(日) 19:21:47.06ID:WwOYSBmy> 俺はクラス構成について意見聞きたい。
だからクラス構成は搭載する機能によって変わってくる。
今はシンプルな機能でいいって話なんだから、クラス構成もシンプル。
何度も言わせんな。
0459デフォルトの名無しさん
2016/05/22(日) 19:27:38.99ID:WENufHUB都合のいいとこだけ切り取るなよ
ユーザーに勝つアルゴリズムを
ベースクラスと継承クラスの2つだけで実装できんの？
1クラスに何十万行書くつもりかな？
0460デフォルトの名無しさん
2016/05/22(日) 19:28:21.77ID:fKm+A9/1>>456が答え
AIサービスの内部の話をしてるなら
クラスもOOPも使われない、が答え
何故なら遅いから
0461デフォルトの名無しさん
2016/05/22(日) 19:32:21.96ID:WwOYSBmyあいつは将棋の思考ロジックの設計はどうすればいんだ？って
うんうんうなってばかりで、何も作れていない。
必要な理由もないくせに、小さなクラスに分けようとしている。
一方俺はシンプルな 1クラスから初めて、後出しで条件が出るたびに
その条件をみたすように、バージョンアップし続けていっている。
0462デフォルトの名無しさん
2016/05/22(日) 19:35:11.10ID:WwOYSBmy実装できるだろ？
0463デフォルトの名無しさん
2016/05/22(日) 19:43:42.95ID:WwOYSBmy言ってる時点で、普通の人は違和感持つよね？
その言い方だと、ユーザーに負けるアルゴリズムならば、
クラス2つで実装できる思ってるように聞こえる。
ユーザーに勝つかどうかは評価関数（繰り返すけど関数な）の
出来で決まるので、クラスの中の一関数にすぎない。
またコードが長ければ、ユーザーに勝てるとか思っていそう。
コードの長さと強さは関係ない。
0464デフォルトの名無しさん
2016/05/22(日) 19:57:01.68ID:EaQ4G/f7それじゃ見積れないじゃん
今回の開発ですけど全部でどのくらいかかりますか?
概算でいいんでお願いします
0465デフォルトの名無しさん
2016/05/22(日) 20:05:41.89ID:WwOYSBmy話がめんどくさくなりそうなので
あんたがこの話に同意すると言ってからねｗ
プログラマが知るべき97のこと.com/エッセイ/見積りとは何か
http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E8%A6%8B%E7%A9%8D%E3%82%8A%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B
0466デフォルトの名無しさん
2016/05/22(日) 20:07:14.83ID:WwOYSBmyもう一つ。
開発の見積もりとスケジュール管理
見積もりとスケジュールとコミットメントは違う
http://techlife.cookpad.com/entry/2016/04/06/100000
0467デフォルトの名無しさん
2016/05/22(日) 20:11:54.86ID:EaQ4G/f7他人のドキュメントが出てきちゃったぞ（笑）
0468デフォルトの名無しさん
2016/05/22(日) 20:12:46.40ID:WwOYSBmy他人のドキュメントとかいい出すやつかｗ
0469デフォルトの名無しさん
2016/05/22(日) 20:18:21.48ID:EaQ4G/f7読んでないけど
お客さんにもそれ読ませて合意取ってるの?
0470デフォルトの名無しさん
2016/05/22(日) 20:18:56.63ID:WwOYSBmyお前に読めって言ってるんだけど？ｗ
0471デフォルトの名無しさん
2016/05/22(日) 20:20:20.00ID:EaQ4G/f7なんで?
設計書書かないでやるのにそんなの必要ないじゃん
0472デフォルトの名無しさん
2016/05/22(日) 20:21:47.98ID:SSySxKMQなんかめっちゃ進んでるｗｗｗ
> 税制の変更やら社内ルールの変更やらは想定される訳で
そういう類なら設定ファイルなりイベントテーブルなり……オブジェクト指向とは別のところでどうにかするかな
アルゴリズム云々は大量に出てると思うけどストラテジーを真っ先に考えると思うよ
> 設計段階で洗い出さないならいつ設計するんだ？
バリデーションの例での話だけど
バリデーションの為のオブジェクト洗い出しなんてしないなあ
なぜならフレームワークで基底を提供してるから
0473デフォルトの名無しさん
2016/05/22(日) 21:33:06.14ID:sxeEi6BC将棋ソフトのクラス構成って例で考えてみてよ。
業務システムの設計で悩むところとだいたい同じようなことは出てくるから。
0474デフォルトの名無しさん
2016/05/22(日) 21:46:19.29ID:bOnbURFw0475デフォルトの名無しさん
2016/05/22(日) 21:53:33.02ID:SSySxKMQゲームマスター……どこにどの駒があるとかどっちの番とかコントロールするやつ
ビュー……UI担当
思考……たぶんコンピューターの強さ別に思考ルーチン考える(か、深さを変える程度かどっちか)
ストラテジーするのは思考のところ
あんま練ってないから抜け漏れあるだろうけどぱっと考えておおまかにこんなもんじゃないかな
将棋だと後からプレイヤーが3人になるとか10×10になるとか駒の種類が増えるとかないから……
0476デフォルトの名無しさん
2016/05/22(日) 21:57:19.19ID:sxeEi6BC思考部分がメインになるけどどう構成する？って疑問。
将棋ソフトについては観戦してちょこっとネットを読んだ程度で詳しくはないけど
将棋のルール
候補手の分岐
点数評価
駒の情報
盤面の情報
とかはあるでしょ。
0477デフォルトの名無しさん
2016/05/22(日) 21:59:56.19ID:sxeEi6BC駒の配置を元に点数を評価したり、
詰み専用のルーチンがあったり、
パラメータを調整したり、
評価の際に考慮する要素を変えてみたり、
今は実現してるソフトはないみたいだけどディープラーニングを実装したり
と頻繁に改修されている模様。
0478デフォルトの名無しさん
2016/05/22(日) 22:03:46.50ID:SSySxKMQOOPの設計とは違う話ではないかな?
0479デフォルトの名無しさん
2016/05/22(日) 22:06:26.17ID:sxeEi6BC思考部分をどのようなクラスで構成するかって考えるのはオブジェクト指向設計だろ。
0480デフォルトの名無しさん
2016/05/22(日) 22:12:39.67ID:SSySxKMQ構成はストラテジーパターンと思ってるよ
easyレベルの思考パターン、normalレベルの思考パターン……みたいな感じ
逆に聞くけど
将棋のルールオブジェクト、候補手のオブジェクト、点数評価オブジェクト……みたいなのを作るの?
0481デフォルトの名無しさん
2016/05/22(日) 22:14:07.31ID:sxeEi6BC動きのルールがあって
盤面に配置されていて
配置された駒が動けるマスがあって
駒の配置とかを見て点数をつけて
ってのを
複数の商品があって
工場や倉庫があって
社内ルールがあって
流通があって
注文があって
最適な生産計画を立てる
みたいな話に置き換えれば思いっ切り業務システム。
業務より将棋のほうがみんな分かっているし、
顧客のルールのヒアリングとかする必要もないから将棋で考えてると思えば
十分現実的に有益な例と言える。
0482デフォルトの名無しさん
2016/05/22(日) 22:21:13.03ID:sxeEi6BCそこまで具体的になっていないから他の人の考えを聞きたいってレベル。
機能的には
駒クラスと盤面クラス（データの集合でクラスにする必要はないかもしれない）
盤面クラスから合法手を抜き出す処理
抜き出した候補手を絞る処理
候補手を動かしてみた盤面を点数化する処理
最高点の手を選択
かなあと。多少漏れはあるかもしれないけど。
で、ルールについては駒クラスに一部持たせることもできるけど
ルールはまとめてどこがで持たせたほうがすっきりする気もするなあってぼんやり。
合法手を出す部分は手を考える部分とは関係なく共通だから
思考ルーチンのクラスとは分けたほうがいいだろうな。
って程度。
0483デフォルトの名無しさん
2016/05/22(日) 22:21:22.93ID:SSySxKMQこれは>>480への回答……ではないよね
俺は現実的でないとも無益だとも主張してないので
俺の質問は>>481が設計者なら
将棋のルールオブジェクト、候補手のオブジェクト、点数評価オブジェクト……みたいなのを作るの?
ちょっと変えて どんな風に作るの? でもいいけど
0484デフォルトの名無しさん
2016/05/22(日) 22:21:45.17ID:SSySxKMQごめん>>482見る前に書いたから見なかったことにして
0485デフォルトの名無しさん
2016/05/22(日) 22:25:17.11ID:SSySxKMQ具体的になってないっていってるのにこう言っていいかわからんけど
クラスと処理が一緒に書かれてると
正直いまいちわからん
>>473の流れからクラス構成の話をしてるはずなので
クラスと処理は明確に分けてくれると嬉しい
0486デフォルトの名無しさん
2016/05/22(日) 22:28:36.60ID:sxeEi6BCそこは俺自身がつめられていない。
明確になっていないのが現状であるのと
自分の考えを言っちゃうと他の人のアイデアが出ににくくなりそうだから
しばらく待ってみようとも思ってる。
0487デフォルトの名無しさん
2016/05/22(日) 22:31:43.20ID:SSySxKMQなるほど了解
とりあえず俺は>>475ってことで
他の人待ちになるよ
0488デフォルトの名無しさん
2016/05/22(日) 22:37:22.72ID:hyVMxkhK0489デフォルトの名無しさん
2016/05/22(日) 22:43:46.32ID:3jWKTqcSデザパタという用語の飛び出し方と
ストラテジーというパターンの居座り方が不思議
小学生が得意げに掛け算の七の段暗唱してみせてるような不気味さがある
小学生が持ち寄った安モンのプラモをいつまでも机に乗っけてる不気味さがある
このゾッとする感じ分かる奴はROMってニヤニヤしてんだろうな
0490デフォルトの名無しさん
2016/05/22(日) 22:45:11.25ID:sxeEi6BCドキュメントなんて書く必要ないだろって主張する人がいた。
設計なんていらないって主張する人がいた。
肯定派と否定派で不毛な争いを続けた。
設計否定派「そんなのなくても設計できるんだ！」
だったら、不毛だから将棋システムのクラス構成をするってで考えてみようぜ。
>>346
>>431
あと、直近のレス10個くらい。
これでほぼ追いついた。
0491デフォルトの名無しさん
2016/05/22(日) 22:47:07.15ID:sxeEi6BCこういう不毛なレスをする奴に送る言葉
「将棋ソフトの設計を提示してくれ」
できないならじゃまなだけだから黙ってて。
0492デフォルトの名無しさん
2016/05/22(日) 22:52:23.14ID:hyVMxkhKだな
0493デフォルトの名無しさん
2016/05/22(日) 23:35:43.97ID:EaQ4G/f7そんなとこメインに何の?
中身はどうあれ入力は将棋盤の現在の状況と両者の持ち駒とちょっとした設定（難易度とか?）
出力は次の一手って決定してるし
関数で中身が超絶長くてもクラス分ける必要は仕様によってはないと思うよ
0494デフォルトの名無しさん
2016/05/22(日) 23:44:55.34ID:sxeEi6BC>>476読んで１つのクラスにまとめるって違和感ある。
>>481とかも読んで。
それでも全部１つのクラスにぶっこむって言うなら「あぁそう」って感じだ。
思うことはあるけど議論しても不毛だってこのスレで学んだから見解の相違ってことで。
0495デフォルトの名無しさん
2016/05/23(月) 00:10:47.30ID:oqijX3By駒の動きのバリエーションが100パターン以上あるとか
もしくは仕様変更で追加されたり、局面により動的に動きが変わったり
といったことが頻発する場合にはオブジェクトに債務を任せるってのは有効だと思われる。
将棋くらいルールが固定されているものを取り扱っても
設計の善し悪しって意味を持たない気がするよ。
0497デフォルトの名無しさん
2016/05/23(月) 00:19:18.67ID:qUt6/ya8それらを保持するためのデータ集合は必要だし、
それらを参照するロジック郡があることは確実。
その場合のきれいな構成はどうなるって話。
オブジェクトにしない設計選択するからって機能的に独立している部分も含めて
すべてを1つにつなげるのがきれいな設計だとは俺は思わない。
0498デフォルトの名無しさん
2016/05/23(月) 00:20:52.30ID:qUt6/ya80499デフォルトの名無しさん
2016/05/23(月) 00:36:52.91ID:oqijX3By適当に作ってもこの場合、そこまで汚くはならんだろう。
逆に駄目な設計例を紹介する方が難しいんじゃないか。
何度も言うけど将棋くらい盤面、駒、ルールが固定されているものを例に
設計の善し悪しを語るのはあんま筋が良くないように思う。
0500デフォルトの名無しさん
2016/05/23(月) 00:40:16.62ID:qUt6/ya8複雑なシステムを1つのクラスにまとめるのがいい設計だと思ってるなら
俺の知ってるオブジェクト指向設計とは違うな。
0501デフォルトの名無しさん
2016/05/23(月) 00:56:16.41ID:wJJwI8Yd設計も必要と思えない
0502デフォルトの名無しさん
2016/05/23(月) 01:17:43.31ID:2wwYSKozどう考えても将棋ソフトは単純だろｗ
0503デフォルトの名無しさん
2016/05/23(月) 01:19:28.34ID:2wwYSKoz> 最適な生産計画を立てる
> みたいな話に置き換えれば思いっ切り業務システム。
なんで全く関係ない話を置き換えてるんだ？ｗ
0504デフォルトの名無しさん
2016/05/23(月) 01:20:59.57ID:2wwYSKoz> 将棋くらいルールが固定されているものを取り扱っても
> 設計の善し悪しって意味を持たない気がするよ。
その通り。
ルールが固定されているものなのに、
それを業務システムの規模と同一視して
複雑な設計を作り出す
バァカ（笑）がいる。
0505デフォルトの名無しさん
2016/05/23(月) 01:21:26.32ID:DQBja8MH0506デフォルトの名無しさん
2016/05/23(月) 01:29:00.13ID:qUt6/ya8相手にするのは不毛だと分かったから頑張って書き込んでもらってもスルーするのであしからず。
0507デフォルトの名無しさん
2016/05/23(月) 03:34:57.55ID:7DLF1n9wコンピューター将棋の思考ルーチンをなにを使いどう実装するのかは別の話
ここら辺はマジ難しい部分
この難しい評価関数の構造に対してのオブジェクトのクラス構造を語るのは
騙るに等しい無為な行為
クラスの要件定義？を書き上げていくといきなりどう実装するか
これでよいのか判断できなくなっていきなり脳みそ爆発じゃないの
この場合の評価方法って膨大な組み合わせから条件事に状態を抽出
その集合へ評価関数で比較の為に数値化(この数値化の基準が凄く難しい肝の部分)
これを盤面全体かつ何手先まで計算するのかって事でここら辺に膨大な
処理速度なり消費メモリーなりのリソースが必要
0508デフォルトの名無しさん
2016/05/23(月) 07:54:00.86ID:RiQgyPKSボードゲームにOOPとかどんだけだよ
0509デフォルトの名無しさん
2016/05/23(月) 08:42:24.80ID:bDXz1lkX0510デフォルトの名無しさん
2016/05/23(月) 09:18:47.98ID:KJgou+2qもっと言うなら駒みたいに種類が限られてるいるものは列挙型にするべきだろう
関数型にしよう（提案）
0511デフォルトの名無しさん
2016/05/23(月) 09:31:33.26ID:2wwYSKozゲーム開発にOOPを入れるのは常識なんだが。
思考ロジック（評価関数）の中身をOOPにするとかは意味不明
■ このスレッドは過去ログ倉庫に格納されています