オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
使ってない証拠を>>280が出してくれるまで
誰も信用しないように >>282
見たことねーｗ
連徹過ぎて記憶が飛んだ覚えしかねーわｗ
俺が関わったとこはまともな資料なんて無かったな
俺が実践で使えると思ったのは
N○Cだけだけどね
ここは１回行ってみる機会があれば
いい勉強になると思うな >>283
> ぶっちゃけ、三○もN○Tもニ○ンもコニカミ○ルタもpana○onicもス○エニもシ○ープもN○Cも沖○気もク○タも富○通も
> 富士○機も東京○力も関西○力もS○NYも
> 使ってないから
> ここは１回行ってみる機会があれば
> いい勉強になると思うな
派遣の仕事って楽しい？ > 俺が実践で使えると思ったのは
> N○Cだけだけどね
> ここは１回行ってみる機会があれば
> いい勉強になると思うな
NECのこれを受講すればいいのかな？
https://www.neclearning.jp/courseoutline/courseId/JV104/
システム開発における詳細設計の位置付け、作業内容、
JavaEEアーキテクチャの特徴を学びます。また
、JavaEEを使用したWebアプリケーション開発に用いる主要な
デザインパターンとその適用方法を設計演習を通して修得します。 >>287
そんなんじゃねーよ
ちゃんと要件定義書から設計、実装までルーチンワークで作れるマニュアルがあるんだよ
見てねー奴も多いんだけど
作った奴天才だと思ったわ ルーチンワークしてるやつには
考える必要がある設計は不要だよ
お前は何も考えなくていい ルーチンワークで十分な仕事しかしてないだけだし
ルーチン化できると言う割に自動化はしないあたり本当はルーチン化できてないんだろうなぁ >>290
考えないとわからないところなんて俺らの仕事の範囲ではないのかもな >>291
> 考えないとわからないところなんて俺らの仕事の範囲ではないのかもな
だから設計は、俺ら＝お前の会社の同僚 の
仕事の範囲でないんだろ？ いやまじ、使わないというのは正しいんだろうよ
使わないから必要ないと思ってる時点でおさとが知れるというだけなのでは 伝言ゲーム理論を使えば三段論法で
デザパタが使われていないことを証明できる
デザパタは
俺は使わない
↓
それは使わない
↓
どれも使わない
↓
だれも使わない
↓
使わない
↓
故にデザパタだ誰も使っていない iOSアプリ開発で公式ドキュメント読んでて
これなんかObjective-C固有のプログラムガイドかと思ったら
アップルのシステムやアプリじゃ実際にこんなパターンを使ってるよ参考にしてね！
だったっけなぁ…
Objective-C プログラミングの概念
https://developer.apple.com/jp/documentation/CocoaEncyclopedia.pdf
現行でこういうのを使いまくった上でiPhoneやiPadが町中で日々動いてるわけで
デザインパターンは無いんだ！デザパタ厨が！とか言われても
おじいちゃん、そろそろ引退したら？としか… >>296
マジ書いてあんなｗ
多くのCocoaアプリケーションでは、モデルオブジェクトの状態が変化すると、
その通知はコントロー ラオブジェクトを 経由して ビューオブジェクトに伝わります。
図 7-2にこの様子を示します。2つの基 本的なデザインパターンが関与していますが、よりすっきりとしています。
図 7-2 複合パターンとしてのMVC（Cocoa）
User action
Update
Update
Notify
Mediator Strategy Controller
ModelView
Command Composite
Observer
この複合デザインパターンでは、コントローラオブジェクトはMediatorパターンと
Strategyパターンを 包含しています。モデルとビューの間でやり取りされるデータフローを、
両方向とも仲介していま す。モデルの状態変化はコントローラオブジェクトを経由して
ビューオブジェクトに伝わります。さ らに、ビューオブジェクトには、ターゲットアクション
機構の実装という形で、Commandパターン も含まれています。 もう一つ
複合デザインパターンとしての
MVC「Model-View-Controller」は、より基本的なデザインパターンをいくつか組み合わせた形のデザインパターンです。
基本パターンどうしの組み合わせにより、MVCアプリケーションを特徴づける、機能の分割や通信経路を定義しています。
しかし従来型のMVCは、組み合わせる基本パターンが、現在のCocoaのそれとは違っていました。その違いは主として、
コントローラオブジェクトやビューオブジェクトに与える役割に関するものです。
当初の（Smalltalk流の）考え方では、MVCはComposite、Strategy、Observerというパターンから成っていました。
Composite：アプリケーションのビューオブジェクトは、実際には入れ子になったビューの
複合体（composite）であり、このビュー群が協調して（ビュー階層の形で）動作します。この表示コンポーネントは、
ウインドウを頂点とし、その下にテーブルビューなどの複合ビュー、さらにその下にはボタンなどの分割できないビューがあります。
ユーザ入力や画面表示の処理は、複合体を構成するどのレベルでも可能です。
Strategy：コントローラオブジェクトは、いくつかのビューオブジェクトに対する戦略（strategy）を実装しています。
ビューオブジェクトの機能は（視覚的）表示に関わる範囲に限定し、インターフェイスの振る舞いが当該アプリケーションに
おいてはどのような意味を持つか、の判断はすべてコントローラに委譲します。
Observer：モデルオブジェクトは、自分自身と直接的な関わり合いがあるオブジェクト（一般にビューオブジェクト）の
状態が変化すると、その通知を受け取ります。 >>296
>>297
Appleはああ見えてソフトの会社だから
そういうとこはしっかりしてる ソフトウェアに強い会社（日本のハードのついでにソフトやってるとか
客の御用聞き会社とは違うやつ）は軒並みデザインパターンが
当然のものとして語られてる気がするね。
関数型のデザイン・パターン、第 1 回
https://www.ibm.com/developerworks/jp/java/library/j-ft10/index.html デザパタ使えないアピールするモチベーションが、デザパタ使ってない自分肯定でしかないのが見え見えだから、つまんない議論だよ 優越コンプレックスを抱えてる人は苦しいだろうなぁ
素直な心を取り戻せることを祈ってる >>26
凝った設計にもできるけど（たとえばDDDのドメインサービスとかさらに突っ込んだDCIのコンテキストベースで）
このくらいの要件なら自販機オブジェクトだけ定義して
在庫管理と商品種別はRDBで管理し、金銭投入→購入のタイミングで
SQLを発行して該当する飲料を商品種別テーブルからピックアップし、その後
在庫管理テーブルで在庫減らしのSQL発行で十分なのでは？
O/Rマッパーの使い方を学びたいならクラス図のようにオブジェクト化するのも手だけれども 意味不明なウンチク垂れてないでコードを書けコードを バターン君をいじめて
得るもんがあったのかどうか
各自寝る前に自問自答してほしい デザインパターンがいらないって言ってるやつは
実装側の視点でしか考えることができないってのがわかった。
これが得たものかな ん？これいつものあたまおかしいおじいちゃんでしょ。 >>308みたいに自演して
「結局キャットドアに戻ってきたな」とかだせえリセット図るの。
けっこうおっさん…つうより“じいさん”って歳で構造体から脳が進化してないから
オブジェクト指向側からのアプローチが歳で理解できない可哀想な初老 >>312
何の自演だよ？
どのレスと同じやつだと勘違いしたのか教えてくれ そろそろ設計の議論もやめるかって思う
プログラムってどう組んでも動くしね
正解なんてないんじゃないかなぁ？
って思うようになった
仮にあったとしてもそれをどうやって証明するのか？
非常に虚しい気がしてきた
デザパタ、オブジェクト指向使うだの使わないだの
どっちが正解もクソも組んで金もらえたらそれでしめーな話をグダグダうるせーよな給料安いくせに
今、組めている人間を否定することはできない
また、否定する必要もない
俺等が話してることは麻雀のどの牌を捨てたらいいか？みてーな話でどうでもいいんだよきっと
初っ端字牌がないから国士無双は狙っては駄目ですよ
って言ったところで実際に狙って来ちまったらそれを誰が否定できようか？
そんなくだらない内容なんだよ > プログラムってどう組んでも動くしね
動くだけじゃダメでしょｗ
最低限じゃん。
動くだけの汚いコードたくさん見たこと有るよ。 「プログラムを組む」っていう表現って何となく手続き的な臭いを感じる
プログラムを組み上げるものとして見てるってことだよね >>318
次の開発が無かったら保守にかけたお金は無駄だよね？
この辺は君等はトレードオフの問題を勝手にプラスサムの問題だと履き違えている
ぶっちゃけ馬鹿にしか見えないのであまりおおっぴらに言わない方がよい 汎用性はトレードオフのはずだ
なぜ君等はつければつけるほどお得みたいなアホな考えもってるんだ？
保守なんかねーよ（あるかどうかわからないじゃん） 改修の方向性も付けた汎用性が役に立たんようなもんだったらまるまる無駄であろ
でもこういう俺の確率が高い方もしくは損害が少ない方に倒す的考えも
所詮は麻雀の捨て牌議論と何も変わらないんだろうな
って話だな
やっぱ意味ねぇよな設計に拘るのはやめたほうがいいな
金にならねぇ >>316
> でも客からしたらどうでもいいよね
いくらでもコストがかかってもいいなんて言う客はいないよ >>320
> 汎用性はトレードオフのはずだ
汎用性の話はしてない
同じコードを何度も書いたり
コピペするとコストがかかるって話をしてる 使い捨てのどうでもいいシステムは
使えない単価安い奴に
やらせとけって話じゃないの
まあ保守は作り始めた時点から始まってるから
リリースまで行けないかもしれないがな >>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
犬のしょんべんに当たっちまったな
自分以外の奴がソースコードを読めないようにする工夫だそれ
元凶がインターフェースで
継承してあるすべてのクラスのインスタンス作成箇所全部をチェックしないと処理がわからない チンポについて教えてください。
チンポをインスタンス化して、引き数にマンコを持つキンタマメソッドの戻り値
ザーメンを取得したいのですが、コンパイル結果がフニャチンになります。
どうしたらいいですか。 ■ このスレッドは過去ログ倉庫に格納されています
