オブジェクト指向システムの設計

1 名前：デフォルトの名無しさん [2016/05/19(木) 22:07:47.87 ID:9fCVrsOw.net] 手順とかノウハウとか語りたい 820 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 19:50:56.91 ID:hH79WOSS.net] まだやってたんかw。 素性の知らないもの同士が、成果物や開発対象、開発体制の情報開示をせずに 喧嘩腰でレスする時点でこういうオチになると思った。 821 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 20:12:20.38 ID:dyQMlzBT.net] 設計書書かないでプログラム組むっていうのと対比させるなら 設計の前にすることすっ飛ばして良い設計も糞もないってことだよな 822 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 20:47:19.10 ID:b4Z/BPeQ.net] >>800 すみませんよくわかりませんでした >>803 具体的にはUnitOfWorkパターンです スマホなのでタイピングを端折ってしまったのですが本当はクラスは4つ(業務ではもっと多い)あります DBセッション/トランザクション管理 DB : IDB Aリポジトリ RA : IRA Bリポジトリ RB : IRB UnitOfWork U : IU コンストラクタはそれぞれ U(IRA , IRB) RA(IDB) RB(IDB) DB() こうなってます ここでRAとRBは同じトランザクションで処理したいので同じDBインスタンスを注入したくなります 823 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 21:15:12.20 ID:fP0wQpWJ.net] >>808 クソ設計じゃね? IDBゴミ箱に捨てちゃったらどうなるの? 824 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 22:55:45.34 ID:vuHucEnZ.net] IDBを捨てられたRAとRBは挙動不審になる感じ? IDBの生存期間が永久だったらどうでもいいんじゃね? でも、いつでも死ぬぜRAとRBとは別のところでひっそりと息をひきとりましたとさ ってなるような構造なら参照保持やめろって思うわ 825 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 23:07:57.42 ID:iUyRPTRl.net] >>810 各インスタンスの寿命はUと同期させたいです 826 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 23:17:24.57 ID:lKk9NsIN.net] 複数ＤＢのトランザクション処理って、分散トランザクションってことですね。 この方面から検討することが必要では？ 827 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 23:24:47.99 ID:z5GhiIYg.net] やっぱ具体的かつ現実的な質問があると捗るな 828 名前：デフォルトの名無しさん mailto:sage [2016/05/28(土) 23:41:45.93 ID:vuHucEnZ.net] なんでコンストラクタで渡すん? IDB太死んだら残されたRA子とRB子はどうしたらいいん? 829 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 01:00:47.21 ID:f/sZpflr.net] UnitOfWorkパターンやリポジトリ、厳密に適用されたオブジェクト指向がどんなものかわかってなくて申し訳ないんだけど･･･ 今通じるかわからなくて申し訳ないけど、少し前のJavaのSpring+Hibernateのように メタデータ利用して、フレームワークにトランザクション管理任せたらあかんの？ 830 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 08:15:01.43 ID:2I7bmxM6.net] うまい例えになるかどうかわからないけど、オブジェクト指向を、お風呂場のいろんなパーツ、蛇口、浴槽、シャワー、ライトなどの構成パーツとしたら、JavaのSpring+Hibernateは、それらが組み合わせられたメーカー品のユニットバスってことではないかと思う。 パーツからユニットバスを完成させるには、それなりの設計が必要になるけど、それらが組み込み済みのユニットバスなら不要。 既製品が気に入らず、オリジナルのユニットバスが欲しい人は、パーツをうまく組み合わせる設計の知識と能力が要求される。 それが「各インスタンスの寿命はUと同期させたいです」なんて要望実現の部分に相当する。 そこは、オブジェクト指向とは別の知識・技術も必要。 それが無理な人は、JavaのSpring+Hibernate、あるいは同等品を探すほうが楽できるってことかな。 831 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 09:57:03.09 ID:f/sZpflr.net] なるほど、確かに既製品で間に合うならそうするよな その要件が他に出てこないシステムの特異点なら、コメントにしっかり残した上で、規約ぶっちぎって実現できる方法で実現すれば良いと思う 832 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 12:14:52.10 ID:1ogDAOAr.net] つまりDobon.netコピペが最強 こういうことだな 833 名前：デフォルトの名無しさん [2016/05/29(日) 13:18:42.71 ID:Cf71caC3.net] 将棋ソフトを構成するコンポーネントを整理した。 https://drive.google.com/file/d/0B2NKffVh2tpqUWNmbTl6MVBRVXc/view?usp=sharing KifuAnalyzerは過去の棋譜を分析して、駒の価値や駒の配置を点数化するためのパラメータを生成する。 MoveGeneratorは局面からルール上指すことが可能なすべての手を生成する。 MovePickerは合法手から深く読むべき手を選択する。 Evaluatorは局面を評価して点数化する。 MovePickerはEvaluatorが生成する点数を考慮するだろうし、 何手か先まで読むのにMoveGenerator→MovePicker→Evaluatorの処理をループするんだろうけど その辺りの整理は不十分かもしれない。 改善の余地はあると思うので、知見がある人の意見を聞きたい。 834 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 13:20:31.00 ID:uH1/jPAH.net] >>819 オブジェクト指向ではなくて手続き型の設計になってるなｗ 835 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 13:21:59.15 ID:1ogDAOAr.net] オブジェクト指向なんてゴミ みんなわかったね 836 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 13:22:24.27 ID:Cf71caC3.net] >>820 もっとオブジェクト指向な設計とは具体的には？ 837 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 13:23:04.73 ID:Cf71caC3.net] ちなみにクラス設計はこれからだから。 838 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 13:25:54.19 ID:Cf71caC3.net] >>821 手続き型だとコンポーネント構成はどう設計するのかいい加減提示してくれよ。 提示してくれるなら比較できて参考になるから見たい。 提示できるならね。 839 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 13:30:29.53 ID:1ogDAOAr.net] 普通に上から下に流れる処理なのにオブジェクト単位に表現される悪夢 840 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 13:31:05.98 ID:GCrD5Cq5.net] 煽り耐性０やな いちいち反応するなってｗ 841 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 13:41:23.22 ID:Cf71caC3.net] >>826 ？？？ もっとオブジェクト指向な設計も手続き型の設計も見てみたいが。 口だけで何もない奴が書き込んでいると決め付けるのは良くない。 842 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 14:07:17.65 ID:uH1/jPAH.net] >>822 > もっとオブジェクト指向な設計とは具体的には？ オブジェクト（データ）をメインに考えること 843 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 14:09:35.72 ID:GCrD5Cq5.net] 棋譜データはどこから持ってくるの？ 最近、日本将棋連盟は棋譜の著作権を主張してるようだけど その辺はどうクリアするの？ 844 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 14:10:21.15 ID:ks+EActS.net] OOPはむしろデータの実体を切り離せるところがメリットなのでは 845 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 14:13:34.46 ID:1ogDAOAr.net] >>830 オブジェクト指向じゃなくね? 846 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 14:16:05.87 ID:2I7bmxM6.net] >>819 たぶん、オブジェクト指向の前に、手続き型プログラミング、構造化プログラミング的な考え方によって大雑把にプログラムの全体構造を把握する設計ステップが入るのだと思う。 それが、この段階。 この段階から、しばらくは構造化プログラミングで設計とコーディングを進めてもいいし、オブジェクト指向をちょっと意識して進めてもいいのだと思う。 で、実際にコードを記述して、ちょくちょくテスト（＝詳細設計）を進めていると、「これはオブジェクト指向の例題にあったような、あのパターンを使うとよさげかも？」なんてのに気づく。 そこで、今まで記述したコードを捨てて新規に作り直したり、あるいは作りかけのソースを修正する、もしくは、どっかから使えそうなフレームワークをコピペして活用するって流れになるのでは？ そうしたとき、最初からオブジェクト指向を意識して作っていたほうが（経験上）修正量が少なくなる気がするし、そのとき、オブジェクト指向のメリットを実感することになるんだろうね。 また、オブジェクト指向でプログラムを作ろうとも、多くの場合、上から下に流れるような構成になると思う。 847 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 14:21:04.75 ID:ks+EActS.net] >>831 カプセル化すれば内部状態の物理的な実装は自由になる OOPの基本理念の１つ 848 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 14:46:06.53 ID:uH1/jPAH.net] >>819が手続き型になってるというのは、 その図の四角が処理になっていて、図全体が情報の流れを 表しているからだよ。 オブジェクトっていうのは役目を四角にするので 情報の流れとは無関係。 849 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 14:58:27.22 ID:Cf71caC3.net] >>828 具体的に。 850 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 15:02:50.83 ID:Cf71caC3.net] >>832 だいたいの方向性は同意なんだけど >この段階から、しばらくは構造化プログラミングで設計とコーディングを進めてもいい は違和感があるなあ。 コーディングに行くのは方針が決まってからじゃないか？ 構造化プログラミングでコーディングまで始まってるのにそこからブジェクト指向プログラムに切り替えるのは 工数がだいぶ無駄になるような。 その辺はどう考えているんだろ？ 851 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 15:08:30.13 ID:uH1/jPAH.net] >>835 図の罫線に矢印を付けた時、 それが継承ではなくて情報の流れだなって 思ったらアウト。 852 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 15:08:35.66 ID:Cf71caC3.net] >>834 抽象的な言葉としては分かるんだが具体的にどうしたいのか分からないなあ。 www.dataio.comで図を書けるからできれば書いて欲しい。 無理ならコンポーネントとインタフェースだけでも列挙してもらえればだいたい分かるかと。 853 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 15:14:36.29 ID:uH1/jPAH.net] >>838 まず最初は全部一つにまとめろ。 その後に「何のために分離するのか」を書きながら 分離するといい。 分離する理由がないならば、それは分離しなくていい 854 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 15:33:37.25 ID:2I7bmxM6.net] >>836 >この段階から、しばらくは構造化プログラミングで設計とコーディングを進めてもいい は違和感があるなあ。 コーディングに行くのは方針が決まってからじゃないか？ まあ、あのレベルの設計で、コーディングの方針が決まればいいけど、初めて作るたぐいのプログラムって、どう作ればいいか、よく分からないことが私の場合は、ちょくちょくある。 だから、イメージとしては、作りたいものの漠然としたイメージはあるけど、またはっきりしない状態で、材料となる粘土の塊をいじって、できた粘土の形を見て、そこから先を考えるって感じでプログラミングやっている。 たとえば、足だけ作ってみるとか、バストだけ作って、それを見て、次に作る部分を決めるみたいな・・・。 本来は、全体の方針を決めてからコーディングってのが正しいと思う。 でも、方針がなかなか決まらないときは、手を動かして、なにかしら動くものを作ると、「今日の成果はこれ！」って感じで気分が良くなる。 で、残りを頑張ろうって気力が沸いてくる。そして、オブジェクト指向で作っていると、各パーツの再利用が容易になる。 まあ、すべての人にこの方式を薦めるわけではない。 855 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 16:00:47.90 ID:uH1/jPAH.net] >>819でおかしい所の一つはMoveGeneratorとかいうコンポーネントがある所 （MovePickerは存在自体が意味不明） なぜならば、移動できる場所は複数存在するが、思考ロジックによって その移動できる場所を解析する順番が違うからだ。 前提条件として、総当りでやると時間が足りない。 だから駒一つ一つすべての移動できる場所を解析するわけじゃない。 解析しない場所（後回しにする場所）などが存在する。 だから、思考ロジック自身が動く場所を知っているし、 解析する順番（評価関数で評価する順番）も知っている。 そして解析する順番というのは、過去の棋譜データから決まる（こともある） ディープラーニングなんかはそれ。 だからそれらを分離した所で、それらのコンポーネントを再利用することは出来ない。 もっとも過去の棋譜データを解析する処理は「思考」とは別のタイミング（対局前）に 行うことだから思考ロジックと分離するのは当たり前 （もちろん思考時には計算結果のみを利用し対局中に過去の棋譜データを解析するわけじゃない） 856 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 16:35:38.18 ID:vZz5+wdA.net] 結局、将棋の思考ロジックのような、時間もメモリも切り詰めなきゃダメなようなものに オブジェクト指向を持ち出すのが誤りってことだな 前々から言われていたことだが、不適切な題材だな やったとしても、「思考ロジック」っていう巨大な一つのクラスがほとんどのことを受け持つ いわゆるGodクラスになってしまうだろう それが一番早く動くなら、将棋にとってはそれが正義 しかも将棋のルールはほぼ固定されていると考えてよいから 変に柔軟性を与えて仕様変更に強くする意味もないしな パラメーターで対応すれば十分 動画のエンコーダーとかといっしょで、規格ものなんだよ 規格が決まっていて、速さや効率が求めらえるなら ハードコーディングも辞さない 857 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 16:38:53.32 ID:uH1/jPAH.net] こういう実時間が足りないタイプのアルゴリズムは データ構造まで工夫する必要があるからね。 いちいちメソッド呼んでデータを取ってきたりしない。 取ってくるにしても駒の動きなんて変わらないんだから 最初に一括して読み込めばいいしそれはファイルから読み込めばいい。 （その後内部で工夫されたデータ構造にして、あとは内部で完結させる） 858 名前：デフォルトの名無しさん [2016/05/29(日) 16:58:54.31 ID:hqWpcQ8C.net] vtable使うなんてもったいない世界だよなぁ 859 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 17:18:08.73 ID:nD7S98HF.net] 工数気にするならボナンザ使えば？ 品質も良いと思うよ 860 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 17:48:41.04 ID:Cf71caC3.net] >>840 >あのレベルの設計で、コーディングの方針が決まればいいけど これについてはまだ設計の途中だからさ。現段階では決まってないけど設計が終わる頃には明確になってる。 まあ、設計段階ですべての問題を洗い出すことが難しいのは同意する。 861 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 17:54:21.52 ID:Cf71caC3.net] >>841 MoveGeneratorとMovePickerの役割はちゃんと説明してあるんだが…。 あと、どういう設計を想定しているのか分からない。 言ってる内容がエンドユーザの要件みたいで、設計者の設計じゃないように感じる。 考えてることを明確にするために設計者はモデリングを利用する訳で、設計者同士の会話は モデリングあるいはコンポーネント・クラスなどを明確にして記述して欲しい。 862 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 17:59:16.14 ID:Cf71caC3.net] >>842 何度も繰り返してるけど、時間もメモリも切り詰めた設計はどうなるか提示してくれ。 863 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 18:00:53.32 ID:Cf71caC3.net] >>845 将棋ソフトを作る気はないから。 864 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 18:09:36.48 ID:uH1/jPAH.net] >>847 > MoveGeneratorとMovePickerの役割はちゃんと説明してあるんだが…。 だからそれが意味不明だって。 お前のは、単に分けているだけで 分ける理由が存在していない。 865 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 18:10:53.57 ID:uH1/jPAH.net] >>848 > 何度も繰り返してるけど、時間もメモリも切り詰めた設計はどうなるか提示してくれ。 [ 思考ロジック ] 866 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 18:16:58.80 ID:uH1/jPAH.net] 思考ロジック以外の部分まで書いていいなら これでもいいがｗ [ 思考ロジック ] - [将棋UI] もう少し細かく言うのなら将棋の駒の配置は、 思考ロジックでも使うが将棋UIでも使う共通情報だから という理由で分離して [ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI] 思考ロジックは、駒の配置データを参照して、駒の配置データを書き換えるという役目。 将棋UIは駒の配置データを参照して、それをUIとしてレンダリングする 将棋UI は更にその内部で、将棋盤オブジェクトや駒オブジェクトとして 2Dや3Dでレンダリングされるが、これは完全にUIの話で思考ロジックとは切り離すべき話だよねｗ オブジェクト指向で設計するならばこれぐらいの話だな。 867 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 18:21:29.72 ID:uH1/jPAH.net] 時間もメモリも切り詰めた設計っていうのもちょっと質問の意図が不明で 時間を切り詰めた実装でも、メモリを切り詰めた実装でも、 一台のマシンを使う実装でも、多数のマシンを使う実装でも 「どんな実装にも変更可能な設計」というのなら、これは設計なわけで正しい。 つまり × 時間もメモリも切り詰めた設計 ○ 時間もメモリも切り詰めた実装 時間やメモリを切り詰め ”られる" のは、それが可能なように設計で考慮するべきことだが 時間やメモリを切り詰め "る" のは設計で決めることじゃない。 868 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 18:27:50.97 ID:hqWpcQ8C.net] >>848 >何度も繰り返してるけど、時間もメモリも切り詰めた設計はどうなるか提示してくれ。 何度も言われてる気はするがほぼ思考ロジックの話になるからオブジェクト指向でやる意味なくね 具体的にどのアルゴリズムを選ぶか？ それが「時間もメモリも切り詰めた設計」となる 振る舞いと実装の分離とかしないわけよ >>852が言ってるようにオブジェクト指向でやる意味あるUIくらいだよ 869 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:05:09.06 ID:Cf71caC3.net] >>850 正しいと思う設計を具体的に示してくれ。 面倒くさくなってきたから明示できないならもういいよ…。 870 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:06:07.22 ID:uH1/jPAH.net] >>855 [ 思考ロジック ] 書いてあるよね？ なんで見えてないの？ 871 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:07:21.11 ID:uH1/jPAH.net] [ 思考ロジック ] ↑ 思考ロジックの正しい設計 [ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI] ↑ UIまで含めた、将棋ソフトの正しい設計 872 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:08:04.03 ID:Cf71caC3.net] >>85 で、設計は？って聞かれると>>652とか答えちゃう訳？ｗ 873 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:10:04.28 ID:Cf71caC3.net] >>857 おっけ、おっけ。 設計に対する前提がかけ離れ過ぎてるから話しても無意味だと分かった。 874 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:12:52.55 ID:uH1/jPAH.net] >>652はコード（実装）書けって書いてあるから 実装書いてあるだけだろｗ 875 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:13:21.23 ID:uH1/jPAH.net] >>859 結局、設計の話してもこうやって無視するわけだ？ 逃げるな卑怯者 876 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:20:13.35 ID:Cf71caC3.net] >>861 率直に言うと、レベルが低過ぎてお話にならないと判断した。 将棋ソフトを設計しろって言われて [ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI] だけ書いて完成したと思うのは>>652並みのお粗末さだぞ…。 思考部分のコンポーネント図が間違っているというなら訂正したコンポーネント図を書けよ。 [ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI] って何じゃそりゃ？ 877 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:22:38.20 ID:uH1/jPAH.net] >>862 お粗末ってなんだ？ 設計というのはシンプルにするものだ。 たくさん書けばいいってわけじゃねーぞｗ 878 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:23:38.63 ID:uH1/jPAH.net] だいたい、間違っていると思うならば、 お前こそ、間違ってる理由を言えよ。 お前が考えるさいきょうのせっけい（笑）の紹介じゃなくて、 何が間違っているのかを言えって。 879 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:25:48.76 ID:uH1/jPAH.net] 思考部分のコンポーネント図が間違っているというなら訂正したコンポーネント図を書けよ。 [ 思考ロジック ] ↑ 思考ロジックの正しい設計 何度も言ってる 880 名前：デフォルトの名無しさん [2016/05/29(日) 19:31:51.54 ID:nCNZLCDh.net] ID:Cf71caC3 もうほとんどあらしだな 881 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 19:45:13.81 ID:hqWpcQ8C.net] >>862 レベルが低い以前に話聞いてないじゃん 将棋の思考ロジックの設計なんかはもうアルゴリズムの設計とほぼ同じ 計算機科学の分野でしょ 882 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 20:19:13.03 ID:vZz5+wdA.net] ざっくりいうとさ、将棋の盤のデータは char ban[9][9]; こんなんで十分なわけでしょ これに相手と自分の持ち駒の配列を付け加えて あと少々何かあればそれで充分な世界 人によってはcharですらデカすぎるというかもしれない この時点でオブジェクト指向らしさは全然ないよね どちらかといえば画像処理とかに近いデータ構造 将来将棋が仕様変更して、いきなり金の振る舞いが変わるとか そういうことはあり得ないから、駒をオブジェクトにするとか意味不明なことはする必要ないし オブジェクト指向でよく言うような、仕様変更に強くするとか 継承とオーバーライドで差分プログラミングとか、全く関係ないよね だって、将棋のルール(仕様)は決まっているわけだからさ、仕様変更とか考えなくてよい むしろ実行時間や効率が問われているのだから 意味のない柔軟性を持たせる分のオーバーヘッドがもったいないし、必要もない 883 名前：デフォルトの名無しさん [2016/05/29(日) 20:30:30.60 ID:Cf71caC3.net] >>868 モジュール構成は？ 相互の関係は？ コンポーネント図を見ればどういう領域を整理しようとしているかくらい分かるだろ？ 884 名前：デフォルトの名無しさん [2016/05/29(日) 20:32:05.69 ID:Cf71caC3.net] あと>>608もな。 885 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 20:42:21.72 ID:f/sZpflr.net] 察して欲しかったら察してもらえるように言葉考えて伝えなよ。 業務プログラマなんだろ？ 886 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 20:44:29.81 ID:uH1/jPAH.net] [ 思考ロジック ] ↑ 思考ロジックの正しい設計 [ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI] ↑ UIまで含めた、将棋ソフトの正しい設計 > コンポーネント図を見ればどういう領域を整理しようとしているかくらい分かるだろ？ これみて、どういう領域を整理しよとしているかわからないの？ｗ 887 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 20:59:39.40 ID:1omdCt5G.net] 外とのインタフェースだけきめて内部はTDDすれば勝手に決まっていく派 最初から全部決めようなんて無理無理 888 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 21:03:08.22 ID:1mIQzqS0.net] AIモジュールはハードウェアも絡むからOOPはない 将棋ソフト全体をOOPで作ったとしてもAIモジュールとはだいぶ隔たりがあるよ ユーザーの入力した結果から低レベルな盤面データを生成して丸ごと渡すだけとかそんなレベル 889 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 21:13:37.84 ID:vZz5+wdA.net] いやだからさ、将棋ってのはルールが決まっているんだよ 歴史のあるゲームであって、いきなりルールが変わって金の動きが変わるとか そういったことは今の時点では全く考慮する必要がないわけだよ で、オブジェクト指向のメリットは、大体において仕様変更に強くすることなんだよ 仕様変更が全くないのであれば、どんな方法でどんな汚い書き方をしたって プログラマだってプロなんだから、書き上げることはできるんだよ ただ、突然の仕様変更は怖いよねって話で、そのためにオブジェクト指向にコストを掛けているわけじゃないですか その点、将棋はルールが決まっていて、仕様変更など気にする必要ないし むしろ実行速度が強さに直結していて、一手でも先を読んだ方が有利なわけだから 仮想関数なんかを使うオーバーヘッドがもったいないし その二つの面からオブジェクト指向である必要性が薄い題材 仮にオブジェクト指向で作ったとしても、仕様変更がないことが分かっているわけだから オブジェクト指向設計の腕の見せ所が全くないし、題材として不適切なんだよ 将来にわたって必要の無いであろう拡張性や柔軟性を持たせても、無駄が多いと言われるだけ 将棋のAIのアルゴリズムには大変興味深いものがあるとおもうが オブジェクト指向としては見るべき点が「全く」ない 890 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 21:32:59.51 ID:vZz5+wdA.net] つまりは、将棋AIをオブジェクト指向で作るにあたって、どんなに不味い設計をしたとしても 仕様変更が発生しない題材なわけだから、オブジェクト指向的に良いも悪いもなく、動けばOKだよねっていう話になる どんなに不味いオブジェクト指向の設計であっても、仕様変更さえなければ大体は問題にならない 当初の予定通り動く ついでに、将棋AIである以上は強くなくてはならない この強くなければならないという案件は、通常ではない 業務システムが他のシステムと喧嘩して勝っただの負けただの言わない 普通は仕様変更に強いように、拡張性があるように、プログラムを設計するし オブジェクト指向の設計の良し悪しもそこに集約されるわけだが 将棋AIは強さが求められているわけで、オブジェクト指向設計でいうところの 良し悪しとは違ったものが求められている しかも仕様変更がない、とくればハードコーディングも止む無しだろう 891 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 21:36:48.37 ID:JprInoKj.net] 暗黙のうちに拡張将棋が題材になってるんでしょうね ワープ駒とか二回倒さないと死なないとか 範囲攻撃とか装備とかアイテムとか擬人化とかイケメン武将とかキャラアドオンとかガチャとか課金とか マルチプラットフォーム対応もするしサービスとして長くメンテナンスし拡張を加えていく前提 当然AIもそれに対応しなければならないからゲームやアプリは良くモデル化されていなければならない 892 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 21:38:49.46 ID:uH1/jPAH.net] >>877 で、そんなことを言い出すと。 YAGNIだってとどめを刺すわけだｗ だからそうする目的を聞いている。目的がないのにわざわざ分割するのは、 必要だからやるのではなく、設計（？）をすること自体が目的になっている。 893 名前：デフォルトの名無しさん [2016/05/29(日) 21:47:24.89 ID:Cf71caC3.net] >>877 現実のプロジェクトなら設計者が設計書に記述するであろう内容についての前提が違うんだと思う。 「将棋ソフトを設計してくれ」って客に言われたら、オブジェクト指向だろうが、他の設計手法だろうが 構成を記述しないってことはあり得ないからさあ。 そこを分からない人に説明してもしょうがないことは分かったから流すようにする。 毎日IDが変わるから新しい人かもと思って対応していたけど、どうも同じ人みたいだし、 対応してもスレが汚れるだけだからスルーすべきだったと反省。 894 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 21:50:11.02 ID:uH1/jPAH.net] > 構成を記述しないってことはあり得ないからさあ。 構成は記述されてありますが？ そもそも将棋ソフトを設計してくれって言われたら 思考ロジック部分だけを設計しませんよｗｗｗ [ 思考ロジック ] - [ 駒の配置データ ] - [将棋UI] こんな感じで設計します。 当然、思考ロジック部分は一つです。 シンプルイズベスト。理由がなければ分割しない。 895 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 21:52:08.59 ID:uH1/jPAH.net] 「将棋ソフトを設計してくれ」って客に言われたら、 どんな仕様か詳しく聞きますね。 その上で必要なら、それを満たすように設計しますが、 あんたのように何も言ってないのに過剰な分割なんかしませんよｗｗｗ 896 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 21:53:29.31 ID:1omdCt5G.net] 客の定義による ただ将棋ソフトで遊びたい人にとって内部設計なんてなんの意味もない 外部の人間が自分たちのソース引き継いでメンテするのが前提ってこと？ 897 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:04:37.03 ID:qPPHNZFg.net] 898 名前：ogg vorbis形式のファイルを自前でデコードして再生するソフトを「設計」しろとか、 円周率を出すソフトを「設計」しろとか、 そういう類の無意味な題材だってことが理解できているのか心配になる。 動物とか自動車とかモデル化するだけの人なのかもしれんが。 [] [ここ壊れてます] 899 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:05:37.63 ID:uH1/jPAH.net] >>882 何を言ってるんだ？ たとえばネット対戦をしたいって言えば それが出来るような設計にするだろ？ 客の要求を聞いた上で、それを実現できるように設計する。 客がネット対戦をしたいって言ってもいないのに あらかじめ先手（笑）を打ってネット対戦機能をつけましたとか それは過剰な設計であり無駄なコストを発生させたに過ぎない。 だからいきなり設計すんなって言ってるんだよ。 客の要望を聞いて、必要であるという理由があれば それが可能なように設計すればいい。 だから、そうした理由を聞いてるのに、明確な理由もなくて、 そうするのがいいと思いましたーでやってるから馬鹿にされてるんだよ。 900 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:06:35.28 ID:1ogDAOAr.net] 別に思考ルーチンも学習機能なんて要件に上がってないしね ここで話せるのはここまでじゃん だから題材が悪いって俺が最初に言ったじゃん 基本的にオブジェクト指向ってz80で作れるものに威力を発揮しないんだよ 将棋ソフトなんて作ったこともないのに題材に選んだ奴責任とって腹切れ どうせ設計に必要な項目も他人に説明できないしできなかっただろ それは将棋ソフトの全容が他人に聞くまでもなく みんなある程度わかっちゃってるからなのさ 901 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:07:18.13 ID:+DJ914Ec.net] >>883 できるだけ抽象的に作ればいいと思ってる抽象馬鹿だと思われ。 902 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:09:35.02 ID:uH1/jPAH.net] >>883 ogg vorbis形式のファイルというのは、正確には音声ファイルフォーマットで Oggがコンテナ、Vorbisがコーデックという設計で、 元々内部の役割が分割されてるからちょっと違うけどねｗ 903 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:11:26.67 ID:uH1/jPAH.net] >>885 > 将棋ソフトなんて作ったこともないのに題材に選んだ奴責任とって腹切れ ↓こいつかな？ｗ 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 具体例があったほうが分かりやすいから将棋ソフトの例で考えてみてよ。 904 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:14:11.15 ID:auBo7N3K.net] スーパーエヴァンジェリストの僕がこのスレの混乱の原因を教えてあげよう ここには顧客ロールの担当者がいないのさ 905 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:17:37.23 ID:1ogDAOAr.net] 要件定義が曖昧なのに求めてる設計書のレベルが見合わないんだよね はじめの話で思考ルーチンが ディープラーニング当然でしょみたいな話になんて絶対ならないわけで 906 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:19:59.67 ID:+DJ914Ec.net] んでは OS の設計でもしてみるかい？ Linux あたりと比較できるしいいんじゃないの？ よりよいオブジェクト指向で設計してもらいたいですな。 907 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:24:35.04 ID:hqWpcQ8C.net] ＞要件定義が曖昧 これ　「将棋ソフト」を設計しろだと いきなり実装の話に入らざるを得ない 908 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:26:13.01 ID:uH1/jPAH.net] >>890 > 要件定義が曖昧なのに求めてる設計書のレベルが見合わないんだよね それもあるけど「何のためにそうしているか？」が存在しないんだよ。 いえばいいだけなのに、言わない。 そうするのが当然だって思い込んでる。 909 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:27:58.83 ID:uH1/jPAH.net] >>892 お題だから、いきなり実装の話に入ってもいいんだけどさ、 それならそれで、どういう「要件を想定した」っていうのを 明確に言わないといけない。 それを言わずに、なんかわけのわからん分割の仕方をしてるから 突っ込み入れられまくってるわけ。 910 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:33:44.93 ID:RrRCCmyQ.net] スレタイに沿ったオブジェクト指向の設計なら 将棋の駒はクラスで正解 しかし設計のきれいさではなく 処理速度を求めるなら構造化で書く 前提が違うのにみな上から目線で書きこむから ただ混乱するだけ やっぱ2ちゃんは雑談はともかく ちゃんとした議論に向かないな 911 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:35:40.39 ID:1ogDAOAr.net] 要件定義がグチャグチャだとダメだね 得に将棋ソフトなんて疑問が無いもん 勝手に作っちゃうでしょ そこは要件を出した方も悪いし聞かないまま進めちゃう方も悪いし 912 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:36:26.79 ID:uH1/jPAH.net] > 将棋の駒はクラスで正解 それはゲームとかで駒を 2Dや3Dでレンダリングする時の話だよｗ 思考ロジックの中でクラスにする理由はない charなりintなりの二次元配列に defineで定義した定数を入れれば十分 913 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:40:50.33 ID:RrRCCmyQ.net] >>897 処理速度を考慮しない前提で言うと それはオブジェクト指向じゃなくて 構造化の考えから抜け出せてない 914 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:45:42.31 ID:1ogDAOAr.net] ところで将棋ソフトにオブジェクト指向を適用するとダメだね 駒なんかクラスにされたらどう作ってもクソになっちまう 915 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:47:10.49 ID:1ogDAOAr.net] でもオブジェクト指向的に将棋の駒をクラスにするのは間違ってないと思うな つまりオブジェクト指向ってもしかして（笑） 916 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:49:05.67 ID:uH1/jPAH.net] >>898 それで理由は？ 917 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:51:44.59 ID:uH1/jPAH.net] >>900 > でもオブジェクト指向的に将棋の駒をクラスにするのは間違ってないと思うな > つまりオブジェクト指向ってもしかして（笑） 最後まで書きなよｗ つまりオブジェクト指向ってもしかして、（思考ロジックの）将棋の駒を クラスにすることには役に立たない。 だろ？ だから俺は最初から何のためにそれをクラスにするのかと聞いてるわけ。 する理由がある、つまり適切な場所をオブジェクト指向にして、 こんな関数レベルの思考ロジックをわざわざ無意味に分割するんじゃないって言ってるんソア。 918 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:52:01.50 ID:+DJ914Ec.net] >>898 抜け出す必要がない場面で無理に抜け出そうとする事がそもそもおかしい。 オブジェクト指向は万能ではない、処理フローがほとんど決まってるものに対しては不向き。 919 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:54:48.91 ID:vZz5+wdA.net] 構造体どころかintかcharの配列で良いって話 charでも何か勿体ないという人もいるかもしれない 画像なら、画像全体が何らかのオブジェクトでラップしてあるならわかるが 画像の1ピクセル1ピクセルを全てオブジェクトにする人はいない こんなものはデータで十分 構造体的発想を抜け出せないというのも意味不明 データで十分なものをオブジェクトにする方が 何も理解していないと言いたい 920 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 22:58:31.03 ID:1ogDAOAr.net] >>902 でもさ 全員の共通認識を一致しやすいって手法だろ? でもこの方法は将棋ソフトに関してははっきり言ってクソ どう作ってもクソにしかならない オブジェクト指向ってダメなのかもしれんね

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef