オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
使い捨てのどうでもいいシステムは
使えない単価安い奴に
やらせとけって話じゃないの
まあ保守は作り始めた時点から始まってるから
リリースまで行けないかもしれないがな >>326
運ゲの麻雀で例える意味がわからない
せめてオセロとか将棋で例えろよ >>329
出来るよ
どっちも定石があるじゃん
そう言うこと
まあ麻雀よりはイメージしやすいでしょ >>331
デザインパターンて、将棋における定石みたいなもんじゃん
定石覚えてなくても駒動かせれば将棋はできるけどねー 定石の有用性を証明してみろ
できなければ定石は役立たずのゴミということ 定石は役立たずのゴミ
飛車は移動して右下隅の王を金銀桂馬香車で囲う
って言ったほうがわかりやすいじゃん
そもそも定石なんて知らなくても将棋はできるし、
何十年もやっていれば定石なんて自然に思いつく AIに以前からの定石がひっくり返されてるらしいなｗ
デザパタもAIにひっくり返される日も近いなｗ 将棋で言う定石はデザインパターンよりももっと粒度の大きいパターン
MVCかMVVMかみたいな
デザインパターンは手筋に近い
何十年もやってれば自然に思いつくことを
数週間から数ヶ月程度の断然短い時間で理解できるようになることや
より高い抽象度で物事を考えられるようになることに価値がある
おじいちゃんに何言っても無駄かもしれんが >>335
AIで新しい定石（デザパタ）ができるってことか？
それは嬉しいことだがｗ そりゃあ常識はひっくり返されるためにあるからな
ひっくり返ってそれが有益ならそれでいいじゃん >>336
> 何十年もやってれば自然に思いつくことを
> 数週間から数ヶ月程度の断然短い時間で理解できるようになることや
寿司学校に3ヶ月通っただけの店がミシュランになるなんて許せん
10年間下積みをしてやっと職人になれるんや。
寿司の修行ってのはなぁ、寿司の勉強じゃなねぇだよ そもそもこんなスレがあること自体おかしいんだよ
オブジェクト指向設計なんてやってればそのうちできるようになるし、それが人と比べてどうなのかなんて気にする必要もない
人それぞれのオブジェクト指向でいい >>340
それをあーやこーや言い合うのが子のスレなんじゃないの
デザインパターンを学習することによる不利益を逆に教えてほしいんだが >>342
麻雀の捨て牌議論といっしょで別に国士無双狙ってもええで
誰も困らん >>339
ネタじゃなく本気で寿司屋と比べてるなら
ソフトウェアの世界から早めに足洗って転職したほうがいいよ >>343
せめて会話しようぜ
言葉のキャッチボールをさ 寿司屋の板前っていうより半完成品を卸してる問屋みたいなもんだろ
で、おまえらはひたすらごはんを詰め込む係
プロパー様がネタを乗せて最後に元請け営業様がたんぽぽ乗せる スシローはIT化進んでるから寿司はオブジェクト指向で管理してるよな
インタフェース名はsushiと予想する オブジェクト指向スレで寿司の話題だから、
シャリを基底クラスに例えてネタごとにシャリクラスを継承、
軍艦巻インターフェイスの実装とか、お子様にはワサビプロパティをtrueにとか、
そんな話かと思ったら全然違った。 わさびプロパティってtrueとfalseのどっちだったらわさびが乗ってるんだ？ 寿司クラスのプロパティはシャリネタワサビだろ
スシローに関して言えばワサビのプロパティは不要 >>355
ワサビの状態は複雑だから真偽で取るなんてナンセンス わさびの量を調整したい場合はどう拡張すればいいの？
例えば罰ゲームで使うような山盛りわさび寿司
外国人向けの程よくわさび増量
あと、わさび巻の場合はわさびプロパティの内容はどう持つべきか？ というかあれか
寿司職人.putワサビ(寿司,量,状態)
かな >>363
キャットドアはやめろ
オブジェクト指向云々とは別のところに問題がある
またこの手の話するならちゃんと要件定義してからやれよ >>365
１つ賢い意見が出たな
要件定義をしないとキャットドアは作れない!
他のものもそうでないかな？ どういう用途のソフトウェアかに関係なく
オブジェクト指向でモデリングできると思ってるやつが多々いるのはオブジェクト指向に密接に関係した問題 >>366
寿司屋はわかりやすくね？
キャットドアやるならまずドアを作ってから継承するなりで基礎がないと >>370
オブジェクト指向が間違っているのでは？（笑） オブジェクトという名前が悪い
責務指向とか役割指向の方が適切 >>359
enum ワサビ量 {なし, ちょっぴり, 少なめ, やや少ない, 普通, やや多め, 多め, メガ盛り, ギガ盛り, テラ盛り, ペタ盛り, ワサビのみ}; 処理の流れがあちこちに飛ぶし
あちこちから飛んでくるし
「これ誰が保守するんだ？」って気分になってる。
ちょっとした修正が今までならピンポイントでテスト合わせて30分位のところが
全体見るために3時間かかる感じ。
能力高くないと無理だと思うけど人手不足だし集められるかな？
もっと緩いオブジェクト指向でいいと思う。
こんなガチガチで上手くいったプロジェクトってあるの？ >>377
犬のしょんべんに当たっちまったな
自分以外の奴がソースコードを読めないようにする工夫だそれ
元凶がインターフェースで
継承してあるすべてのクラスのインスタンス作成箇所全部をチェックしないと処理がわからない チンポについて教えてください。
チンポをインスタンス化して、引き数にマンコを持つキンタマメソッドの戻り値
ザーメンを取得したいのですが、コンパイル結果がフニャチンになります。
どうしたらいいですか。 >>377
それガチガチなんじゃなくて設計や実装が下手なだけ >>377
ほんとにガチガチならそのクラスを作ったやつの後任者〜お前の前任者までの間で間違ったクラスの使い方が広まったんだろうよ “これはこれをする奴”と一目でわかって
処理飛ばした後はそいつがよしなにやるから
細かいことは考えなくていい。
というのがオブジェクト指向の売りだから
「コイツはなにやってんだよ！」と処理追うのに混乱するようなのは
基本を履き違えてる気はする。
変なとこから流れてきた自称プログラムのプロがやりがちな
暗号みたいなクラス名とか だいたいインターフェースが元凶だって
実行してみないとわかんねーし インターフェースが現況って言ったってクラス名とメソッド名である程度目的はわかるようになってるんじゃねえの
それができてないなら単なる設計ミスじゃん >>386
バカの作るインターフェースは思いつきで入れた汎用性を実現するものだからそもそも設計書に書かれない >>387
そういうもんか
そういう用途で使うべきではないわな >>384
手続き型みたいなのでバグ探すと、大体1ファイルの中見て
処理の流れもその中だけ追えば良くて
シンプルな流れだからチョイチョイってできるけど
完全なオブジェクト指向だと、
｢この値を設定してるのは、ここ、
…、
じゃなくて、コイツ他のとこで設定してるのか〜、
ここ？
あ、もっと上か〜｣
みたいにあちこち辿っていくから
あんまり良いことに感じないけど。
影響範囲も広いし。
考えなくていいのは、製造するときに何が何をすると
ハッキリと決められてる時で
どこにバグあるかとか見るときは
｢ここだろう｣と最初に思ったとこではなかったりしなくね？
設計が難しいなら、
バカでもできる簡単な設計で済む手続き型最強な気がする。 >>389は詳細設計書位しかなくて、クラス図とかもろもろないケースの話で。 >>389
ガチガチのオブジェクト指向ならその値がどこで設定されたなんか関係ないよ
今受け取った値に対しての動きをするだけ ワンインスタンス内ではメンバはグローバル変数みたいに振る舞うから
継承多くなるとっていうかある時点でクソ言語になるんだよね >>389
＞>>384
＞手続き型みたいなのでバグ探すと、大体1ファイルの中見て
＞処理の流れもその中だけ追えば良くて
＞シンプルな流れだからチョイチョイってできるけど
これはむしろオブジェクト指向の特徴だね
＞完全なオブジェクト指向だと、
＞｢この値を設定してるのは、ここ、
＞…、
＞じゃなくて、コイツ他のとこで設定してるのか〜、
＞ここ？
＞あ、もっと上か〜｣
これは典型的な手続き型のデバッグだよね
もしかしてスレ加速を狙ってわざと間違えてる？ >>393
それ明らかに俺から見て逆だわ
処理に対して一旦オブジェクトで纏めるオブジェクト指向がそこの辺シンプルになるわけねーだろチンカス >>394
あ〜
うん
まあそういう人も居るよね
存在を否定はしないよ
民主主義国家の人民は自由であるべきだ >>395
393で言いたいことはまぁわかる
けど自分が多数派であると思い込んでるのはおかしい
おまえの中の「〜べき」って論は他人に通じないので押しつけないで >>396
いろんなコミュニティに顔だしてみなよ
リアルが無理ならネットコミュニティだけでもいい
>>393が常識的な認識だよ 呼び出し階層が深いだけで可読性が低いなら抽象化が下手なだけで、オブジェクト指向に限った話じゃない
呼び出し元や定義にジャンプする機能のないエディタ使ってると辛いとか
DIでコンフィグから実装を注入してると追うのが面倒くさいとかなら分かる >>397
おまえの中ではそうなんだろうな
繰り返すが393で言いたいことはまぁわかる >>398
> どこにそんなの書いてあるんだよ
いろんなコミュニティ いろんな考えかたの人がいる
それは認めるべきだ
オブジェクト指向が好きなやつも手続き型が好きなやつもみんな自由と権利を持っている
でもここはオブジェクト指向のスレなので
手続き型に興味があるなら手続き型スレで議論を深めればいいんじゃないかな？
手続き型システムの設計 1 [無断転載禁止]©2ch.net･
http://mevius.2ch.net/test/read.cgi/tech/1500282714/
オブジェクト指向がわかりにくくて嫌いだからといってもオブジェクト指向のコミュニティを荒らしてもいい理由にはならないだろう
住み分けは大事だ >>401
なんだそのキチガイコミュニティ
2〜3個リンク貼ってみろ
潰してくる ガチガチに手続き型で組んだプログラムなんて見とうないわ
あちこちに飛ぶから云々ってマジでいってんのか あちこち飛ぶからいいんじゃねえか
飛ばなかったら全ての処理が一箇所に集まってパンクするだろw 飛び方がキレイな木の枝のようになっていればよい
枝から枝へモモンガのように飛ぶ処理が入っていたら地獄だ というか、オブジェクト指向はクラスに責任を持たせることで
責任が遡ったり他へ波及するのを防ぎデバッグも局所化して容易にする思想なので
どこかで一目でわかるように「この値を設定する一意の責任を持つのはおまえ」と
責任を持った誰かがいて、正しく作ってればそこから周りにゴミが飛び散るはずがないので
＞｢この値を設定してるのは、ここ、
＞…、
＞じゃなくて、コイツ他のとこで設定してるのか〜、
＞ここ？
＞あ、もっと上か〜｣
とか、それのどこがオブジェクト指向だ。>>393と同じ感想 >>410
意味わからんけど
どんな使い方してんねん 素人がインターフェースを使うと実装に強く依存してしまうことがある
実装クラスの内部的な挙動を前提にするとかね おまえらおしゃべりしたいだけだろ
リアルで交流しろや >>408
なに？ お前、モモンガ先輩の事ディスってるの？ しっかり役割を分担しないとオブジェクト指向の利点をいかせないと言うことか >>416
利点も何も役割分担できてないならそもそもオブジェクト指向じゃないよ >>418
いやだから、インターフェイスってそういうもんじゃん オブジェクト指向の設計の話をしてると
このクラスはこのことを知ってるべきだ、イヤ知らないべきだ
なんて話がよくあるが
アスペの代表的な特徴として自分の視点でしか考えられない
ということかあるのでアスペにOOは無理 >>421
確かにアスペに取り扱いは難しいな
だが言うなればオブジェクト指向はアスペクラスの集合体だからアスペ視点は大切 ■ このスレッドは過去ログ倉庫に格納されています
