オブジェクト指向システムの設計 [無断転載禁止]©5ch.io
レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん
2016/05/19(木) 22:07:47.87ID:9fCVrsOw0809デフォルトの名無しさん
2016/05/28(土) 21:15:12.20ID:fP0wQpWJクソ設計じゃね?
IDBゴミ箱に捨てちゃったらどうなるの?
0810デフォルトの名無しさん
2016/05/28(土) 22:55:45.34ID:vuHucEnZIDBの生存期間が永久だったらどうでもいいんじゃね?
でも、いつでも死ぬぜRAとRBとは別のところでひっそりと息をひきとりましたとさ
ってなるような構造なら参照保持やめろって思うわ
0811デフォルトの名無しさん
2016/05/28(土) 23:07:57.42ID:iUyRPTRl各インスタンスの寿命はUと同期させたいです
0812デフォルトの名無しさん
2016/05/28(土) 23:17:24.57ID:lKk9NsINこの方面から検討することが必要では？
0813デフォルトの名無しさん
2016/05/28(土) 23:24:47.99ID:z5GhiIYg0814デフォルトの名無しさん
2016/05/28(土) 23:41:45.93ID:vuHucEnZIDB太死んだら残されたRA子とRB子はどうしたらいいん?
0815デフォルトの名無しさん
2016/05/29(日) 01:00:47.21ID:f/sZpflr今通じるかわからなくて申し訳ないけど、少し前のJavaのSpring+Hibernateのように
メタデータ利用して、フレームワークにトランザクション管理任せたらあかんの？
0816デフォルトの名無しさん
2016/05/29(日) 08:15:01.43ID:2I7bmxM6パーツからユニットバスを完成させるには、それなりの設計が必要になるけど、それらが組み込み済みのユニットバスなら不要。
既製品が気に入らず、オリジナルのユニットバスが欲しい人は、パーツをうまく組み合わせる設計の知識と能力が要求される。
それが「各インスタンスの寿命はUと同期させたいです」なんて要望実現の部分に相当する。
そこは、オブジェクト指向とは別の知識・技術も必要。
それが無理な人は、JavaのSpring+Hibernate、あるいは同等品を探すほうが楽できるってことかな。
0817デフォルトの名無しさん
2016/05/29(日) 09:57:03.09ID:f/sZpflrその要件が他に出てこないシステムの特異点なら、コメントにしっかり残した上で、規約ぶっちぎって実現できる方法で実現すれば良いと思う
0818デフォルトの名無しさん
2016/05/29(日) 12:14:52.10ID:1ogDAOArこういうことだな
0819デフォルトの名無しさん
2016/05/29(日) 13:18:42.71ID:Cf71caC3https://drive.google.com/file/d/0B2NKffVh2tpqUWNmbTl6MVBRVXc/view?usp=sharing
KifuAnalyzerは過去の棋譜を分析して、駒の価値や駒の配置を点数化するためのパラメータを生成する。
MoveGeneratorは局面からルール上指すことが可能なすべての手を生成する。
MovePickerは合法手から深く読むべき手を選択する。
Evaluatorは局面を評価して点数化する。
MovePickerはEvaluatorが生成する点数を考慮するだろうし、
何手か先まで読むのにMoveGenerator→MovePicker→Evaluatorの処理をループするんだろうけど
その辺りの整理は不十分かもしれない。
改善の余地はあると思うので、知見がある人の意見を聞きたい。
0820デフォルトの名無しさん
2016/05/29(日) 13:20:31.00ID:uH1/jPAHオブジェクト指向ではなくて手続き型の設計になってるなｗ
0821デフォルトの名無しさん
2016/05/29(日) 13:21:59.15ID:1ogDAOArみんなわかったね
0822デフォルトの名無しさん
2016/05/29(日) 13:22:24.27ID:Cf71caC3もっとオブジェクト指向な設計とは具体的には？
0823デフォルトの名無しさん
2016/05/29(日) 13:23:04.73ID:Cf71caC30824デフォルトの名無しさん
2016/05/29(日) 13:25:54.19ID:Cf71caC3手続き型だとコンポーネント構成はどう設計するのかいい加減提示してくれよ。
提示してくれるなら比較できて参考になるから見たい。
提示できるならね。
0825デフォルトの名無しさん
2016/05/29(日) 13:30:29.53ID:1ogDAOAr0826デフォルトの名無しさん
2016/05/29(日) 13:31:05.98ID:GCrD5Cq5いちいち反応するなってｗ
0827デフォルトの名無しさん
2016/05/29(日) 13:41:23.22ID:Cf71caC3？？？
もっとオブジェクト指向な設計も手続き型の設計も見てみたいが。
口だけで何もない奴が書き込んでいると決め付けるのは良くない。
0828デフォルトの名無しさん
2016/05/29(日) 14:07:17.65ID:uH1/jPAH> もっとオブジェクト指向な設計とは具体的には？
オブジェクト（データ）をメインに考えること
0829デフォルトの名無しさん
2016/05/29(日) 14:09:35.72ID:GCrD5Cq5最近、日本将棋連盟は棋譜の著作権を主張してるようだけど
その辺はどうクリアするの？
0830デフォルトの名無しさん
2016/05/29(日) 14:10:21.15ID:ks+EActS0831デフォルトの名無しさん
2016/05/29(日) 14:13:34.46ID:1ogDAOArオブジェクト指向じゃなくね?
0832デフォルトの名無しさん
2016/05/29(日) 14:16:05.87ID:2I7bmxM6たぶん、オブジェクト指向の前に、手続き型プログラミング、構造化プログラミング的な考え方によって大雑把にプログラムの全体構造を把握する設計ステップが入るのだと思う。
それが、この段階。
この段階から、しばらくは構造化プログラミングで設計とコーディングを進めてもいいし、オブジェクト指向をちょっと意識して進めてもいいのだと思う。
で、実際にコードを記述して、ちょくちょくテスト（＝詳細設計）を進めていると、「これはオブジェクト指向の例題にあったような、あのパターンを使うとよさげかも？」なんてのに気づく。
そこで、今まで記述したコードを捨てて新規に作り直したり、あるいは作りかけのソースを修正する、もしくは、どっかから使えそうなフレームワークをコピペして活用するって流れになるのでは？
そうしたとき、最初からオブジェクト指向を意識して作っていたほうが（経験上）修正量が少なくなる気がするし、そのとき、オブジェクト指向のメリットを実感することになるんだろうね。
また、オブジェクト指向でプログラムを作ろうとも、多くの場合、上から下に流れるような構成になると思う。
0833デフォルトの名無しさん
2016/05/29(日) 14:21:04.75ID:ks+EActSカプセル化すれば内部状態の物理的な実装は自由になる
OOPの基本理念の１つ
0834デフォルトの名無しさん
2016/05/29(日) 14:46:06.53ID:uH1/jPAHその図の四角が処理になっていて、図全体が情報の流れを
表しているからだよ。
オブジェクトっていうのは役目を四角にするので
情報の流れとは無関係。
0835デフォルトの名無しさん
2016/05/29(日) 14:58:27.22ID:Cf71caC3具体的に。
0836デフォルトの名無しさん
2016/05/29(日) 15:02:50.83ID:Cf71caC3だいたいの方向性は同意なんだけど
>この段階から、しばらくは構造化プログラミングで設計とコーディングを進めてもいい
は違和感があるなあ。
コーディングに行くのは方針が決まってからじゃないか？
構造化プログラミングでコーディングまで始まってるのにそこからブジェクト指向プログラムに切り替えるのは
工数がだいぶ無駄になるような。
その辺はどう考えているんだろ？
0837デフォルトの名無しさん
2016/05/29(日) 15:08:30.13ID:uH1/jPAH図の罫線に矢印を付けた時、
それが継承ではなくて情報の流れだなって
思ったらアウト。
0838デフォルトの名無しさん
2016/05/29(日) 15:08:35.66ID:Cf71caC3抽象的な言葉としては分かるんだが具体的にどうしたいのか分からないなあ。
www.dataio.comで図を書けるからできれば書いて欲しい。
無理ならコンポーネントとインタフェースだけでも列挙してもらえればだいたい分かるかと。
0839デフォルトの名無しさん
2016/05/29(日) 15:14:36.29ID:uH1/jPAHまず最初は全部一つにまとめろ。
その後に「何のために分離するのか」を書きながら
分離するといい。
分離する理由がないならば、それは分離しなくていい
0840デフォルトの名無しさん
2016/05/29(日) 15:33:37.25ID:2I7bmxM6>この段階から、しばらくは構造化プログラミングで設計とコーディングを進めてもいい
は違和感があるなあ。
コーディングに行くのは方針が決まってからじゃないか？
まあ、あのレベルの設計で、コーディングの方針が決まればいいけど、初めて作るたぐいのプログラムって、どう作ればいいか、よく分からないことが私の場合は、ちょくちょくある。
だから、イメージとしては、作りたいものの漠然としたイメージはあるけど、またはっきりしない状態で、材料となる粘土の塊をいじって、できた粘土の形を見て、そこから先を考えるって感じでプログラミングやっている。
たとえば、足だけ作ってみるとか、バストだけ作って、それを見て、次に作る部分を決めるみたいな・・・。
本来は、全体の方針を決めてからコーディングってのが正しいと思う。
でも、方針がなかなか決まらないときは、手を動かして、なにかしら動くものを作ると、「今日の成果はこれ！」って感じで気分が良くなる。
で、残りを頑張ろうって気力が沸いてくる。そして、オブジェクト指向で作っていると、各パーツの再利用が容易になる。
まあ、すべての人にこの方式を薦めるわけではない。
0841デフォルトの名無しさん
2016/05/29(日) 16:00:47.90ID:uH1/jPAH（MovePickerは存在自体が意味不明）
なぜならば、移動できる場所は複数存在するが、思考ロジックによって
その移動できる場所を解析する順番が違うからだ。
前提条件として、総当りでやると時間が足りない。
だから駒一つ一つすべての移動できる場所を解析するわけじゃない。
解析しない場所（後回しにする場所）などが存在する。
だから、思考ロジック自身が動く場所を知っているし、
解析する順番（評価関数で評価する順番）も知っている。
そして解析する順番というのは、過去の棋譜データから決まる（こともある）
ディープラーニングなんかはそれ。
だからそれらを分離した所で、それらのコンポーネントを再利用することは出来ない。
もっとも過去の棋譜データを解析する処理は「思考」とは別のタイミング（対局前）に
行うことだから思考ロジックと分離するのは当たり前
（もちろん思考時には計算結果のみを利用し対局中に過去の棋譜データを解析するわけじゃない）
0842デフォルトの名無しさん
2016/05/29(日) 16:35:38.18ID:vZz5+wdAオブジェクト指向を持ち出すのが誤りってことだな
前々から言われていたことだが、不適切な題材だな
やったとしても、「思考ロジック」っていう巨大な一つのクラスがほとんどのことを受け持つ
いわゆるGodクラスになってしまうだろう
それが一番早く動くなら、将棋にとってはそれが正義
しかも将棋のルールはほぼ固定されていると考えてよいから
変に柔軟性を与えて仕様変更に強くする意味もないしな
パラメーターで対応すれば十分
動画のエンコーダーとかといっしょで、規格ものなんだよ
規格が決まっていて、速さや効率が求めらえるなら
ハードコーディングも辞さない
0843デフォルトの名無しさん
2016/05/29(日) 16:38:53.32ID:uH1/jPAHデータ構造まで工夫する必要があるからね。
いちいちメソッド呼んでデータを取ってきたりしない。
取ってくるにしても駒の動きなんて変わらないんだから
最初に一括して読み込めばいいしそれはファイルから読み込めばいい。
（その後内部で工夫されたデータ構造にして、あとは内部で完結させる）
0844デフォルトの名無しさん
2016/05/29(日) 16:58:54.31ID:hqWpcQ8C0845デフォルトの名無しさん
2016/05/29(日) 17:18:08.73ID:nD7S98HF品質も良いと思うよ
0846デフォルトの名無しさん
2016/05/29(日) 17:48:41.04ID:Cf71caC3>あのレベルの設計で、コーディングの方針が決まればいいけど
これについてはまだ設計の途中だからさ。現段階では決まってないけど設計が終わる頃には明確になってる。
まあ、設計段階ですべての問題を洗い出すことが難しいのは同意する。
0847デフォルトの名無しさん
2016/05/29(日) 17:54:21.52ID:Cf71caC3MoveGeneratorとMovePickerの役割はちゃんと説明してあるんだが…。
あと、どういう設計を想定しているのか分からない。
言ってる内容がエンドユーザの要件みたいで、設計者の設計じゃないように感じる。
考えてることを明確にするために設計者はモデリングを利用する訳で、設計者同士の会話は
モデリングあるいはコンポーネント・クラスなどを明確にして記述して欲しい。
0848デフォルトの名無しさん
2016/05/29(日) 17:59:16.14ID:Cf71caC3何度も繰り返してるけど、時間もメモリも切り詰めた設計はどうなるか提示してくれ。
0849デフォルトの名無しさん
2016/05/29(日) 18:00:53.32ID:Cf71caC3将棋ソフトを作る気はないから。
0850デフォルトの名無しさん
2016/05/29(日) 18:09:36.48ID:uH1/jPAH> MoveGeneratorとMovePickerの役割はちゃんと説明してあるんだが…。
だからそれが意味不明だって。
お前のは、単に分けているだけで
分ける理由が存在していない。
0851デフォルトの名無しさん
2016/05/29(日) 18:10:53.57ID:uH1/jPAH> 何度も繰り返してるけど、時間もメモリも切り詰めた設計はどうなるか提示してくれ。
[ 思考ロジック ]
0852デフォルトの名無しさん
2016/05/29(日) 18:16:58.80ID:uH1/jPAHこれでもいいがｗ
[ 思考ロジック ] - [将棋UI]
もう少し細かく言うのなら将棋の駒の配置は、
思考ロジックでも使うが将棋UIでも使う共通情報だから
という理由で分離して
[ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI]
思考ロジックは、駒の配置データを参照して、駒の配置データを書き換えるという役目。
将棋UIは駒の配置データを参照して、それをUIとしてレンダリングする
将棋UI は更にその内部で、将棋盤オブジェクトや駒オブジェクトとして
2Dや3Dでレンダリングされるが、これは完全にUIの話で思考ロジックとは切り離すべき話だよねｗ
オブジェクト指向で設計するならばこれぐらいの話だな。
0853デフォルトの名無しさん
2016/05/29(日) 18:21:29.72ID:uH1/jPAH時間を切り詰めた実装でも、メモリを切り詰めた実装でも、
一台のマシンを使う実装でも、多数のマシンを使う実装でも
「どんな実装にも変更可能な設計」というのなら、これは設計なわけで正しい。
つまり
× 時間もメモリも切り詰めた設計
○ 時間もメモリも切り詰めた実装
時間やメモリを切り詰め ”られる" のは、それが可能なように設計で考慮するべきことだが
時間やメモリを切り詰め "る" のは設計で決めることじゃない。
0854デフォルトの名無しさん
2016/05/29(日) 18:27:50.97ID:hqWpcQ8C>何度も繰り返してるけど、時間もメモリも切り詰めた設計はどうなるか提示してくれ。
何度も言われてる気はするがほぼ思考ロジックの話になるからオブジェクト指向でやる意味なくね
具体的にどのアルゴリズムを選ぶか？
それが「時間もメモリも切り詰めた設計」となる
振る舞いと実装の分離とかしないわけよ
>>852が言ってるようにオブジェクト指向でやる意味あるUIくらいだよ
0855デフォルトの名無しさん
2016/05/29(日) 19:05:09.06ID:Cf71caC3正しいと思う設計を具体的に示してくれ。
面倒くさくなってきたから明示できないならもういいよ…。
0856デフォルトの名無しさん
2016/05/29(日) 19:06:07.22ID:uH1/jPAH[ 思考ロジック ]
書いてあるよね？
なんで見えてないの？
0857デフォルトの名無しさん
2016/05/29(日) 19:07:21.11ID:uH1/jPAH↑ 思考ロジックの正しい設計
[ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI]
↑ UIまで含めた、将棋ソフトの正しい設計
0858デフォルトの名無しさん
2016/05/29(日) 19:08:04.03ID:Cf71caC3で、設計は？って聞かれると>>652とか答えちゃう訳？ｗ
0859デフォルトの名無しさん
2016/05/29(日) 19:10:04.28ID:Cf71caC3おっけ、おっけ。
設計に対する前提がかけ離れ過ぎてるから話しても無意味だと分かった。
0860デフォルトの名無しさん
2016/05/29(日) 19:12:52.55ID:uH1/jPAH実装書いてあるだけだろｗ
0861デフォルトの名無しさん
2016/05/29(日) 19:13:21.23ID:uH1/jPAH結局、設計の話してもこうやって無視するわけだ？
逃げるな卑怯者
0862デフォルトの名無しさん
2016/05/29(日) 19:20:13.35ID:Cf71caC3率直に言うと、レベルが低過ぎてお話にならないと判断した。
将棋ソフトを設計しろって言われて
[ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI]
だけ書いて完成したと思うのは>>652並みのお粗末さだぞ…。
思考部分のコンポーネント図が間違っているというなら訂正したコンポーネント図を書けよ。
[ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI] って何じゃそりゃ？
0863デフォルトの名無しさん
2016/05/29(日) 19:22:38.20ID:uH1/jPAHお粗末ってなんだ？
設計というのはシンプルにするものだ。
たくさん書けばいいってわけじゃねーぞｗ
0864デフォルトの名無しさん
2016/05/29(日) 19:23:38.63ID:uH1/jPAHお前こそ、間違ってる理由を言えよ。
お前が考えるさいきょうのせっけい（笑）の紹介じゃなくて、
何が間違っているのかを言えって。
0865デフォルトの名無しさん
2016/05/29(日) 19:25:48.76ID:uH1/jPAH[ 思考ロジック ]
↑ 思考ロジックの正しい設計
何度も言ってる
0866デフォルトの名無しさん
2016/05/29(日) 19:31:51.54ID:nCNZLCDhもうほとんどあらしだな
0867デフォルトの名無しさん
2016/05/29(日) 19:45:13.81ID:hqWpcQ8Cレベルが低い以前に話聞いてないじゃん
将棋の思考ロジックの設計なんかはもうアルゴリズムの設計とほぼ同じ
計算機科学の分野でしょ
0868デフォルトの名無しさん
2016/05/29(日) 20:19:13.03ID:vZz5+wdAchar ban[9][9];
こんなんで十分なわけでしょ
これに相手と自分の持ち駒の配列を付け加えて
あと少々何かあればそれで充分な世界
人によってはcharですらデカすぎるというかもしれない
この時点でオブジェクト指向らしさは全然ないよね
どちらかといえば画像処理とかに近いデータ構造
将来将棋が仕様変更して、いきなり金の振る舞いが変わるとか
そういうことはあり得ないから、駒をオブジェクトにするとか意味不明なことはする必要ないし
オブジェクト指向でよく言うような、仕様変更に強くするとか
継承とオーバーライドで差分プログラミングとか、全く関係ないよね
だって、将棋のルール(仕様)は決まっているわけだからさ、仕様変更とか考えなくてよい
むしろ実行時間や効率が問われているのだから
意味のない柔軟性を持たせる分のオーバーヘッドがもったいないし、必要もない
0869デフォルトの名無しさん
2016/05/29(日) 20:30:30.60ID:Cf71caC3モジュール構成は？
相互の関係は？
コンポーネント図を見ればどういう領域を整理しようとしているかくらい分かるだろ？
0870デフォルトの名無しさん
2016/05/29(日) 20:32:05.69ID:Cf71caC30871デフォルトの名無しさん
2016/05/29(日) 20:42:21.72ID:f/sZpflr業務プログラマなんだろ？
0872デフォルトの名無しさん
2016/05/29(日) 20:44:29.81ID:uH1/jPAH↑ 思考ロジックの正しい設計
[ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI]
↑ UIまで含めた、将棋ソフトの正しい設計
> コンポーネント図を見ればどういう領域を整理しようとしているかくらい分かるだろ？
これみて、どういう領域を整理しよとしているかわからないの？ｗ
0873デフォルトの名無しさん
2016/05/29(日) 20:59:39.40ID:1omdCt5G最初から全部決めようなんて無理無理
0874デフォルトの名無しさん
2016/05/29(日) 21:03:08.22ID:1mIQzqS0将棋ソフト全体をOOPで作ったとしてもAIモジュールとはだいぶ隔たりがあるよ
ユーザーの入力した結果から低レベルな盤面データを生成して丸ごと渡すだけとかそんなレベル
0875デフォルトの名無しさん
2016/05/29(日) 21:13:37.84ID:vZz5+wdA歴史のあるゲームであって、いきなりルールが変わって金の動きが変わるとか
そういったことは今の時点では全く考慮する必要がないわけだよ
で、オブジェクト指向のメリットは、大体において仕様変更に強くすることなんだよ
仕様変更が全くないのであれば、どんな方法でどんな汚い書き方をしたって
プログラマだってプロなんだから、書き上げることはできるんだよ
ただ、突然の仕様変更は怖いよねって話で、そのためにオブジェクト指向にコストを掛けているわけじゃないですか
その点、将棋はルールが決まっていて、仕様変更など気にする必要ないし
むしろ実行速度が強さに直結していて、一手でも先を読んだ方が有利なわけだから
仮想関数なんかを使うオーバーヘッドがもったいないし
その二つの面からオブジェクト指向である必要性が薄い題材
仮にオブジェクト指向で作ったとしても、仕様変更がないことが分かっているわけだから
オブジェクト指向設計の腕の見せ所が全くないし、題材として不適切なんだよ
将来にわたって必要の無いであろう拡張性や柔軟性を持たせても、無駄が多いと言われるだけ
将棋のAIのアルゴリズムには大変興味深いものがあるとおもうが
オブジェクト指向としては見るべき点が「全く」ない
0876デフォルトの名無しさん
2016/05/29(日) 21:32:59.51ID:vZz5+wdA仕様変更が発生しない題材なわけだから、オブジェクト指向的に良いも悪いもなく、動けばOKだよねっていう話になる
どんなに不味いオブジェクト指向の設計であっても、仕様変更さえなければ大体は問題にならない
当初の予定通り動く
ついでに、将棋AIである以上は強くなくてはならない
この強くなければならないという案件は、通常ではない
業務システムが他のシステムと喧嘩して勝っただの負けただの言わない
普通は仕様変更に強いように、拡張性があるように、プログラムを設計するし
オブジェクト指向の設計の良し悪しもそこに集約されるわけだが
将棋AIは強さが求められているわけで、オブジェクト指向設計でいうところの
良し悪しとは違ったものが求められている
しかも仕様変更がない、とくればハードコーディングも止む無しだろう
0877デフォルトの名無しさん
2016/05/29(日) 21:36:48.37ID:JprInoKjワープ駒とか二回倒さないと死なないとか
範囲攻撃とか装備とかアイテムとか擬人化とかイケメン武将とかキャラアドオンとかガチャとか課金とか
マルチプラットフォーム対応もするしサービスとして長くメンテナンスし拡張を加えていく前提
当然AIもそれに対応しなければならないからゲームやアプリは良くモデル化されていなければならない
0878デフォルトの名無しさん
2016/05/29(日) 21:38:49.46ID:uH1/jPAHで、そんなことを言い出すと。
YAGNIだってとどめを刺すわけだｗ
だからそうする目的を聞いている。目的がないのにわざわざ分割するのは、
必要だからやるのではなく、設計（？）をすること自体が目的になっている。
0879デフォルトの名無しさん
2016/05/29(日) 21:47:24.89ID:Cf71caC3現実のプロジェクトなら設計者が設計書に記述するであろう内容についての前提が違うんだと思う。
「将棋ソフトを設計してくれ」って客に言われたら、オブジェクト指向だろうが、他の設計手法だろうが
構成を記述しないってことはあり得ないからさあ。
そこを分からない人に説明してもしょうがないことは分かったから流すようにする。
毎日IDが変わるから新しい人かもと思って対応していたけど、どうも同じ人みたいだし、
対応してもスレが汚れるだけだからスルーすべきだったと反省。
0880デフォルトの名無しさん
2016/05/29(日) 21:50:11.02ID:uH1/jPAH構成は記述されてありますが？
そもそも将棋ソフトを設計してくれって言われたら
思考ロジック部分だけを設計しませんよｗｗｗ
[ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI]
こんな感じで設計します。
当然、思考ロジック部分は一つです。
シンプルイズベスト。理由がなければ分割しない。
0881デフォルトの名無しさん
2016/05/29(日) 21:52:08.59ID:uH1/jPAHどんな仕様か詳しく聞きますね。
その上で必要なら、それを満たすように設計しますが、
あんたのように何も言ってないのに過剰な分割なんかしませんよｗｗｗ
0882デフォルトの名無しさん
2016/05/29(日) 21:53:29.31ID:1omdCt5Gただ将棋ソフトで遊びたい人にとって内部設計なんてなんの意味もない
外部の人間が自分たちのソース引き継いでメンテするのが前提ってこと？
0883デフォルトの名無しさん
2016/05/29(日) 22:04:37.03ID:qPPHNZFg円周率を出すソフトを「設計」しろとか、
そういう類の無意味な題材だってことが理解できているのか心配になる。
動物とか自動車とかモデル化するだけの人なのかもしれんが。
0884デフォルトの名無しさん
2016/05/29(日) 22:05:37.63ID:uH1/jPAH何を言ってるんだ？
たとえばネット対戦をしたいって言えば
それが出来るような設計にするだろ？
客の要求を聞いた上で、それを実現できるように設計する。
客がネット対戦をしたいって言ってもいないのに
あらかじめ先手（笑）を打ってネット対戦機能をつけましたとか
それは過剰な設計であり無駄なコストを発生させたに過ぎない。
だからいきなり設計すんなって言ってるんだよ。
客の要望を聞いて、必要であるという理由があれば
それが可能なように設計すればいい。
だから、そうした理由を聞いてるのに、明確な理由もなくて、
そうするのがいいと思いましたーでやってるから馬鹿にされてるんだよ。
0885デフォルトの名無しさん
2016/05/29(日) 22:06:35.28ID:1ogDAOArここで話せるのはここまでじゃん
だから題材が悪いって俺が最初に言ったじゃん
基本的にオブジェクト指向ってz80で作れるものに威力を発揮しないんだよ
将棋ソフトなんて作ったこともないのに題材に選んだ奴責任とって腹切れ
どうせ設計に必要な項目も他人に説明できないしできなかっただろ
それは将棋ソフトの全容が他人に聞くまでもなく
みんなある程度わかっちゃってるからなのさ
0886デフォルトの名無しさん
2016/05/29(日) 22:07:18.13ID:+DJ914Ecできるだけ抽象的に作ればいいと思ってる抽象馬鹿だと思われ。
0887デフォルトの名無しさん
2016/05/29(日) 22:09:35.02ID:uH1/jPAHogg vorbis形式のファイルというのは、正確には音声ファイルフォーマットで
Oggがコンテナ、Vorbisがコーデックという設計で、
元々内部の役割が分割されてるからちょっと違うけどねｗ
0888デフォルトの名無しさん
2016/05/29(日) 22:11:26.67ID:uH1/jPAH> 将棋ソフトなんて作ったこともないのに題材に選んだ奴責任とって腹切れ
↓こいつかな？ｗ
346 名前：デフォルトの名無しさん[] 投稿日：2016/05/22(日) 16:27:04.89 ID:sxeEi6BC [38/89]
ちょうど今電王戦見てるから将棋ソフトで考えてみるとさ。
駒クラスがあって王・飛車とかは駒のサブクラスにしようかって感じだろ。
盤面情報と思考ロジックはどんな感じのクラスにするのがいいだろう？
354 返信：デフォルトの名無しさん[] 投稿日：2016/05/22(日) 16:44:19.40 ID:sxeEi6BC [43/89]
>>351
具体例があったほうが分かりやすいから将棋ソフトの例で考えてみてよ。
0889デフォルトの名無しさん
2016/05/29(日) 22:14:11.15ID:auBo7N3Kここには顧客ロールの担当者がいないのさ
0890デフォルトの名無しさん
2016/05/29(日) 22:17:37.23ID:1ogDAOArはじめの話で思考ルーチンが
ディープラーニング当然でしょみたいな話になんて絶対ならないわけで
0891デフォルトの名無しさん
2016/05/29(日) 22:19:59.67ID:+DJ914EcLinux あたりと比較できるしいいんじゃないの？
よりよいオブジェクト指向で設計してもらいたいですな。
0892デフォルトの名無しさん
2016/05/29(日) 22:24:35.04ID:hqWpcQ8Cこれ 「将棋ソフト」を設計しろだと
いきなり実装の話に入らざるを得ない
0893デフォルトの名無しさん
2016/05/29(日) 22:26:13.01ID:uH1/jPAH> 要件定義が曖昧なのに求めてる設計書のレベルが見合わないんだよね
それもあるけど「何のためにそうしているか？」が存在しないんだよ。
いえばいいだけなのに、言わない。
そうするのが当然だって思い込んでる。
0894デフォルトの名無しさん
2016/05/29(日) 22:27:58.83ID:uH1/jPAHお題だから、いきなり実装の話に入ってもいいんだけどさ、
それならそれで、どういう「要件を想定した」っていうのを
明確に言わないといけない。
それを言わずに、なんかわけのわからん分割の仕方をしてるから
突っ込み入れられまくってるわけ。
0895デフォルトの名無しさん
2016/05/29(日) 22:33:44.93ID:RrRCCmyQ将棋の駒はクラスで正解
しかし設計のきれいさではなく
処理速度を求めるなら構造化で書く
前提が違うのにみな上から目線で書きこむから
ただ混乱するだけ
やっぱ2ちゃんは雑談はともかく
ちゃんとした議論に向かないな
0896デフォルトの名無しさん
2016/05/29(日) 22:35:40.39ID:1ogDAOAr得に将棋ソフトなんて疑問が無いもん
勝手に作っちゃうでしょ
そこは要件を出した方も悪いし聞かないまま進めちゃう方も悪いし
0897デフォルトの名無しさん
2016/05/29(日) 22:36:26.79ID:uH1/jPAHそれはゲームとかで駒を
2Dや3Dでレンダリングする時の話だよｗ
思考ロジックの中でクラスにする理由はない
charなりintなりの二次元配列に
defineで定義した定数を入れれば十分
0898デフォルトの名無しさん
2016/05/29(日) 22:40:50.33ID:RrRCCmyQ処理速度を考慮しない前提で言うと
それはオブジェクト指向じゃなくて
構造化の考えから抜け出せてない
0899デフォルトの名無しさん
2016/05/29(日) 22:45:42.31ID:1ogDAOAr駒なんかクラスにされたらどう作ってもクソになっちまう
0900デフォルトの名無しさん
2016/05/29(日) 22:47:10.49ID:1ogDAOArつまりオブジェクト指向ってもしかして（笑）
0901デフォルトの名無しさん
2016/05/29(日) 22:49:05.67ID:uH1/jPAHそれで理由は？
0902デフォルトの名無しさん
2016/05/29(日) 22:51:44.59ID:uH1/jPAH> でもオブジェクト指向的に将棋の駒をクラスにするのは間違ってないと思うな
> つまりオブジェクト指向ってもしかして（笑）
最後まで書きなよｗ
つまりオブジェクト指向ってもしかして、（思考ロジックの）将棋の駒を
クラスにすることには役に立たない。
だろ？
だから俺は最初から何のためにそれをクラスにするのかと聞いてるわけ。
する理由がある、つまり適切な場所をオブジェクト指向にして、
こんな関数レベルの思考ロジックをわざわざ無意味に分割するんじゃないって言ってるんソア。
0903デフォルトの名無しさん
2016/05/29(日) 22:52:01.50ID:+DJ914Ec抜け出す必要がない場面で無理に抜け出そうとする事がそもそもおかしい。
オブジェクト指向は万能ではない、処理フローがほとんど決まってるものに対しては不向き。
0904デフォルトの名無しさん
2016/05/29(日) 22:54:48.91ID:vZz5+wdAcharでも何か勿体ないという人もいるかもしれない
画像なら、画像全体が何らかのオブジェクトでラップしてあるならわかるが
画像の1ピクセル1ピクセルを全てオブジェクトにする人はいない
こんなものはデータで十分
構造体的発想を抜け出せないというのも意味不明
データで十分なものをオブジェクトにする方が
何も理解していないと言いたい
0905デフォルトの名無しさん
2016/05/29(日) 22:58:31.03ID:1ogDAOArでもさ
全員の共通認識を一致しやすいって手法だろ?
でもこの方法は将棋ソフトに関してははっきり言ってクソ
どう作ってもクソにしかならない
オブジェクト指向ってダメなのかもしれんね
0906デフォルトの名無しさん
2016/05/29(日) 22:59:10.96ID:1omdCt5G0907デフォルトの名無しさん
2016/05/29(日) 23:01:49.14ID:vlcsE4Oaうんうん。将棋のコマって
王将・玉将
金将
銀将 → 成銀
桂馬 → 成桂
香車 → 成香
飛車 → 竜王
角行 → 竜馬
歩兵 → と金
うまい具合に15種類なんだよねぇ。
4bitでじゅーぶんですよね。空白含めても。
0908デフォルトの名無しさん
2016/05/29(日) 23:02:20.91ID:Cf71caC3「設計は>>652」
「設計は思考ロジック！」
とか言ってないで、設計を提示すりゃいいじゃん。
設計書を書いたことなくて、書き方知らないんだからおとなしくしてりゃいいのに。
あと、要件についは十分説明したから読み直せ。
参加者はあれで読み取ってるんだから読み取れない自分が問題だといい加減気付けよ。
レス数が900を超えています。1000を超えると表示できなくなるよ。