【OOP/D】ｵﾌﾞｼﾞｪｸﾄ指向を何故理解できないの？★5

【前スレ】

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★4
http://pc11.2ch.net/test/read.cgi/prog/1173529414/

NG推奨ワード： ◆tIS/.aX84

前回スレの成果

【入門者用：オセロプログラムの設計と実装】
・プロトタイプ・プログラム：　Othello.java (非OOプログラム)
・OO設計：　クラス図、インタフェース・ソース (C++)

【実務者用：受注システムのクラス設計】
・OO設計：　分析モデル
・課題：　　　いろいろ

【COBOL者用：COBOL→Javaマイグレーションの設計上の問題点】
・密結合によりﾃﾞｽﾏ化したシステムの事例： クラス図

【入門者用：オセロプログラムの設計と実装】
・プロトタイプ１： 七行オセロ　
　　　　　　　　　　　おにぃちゃん、見ちゃらめぇっ！目が潰れる！

#include <stdio.h>
int p,t,a,d,c,v,i,m[90]={0},s,r[]={-10,-9,-8,-1,1,8,9,10};void k(){if(m[p]==0)
for(i=0;i<8;i++){for(c=0,v=p+r[i];m[v]==3-t;v+=r[i])c++;if(c&&m[v]==t){a+=c;v=
p;if(d)do m[v]=t,v+=r[i];while(m[v]!=t);}}}char*h="・○●\n";int main(){for(i=
1,m[41]=m[49]=2;i<10;m[i++*9]=3)m[40]=m[50]=t=s=1;for(;;a=d=0){for(p=9;p<82;++
p)k(),printf("%.2s",&h[m[p]*2]);if(a)for(d=a=s=p=8;a==8;k())t-2?(scanf("%d %d"
,&p,&i),p+=i*9):++p;else if(s)s=0,printf("pass");else break;t=3-t;}return 0;}

【入門者用：オセロプログラムの設計と実装】
・プロトタイプ２： Javaオセロ (非OO java)

　http://vipup.sakura.ne.jp/512kb/src/512kb_8358.lzh

　※なおアップロードした人物は、作者ではない可能性が高いです。
　　　本当の作者の方、ごめんなさい。文句はアップロードした人へ

【入門者用：オセロプログラムの設計と実装】
・オブジェクト指向設計：クラス図

　　　　　　　　[Othelloゲーム]
　　　　　　　　△　　　　　　◇
　　　　　　　　│　　　　　　│
　　　　　　[ 試合 ]◇─[ルール]
　　　　　　　　◇　　　　　　↑従う
　　　　　　　　↓　　　　　　│
{ ルール, プレーヤ,　　　{ 審判, (進行係), プレーヤ,
　　　記録, 進行係, }　　　ゲーム盤, 石, }

　┏━━━━━━┓　　　　　　　　　　　　　　　　　 ┏━━━━━━┓
　┃進行係　 　 　 ┃　　　　　　　　　　　　　　　　　 ┃審判　　　　　...┃
　┣============┫　　　　　　　　　　　　　　　　　 ┣============┫
　┃先攻後攻決め┃　　　　　　　　　　　　　　　　　 ┃　　　　　　　　 .┃
　┃開始指示　 　 ┃　　　　　　　　　　　　　　　　　 ┃　　　　　　　　 .┃
　┃打ち順指示......┠───────────→┨お手付き判定.┃
　┃　　　　　　　　 .┠←───────────┨パス判定.　 　 ┃
　┃終了指示　 　 ┠←───────────┨終了判定　 　 ┃
　┗━┯┯━━━┛　　　　　　　　　　　　　　　　　 ┗━━━┯━━┛　　　　　　　　　　　　
　　..次││　開始/終了/手戻り/譜の再現　　　　　　　 　 　.│ﾁｪｯｸ
　　　　↓└────────────────→┐　　 .↓
　┏━┷━━━━┓　　　　　　　　打つ　　　　　　 .┏┷━━┷━━┓　記録 ┏━━━┓
　┃プレーヤ　　　.┠───────────→.┃ゲーム盤　　....┠──→┨記録　 ┃
　┠──────┨　　　　　　　　　.：　関連　　　 .┠──────┨　 　 　 ┗━┯━┛
　┃石の色　 　 　 ┃　　　　　　┏━┷━┓　　　　.┃石の配置　　　┠←────┘
　┠──────┨　　　　　　┃手　 　 ┃　　　　.┠──────┨　手戻り/譜の再現
　┃手を考える　　┃　　　　　　┠───┨　　　　.┃初期配置　　　┃
　┗━━━△━━┛　　　　　　┃石　 　 ┃　　　　.┃ﾘﾊﾞｰｽ　　　　　┃
　 　 ┌──┴──┐　　　　　..┃位置　 ┃　　　　.┃集計　　　　　...┃
　 　 │　　　　　　　.│　　　　　..┗◇━◇┛　　　　.┗━━━━━━┛
┏━┷━━┓┏━┷━━┓　 ┌┘　 └─┐
┃人　　　　.┃┃ｺﾝﾋﾟｭｰﾀ .┃┏┷━━┓┏┷━━┓
┣========┫┗━━┯━┛┃石　 　 ┃┃位置　 ┃
┃手入力　 ┃.考える↓　　　┠───┨┗━━━┛
┗━━━━┛┏━━┷━┓┃色　 　 ┃
　　　　　　　　 .┃戦略　 　 ┃┠───┨
　　　　　　　　 .┗━━━━┛┃ﾘﾊﾞｰｽ..┃
　　　　　　　　　　　　　　　　　 ┗━━━┛

俺メモ

●●オブジェクト設計は何故流行らないの？●●
http://pc10.2ch.net/test/read.cgi/prog/1167841734/

●●オブジェクト設計は何故流行らないの？●●02
http://pc10.2ch.net/test/read.cgi/prog/1169570260/

過去重複スレ
●●ｵﾌﾞｼﾞｪｸﾄ設計は何故流行らないの？（2）●●
http://pc10.2ch.net/test/read.cgi/prog/1169568701/

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
http://pc11.2ch.net/test/read.cgi/prog/1171808096/

【OOP/D】ｵﾌﾞｼﾞｪｸﾄ指向を何故理解できないの？★4
http://pc11.2ch.net/test/read.cgi/prog/1173529414/

【入門者用：オセロプログラムの設計と実装】
・オブジェクト指向設計： インターフェースレベルの天麩羅 (C++)

こいつらは目印用interfaceな。
石って名前はいまいちだが、汎用的な名前思いつかなかた(´・ω・`)
　位置interface：
　石interface：
　ルール情報interface：

こっちは処理系interface
　盤interface：
　　put石(石interface);
　　get石リスト();
　　get終了判定();　
　プレーヤーinterface：
　　put石(位置interface);
　　get終了判定();　
　ルールinterface：
　　checkルール(ルール情報interface);
　　戦術interface：
　　get駒位置();
　全体制御interface：
　　exec();

続く。。。

[設計レベルのクラス仕様書？のようなもの]

んで、オセロとか将棋とかの独自実装をする。

　位置クラス：
　　位置interfaceをimplementして作成。
　　位置情報を保持する。
　　ゲームによって保持する情報が変更される。

　石クラス：
　　石インターフェースをimplementして作成。
　　位置・状態(裏表)等を保持。
　　ゲームによって保持する情報が変更される。

　ルール情報クラス：
　　ルール情報インターフェースをimplementして作成。
　　ルールを判断するのに必要な情報を保持。
　　ゲームによって保持する情報が変更される。

　盤クラス：
　　singleton指定
　　盤interfaceをimplementして作成。
　　ルールクラスをinjection。
　　石instanceを保持。
　　ルールクラスのメソッドを参照し石が置けるか判断。
　　置けたら他の石インスタンスの状態を変更。

さらに続く。。

[設計レベルのクラス仕様書？のようなもの]

　プレーヤークラス：
　　プレーヤーinterfaceをimplementして作成。
　　盤クラスをinjection
　　プレーヤー情報を保持。盤に石を置く。

　ルールクラス：
　　プレーヤーinterfaceをimplementして作成。
　　渡されたルール情報instanceを参照しルールに従っているか判断。

　戦術クラス：
　　戦術interfaceをimplementして作成。
　　盤クラス・ルールクラスをinjection。
　　それぞれのクラスを参照し石を置く位置を決定。

　全体制御クラス
　　全体制御interfaceをimplementして作成。
　　main処理。ゲーム・プレーヤークラス・AI(戦術クラス)の管理を行う。

めんどくさくなた。。後は意見出して発展させてくれ。

ちなみに終了判定は、
全体制御クラス→プレーヤークラスのget終了判定()→盤クラスのget終了判定()で呼ばれる。
そうする事によってどのプレーヤーが終了したかが分かる。
でも、全体制御クラス→盤クラスでもいいかも。
プレーヤーinterfaceにget終了判定持つのはちょっと違和感あるし。

【入門者用：オセロプログラムの設計と実装】
・オブジェクト指向分析： プアなイメージのコラボレーション図

　　プアなコラボレーションの書き方
　　> OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
　　> オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。

+---------------+ 手を打つ　+---------------+
| プレーヤ　　　　　 |────→| ゲーム盤　　　　 |
+---------------+2　　　　　 1+---------------+
| 石の色※1　　　　 |　　　　　　　 | 石配置　　　　　　 |
+---------------+ (パス)　　　+---------------+
| 次の手を考える　|────→.| 初期配置　　　　　|
|　　　　　　　　　　　 |2　　　　　　1| はさまれた石を　 |
|　　　　　　　　　　　 |　　　　　　　 | 　ひっくり返す　　 |
|　　　　　　　　　　　 |　　　　　　　 | 終了判定　　　　　|
|　　　　　　　　　　　 |　　　　　　　 | 得点集計　　　　　|
+---------------+　　　　　　　+---------------+

※1 石の色は、黒を先手、白を後手とする。

【実務者用：受注システムのクラス設計】
・設計課題？らしきものの羅列

前ｽﾚ751: 「客」が「店」に入って「商品」を手にとって「レジ係」に渡して「金」を払う。
　　　　　　これって、括弧の奴をクラスにすればいいの？ 教えてエロぃ人
前ｽﾚ754:金じゃなくて「支払い」ならクラスにするかな。
　　　　　　現金　クレジットカード　商品券(つけ)

分析モデル１　　　　　　　　　　　　分析モデル２

　　　選ぶ
　┌　→ [商品] 　　　　　
　｜ 　　　　　　　　　　　　
　｜ 支払う 　　　　　　　　　
[客]　→　[店] 　　　　　　　　　　　　[客]　→　[店]
　　　　： 　　　　　　　　　　　　　　　　　　　：
　　　[支払] 　　　　　　　　　　　　　　　 [購入]
　　　　　　　　　　　　　　　　　　　　　　　↓　 ↓
　　　　　　　　　　　　　　　　　　　　　[商品]　[支払い]


点線部　　　　　　　　　　　　　　　　　　点線部
　「客」と「店」の関連「支払う」を、　　店から客に何らかの「商品 (物品やサービス)」を提供し、
　関連クラス「支払」として抽出　　　その対価として客が「支払い」をする。
　　　　　　　　　　　　　　　　　　　　　　　

【実務者用：受注システムのクラス設計】
・設計課題？らしきものの羅列

前ｽﾚ761:うちは特例としてサービス金券を出していて
　　　　　　月3万以上お買い上げしたお客様には10万以上の品は10%引き
　　　　　　それ以下は5.8%引きのサービスを行うを追加してください

[客　　　　　　]　----→　[店　　　　　　]
-----------　　　：　　　-----------
[買い物カゴ ]　　 .：　　 [商品　　　　 ]
[残高　　　　 ]　　 .：　　 [　　　　　　　 ]
[債務　　　　 ]　　 .：　　 [債権　　　　 ]
[クーポン　　]　　　：　　 [割引ルール]
[購入履歴 　]　　　：　　-----------
-----------　　　：
[商品を選ぶ]　　　.：
　　　　　　　　　　 　：
　　　　　　　　　[購入　　　　]
　　　　　　　　 ／　 ｜　　　＼
　　　　　　 　↓　 　↓ 　　　　↓　
[商品　　　　]　[請求　　　　]　[支払い　　]
-----------　----------　----------
[価格　　　　]　[合計金額　]　[支払い手段]
　　　　　　　　　[請求金額　]　[支払い金額]
　　　　　　　　　----------.　[クーポン　　]
　　　　　　　　　[割引適用　]

・オブジェクト指向で、構造体が必要に感じるようではまだまだｗ
・オブジェクト＝＝インスタンスではまだまだぜんぜんｗ
・関数＝＝メソッドではほど遠いｗ
・汎化＝＝汎用のああ勘違いｗ
・構造体＋関数＝＝クラスの単純理解ｗ
・クラス＋ポリモーフィズム＝＝オブジェクト指向な安直さｗ
・クラス実装＝＝オブジェクト指向設計な思い違いｗ

【実務者用：受注システムのクラス設計】
・設計課題？らしきものの羅列

前ｽﾚ766:別の店を相手にする場合は購入履歴はどうなる？

[客　　　　　　]　----→　[店　　　　　　]
-----------　　　：　　　-----------
[買い物カゴ ]　　　：　　 [商品　　　　 ]
[残高　　　　 ]　　　：　　 [　　　　　　　 ]
[債務　　　　 ]　　　：　　 [債権　　　　 ]
[クーポン　　]　　　.：　　 [割引ルール]
[　　　　　　　 ]　　　：　　 [顧客情報　 ]
-----------　　　：
[商品を選ぶ]　　　 ：
　　　　　　　　　　　 ：
　　　　　　　　　[購入　　　　]
　　　　　　　　 ／　 ｜　　　＼
　　　　　　 　↓　 　↓ 　　　　↑
[商品　　　　]　[請求書　　 ]　[支払い　　　]
-----------　----------　-----------
[価格　　　　]　[合計金額　]　[支払い手段]
　　　　　　　　　[請求金額　]　[支払い金額]
　　　　　　　　　----------.　[クーポン　　]
　　　　　　　　　[割引適用　]

前スレ >>1(==>>625) のカキコより引用

　スレッドを立てたものです。

　このスレは設計、実装含めた形でのOOに関する話題について語り合う目的で立てています。
　なので設計だけ、実装だけといった縛りは特にありません。
　設計には方針レベルからデザインパターンなどの実装設計レベルまで幅広くあります。

　いままでの流れをみるかぎり、各々OOに対する考え方や適用レベルが異なるため、煽りや中傷のレスが書き込まれていますが、
　書き込む方はどのスコープでOOを適用するかを伝えた上で書き込むのが良いかと思います。

　なお、私的な意見ですが、厳密に自分の意図を伝えるために実装サンプルと合わせて説明することは良いプラクティスだと思います。
　書き込みを読む方も、自分の考え方と違う考え方だからといって否定するのではなく、
　改善策や自分の考え方を書いてみましょう。

ということで　しばらくＯＯちゅ撲滅キャンペーンを展開することにする。

【実務者用：受注システムのクラス設計】
・設計課題？らしきものの羅列

前ｽﾚ768:基本的に返品はうけつけてないんですけど
　　　　　　クレーマーな客の無理やり返品・返金にも対応してください

[客　　　　　　] ────→ [店　　　　　　]
-----------　　　：　　　　　-----------
[返品商品　 ]　　　：　　　　 [商品　　　　　]
[口座　　　　 ]　　　：　　　　 [返品ルール. ]
[債務　　　　 ]　　　：　　　　 [債権　　　　 ]
[　　　　　　　 ]　　　：　　　　 [顧客情報　 ]
　　　　　　　　　　　：
　　　　　　　　　[　返品　　 　]
　　　　　　　　　-----------
　　　　　　　　　-----------
　　　　　　　　　[ルール判定]
　　　　　　　 ／　　　│　　　　 ＼
　　　　　　 ↑　　　　↓応じる 　↓応じない
[返品商品 　]　[返金　　　　] 　[リジェクト　 ]
-----------　----------- 　-----------
[購入価格 　]　[返金方法　] 　-----------
[返品送料 　]　[返金金額　]　 [客に通知　 ]
　　　　　　　　　　　　　　　　　　　[商品再返送]


前ｽﾚ794：返品はビジネス例外で返すべきでは

ﾜﾛｽ

【実務者用：受注システムのクラス設計】
・設計課題？らしきものの羅列

前ｽﾚ769:支払いは例外が多いんだよねえどこの会社も。
　　　　　　只とか相殺とか贈与とか割引、お釣りが無かったのでまけた、などなど

[支払い　　 ]
-----------
[支払方法[]]
[合計金額　]
-----------
[確認　　　　]
　　　　◇
　　　　｜
[支払方法]
---------
[金額　　　]
[確度　　　]
---------
[確度ﾁｪｯｸ]
　　　　 △
┌──┼──┬─────┬─────┬─────┐
現金　　　　　金券　　　　　クレジット　　　　債権相殺　　　クーポン/割引/オマケ/贈与
--------　　--------　　--------　　　　
入金済　　　 有効性　　　 信用　　　　　　　
--------　　--------　　--------
入金確認　　有効か？　　与信処理

【実務者用：受注システムのクラス設計】
・設計課題？らしきものの羅列

>>768 基本的に返品はうけつけてないんですけどクレーマーな客の無理やり返品・返金にも対応してください
→爺曰く、「ビジネス例外」処理サーバで処理との事。ｗｗｗ

>>771 在庫の引きあてトランザクション処理も追加してください
>>809 在庫をストックする場所は複数で、在庫連動をマネージする仕組みも必要
→まず、現在の在庫管理システムの仕様を調査して、受注時に在庫引当処理しるｗ

>>774 そのクラスが直販をしているメーカ本社であったとすると 代理店が複数あった場合はどうなりますか？
→いみふめ
>>807 直販&&一次代理店&&取次店&&二次代理店&&紹介手数料支払いルール&&大量業務販売卸
→日本語でおｋ
>>777 直販の仕入れ価格と、代理店の仕切り価格がばらばらだとその管理も考慮しなくてはなりませんね。
>>778 一次代理店と取次ぎ店と二次代理店があった場合はもっと複雑になってきますね。どーしましょうか？
>>808 同一商品の仕入先は多数でその時の相場で変動する
→価格付けルールの問題かと。

>>810 輸入品のため、予約注文はインボイス日時の予想をするシミュレータが必要
→で、一体何を設計して欲しいんだ？シミュ？それともインボイス日時を含めた受注処理？

>>813 個人のお客でもある一定ロット数以上の注文ならば業務販売卸価格を適用できる
　　　　 この場合は個人客の監査を行い、問題が無ければ顧客リストに登録できる仕様
→価格付けルール＋顧客管理システムへ丸投げだろｗ

【COBOL者用：COBOL→Javaマイグレーションの設計上の問題点】
・密結合によりﾃﾞｽﾏ化したシステムの事例

前前ｽﾚ737:
　それぞれの画面にはそれぞれ別クラスを用意するのが基本だろう。
　ただ、共通化される処理やデータは基底クラスにかけるから、クラス数が多くたって
　ソースの見通しは良くなる。
　普通はロジック部分は分離するから更にクラス数は増えるし、
　インターフェイスにすれば、それぞれ実装クラスがあるから更に増える。
　が、増えても設計がきちんとしていれば別に混乱もしないし、保守性も上がる。
　DB部分はDAOクラスで隠蔽してしまえばいい

前前ｽﾚ738:
　はぁ？全然根拠なーいｗ
　クラスが１００個２００個あったらどーすんだよ
　こんなんで継承なんて使ってて変更あったら地獄だぞ
　つか、間違いなく死ぬ
　リストで単純に２００個管理したほうがよっぽどよかったと絶対に後悔する
　
　こんなもん継承使ってツリーになんてするもんじゃない
　単純にリストで管理すればどんなに増えても構造は簡単
　ツリーは量が増えれば爆発的に複雑になっていく

前ｽﾚ240:
　とある数百人月規模のOO開発現場の基本設計で
　とんでもない継承/関連ツリーを見た事がある。
　・数百ある画面を、全て別々の画面サブクラスとして定義し、
　・データクラス、ビジネスロジック・クラスを
　　画面と密結合した形で画面毎に個別定義
　つー設計。

【COBOL者用：COBOL→Javaマイグレーションの設計上の問題点】
・密結合によりﾃﾞｽﾏ化したシステムの事例： クラス図

　　　　　画面abstract
　　　　　　　　△　
　　　　　　　　 ：implements
　　┌………┼………┐
　 画面1 　　画面2　　画面300
　　 ◇　　　　◇　　　　 ◇
　　 │　　　 (略)　　　 (略)
　画面1専用
　ｺﾝﾃｷｽﾄ
　　 ◇
　┌┴────┬───┐
　画面1専用　画面1専用　画面1専用
　入力ﾃﾞｰﾀ　　ｴﾝﾃｨﾃｨ　　 出力ﾃﾞｰﾀ
　(DTO)　　　　(POJO)　　 (ValueObject)
　↑　　　　　　　 ↑　　　　 ↑
　│参照　 参照│代入　 │代入
　└─────┼───┘
　　　　　　　　　　 ： n
　　　　　　　　画面1専用 　　　　← 天麩羅ﾊﾟﾀｰﾝで順次呼び出し
　　　　　　　　ﾋﾞｼﾞﾈｽﾛｼﾞｯｸ1〜n

【COBOL者用：COBOL→Javaマイグレーションの設計上の問題点】
・密結合によりﾃﾞｽﾏ化したシステムの事例：

前ｽﾚ251
　まぁこの手のシステムでは MartinFawler言うところの
　トランザクション・スクリプト・パターンに陥りがちなんだよな。
　あと、数百ある画面自体は、開発ﾂｰﾙでﾎｲﾎｲ作成できるっつうのに、
　そこに付帯する味噌っかすみたいなトランザクション・スクリプトを
　何百人月とかけて設計、コーディング、テストしてるっつうのが
　バカバカしいんだよな。

　・・・と、これで、
　前々ｽﾚ1 の主旨に沿って設計論を語る準備ができたぞ。
　後は任せたｗ

前ｽﾚ252
　実際COBOLやってた組織のシステム作るときは>240みたいな設計を押し付けられることが多い。
　しかも基本設計という名の下に。
　なぜか要件定義段階からStruts拡張自前フレームワークを使用するという前提までつけられる。
　
　本来であればサービスの1メソッド程度のものを、個別のビジネスロジッククラスとして定義させられたりしてな。

前ｽﾚ253
　要するに、メインフレーム系COBOLから、オープンシステムへのマイグレーションね。
　ユーザ企業本体の情報システム部門〜関連子会社の下請けに入る限りは、
　そこらへんに変な条件が付帯するのはしょうがないよな。

前ｽﾚ256
　今時、画面とB/Lの分離もできないっていうのが、致命的なんだよな。
　前ｽﾚ240 の設計は実装を分離しただけの代物だろ。

【COBOL者用：COBOL→Javaマイグレーションの設計上の問題点】
・密結合によりﾃﾞｽﾏ化したシステムの事例

前ｽﾚ261-265
要するに、あれはﾌｧｯﾄｸﾗｲｱﾝﾄ流の設計＋αだ。
ﾌｧｯﾄｸﾗｲｱﾝﾄの画面なら、IDEの画面ﾂｰﾙでｻｸｻｸ作れる。
その手のﾂｰﾙは大抵、１画面１クラスみたいなｺｰﾄﾞを吐き出す。
そしてその画面ｸﾗｽにﾐﾄﾞﾙｳｪｱ使ってﾘﾓｰﾄｲﾝﾀﾌｪｰｽ付けりゃ
画面部は完了だろ。
　(そのあたりはかなり枯れている)

問題はその後、＋αの部分だ。
個々の画面に密結合する形で、
画面専用のデータクラス、画面専用のロジッククラス
などというものの設計を許しちゃうから、
クラス数の爆発して、ﾃﾞｽﾏｰﾁ化する、って事。

問題はもう一つある。
１画面１クラスを頂点に、 画面単位で
COBOLﾌﾟﾛｼｰｼﾞｬ＝１ｸﾗｽとするﾋﾞｼﾞﾈｽﾛｼﾞｯｸ (Coplienのfunctorパターン)と、
構造体＝1ｸﾗｽとするﾃﾞｰﾀｸﾗｽ(J2EEﾊﾟﾀｰﾝのValueObject or DTO)を追加して、
なおかつそれを継承/関連でガンジガラメに密結合しちゃってる事。
これではﾋﾞｼﾞﾈｽﾛｼﾞｯｸもﾃﾞｰﾀｸﾗｽも再利用できない。

これらの問題の解決方法はただ一つ。
ﾋﾞｼﾞﾈｽﾛｼﾞｯｸやﾃﾞｰﾀｸﾗｽを、できるだけ画面に依存しない形(疎結合)にしろって事。
そのためには、設計に充分時間をかけて、判りやすい疎結合の手法を決めておけ
って事。
よく、「設計に時間をかける程品質が上がる」ってのは、
その類の問題を事前に検出して、その問題に対するｿﾘｭｰｼｮﾝを検討しておく
って事なんだ。

【COBOL者用：COBOL→Javaマイグレーションの設計上の問題点】
・密結合によりﾃﾞｽﾏ化したシステムの事例

おさんｽﾚ148 (69式)
ビジネスロジックに対する正しい対処法：

　そういうところに関わらない仕事で食っていく。
　ドカタ仕事はドカタに投げる。ドカタはそれが技術と思って喜んで作っては捨て作っては捨てを
　繰り返す。無限にデスマを続けながら、俺は先端技術者だぜｲｪｰｲと喜ばせておく。
　
　やっすい単金で。

>>6
この設計ではｗ

【オブジェクト指向設計の手順：UMLヲタ編】


前ｽﾚ446
【分析クラスの抽出】
View部
　　　　　　(略)
Model部
　Game　　１回戦分のゲーム
　Score　　対戦記録 (コマンドパターンで譜の再現等)
　Step　　　一手 (Commandパターン)
　Board　　盤面の管理
　Player　　プレイヤ (人間およびコンピュータ)
　Strategy コンピュータ側思考 (Strategyパターン)
あと、審判(指し手交代、パス判定、パス回数、終了判定、得点の管理)とか、
ルール(StrategyパターンでOthello/Reversi/源平碁等のルール切替)
があっても良いかもな。

前ｽﾚ667
【設計】
上の分析クラスをもとに、
その責務は何か、データは何を持つか、
どんな振る舞いをするか、ってなあたりを
シーケンス図かなんか使って詰めてけば
いいじゃないか。

もし、ドメイン・モデル以外の部分も問題にしたいなら、
バウンダリ/コントロール/エンティティ抽出してロバストネス図作って、
エンティティがドメインモデルに対応している事を確認して、
最後に、MVCなりDocumentViewに対応させればいいじゃないか。

ってUMLヲタが言ってたｗ

【オブジェクト指向設計の手順：おじゃばさま(仮名)】

前ｽﾚ601は難しく設計しているようだが、OOで設計するコツが少しある。
まず、そんなに後々の拡張や例外を考慮する必要はない。
これは優秀な構造化プログラマーが陥りやすい罠である。
構造化では最初の設計で見越した拡張性が後々の変更に大きく関わる。
そのためローカルルールやゲーム自体の変更を意識して設計するが、OOでは使用する部分としない部分の
選択の自由度が比較的高いため、それほど意識する必要はない。
オセロ作るならシンプルなオセロだけ考えれば良い。
そうなると、最初は継承やインタフェースは出て来ないだろう。

それと機能分割する考え方が異なる。
構想化プログラマーは無意識のうちに「機能」を抜き出してそれを分類しようとする。
すると前ｽﾚ601のようにオブジェクトと機能の区別が曖昧になる。
OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。

そして重要なのは修正だ。
単純なオブジェクトに対して、ルールや値を追加して、どこに機能を持たせるか考える。
多くの場合は、設計の誤りに気が付くだろう。しかし最適な場所がある。
ここで継承やインタフェースも出て来るだろう。
この修正を繰り返すたびに、モジュールの結合が緩くなり、完成度が増すのがOOだ。
是非ともこの感覚を味わってもらいたい。まあ、普通の人は1年半後かな？

【オブジェクト指向設計の手順：トップダウン＋ボトムアップ】

前ｽﾚ681：トップダウンもボトムアップも程よく折衷するのがよろし。
前ｽﾚ688：トップダウンで言うと、
　　　　　　まずドメインモデルの抽出手法ってのがある。
　　　　　　シナリオの品詞に着目して
　　　　　　ドメイン・オブジェクトの候補を洗い出す、ってな手法だ。
　　　　　　この手法では、名詞＝静的データ構造、動詞＝動的振る舞い
　　　　　　ってな解釈でオブジェクトができる。
　　　　　　しかしこの手法には大きな問題点があって、
　　　　　　それは明確に概念化されていない対象、見えない対象、実装方法等は
　　　　　　抽出の落ちや、不適切な抽出が発生しやすい。

　　　　　　次にボトムアップで言うと、
　　　　　　「コードやデータの凝集度」といった言葉で表される、
　　　　　　「これとこれ、わけて、あっちでまとめたら、判りやすくねぇ？」
　　　　　　というコード感覚、モジュール感覚、アスペクト感覚がある。

　　　　　　ボトムアップのモジュール感覚、アスペクト感覚を、
　　　　　　トップダウンの分析モデルと擦り合せたものが、
　　　　　　設計モデルだ。もちろん、詳細化していく中で、
　　　　　　最初の設計モデルの見込みが間違ってたり、
　　　　　　あるいは詳細化能力の低いのが仕事にタッチしてきて、
　　　　　　設計モデルが崩れる事もあるけれど。

ここで視聴者のみなさんに素敵なお知らせがあります。

ただいま、この開運オブジェクト壷、
通常価格￥１０、０００，０００，０００の所を
先着５名様になーんと
　　　　　　￥１０、０００，０００
という特別価格で提供しちゃいます。

しかも！
通常なら別売りの
・隙間アダプター　・・・タンス裏のホコリを取るのに便利ですね！
・高枝切バサミ・ストラテジー　・・・コウルサい上司を簡単に切れますよ。便利ですねぇ！
・収納コンテナー ・・・使わなくなった壷をスマートに格納できますよ。いいですね！
の三点セットで、なんと
　　　　　　　￥１０，０００，０００
いまなら送料無料です。ご注文は画面下側のURLまでどうぞー

オセロの場合、石は本質的に不要である。
陥りやすい設計ミスだね。

631 名前： 仕様書無しさん [sage] 投稿日： 2007/03/23(金) 17:37:16
あと、>>601=>>466-468ではワザとネグっといたんだけど、
オセロの石(Piece)は分析クラスにも設計クラスにも入れといた方が良さそうだな。

分析上の理由：
・現実世界に石は存在する。
・ある種のローカルルールでは、プレーヤの持ち石の数が制限されている。
　(リバーシ・ルール。いずれかの持ち石が無くなったら終了)

設計上の理由：
・実装Othello2でリバース・アニメーションをやっている関係上、
　石クラスがあり、そのViewクラスでアニメーションを表示する、
　というクラス分割が自然に見える。

実装上の注意点：
・思考ルーチン内では通常、
　盤面をbitmap配列として保持し、石はbit列として表現される。
　ここに石クラスを持ち込むのは、ナンセンスである。
・もし、bitmap配列とボードクラス、石クラスを関連付ける必要があるのであれば、
　Flyweightパターンの適用を検討するとよい。

【入門者用：オセロプログラムの設計と実装】
・ルール仮想クラスの天麩羅

// プレーヤ識別子 (二人限定版)
typedef enum { WHITE, BLACK } Side;

// ゲーム盤上のセル状態 (ボード形状や初期配置の記述に使用)
typedef enum { _WHITE=WHITE, _BLACK=BLACK, NONE, OUTSIDE } CellState;

// ゲーム盤の状態 (Ruleクラス記述用簡易版)
typedef struct {
　int w, h;　　　　// 幅、高
} Size;
typedef struct {
　Size size;　　　// ゲーム盤の幅、高 （＝二次元配列の幅、高)
　CellState **b;// セル状態の二次元配列
} BoardState;

// 手クラス
class Step {　/* 略 */ };
// 譜クラス
class Score {/* 略 */ };
// プレーヤクラス
class Player {/* 略 */ };

//つづくよ

【入門者用：オセロプログラムの設計と実装】
・ルール仮想クラスの天麩羅

// ルール記述用仮想クラス
class Rule {
public:
　// 用語のカスタマイズ
　virtual char *getTerm(char *termID);
　// 見た目、ボード形状等のカスタマイズ
　virtual int getColor(int colorID);　　　　 // 配色
　virtual bool isCellSurroundedByLine(); // 線の引き方
　　　　// (セル外周 or セル並び四方向)
　virtual Size *getBoardSize();　　　　　　// ボードサイズ
　virtual BoardState getBoardShape();　// ボード形状

　// 初期配置
　virtual BoardState getInitialPlacement();
　// 先攻後攻
　virtual Side getFirst();
　　　　/* TODO: 先攻後攻決め処理(ジャンケン等)の提供 */

　// 判定ルール
　virtual bool canPut(BoardState b, Step s);　// 石の置き場所チェック
　virtual bool isPass(BoardState b, Side s);　　// パス判定
　virtual bool isEnd(BoardState b, Score *s, Player ps[]); // 終了判定
　　　　// (置き場所なし、手詰まり、プレーヤの持ち石なし、等)
　/* TODO: その他ルールがあれば追加。(時間制限等) */

　/* TODO: ゲームに参加するオブジェクトが、ルールに準拠している事を監査/保証する仕組み */
};

スレ重ねる度に、OO厨大量発生っていうか
グダグダになってる気がするんだが…

そもそもオセロでも将棋でも動く拡張性とかさw
final使ってないから駄目とかさw
もう、お前らOO言いたいだけちゃうんかとw

>>28 【オブジェクト指向設計の手順：おじゃばさま(仮名)】 に対する反論

前ｽﾚ709
あと、詳細にマジレスしておこう。

> OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
> オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。
>
> そして重要なのは修正だ。
> 単純なオブジェクトに対して、ルールや値を追加して、どこに機能を持たせるか考える。
> 多くの場合は、設計の誤りに気が付くだろう。しかし最適な場所がある。

オセロのルールはどの「物」に付与しますか？
まさかゲーム盤や石がルールを持って協調作業する、
なんて奇妙な設計を、わざわざ苦労してするつもりですか？

ゲームの進行はどうやって書きますか？
まさかプレイヤーとプレイヤーの協調作業だなんて、
不確実なものを、わざわざ苦労して設計しますか？

目には見えないけれど、ルールは存在する。
そして、きっちりとゲームをする時は、
審判を置いて、ゲーム進行とルール遵守を確認する。
そういった突き詰めた思考こそが、分析・設計には重要かと存じます。

過去に多々言われているとおり。馬鹿をコントロールする仕組みだからね。

>>37 バカ乙。

まぁポストOO壷で生計を立てて、趣味でサイエンス研究を指向するおいらにゃ、
バカ様様だけどなｗ

>>現実世界に石は存在する
オブジェクティブスパゲッティへ陥る危険な兆候です。
実践の場では、誰も手の着けられない保守不可能なシステムが出来上がってしまいます。

まとめるようで全然まとまってないなw

↑不幸で不幸でどうしようもなくて、むしゃくしゃしてる可哀相な老人

おいらもUML書いて、ほらこれなって渡せばいいから便利だな。
じゃわぽんって出来ないくせに変なプライドがあって聞きにこないから楽。
リリース間際に必ず契約切れで次のとこにいくから後の祭りは知らずにすむし。
風邪の便りで火を噴いたと毎回聞くけど、おいらにゃ関係なし。

それはそうとイってそろそろIPOしないの？ｗ
そろそろ資金切れか？

まあ>>39に同意だな
こういうのはオブジェクト指向のオブジェクトを
「物」って誤訳した奴らのせいだな

>>現実世界に石は存在する
原因は、オブジェクト＝＝インスタンスと捉えた勘違い。

実装上の理由があれば、ええんじゃね？
「オブジェクト指向の落とし穴｣っつう、
NeXTSTEP用アプリ作ってた会社(Sunが吸収済)の開発者が書いた本があるんだけど、
あれなんて「OOの常識は世界の非常識」みたいなエンターテーメントだからな。
プレOO厨房も、あれぐらいの乾いたユーモアがあれば、少しは笑えるんだけど。
現状はサルが人を見て笑っているに過ぎん。はやくOO厨房に進化してくれｗ

動物園の類人猿が、人間に進化するのを手伝うスレ

OOが成果あげてるとこは、予想だとかなり少なそうなんだけど。

抽象化＝＝単純化で混乱する実装部隊

>>48
だって「現実世界に石は存在する 」ですもんwww

石ころいっぱいでけつまずく罠

再利用しないものをクラス化しても意味無いね
粒度も小さすぎるし。

※粒度の最適化は経験からしか決められない。

クラス化と再利用は関係ない

>>53
ヒント：スルー
ベストプラクティス：NGワードに登録

プログラムとしてのオセロにとって、石って言われてるものの本質は「盤面のあるマス目の状況」だろ。
そいつらは石が無い状態・黒石・白石の３つあるわけだろ。
すなわちプログラムにとってその３つの状態さえ識別できればよくて
とすればintなりenumなりで十分それを表現することができるだろ。

こういう風に、「何かにとって」「何かはどう見えるか・振舞うか」
言葉を変えれば「主体にとって」「客体はどう見えるか・振舞うか」
訳すと「subjectにとって」「objectはどう見えるか・振舞うか」
を考えるのがオブジェクト指向なんだ。

よってobjectを設計するときには必ず「誰にとって」のオブジェクトで
あるかをよく意識する必要がある。

石のことだけ考えてても、石の設計は出来やしないぜ。

ですな

>>55
ちょっと参考になった

>>55
おもいっきり参考になりました。カルチャーショックです。

似非オブジェクト指向で石ころゴロゴロけつまずく

>>6
ゲーム番と仲良しの記録くんｗｗｗ

石の所有者はだれ？
居なかったら自分自身だよ

>「subjectにとって」「objectはどう見えるか・振舞うか」
これが変更されるときにOOって破綻するんでしょ?

石の反転をアニメーションする場合は石クラスがあった方がいいんじゃね？

>>55
まあこの件に関しては、どうでもいいレベルの話だ。

・ プレーヤが白組か黒組か (ただしルールが変わると石の色も変わる)
・ 盤面上に置いた石が白組のものか黒組のものか
・ ルールによっては、プレーヤが打てる石の数に制限がある
・ ココ電柱が拾ってきたソースに、石がひっくり返るアニメが付いてた

ってな状況下で、石を第一級のクラス (www にしといた方が
設計〜実装の見通しが良くなる (石という横断的関心事を石クラスにまとめる)
ってだけの話でしょ。

いつまでも古臭いOO設計のヒューリスティック
　　(些細な存在物をなんでもクラスにするのは悪)
を振り回せばいいってもんじゃない。
設計者には臨機応変な対応こそ必要なんだ。

>>55
どうよ

>>62
そりゃそうでしょ
変更するのは振る舞いの中身だから影響が少ないんであって

>>63
もっともっと勉強しようね

>>・ ココ電柱が拾ってきたソースに、石がひっくり返るアニメが付いてた
アレ、拾ったもんかよwww

>>64
石クラスに盤上での状態とアニメーションを一緒に持たせることは
表示とロジックを混同することにならないか？

>>67
いや、石の状態とアニメーションの管理を分離する合理的な理由は見当たらない。

>>55
また書き逃げか。あいかわらずだな。

お前が考えているような話は、最初から考慮している。
だから最初は石(Piece)を分析モデルに加えなかった。

だが分析を詳しく進めていく中で、>>64のように

　　石の色が横断的関心事として複数のクラスに散らばる

という事実に気が付いて、改めて石クラスを追加した。

ただし、思考ルーチンや記録における石の扱いは、
オブジェクトというよりは盤面上の状態として扱う。
これは、最初から終始一貫した方針だ。

例えばWindowコントロール（ラジオボタンやチェックボックスなど）は、
状態管理と描画は同一クラスで受け持たせている場合が多い。

>>65
別に「その」設計に石クラスが必要あるとかないとか、
そんな話してるつもりじゃないぜ

>>70
アニメーションいらない

つかおめえちっとくらい待てねえかよ

>>73=55
あい。

>>69
盤や他のアニメーションとの同期も考えたら
アニメーション管理クラスを作成しておいて
アニメーションの指示を出したほうがいいと思うんだが。
これなら同期処理が入ったり見た目が3Dになって描画方法が変わっても対応できる。

>> 71 あなた誰、このスレ初めてでしょ

>>69
石クラスは reverse() するだけ。
アニメ担当は 石Viewクラスだ。

>>74 お前がいらないっつっても顧客がいれろって言ってくるんだよ。

>>78
　>>64だ文章嫁。

>>79
つまり石クラスは不要なわけだ

>>79
石Viewクラスは必要だと思うが石クラスはいらないだろ

池沼祭り

>>81　嘘はイクナイ

お初です。池沼って何？

このスレ見てるだけでも結局設計者次第でどうにでもなってしまうというのがよく判るね。

またバカが一人で粘着してるのか

>>87
設計者次第、というよりはプロジェクト次第だろうね。

なんとかviewとか、徒にクラス増やすなよ。複雑にしてるだけじゃん。
意味ねぇよ。Webアプリかよ。ハァ...

だから意味が無いように見えるのはお前がわかってないからだって言ってるだろ

>>89
でもさ、設計者が変わったりすると考え方の相違とか生まれない?

ロジックが表示の拡張に引きずられてボロボロになるほどアホらしいことはない

MVCね。

>>91 MVC厨乙。ロバストネス図はもう書けるようになったかい？

まさにオブジェ苦闘指向

>>95
お前はデスマで死ね
最後に立っているのは俺のほうだ

>>64
アニメーションするために必要な「石クラス」と、
オセロゲームとしてひつような「石クラス」はまったく別モンだべ。

つかアニメーションするために必要なクラスは
あんたのやってるドメイン分析になんの関係もなかろ

それと、どうでもいいけど横断的関心事って言葉の使い方がちがう

>>95
お里がバレバレですな。

すると次はシーケンス図厨が出現して、
しまいにはGRASPパターンかなｗ

オブジェクト指向は達人が利用するものなので、それ以外の方は構造化オンリーでお願いします。

分けわからめだが

>>55　アーキテクト　vs.　>>64　似非アーキテクト？

で良い、ぷっまえら？

>>98
はいはい疲れてるみたいだねぇ。
昨晩噛み付いてきた【残念】厨房かな。

相手の意見を正したい時は、
一つの文で一つの事だけを話した方がいい。
キミみたく、一つの文に複数の事を書き連ねると、
レスを重ねるのが非常に面倒だよ。

で？なんか言ってたっけ？聞いてなかった

おＫょ

偉そうなこと行ってるこいつ>>102　は誰？

そろそろ 55 はスルーかな。
得られるものはあんまないし。

あ、そうそう>>94。
横断的関心事の定義が違う、だって？ｗ
じゃあ、キミの定義はどうで、
どこが違うと思ったのか、説明してごらん。ｗ

>>55
また書き逃げか。あいかわらずだな

俺が3Dでオセロ作るとしたら、絶対、石クラスは作るな。状態とか、
ポリゴンとかテクスチャとかに関する属性は石クラスに持たせる。
だいたい同じ情報を分散して保持するのは俺のポリシーに合わない。

>>104

>>64じゃね

おい５５
前ｽﾚでインターフェース設計するとか言ってたな。
そろそろ出したらどうだ？ん？

本当に困るんだよ。オブジェクティブスパゲッティは手に負えない。教えてやっても頑固だしね。
オブジェクト指向は免許制にした方が良いかも。

>>107
俺の場合そのせいでAIを載せるのに非常に苦労した。
その経験からやはりMVCを適用するべきだと思った。

今吠えてるのが>>64だとしたら糞の役にも立たんな

おれも>>107の考え方に近いな。
正直なところ、それが正しいかどうかについてはあまり自信がない。

入門者向けの話題はそろそろ終了して、
次はマイグレか受注に話題転換したらどうだ？

>>108　層化
>>64は似非アーキテクトだから、自分を名乗れないだな
それに比べ>>55は名乗ってるから偉いよ、>>64はもうDQN化してるし

あ、そうそう>>98=55。
横断的関心事の定義が違う、だって？ｗ
じゃあ、キミの定義はどうで、
どこが違うと思ったのか、説明してごらん。ｗ

また自演かよ。

>>111
具体的にはどの辺で困ったの?

説明できない放言をする >>98＝似非

＞＞９８は現在ごっぐるさんを検索中・・・

>>98
おい、やっぱ逃げかよ。
言い訳もできない発言すんな

ヒント：スルー

>>118
プレイヤーが打った後、石が裏返るのを待ってAIが次の手を打つという
アニメーションの同期処理が必要だったんだけど
石にアニメーションの情報を内包した状態ではそれが困難だった。
そのときは適当にフラグで回避した。

知的障害者が来ると、スレが汚れまくるな。

>>119-121
はDQN>>64でOK？、ぽまえら

>>92
PJ次第というか要求仕様次第で設計が変わるのは
OOでも一緒でOOを使いこなすとかの類の話とはあまり関係はない。

OO厨としてのレベルが上がってくるとw
あるべき論とかの違いも含めて実装方法が
窮屈になってきたり、劣化したりする不思議。

OO厨とOOを適切に使う人の境界線は
本来の要求仕様の事を意識できているかの違いと思われ。

別に納期があるものつくってるわけじゃなし、
ここじゃ議論することそのものに価値があるわけだよなあ

なのになんでそんな必死？

盤と石とのObserverパタンでいいんじゃね？

たかひろ乙

今度は書き逃げしないように。

>>127　DQNは必死なんですよ、理由は有りませんよ

それより、ぽまえら、前スレで、ぽれ1000取れなかったよ
取る為に、眠いの我慢して頑張ってたのによ、うあーーーーん
取った香具師、氏ね

>>127
おまえ、性格の悪さが染み出てるな。
千葉茂センセ (俺の元職場の近くに研究室持ってる人だ)のページでも逝って、再確認してこいｗ

石クラス作ってごてごて詰め込むより
MVCに分けたほうが結果的にシンプルになる

>>128
無理矢理パタンしたらだめだよ。

まぁいくら長文書くのが得意でも
実際の設計が>>22じゃなぁ。
説得力に欠けるよ。

>>131　首にされたんか？

ヒント： イ釣り

>>131
ちっとまてよ。俺はすげえ性格いいっつの

あ、そうそう>>131=>>98=>>55。
横断的関心事の定義が違う、だって？ｗ
じゃあ、キミの定義はどうで、
どこが違うと思ったのか、説明してごらん。ｗ

＞＞９８はさぁ、特に意見持ってるわけじゃないんだけど、
なんかすごい良さそうな意見言ってる人ににじりよって
文句つけたくなる性格なんじゃないの？
一晩で二回も噛み付くのって、例の池沼以外には見た事ない。

>>55
必死なつもりはないんだが、正直なところ手法自体に拘りはあまりないんだ。
極端な話、Cやアセンブラで開発したい位だw

しかし、生産性という事を鑑みるとそういう訳にもいかないだろ。
俺はそういう理由でOOを選択しているので
OOを選択する人にはそこを忘れないでほしいんだよね…

あ、そうそう>>131=>>98=>>55。
横断的関心事の定義が違う、だって？ｗ
じゃあ、キミの定義はどうで、
どこが違うと思ったのか、説明してごらん。ｗ

どうでもいいってかいたろ？

横断的関心事っつのは通常「異なるクラス間にまたがってしまう処理」
のことをいうんじゃないのか？
んで「石クラス」は「処理」なのか？ちゃうやろ。

>>138
たかひろ、DQNになるなよ

流れが無茶苦茶速い記念カキコ

>>142
処理には限んねぇだろ。
関心事だよ関心事。
メソッドだろうが変数だろうが、本来一つのものが
(クラス設計手法が持っている欠陥＝「仔細な存在物をクラス化するのは悪」というドグマによって)
あちこちに散らばる、それを正しましょうって話。

>>139
そ、そんなつもり毛頭ないぜ。
「どうよ？」って聞かれたから、レスしただけなのに。。

レス進むの速w

>>130
お前にDQN扱いされる筋合いはない。
っていうか、お前のレスのほうがDQNだろがw

うあーーーーん
とか、キモイんだよw

アスペクト指向がめざすもの
http://www.csg.is.titech.ac.jp/~chiba/notes/aop03/index.html

現実の開発では、主要な機能に着目して、has-a 関係や is-a 関係にそってシステムを
コンポーネントやオブジェクトに分割してゆくことが多い。
そこから漏れた機能については、後から適宜、
関係するコンポーネントやオブジェクトにまたがるように、
ばらばらに割り当てることになる。図１の灰色の部分がこれに該当する。

ここまで「機能」という用語を使ってきたが、これは説明を単純にするためで、
正しくは、モデリングや設計、実装に登場する様々な観点、と書くべきであった。
アスペクト指向では、これを「関心事 (concern)」という。
システムが提供する機能は、関心事の一例であるが、
モデル上のエンティティや、分散処理など実装上の留意点も関心事の例である。

>>145
ああそうか。悪かったな。

アスペクト指向がめざすもの
http://www.csg.is.titech.ac.jp/~chiba/notes/aop03/index.html

（つづき）
いくつかのコンポーネントやオブジェクトにまたがってしまう関心事は、
補助的な取るに足らないものとして、オブジェクト指向では注目されてこなかった。
しかしながら、このような関心事は、ソフトウェアの開発や保守を困難にしている元凶の一つである。
分割統治が基本のソフトウェア開発で、これを妨げるからである。

アスペクト指向では、このような関心事を「横断的関心事 (crosscutting concern)」と呼び、
これを独立したコンポーネントに分離することをめざす。
横断的関心事を、他の関心事にもとづく分割で得られた複数のコンポーネントのあちこちに間借りさせるのではなく、
その関心事に対応する専用のコンポーネントにまとめられれば、ソフトウェアの開発効率や保守性が向上する。

アスペクト指向はオブジェクト指向の限界を補完しようとするものである。
決してオブジェクト指向を置き換えるものではない。
ちょうど手続きや関数による抽象化では不十分な点をオブジェクト指向が補っているように、
オブジェクト指向では不十分な点をアスペクト指向は補おうとしている。
オブジェクト指向が普及しても、手続きや関数が依然として基礎であるように、
アスペクト指向にとってもオブジェクト指向は基礎である。

お初で石投げたら、猿山のバナナ状態だなｗｗｗ
もっと精進しような。

>>147 歩前は勘違いをしている
>>130は歩前に噛み付いているDQN対して
DQNは必死なんですよ、理由は有りませんよ だ

いや、お前はアフォだけど、石の投げ方が適切だっただけ。

>>55
あと、手法に時間をかけるって事は
その分、中身の開発の時間を削る事になる訳で
なるべくなら中身の開発に時間を掛けたいってだけ。

147よ
おまぃ友達いないんだな・・・

オブジェクト指向は危険だよな。C言語のポインタも危険だったけど。
やっぱり免許制が必要だな。このスレで実感したよ。
んじゃ、おやすみ。

スルー推奨

ある日オセロ開発チームへメールが。

件名：スキン変更機能について

・盤面や背景画像
・駒置き／反転アニメーション
・画面レイアウト

をスキンで変更出来るようにしてくれ。

いじょ。

>>61
> 石の所有者はだれ？
> 居なかったら自分自身だよ

ナイス突っ込み。
>>6の図を更新し忘れてたんだが、
石の所有者はプレイヤ。

先攻後攻決めた後で、
先攻には黒、後攻には白の石が
有限個〜無限個与えられて、
それを手として打つ、ってな話。

>>152
なんだかレスが速すぎて訳がわからなくなってきてるなw
とりあえず>>55がDQNという風には俺は今のところ感じない。

あと、「人の事を馬鹿って言う奴が馬鹿」
っていう格言みたいなのあるけど、結構当たってるぞw

>>158
そのスキンは、ルールに依存しますか？
それともルールと無関係にカスタマイズしちゃいますか？
あと、スキンはViewの話だから今回はスルーですね。

>>160
丁寧な物腰で絡んでくる奴も居るって事で。

画像ってのは盤面だけ（石も含める？）に持たせるのか？

>>162
ああ、居る居る。聞いたこともない大学の教員とか、引退生活者とか、
社会生活のある面がふっきれちゃってる人に多い。

おっと、161が言いたいことを言ってくれてた

荒らしはスルーしれ

>>163
ルールで「盤面には濃緑色のフェルト模様のスキン使え」とか言うのなら、
とりあえずルールに持たせといて、そっからゲーム盤Viewに渡るようにする。
さもなくば、今回の問題領域の外・・・そろそろViewも設計するとか言い出すのかな・・・

とりあえず見てくれの話はあとにしまいか？

>>155
何故そう思うのかは置いておいてw
おまぃは友達が多いと言いたいみたいだなw

ひでえ。誰にもからんだつもりなんてないのに。。

>>163
あ、お話の意味がよくわからないです。。
ルールで「石には、黒および白の大理石のテクスチャーを使え」とかあるのなら、
ルールに持たせて、石Viewに渡す、とかでおｋ？

>>55
ﾖｼﾖｼ(;ﾟｰﾟ)ﾉ(T-T)ｳﾙｳﾙ

>>160
>>55はDQNじゃない、自分に噛み付いてたDQNが分からなくなってるよ、ポ前
横断的関心事の定義がどうのこうのと言ってる香具師いたろ
もう、DQN去ったみたいだから、噛み付く香具師いないと思われ

おいおい、誤解に基づく絡みを、
リファレンスまで挙げて訂正してやった挙句にDQN扱いかよ。
噛まれ損だな

AA見てるだけで、自己認識がどうなってるのか良く判るね

もまぃらもちょっと大人になれ。
ほれ、お茶でも飲んでもちつけ。

ってな訳で、このスレはアスペクト指向設計方法論を議論するスレに生まれ変わりますた。

【AOP/D】ｱｽﾍﾟｸﾄ指向をまだ理解できないの？★

議題
1. ｱｽﾍﾟｸﾄ指向分析/設計は、ｵﾌﾞｼﾞｪｸﾄ指向分析/設計と
　 どのような点が異なるか
2. ｱｽﾍﾟｸﾄ指向分析/設計は、開発方法論たりえるか？

>>173
なるほど…、ポ前いい奴だな

じゃ、リファレンス漁って来るから。

>>68
捏造すんなよ
あれは俺が書いたの

>>147
ついでだが、ｗを落とすだけで印象が違うから。

今晩はNGワード.txtを３回更新した。チラ裏

>>181
ココ電　キター、ビッグリ、age

ログ残ってた　パート２あたりかな
http://piza2.2ch.net/tech/kako/1003/10038/1003850943.html

1 名前： デフォルトの名無しさん 投稿日： 01/10/23 14:44

オープンソースプロジェクトの成功率

C++を採用したプロジェクト→20.8%
JAVAを採用したプロジェクト→20.6%
Cを採用したプロジェクト→45.13%

はっきり言ってオブジェクト指向が生産性を
高めるなんて、幻想です。
みなさん、オブジェクト指向なんて浮ついたものに踊らされてないで
Cに回帰しましょう。

http://www.gyve.org/~jet/lang2.txt

じゃココ電は戦場スレ立てて独立してくれ。
邪魔すんな

>>185
ココ電、2001年じゃないか、5年以上前だぞ、もうココ電はオッサンじゃね
おっさんならOO嫌い当然だな

このスレだわ　アップしたの
http://pc3.2ch.net/tech/kako/1032/10329/1032985885.html

159 名前： プロの逝って良しの１ 投稿日： 02/09/30 05:21

アップしたよー
動くかどうかわからんが
http://megami.s1.x-beat.com/upload/upload.cgi
[megami0131.lzh] Othelloソース(Javaファイル) 5 2002年09/30(月)05:17

荒らしの相手をする行為も荒らしとみなされます

>>189
最後にココ電、おっさんスレへ行け、同士がいて楽しいぞ
そこは、おまいの安住の地だ

そういえば、このスレでも結局OO版の動くオセロ
は誰もうpしてないわけだが、つまり、OOってのは
机上の空論っつうことでおＫ？

オセロのOO的分析によるクラス設計

クラス　石
　　白黒状態の保持
　　白に出来るか(単に黒判定)
　　黒に出来るか(単に白判定)
　　白にする
　　黒にする

クラス　盤
　　８ｘ８のマス上の石の管理
　　プレーヤから石を受け取る
　　石を置けるかどうかの判定処理など
　　ルールの判定ルーチンを持たせる

クラス　プレーヤ
　　白黒どちらを打つプレーヤーか
　　手持ちの石の管理
　　盤のどこに石を置くか
　　次の一手を打つための思考処理を持たせる

クラス　ゲーム
　　 プレーヤ　Ａ
　　 プレーヤ　Ｂ
　　　盤　　X

初期化
　　ゲーム開始

193の続き

プレーヤに石インスタンスを持たせ、石インスタンスは
ゲーム進行につれて盤に渡される。

プレーヤを階層化して、
クラス 賢いプレーヤ
を用意して、単純作業用のプレーヤインスタンスや、
盤インスタンスを持たせ、次の手を打つ思考に使う。
これは、コンピュータがプレーヤになるとき用。

こんな感じだな。オレなら。

ロックマン2のすごさには敵わないでしょうｗｗｗｗ

おっくせんまんｗおっくせんまんｗ

>>193 ゴタクはいいからさっさと作れ

もちろんCOBOLでな

まあ、入門者向けの設計テーマとしてオセロ選ぶのは自由だが、
２ちゃんごとき糞壷の分際で設計スレにコード出せ出せ騒ぐのはガキだよな。
発言読めば、どの程度の設計経験を持っているか、
どの程度の設計上の洞察力を持っているか、判断できる。
だから面白れぇんじゃねぇか。

>>193
乙です。その時間にまともなクラス設計出すあなたに、ちょっと感動。

OOを分かってない奴が「ソース！ソース！」と煽ってますが、
本来のOOはエイヤで作るものではなく、
設計概念を確立するまでに時間かかかるものです。
それが理解できないワカランチンはスルー推奨で参りましょう。

オセロを判ってないね。

OO的オセロは、各石の意思を聞くもんだろ？
プレーヤーが石に意思を確認すると、石が意思を反して来るんだよ。

>>193
ドメイン分析の成果物は、そのまま実装するものじゃないぜ

はいはい、ﾊﾞﾛｽﾊﾞﾛｽ

>>193
要するに、>>5-6の分析クラスと >>193の設計クラスの対応関係はこんな感じね。

【設計クラス】　【分析クラス】
-----------+-------------
　ゲーム　　　ゲーム, 試合, 進行係
　　　　　　　
　盤　　　　　　ルール, 審判, ゲーム盤
　　　　　　　
　プレーヤ　　プレーヤ, 戦術
　　　　　　　
　石　　　　　　石
　　　　　　　
(機能削除)　　記録係、手、位置
　　　　　　　
-----------+-------------

>>202
お前には言われたくな(ry

　　　　　　　　 ┏━━━━━━┓
　　　　　　　　 ┃ゲーム　　　　..┃
　　　　　　　　 ┠──────┨
　　　　　　　　 ┃プレーヤA　　 ┃
　　　　　　　　 ┃プレーヤB　　 ┃
　　　　　　　　 ┃ゲーム盤　 　 .┃
　　　　　　　　 ┠──────┨
　　　　　　　　 ┃初期化　　　　 ┃
　　　　　　　　 ┃ゲーム進行 　.┃
　　　　　　　　 ┗━◇━━◇━┛
　 　 　 2.┌───┘1.　　└───┐
　┏━━┷━━━┓　打つ .┏━━┷━━━┓
　┃プレーヤ 　 　 ┠──→.┃ゲーム盤　　....┃
　┠──────┨　　　　..┠──────┨
　┃色　　　　　　　.┃　　　　..┃石の配置　 　 ┃
　┃石　　　　　　　.┃　　　　..┠──────┨
　┠──────┨　　　　..┃初期配置　 　 ┃
　┃思考処理　 　 ┃　　　　..┃石を置けるか ┃
　┗━━◇━━━┛　　　　..┃リバース 　 　 .┃
　　　　　 │　　　　　　　　　　.┃パス判定 　 　.┃
　　　　　 ├───────◇ 終了判定　.　.┃
　┏━━┷━━━┓　　　　..┃集計　　　　 　 ┃
　┃石　　　　　　　.┃　　　　..┗━━━━━━┛
　┠──────┨　
　┃色　　　　　　　.┃　 ┌─────────────|＼
　┃所有者　 　 　 ┃←┤最初、石の所有者はプレーヤ　|　 ＼
　┠──────┨　 │プレーヤが盤に石を打つと、　　￣￣|
　┃白に出来る？.┃　 │石の所有者は盤に変わる。　　　　　 |
　┃黒に出来る？.┃　 │石のリバースは所有者(盤)のみ　　　|
　┃白にする　　　.┃　 │実行可能。　　　　　　　　　　　　　　　 |
　┃黒にする　　　.┃　 └───────────────┘
　┗━━━━━━┛　　　※つか、適当に石をネグってもらって結構なんだがｗ

納期を決めてからやれ。
ガキの遊びじゃないんだ。

白に出来るか黒に出来るかの情報は石自体は持ってないよ
石がゲーム盤に対して問い合わせるというのなら
最初からゲーム盤にメッセージ送ったほうが速い

>>200
煽りじゃなくって、コードは出していくべきだと思うぜ
モデル設計の良し悪しは、つまるところ「使いやすさ」で決まる。

>>206
ガキの遊び以外の何なのｗ

>206
残念ながら、ガキの遊びですが何か？

>>204
なんでそんなキレてんの？
モデルはアーキテクチャのうえで動かす。

>>202
まぁ、OOA/OODの常識はソレとして。

最近は分析クラスをほぼそのまま
シミュレーションする環境もあるようだし。

俺は、OOA/OODからやる時は
実装に無理や無駄が無い範囲で
分析クラスの実装を試みるな、まずは。
だって前工程の成果物(分析、設計)を
後工程(設計、実装)で適当に解釈して捻じ曲げちゃったら、

　　要求→分析→設計→実装→各前工程段階の要件のテスト

つうプロセスの見通しが悪くなるもん。
だから、有象無象が跳梁闊歩する大規模開発は、
やらない（爆

>>208
よく分からんな
使いやすさってなんだ？

>>213
言葉で説明するのはやりにくいな。
実装してみりゃ実感できるんだけど。

今回の設計クラス、
石クラスの設計の解釈はずいぶん苦労したぜ。
詳細な分析モデル適当にネグるなら、石も省略してくれていいのに。

例えば >>207 の指摘はもっとも。
まあクラス図レベルじゃ細かいメッセージ・フロー追っかけないから
問題が表面化しにくいけど。

あと、石の所有者、石のリバース処理の実行権。
これは俺の分析時の見落としだな。
これもメッセージ・フローを追っかけとけば（ｒｙ

>>207
俺は>>193じゃないから、設計意図はわかりかねるが。
石クラスのソレは、

>　　白に出来るか(単に黒判定)
>　　黒に出来るか(単に白判定)

だそうだ。
まあ、気に入らないけど削りにくい分析モデルは、
設計を捻っておいて最終的に削除に持って行く、つう駆け引きもあり得るし

>>214
OOは設計がそのまま実装に落とせるのがメリットなんだよ
実装しないと分からないなんて言ってる時点で
明らかにOOの理解を間違ってるぞ

>>212を判り易く言うと、

　　要求、分析、分析モデル、設計、設計モデル、詳細設計、実装

は所詮は別物。
・粒度、詳細度だけでなく、
・各工程の担当者の認識のズレ、
・認識の深化/進化によるズレ
があるからね。

だけど、それらの間には、判り易いマッピングが成立しないとマズイと思うんだ。
さもなければ、イテレーション・プロセスは成り立たない。
単なるウォーターフォールの繰り返しになってしまう。

>>217
はいはい釣り針釣り針

>>217
実装を試みることで設計にフィードバックできるものが
たくさん得られるんだよ、と釣られておく。

>>217
ワカランチンはスルーしましょう

>>218
なんかそれチガクナイ？
各工程による担当者の認識のズレはOOの話じゃないでしょ
カスタマイズが入ったときにクラス図などを見て
対象箇所が分からないなんてのはすでにOOじゃなくなってるし

>>222

そういうぐちゃぐちゃな物言いをすると、
議論がすすまなくなるよ？

>>223
プロジェクト管理手法の話とOOの話を一緒にしてるのを
指摘してるだけなんだけどな
どっちで話をしたいの？
OO＋PJ？それともOOのみ？

しまった、プラッチック製ルアーに食いついちゃったよｗ

>>221
それがいいかも

>>224
プロジェクト管理 ∋ ＯＯＡ/ＯＯＤの管理

>>224
開発プロセスの話なんだけど？
プロジェクト管理って言葉は
いったいどこから妄想したの？

開発プロセスもプロジェクト管理も、このスレには関係ない
227もいい加減煽るのをヤメレ

>>227
お前さあ、鳥つけてといてくれない？
なんつか、頭がおかしいとかんじる。

プロジェクトでしか物を作れない人の発想：
　開発ってのは、プロジェクト前提でやるものだ。
　だけど、プロジェクト管理は大変だ。
　だから、しばしの間プロジェクト管理の事は忘れて、
　開発の話に現実逃避しよう。

プロジェクトがなくても物を作る人の発想：
　一人でやろうと、プロジェクトでやろうと、
　開発にはおおまかな工程があって、
　その工程を (脳内にせよ報告書形式にせよ)
　順次くぐらないと、物は完成しない。
　物を作る手順＝開発プロセス

やっぱレベル低いな。
プロジェクトにしがみつかないと物も作れない人間ばっかだな。

>>228
このスレのスコープは、分析、設計、実装だ。
これら分析、設計、実装という工程を実行すれば、
それが開発プロセスになる。

きみさぁ、どこの会社の人？

ところで、なんか七転八倒だから、ここいらで、
オブジェクトが整備されてきたと仮定して(今のところ幻想だけど)、
オブジェクトのリモート呼び出し(更にシリアライズしてローカル実行含む)して、
例えば、ＳＯＡＰ-ＲＰＣや、本にはよく出てくるSOAP/WDSL,SOAP/UDDIでどんなことができるようになるのか語ってみてよ。
現状だとＣＯＭが担ってる動画配信とかあるけど。

>>232
脳内会社の幽霊プロジェクトに所属する引き篭もり社員

>>233
スレ違いの○違い乙

煽り・中傷荒らしはスルーしましょう

>>236
メインでスレまわしてる奴が荒らしと思われ。

CMついでに見てみたら指摘されて切れた春厨が暴れてるな・・・
オセロ設計の話に戻さないか？

オセロもうやめね？しきってる奴が、あまりに聞く耳もたなすぎなんだもん。

開発プロセスは分析設計と密接な関係があるよ。
分析設計のインプットは、要求や以前の分析設計。
分析設計のアウトプットは、実装のインプット。
分析設計は、与えられた資源の下で
要求を満たす実装が可能になるようにする、
という責務がある。

要するに、前後のプロセス(工程)への配慮や、開発プロセス全体への配慮が必要って話

>239
しきってる奴なんて居るっけ？

>>240
OOとそれ、関係あるんか？
OOに限らない話を持ってきて荒らすんじゃねーよ

>>241
わからない。けど、正常な議論が行われてる気がしない。

240に類することが荒れてる原因なのはよく分かる。

いまどき、開発プロセスという単語に拒絶反応示す
現場作業員が居るとは驚いた。

>>244
もっと低次元なところで、このスレが機能してないと感じる

>>246
同意。ダメな奴が自作自演してるしな。

>>242
関係ありますよ。
要求のトレーサビリティは、開発一般の重要なテーマだから
ＯＯ開発もそれをサポートする必要がある。

要求のトレーサビリティとは：
　要求が分析、設計、実装、テストの各段階に正しく反映されているか、
　確認できること。

　>>222の言う
　> カスタマイズが入ったときにクラス図などを見て
　> 対象箇所が分からないなんてのはすでにOOじゃなくなってるし
　というシチュエーションを無くすのが目的。

おっと正確には、「〜されているか、確認できること」というよりは
「〜されている事の確認しやすさ」だな。

要求のトレーサビリティとは：
　要求が分析、設計、実装、テストの各段階に正しく反映されていることの
　確認しやすさ。

>>248
わかったわかった。
で、結局話しの主題はなんだ？
そこがはっきりしないから荒らし呼ばわりされるんじゃまいか？

話を元に戻すと、
>>202 ドメイン分析の成果物は、そのまま実装するものじゃないぜ。

ドメイン分析の成果物を、設計に落とさないと実装できない、という意味では同意。

ただし、ドメイン分析の成果物を、できるだけ形を変えずにシミュレーションしたり、
あるいはできるだけ形を変えずに設計、実装する、という手法もある。
このようなシミュレーションや手法の目的は、

　　要求-分析-設計-実装

の間のセマンティック・ギャップを小さくし、
要求変更を即座に実装に反映させる事にある。

つか、ようやく最近話がかみ合ってきたな。
>>250 読む前から >>251書いて投稿しちゃったし。おれ。

一体何の話をしたいのかさっぱり分からん

かみ合ってねーよｗ

>>253
要するにアレだ。

頭が悪いわけでもないのに、
仕様変更をガンガン入れてくる上客が居たとして、
そいつに「はい、できたよ！」ってすぐブツを出すための手法。

>>251
おれ>>202書いたけど、>>251にはまるっきり同意だよ。

>>251
分析モデルのシミュレーションの理由は違うだろ。
実装まで落とさずに、精度の高い分析モデルを出すための手法。

>>256の補足

コードによるモデル検証はすぐやるほうがいいよ。
オセロだったら「盤+石」がモデルであることに異論はなかろうし、
俺だったら初期段階で検証コード書いてみるだろうな。

どうぞ

設計段階でデスマーチですか。
スケジュールが押しに押して、メイキングの時間がないという典型例ですな。

コードも書けない設計オタが多いからな。
ところで大事な用件を見落としてるぞ、
・Undo/Redo をサポートすること。
はい、はい、設計見直してね。それとも、PGに押し付けですか？

>>261
　>>6 で設計済。
　手クラス、記録クラスをCommandパターンで使う。
いじょ

>>258
> 俺だったら初期段階で検証コード書いてみるだろうな。

　　　　　　　☆ ﾁﾝ　　　　　　　　ﾊﾗﾍｯﾀ〜
　　　　　　　　　　　　　　　　　　　　　ﾊﾗﾍｯﾀ〜
　☆　ﾁﾝ　　〃　∧＿∧ 　 ／￣￣￣￣￣￣￣￣￣￣￣￣
　　ヽ　＿＿_＼（＼・∀・）＜　>>258 検証結果、まだぁ〜？
　 　 　 ＼＿／⊂　⊂＿)＿ ＼＿＿＿＿＿＿＿＿＿＿＿＿
　 　 ／￣￣￣￣￣￣￣／|
　　 | ￣ ￣￣￣￣￣￣:|　 |
　　 |　淡路たまねぎ 　 .|／
　　 ￣￣￣￣￣￣￣￣

>>263
設計する奴がやりなよ。。

>>262 Aクラス、BクラスをCommandパターンで使う。いじょ
こんな説明で、Undo/Redoが実装できるんだったら楽だけどな。
デスマが減らないわけだよ。てめぇで実装してみろよ。

俺の担当は分析 >>6
設計したのは >>193
すると設計モデルを検証するのは >>193の役目だな

　　　　　　　☆ ﾁﾝ　　　　　　　　ﾊﾗﾍｯﾀ〜
　　　　　　　　　　　　　　　　　　　　　ﾊﾗﾍｯﾀ〜
　☆　ﾁﾝ　　〃　∧＿∧ 　 ／￣￣￣￣￣￣￣￣￣￣￣￣
　　ヽ　＿＿_＼（＼・∀・）＜　>>193 はやくして〜！まだぁ〜？
　 　 　 ＼＿／⊂　⊂＿)＿ ＼＿＿＿＿＿＿＿＿＿＿＿＿
　 　 ／￣￣￣￣￣￣￣／|
　　 | ￣ ￣￣￣￣￣￣:|　 |
　　 |　淡路たまねぎ 　 .|／

>>265
　>>204の比較表に載ってるように、
　>>193の設計では Undo/Redoのためのインフラを削除したみたい。

　まずは >>193と相談してはどうか？

>>266
おめえ>>6書いたんならお前がやれよ
とりあえずゲーム版と記録がコラボって、Undo/Redoやるとこだけでいいからよ

じゃあ、入門者用課題オセロ設計は、
誰かが主体的に次のアクションを起こすまでペンディングって事で。

========================================================

　　　　　休　　憩　　時　　間　(2006/3/25 15:00〜

========================================================

だれかがってなんだよ。ふざけてんの？

とりあえず、次のレビューのスケジュールが決まったら、CC頂戴。

template<class TYPE ...> class CGomokuNarabe{
typedef ....
うんーん　＞＜、すまん、これが限界だ。>>266　後を頼む

>>207
> 白に出来るか黒に出来るかの情報は石自体は持ってないよ

今、白か黒かということ。
白なら、黒にできるが、黒なら、黒にはできないからね。

盤は、個々の石の状態は、個々の石に問い合わせて確認する。
打たれた石によって裏返すことができる石があるかどうかは、
盤が処理するけれど、その中で各石が白なのか黒なのかは
各石に状態を確認する。

ここのところを、きちんと分けて考える。

だから、盤で8x8配列の要素として、
enum
NON,
BLACK,
WHITE
なんていう状態を示すデータの持ち方をすると OO的には破綻する。

8x8配列には、石の有無と、石がある場合その石インスタンスに
アクセスできるための情報を格納する。
C++だったら、石インスタンスのポインタの8x8配列を用意しておけばOK。

あ、そう。
んじゃ底辺ソリューションシステムズの宇津井さん、今回のレビューをまとめて、
それをうちにメールしといて。明日の午前中は俺会社いるから、朝一で送ってね。

>>273
念のため確認なんだけど、その設計は今回「あえて全てをオブジェクトとして設計する」って
コンセプトの元に、ネタとしてやってるって意識でOK？

あんた、レビューに出席しててそんなこともわからないの？

>>269
すまん、休憩時間だった。

また罵り合いか

いえいえ、休憩時間も仕事して下さるなんて有難い限りです。
コーヒー飲みます？

========================================================

　　　　　休　　憩　　終　　了　(2006/3/25 15:15)

========================================================

何を持って妥当性を検証するのかよくわからないんだよね。
もしかして好みでやってない？仕事なんだからさ、趣味は学生で卒業してよ。ね？

少し進んだよ
CIshikoro *ita[8][8];

別にポインタじゃなくてもいいじゃん

>>281
学生さん乙。
現場にまともな要求書があると思ったら大間違いだぞ、と。
自分で要求を想像しながら作って、結果に責任をもつ。
ここまでやらないと社会人としてやってけないぞ。がんばｗ

973 名前： 69式オサンクローン ◆4E1yVnBRhg 投稿日： 2007/03/25(日) 00:48:32
議論の核がないからな。要件定義はできない馬鹿どもしかいないっぅことかな。
んぽぽんだから無理はない。

907 名前： 仕様書無しさん 投稿日： 2007/03/25(日) 11:54:18
オブスレの馬鹿供は「要件」もはっきりさせずに
設計を語る
んぽぽんです。だから荒れる。まとまりがつかない。
これはまわりくどいジャワポンの基本的体質。

>>283　頼むよ、宜しく

char ita[8]; でいいんじゃね 8bit x 8

ビットテストして判断すれば一番高速

ビットテストって何？

#define X_MAX 8
#define Y_MAX 8

class Board{
private:
　CIshikoro *_p_ishi_array[Y_MAX][X_MAX];

　void InitBoard(void)
　{
　　for(int yy = 0; yy < Y_MAX; yy++)
　　{
　　　for(int xx = 0; xx < X_MAX; xx++)
　　　{
　　　　_p_ishi_array[yy][xx] = new CIshikoro();
　　　}
　　}
　　初期配置する処理
　}
　
}

シフト演算してビットの値0|1を見る

状態が3つなんだから一つの石に2ビット必要なわけだが

C厨どぽぽん

ところで記録の実装って
盤全体を覚えるの？
それとも直前と直後の手を覚えるの？

>>292
じゃあshort使えばいいじゃん、俺めんどいから前のいきさつ読んでないのよ
それよか他につっこむところない？

だれがだれかわからん

>>290
defalt constructorで
Board（）｛.....
_p_ishi_array[yy][xx] = 0;
....｝
じゃだめですか？

NULLを何も置いてない状態と見なすんですか
あまり良い方法とは思えないなあ

class CIshikoroの属性は何が良い？

なんでポインタの必要があるの？

>>294
ははは。C厨が実装方法聞くようじゃおしめぇだな。

基本は初期配置と手の系列だけ覚えといて、
30手目から1手戻るときは
初期配置から29手目まで配置計算しなおすんだろ。

今回必要だとは思わないけど、
複雑なケースは動画圧縮の方法に習って、
例えば8手目毎に盤面状態も記録とって、
配置再計算の手間を省くとか。

俺は聞いてないよ

一部だけ出していいも悪いもねーだろ
コード出すならまとめて出せ
コーディングのお勉強は別でやれ

>>303　早く設計おわらせるなり、ほら、早く>>303、納期に間に合わないよ

>>304
仕事できなさそうな奴だな

>>305　うん、わては仕事できないよ。
ココ、わてと同じ香具師多いから好きなスレなりよ。

お前ら、ちょっとこれ見て一服しろ
http://up.nm78.com/old/data/up128194.jpg
ム版から拾ってきたぞ

>>307
ブラクラぽいアドレスだなぁ

>>308　天下のNHKのコピーだぞ、見れよ

見覚えある女性穴がぐいっとこう足を拡げてだな・・・

それをチラ見している男の目つきがいやらいな

身体が若いな。

騙されんな、コラだぞ。

つかあくまで検証なんだから、もっと楽な言語つかえよ

>>258のせいでスレが伸びなくなったな。

>>258 (この局面では)〜はすぐやるほうがいよ。
　　　　俺だった〜するだろうな。
>>259 どうぞ

終了って、アフォかと。

つうわけで >>258よ、
お前の主張を別に否定しないから
お前の主張はお前さんが実行してくれ。

実行しないなら、すくなくとも最後の煽り文句
「俺だったら〜する」を撤回してくれ。

それがこのスレのマナーなんだ。皆それを守って、
自分の発言を実証しようとしている。

違うだろ、まずテストコード書かなきゃ。

じゃぁもう>>258はスルーするぞ。

今度 >>258が発言する時は、
　・　発言を訂正するか
　・ 検証結果を持ってくるか
二つに一つって事で。

>>317 テストファースト・スレ立ててそこでやってろｗ

質問、主張、説明の仕方をわきまえない んぽぽん ばっかだな。

ある程度設計がまとまった段階でコードに落としてみるのは
間違った手法じゃないと思うがな。特にノウハウが十分でない
技術使うような場合は、設計だけで要件満たすものができる
確信なんてもてないだろ。

ただ、2chみたいに叩かれることが確実な場所にソース晒すの
は結構勇気がいるな。金くれるんだったら、出さんでもないが。

このスレって最近流れ早いよね。なんで？

>>322が荒すから。

>>316
そんなこといったって、現時点じゃ設計したやつ以外できないだろ

いや、>>6のクラス図あれば作れると思うけど。
みんな面倒だからやらないんでしょ？

>>316
>>318
なに人のせいにしてんの
別にだれかにやれとかいってないし
大体訂正たって、どう訂正すればいいのさ。
コードなんて書いても、何の意味もありませーんってか？

ここをおまえ自身が否定しない限り、この意見は「お前の」意見でもあるわけだぞ？

荒し煽りはスルーしましょう。

>>325
無理っぽくね？

>>321
ごもっとも。

俺、石クラスなら作れるぞ。
戦略クラスは、>>331 にまかせる。

だが断る

ぶっちゃけ石クラスなんていらない

確定申告はどうするの？

終わった

AIのアルゴリズムが一番面倒くさい

おまえら、あいつらは理解できないんじゃない。

理 解 す る つ も り が 無 い だ け。

余計性質が悪いｗ

生成()
→[ゲーム]　　new Player(黒)
　　　││────→ [プレーヤA]　　new Player(白)
　　　││───────┼┼────→ [プレーヤB]　　new Board()
　　　││───────┼┼───────┼┼────→ [ゲーム盤]
　　　││　　　　　　　　　　.││　　　　　　　　　　.││　　　　　　　　　　││
　　　││　　　　　　　　　　.││　　　　　　　　　　.││　　初期配置().　││
　　　││───────┼┼───────┼┼──────→││
　　　││　　　次を打て()...││　思考処理()　　 ││　　　　　　　　　　││
　　　││──────→││.─┐　　　　　　　││　　　　　　　　　　││
　　　││　　　　　　　　　　.│|　|←┘　　　　　　　.││　　　　 　 打つ() ││　石を置けるか()
　　　││　　　　　　　　　　.││───────┼┼──────→││.─┐
　　　││　　　　　　　　　　.││　　　　　　　　　　.││　　　　　　　　　　│|　|←┘
　　　││　　　　　　　　　　.││　　　　　　　　　　.││　　　　　　　　　　││　リバース()
　　　││　　　　　　　　　　.││　　　　　　　　　　.││　　　　　　　　　　││.─┐
　　　││　　　　　　　　　　.││　　　　　　　　　　.││　　　　　　　　　　│|　|←┘
　　　││　　　　　　　　　　.││　　　　　　　　　　.││　　　　　　　　　　││　パス/終了判定()
　　　││　　　　　　　　　　.││　　　　　　　　　　.││　　　　　　　　　　││.─┐
　　　││　　　　　　　　　　.││　　　　　　　　　　.││ (パス/終了なし)│|　|←┘
　　　││←──────┼┼───────┼┼───────┤│
　　　││　　　次を打て()...││　　　　　　　　　　.││　思考処理()　　 ││
　　　││───────┼┼──────→││.─┐　　　　　　　││
　　　││　　　　　　　　　　.││　　　　　　　　　　.│|　|←┘　　　　　 　 ││

warota

げげぇ。
ライフラインが全部アクティベーションになっちゃってるし。
書き直しだ。

UMLエディタにAA出力機能をつけてほすぃ。

何故、お前らUIを蔑ろにしてんだ。
UIがなきゃ、人(プレーヤー)とのやり取りもできないし、
処理結果の描画もできないじゃねぇか。

>>340
UIを重視する文化があったら、Webアプリ
全盛時代なんか来るはずがない罠。

はぁ？　UIにWebアプリとか関係ないだろ

生成()
→[ゲーム]　　new Player(黒)
　　　││────→ [プレーヤA]　　new Player(白)
　　　││────────：─────→ [プレーヤB]　　new Board()
　　　││────────：───────────────→ [ゲーム盤]
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　　：
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　初期配置().　　：
　　　││────────────────────────→││
　　　││　　　次を打て()　　：　 思考処理()　　　　 ：　　　　　　　　　　　　：
　　　││──────→││.─┐　　　　　　　　 ：　　　　　　　　　　　　：
　　　││　　　　　　　　　　.│|　|←┘　　　　　　　　 ：　　　　　 　 打つ()　 ：　石を置けるか()
　　　││　　　　　　　　　　.││───────────────→││.─┐
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　│|　|←┘
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││　リバース()
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││.─┐
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　│|　|←┘
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││　パス/終了判定()
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││.─┐
　　　││　　　　　　　　　　　 ：　　　　　　　　　　　　 ： (パス/終了なし)│|　|←┘
　　　││←────────────────────────┤│
　　　││　　　次を打て()　　：　　　　　　　　　　　　 ：　思考処理()　　　　 ：
　　　││───────────────→││.─┐　　　　　　　　：
　　　││　　　　　　　　　　.　：　　　　　　　　　　　.│|　|←┘　　　　　　　　：

うわぁ、よくやるなｗ
すげえ根性。ほめてつかわす

何かがおかしい

UIなんかくだらねえ。
プロトコルやらせろやプロトコル。

>>345
ほいほい
生成()
→[ゲーム]　　new Player(黒)
　　　│|　|────→ [プレーヤA]　　new Player(白)
　　　│|　|─────────────→ [プレーヤB]　　new Board()
　　　│|　|───────────────────────→ [ゲーム盤]
　　　││.─┐初期化()　　　：　　　　　　　　　　　　 ：　　　　　　　　　　　　：
　　　│|　|←┘　　　　　　　　 ：　　　　　　　　　　　　 ：　　　初期配置().　　：
　　　│|　|────────────────────────→││
　　　││─┐ゲーム進行() .：　　　　　　　　　　　　 ：　　　　　　　　　　　　：
　　　│|　|←┘　次を打て()　.：　 思考処理()　　　　 ：　　　　　　　　　　　　：
　　　│|　|──────→││.─┐　　　　　　　　 ：　　　　　　　　　　　　：
　　　│|　|　　　　　　　　　　.│|　|←┘　　　　　　　　 ：　　　　　 　 打つ()　.：　石を置けるか()
　　　│|　|　　　　　　　　　　.││───────────────→││.─┐
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　│|　|←┘
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││　リバース()
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││.─┐
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　│|　|←┘
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││　パス/終了判定()
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││.─┐
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　(パス/終了なし).│|　|←┘
　　　│|　|.←────────────────────────││
　　　│|　|　　　次を打て()　　：　　　　　　　　　　　　 ：　思考処理()　　　　 ：
　　　│|　|───────────────→││.─┐　　　　　　　　：
　　　│|　|　　　　　　　　　　.　：　　　　　　　　　　　.│|　|←┘　　　　　　　　：

>>346 つまり作れないんだな。

>>346
プロトコルをやらせろって。。オセロでどんな通信するのかとw
せめてインターフェース定義させろとかにしとけ

まだできないの？

>36
36は非常にいい突っ込みだ。
OOをやっていると必ず「見えない物」を設計しなければならなくなる。
初心者のうちは最初はその見えない物を、どこかの見える物に付加するやり方でも構わないと言うのが、
誰かが反論していた内容だろう。最初はそれでも構わない。
しかし確かに36の言う通り、正しくは見えない物も設計する必要がある。
オセロの例では進行手順とルールが見えない物だろう。
だから俺の例ではGameクラスを設計しそれを入れている。
慣れないうちは見える物から設計し、見えない物を後から分離した方がやりやすいと言うのが趣旨である。

OOの特徴は修正を繰り返しても劣化しない（むしろ完成度が増す）と言う特徴がある。
「OOなんだから最初に完成度の高い設計をして...」と言うのは大ウソである。
このすスレで難しい設計書を書いてもついていけるのは、最初から本気で見ている人だけだろう。
見ている人は「何で分からないんだ」、ぱっと見の人は「ごちゃごちゃ分からない」となる。
OOのコツは、最初に必要最小限で単純な設計から始めると言う事である。

>電球
オセロの例で分かってもらえなかったのは非常に残念だ。
まず、電球の言う「OOは生産性が悪い」と言うのは、確かにその通りだ。
業務を知り尽くした優秀な設計者が、構造化とOOで設計したとしよう。OOの場合はセッターやゲッターで
抽象化されるため、コードが冗長になる。つまり構造化の方が簡単にできる。
ではなぜOOでやるのか？それは仕様に不明な点や変更が多い物を作るからだ。
例えば電球の言う「在庫管理システム」のような物を作ったとしよう。
電球は多分この手の処理は作り慣れているので、何の疑問もなく適切に作ることができるだろう。
しかし今の世の中、高い金を出して同じ物を作ることは少ない。また社会の変化も早い。
例えば「マンが喫茶の在庫管理システム」を作ることになったとしよう。
電球が処理抽出型で作り慣れている「デパートの在庫管理システム」のつもりで作ったら、
使い物にならない物が出来るかもしれない。この場合、全部作り直しだ。
またそれが判明するのは改修を重ねて破綻し、どうしようもなくなった開発後半だろう。
しかし倉庫を抽象化したOOで設計したなら、倉庫を使うシステムなら大きく外れることはない。
また正しく抽象化されていれば、倉庫の変わりに別の物を使っても、影響範囲は倉庫の所だけになる。
変更の自由度も高いし、実際にわかる所から設計を進められるので開発の序盤で問題点も分かる。

つまりOOとは不確かで変更の多いシステムを作るのに優れているということだ。

ゲッターやセッターは構造化のときからあるけど・・・

>>351
今回のスレのメインテーマは >>22 のような密結合設計の
生産性、再利用性、拡張性、保守性の改善だ。
ここで言う再利用性、拡張性は、完成後の話ではなく、主に開発中の話だ。

いくら空理空論を重ねても、>>22 のような設計では、
同じような構造で型違いのデータ、ロジックが大量生産され、
出来上がったシステムのどこへ行っても同じ風景の迷路のような構造になるだろう。

>>22の設計の問題点は、

・View と Model の分離が完全には出来ていない事
・Modelがデータとロジックに分離している事
・画面主導設計により、ロジックが画面に従属している事

にあり、その本質は「疎結合設計」の欠落にある。

今回のオセロ設計でも、
>>6にあった「疎結合設計」を>>193で削除してしまった。
これはキミの経験不足、スキル不足の賜物とは言えないかね？

>>351
今回のスレのメインテーマは >>22 のような密結合設計の
生産性、再利用性、拡張性、保守性の改善だ。
ここで言う再利用性、拡張性は、完成後の話ではなく、主に開発中の話だ。

いくら空理空論を重ねても、>>22 のような設計では、
同じような構造で型違いのデータ、ロジックが大量生産され、
どこへ行っても同じ風景の迷路のような構造になるだろう。
つまり生産性、再利用性、拡張性の低いコードができてしまう。

>>22の設計の問題点は、

・View と Model の分離が完全には出来ていない事
・Modelがデータとロジックに分離している事
・画面主導設計により、ロジックが画面に従属している事

にあり、その本質は「疎結合設計」の欠落にある。

今回のオセロ設計でも、
>>6にあった「疎結合設計」を>>193で削除してしまった。
これはキミの経験不足、スキル不足の賜物とは言えないかね？

なぜ2回も

分析クラスて設計におちるとパッケージになるの？

チュウしようか？

接続状態が悪いかサーバの反映が遅かったかのどちらかじゃね

>354
351って俺だけど、俺に言っているのかよく分からんな。
とりあえず答えておくか。
開発中の再利用性の話と言うのと、空論ではダメだと言うのは同意だ。
22の設計の問題点を書いているが、実際にはその解析は結果論だろう。
帳票と画面はOO向きではない。それは画面内のパーツは再利用出来るが、基本的に同じ情報を表示する
別の画面は少ないと言う事による。ただし知らない人にはこれも結果論だ。

一番の問題点は、最初に数枚の帳票を作ってみなかった事による。
最初にOOで帳票を1枚作って見る。次にもう一枚作って見ると、最小単位のパーツを除き、
ほとんど再利用出来ない事に気が付くだろう。5枚も作れば抽象化が困難なことに気が付く。
つまりOO論理先行の中級者が、実際に作りもしないで強引に設計を進めた事が問題なのだ。

>>360
>>22の設計は
帳票出力なんていう単純な話じゃなくて、
金融証券系の基幹システム(マスターメンテ型アプリ)だろ。

その類の技術的テーマ

　・View はView固有のデータとモデルを持つ事もある。
　・Modelは、Viewに依存しないデータとモデルを持つ。
　・両者の分離は、例えばMVC type1 や MVC type2で行われる。

は、もうWebｱﾌﾟﾘｹｰｼｮﾝ分野で解決済である
という事実を教えてあげよう。

結局、他分野のアーキテクチャへの目配りが足りねぇから
時代遅れの設計を繰り返してるだけじゃねぇの。

もうひとつ突っ込んどくと、
帳票出力なんていう単純アプリの場合は
帳票(View)側は既存のフレームワークを使って
そこに出力内容に関するロジックを追加する程度の話だろ。

> 金融証券系の基幹システム(マスターメンテ型アプリ)

> マスターメンテ型

とても複雑そうには見えんな。
けっきょく単純アプリでﾃﾞｽﾏっただけだろう。

帳票出力を笑う者は帳票出力に泣く。

結局、肝心な事は何一つ学ばない 62式おじゃばさま

結論： 62式おじゃばは、疎結合設計のできないﾃﾞｽﾏ製造機

OOとはメモリという砂場で砂のお城を作るために、
お母さんが幼児に与えたプラスチックのスコップの
ようなもの。
幼児達はスコップを振り回してキャッキャキャッキヤ
と喜んでいます。でも、幼児達は砂のお城は作れて
も砂場の外に出ると、とたんに泣き出してしまいます。
VRAMという硬い土や、レジスタというコンクリートや、
出力ポートという鉄の扉や、割り込みという外敵を前
にどうしてよいのかわからないのです。メモリという砂
場の中でしか遊べない幼児達は、今日もせっせと楽
しそうに自分でイメージした砂のお城を作って遊んで
います。

ここでは低レベルの話はしていない

・ゲーム盤 と 審判＆ルール
・審判 と ルール
・プレイヤ と 戦術
の分離理由

■マイクロカーネル・パターン　あるいは
■「方針と実現の分離」原則
　プログラム中に散在する「方針」と「実現」を分離する事で、
　プログラムの複雑性を減らし、保守性や拡張性を高める方法。

　【方法】
　　方針と実現の「インタフェース」を設計する。
　　方針と実現の間のやり取り＝「プロトコル」を設計する。
　【メリット】
　　・実現の分離により、実現方法の改善が容易になる。
　　・方針の分離により、方針変更への対応が容易になる。
　　・プログラムの複雑性が減り、保守性や拡張性が高まる。
　【デメリット】
　　・方針と実現の分離により、オーバーヘッドが発生する可能性がある。
　　　- 方針と実現を異なるプロセスに置くと、コンテキスト・スイッチングが多発し、
　　　　メモリキャッシュのミスヒット、CPUレジスター退避、CPUパイプライン破壊
　　　　といったパフォーマンス低下につながる。(WinNTデバイスドライバ・モデル)
　【由来】
　　Mach OS, MacOSX, WinNT系Kernel などのマクロカーネルOSでは、
　　既存OS開発の反省点
　　　- 巨大かつ複雑なため、保守性や拡張性が低い
　　　- 方針と実現が未分離なため、変更が困難
　　を踏まえ、カーネル内に方針のみを置き、
　　実現はカーネル外のプロセスに委譲した。

　　この結果、それまで巨大化する一方だったOSコアがコンパクトにまとまり、
　　以降の開発で、OS本体の改善や、実現方法の拡張を行うベースとなった。

アーキテクチャ・パターン第一巻のパターンやね。

>　　　- 方針と実現を異なるプロセスに置くと、コンテキスト・スイッチングが多発し、

マルチタスクOS自体のコンテキスト・スイッチングは、
マルチスレッド採用である程度回避できるけど、

>　　　　メモリキャッシュのミスヒット、CPUレジスター退避、CPUパイプライン破壊

CPU側のコンテキスト・スイッチングは
マルチスレッドを使っても無力だな。

まあ、スレッド内部で複数のオブジェクトに責任分担する分には、
関数呼出＋α程度のオーバーヘッドで済むと思うけど。

ってそんなLow Levelなパフォーマンスが問題になるのは、
戦術クラスくらいなものだけど。

本の中身をここにコピペしてどうするつもりかと、

なんだ、その程度のことをすらすら語る教養もねぇのか。
アーキテクチャ・パターン云々は、知らない人へのリファレンスだと思ってくれ。

自演やめれ。みてて恥ずかしいわ。

あと、審判とルールの分離理由はもう一つあるな。

ルール： 特定のアプリケーションに依存しない
　　　　　　中立なルールの表現
審判：　　特定のアプリケーションに対する
　　　　　　ルールの適用

>>33-34 のルール仮想クラスにもうちょっと手を入れると、
「特定のアプリケーションに依存しない中立なルール」として完結できるな。

ヒント： Step, Score, Playerの抽象化

ゴタクはいいからさっさと作れよ。納期過ぎてんぞ。
画面設計どうなってんだよ。客が画面の動きだけでも
見たいって、言ってきてっぞ。

優れたノウハウってのは高い所から低い所へ何年もかけて流れるものだ。

最初は、スーパー・プログラマを擁する研究開発
　　例えば マイクロカーネルOS
次は、新規市場の期待できる新規分野や
　　　　既存のしっかりした研究開発基盤を持っている分野
　　例えば Webアプリケーション、携帯電話
　　例えば 通信インフラ
途中で優れたソフトウェアエンジニアが、ノウハウをまとめてパターン化
　　例えば アーキテクチャパターン
最後は レガシー開発分野
　　ここは、ノウハウの否定に血道をあげる。
　　例えば このスレ住人

おい、客がもう画面はhtmlでいいって言ってきたぞ。
もちろんアニメーションもいらないということだ。
これだったら作れるだろ。ということで、脳内設計は
ほどほどにして、さっさと作れ。

あ、いっとくが大分値切られたから、今度のボーナス無しな。

マイクロカーネル・パターンのデメリットはもう一つあるな。

■マイクロカーネル・パターン　あるいは
■「方針と実現の分離」原則
　【デメリット】
　　・方針と実現、双方に関わる変更をする場合、
　　　マイクロカーネル・パターンの疎結合は、
　　　通常の密結合と比較して、変更コストがかさむ。
　　　具体的にはインタフェースやプロトコルの再設計が必要になる。

>>378
入門者向け課題を客に売るダメ営業乙

しかも見ず知らずの著作者に断りなく営業活動する権利侵害っぷり

およ、>>380-382 顔真っ赤だぞ、どした？

方針と実行の分離原則がわからねぇっつうなら、
例えば管理職と実行部隊の分離を考えてみればいい。

・実行部隊は管理職の指示に従う
・管理職は、実行部隊にダメなのが入ってきたら入れ替える
・管理職が成果を出せなければ、(上司が)管理職をすげかえる。

っつう前提で、もし

・管理職が実行部隊の仕事に手を出すと、
　現場が混乱したり、管理業務に支障を来たす。
・実行部隊が管理職にさからうと、
　命令系統が混乱して、仕事を管理しにくくなる。

だから、管理職は管理業務、実行部隊は命令の実行に専念した方がいい
っつうだけの原則論。

すみません、>>384をすげかえて欲しいんですが...
あと、オセロゲームツクールっていうフレームワークがあるんで
これを発注しといてください。
えぇ、>>384の人件費より全然安いんすよ。

自由参加の討論を
自分が所有する会社かなんかと勘違いしてる
妄想患者乙

方針と実現の分離

方針課長：おぃおまぃらー、金稼いで来い
実現社員：わかりますたー

実現社員A：大規模プロジェクトを受注しますた
方針課長：よしよし。支払い受けるまでﾃﾞｽﾏ化させんなよ

実現社員B：銀行強盗して金持ってきますた
　　　　　　　　指名手配中くらったんで逃亡資金を前払いしてくらさい
方針課長：通報しますた。頑張って勤めて来い、です。

方針課長：今期売り上げ足りねぇなぁ〜
　　　　　　　ここらでいっちょ現場にでるか〜

実現社員A：大規模プロジェクトがﾃﾞｽﾏりますた。
　　　　　　　客は上司出せって逝ってます・・・あれ？課長が居ない・・・
　　　　　　　契約破棄されちゃうよ、どうしよう・・・

(一方その頃、課長は・・・)
方針課長：あれ？これやり方違うんじゃないの？
現場監督C：あ、課長！それはこの現場のやり方なんで・・・
　　　　　　　　いやなんでもないです (ちくしょー課長の作業全部やり直しだ)
現場作業員D： 課長！お仕事ご苦労様です。
　　　　　　　　実はAの大規模プロジェクトが火を噴いてるって話ですが、
　　　　　　　　あれは社員Aの方針が間違ってるんです
方針課長：　(あれは俺が出した方針だよ！)

OOでない開発方法論の御託を偉そうに語るな。
ここに書くのはスレ違いだ。

> OOでない開発方法論

バカかこいつは。
OOが、OO以外から学ぶ事をやめたら、
それは空理空論に過ぎなくなる。

OOってのはメタファ。
他にネタ元があって、それをメタファるためのフレームワークがOO。
OOそのものに本質があるかのような発言は、世迷言も甚だしい。

だからプロジェクト管理の話はスコープ広げすぎだと何度いったら…

マイクロカーネル・パターン、もう一つ大きなメリットがあるな。

■マイクロカーネル・パターン　あるいは
■「方針と実現の分離」原則
　【メリット】
　　・方針と実現を分離し、間のやりとりを「プロトコル」化する事で、
　　　OSの分散処理〜ネットワーク・サービスへの拡張が可能になる。
　　　　
　　　[そして現在]
　　　OSの責任範囲は縮小し、あらゆるサービスを提供するネットワーク上の
　　　１要素を管理するプログラムに過ぎなくなった。
　　　他方、ネットワーク・サービスは発展し、遍在化し、コモディティ化した。
　　　

↑こんな話ここでして何の意味があんのよ。
ゼミか研究室でやってろよ。脳内の誰かと議論してんのか？

>361
俺に言っているのか誰に言ってるのかイマイチ不明瞭だが、とりあえず忠告しておこう。
MVCモデルと言うのは、画面表示とロジックを分離すると言う事で、OOとは関係ない。
まあはっきり言うと、OOとは逆の考え方だ。
なんでこれがWEBで発生したかというと、WEBでは画面デザイナーとプログラマで分業する必要があったからだ。
しかし実際にはデザイナーが直接JSPを触るのは危険で、結局はプログラマがデザイナーのデザインを元に
JSPを修正してテストしているのが実情だろう。
ちなみにMVCモデルに利点はない。WEBアプリケーションの分野で解決済み？
偽コンサルとStruts開発者のよた話以外では聞いたことないな。

帳票なんて言う単純アプリの場合はどうのと言うのは同意だが、現存するプログラマの全員が自分と同じ
スキルを持っていると考えては行けない。
いかに自分が単純だと思うことでも、知らない人は知らないのだ。
逆に当たり前だと思えることの方が、実際にその場面に直面した場合に見過ごされることが多い。
重要なのは、当たり前と思うことにも疑問を持ち、冷静に分析することである。

>365
一応言っておくが、オサンスレの62式と俺は別人だぞ。
つーかこっちに62式が現れたのか？見かけないが。

> MVCモデルと言うのは、画面表示とロジックを分離すると言う事で、OOとは関係ない。
> まあはっきり言うと、OOとは逆の考え方だ。
> なんでこれがWEBで発生したかというと、WEBでは画面デザイナーとプログラマで分業する必要があったからだ

なんだ、Smalltalkもやった事ない低学歴か

62式おじゃばさまは、まだ「疎結合」を学習できていませんでした。

業務系開発ばっかやってると
WebのJSPなんかに未だにコダワリ持っちゃうんだね。

もう見てて痛々しくなってきた。

この手の低脳に、理系研究開発職のおいらが
Web開発者呼ばわりされるのかと思うと、
もう笑うしかない。

結論： 62式おじゃば は、やっぱり疎結合設計を理解できていませんでした。

>>393

仮にもOOコンサルの名前を騙っていた人間が
そんな嘘ばかり並べて、お前は恥かしくないのか？

>>399

だから　たかひろはOOコンサルを名乗るのを辞めたんだろう。
もういいじゃないか。ほおっておいてやれ。

たかひろとは違って、OOを一切騙らずに
業務システムの疎結合を語れるコンサルの例：

　　http://watanabek.cocolog-nifty.com/blog/2005/10/post_8562.html

↑そこに書かれてることもどうかと思うが。。。

業務SE向けにRDB用ドメイン・モデリング集を出してる人だね。
しかもモデリングツールまで自前で開発してる気合の入りよう。
ひがちゃんのダイコンをおすすめページにしてる所なんか、
気が利いてるよな。

>>402
具体的な話をしないと、
単なる中傷になっちゃうよ。

って具体論でも嘘を吐きまくる>>393の撚れた認識じゃあ、
また妙な妄想に基づいて人格攻撃に走るだけかな。

次はマイクロカーネルか。
マイクロカーネルはオブジェクト指向を語る上では良い失敗作である。
つまりカーネルのようなハードウェアに密接に関わり、速度が必要な分野においては抽象化すべきでない
と言う事である。誰かが「優れたノウハウってのは高い所から低い所へ何年もかけて流れるものだ」と
言っていたが、時代錯誤も甚しい。最新技術は現場から猛スピードで吹き荒れる物だ。
マイクロカーネルについては自称研究者によって何年も研究されたが、Linuxの開発者によって見事に
叩き潰された。研究室では時代の流れについて行けない好例だろう。

>394
Smalltalkで使っていたからOO？
その論理で言えば日本で作ればハンバーガーも日本料理になる。

>399
俺はOOコンサルではない。OO技術者だ。
俺は偽コンサルには少なからず恨みがある。デスマーチの尻拭いをさせられた恨みだ。
だから偽コンサルは叩き潰す。ちなみにMVCやマイクロカーネルマンセーとか、
初心者にデザパタ覚えろと言う奴とか、EJBやO/Rマッピングが素晴らしいとか言う偽コンサルは
攻撃対象なので覚悟しておいた方がいい。

結論： 業務系OOコンサルは平気で嘘をつける。
　　　　業務系OOコンサルは、ネット上で匿名で何年間も人格攻撃をしてきた。
　　　　業務系OOコンサルは、実はOOの事も業務の事もよく判っていない口先だけの詐欺師。
　　　　業務系OOコンサルは、矛先が自分に向けられると、他人を攻撃しだす。

>>404
いや、イベントドリブンを主体にしてモデル設計すると、そのまま実装に
もっていきにくくね？ まるでクラスを個々のスレッドで動かさないといけ
ないようなイメージを与える。業務処理というより分散処理を使った処理
の方に向いてると思っただけ。一般的な業務処理だったら俺はアクティ
ビティ図とノートの説明ぐらいの方が分かり易い。

追加： 業務系OOコンサルは、業務とOO以外の知識もデタラメ。
　　　　ただ自分がこうあってほしいという妄想の世界を語り続けるだけ・・・

MVCはGUIなんてどうでもいい部分は切り離そうという考え方でしょう

一般の皆様へ：

62式おじゃばさまの発言 >>393、>>406 は
専門家としての発言ではなく、素人の思い込みにすぎません。
まちがっても信じこまないように、注意を喚起しておきます。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上

>>406
基地外にいちいちマジレスすんな

>>408

デスクトップアプリ、ネットワークアプリ、SOA、DBMS、
大抵そんな動きだよな。
え？イベントドリブンな実装すらしたことないの？
もっと経験を積んで成長してくれ。

>>410 GUIって自分で一から作ろうとしたら、結構専門的な知識いるぞ。
まぁ出来合いの部品使ってる分にはそれほどでもないだろうが。

>>412＝おじゃばさまが涙目になりながら必死にかきましたね？

>>413
ちょっとお前さ、実装してここに晒してみろ。
簡単なのでいいからよ。

>>413
お前、業務のイベントとイベント駆動型プログラミングのイベントを混同
してるだろ。著者マンセーのくせに、著者の意図理解してないんじゃね？
権威に迎合すんものほどほどにして自分の意見もった方がいいよ。

>393
仕方がないのでこちらに来てみました。
おじゃばさまさん、どうやら彼の中で前オサン？スレで君が
「内容があったのは」云々で私のことを書いてくれたおかげで
自作自演という考えがうかんだものと想像されます。
真偽の程はここは2chですから、どうでもいいことです。
彼？の思うようにさせてあげればよろしいのでは。

ID出ない板で、誰の発言も糞も関係ねっつの
発言の中身以外どうでもいい

おじゃばさまの目的は、
素人に嘘を流し込んで、自分の餌とすること。

間違っても巻き込まれてはいけない。

嘘の例：
>>393 MVCモデルと言うのは、OOとは関係ない。はっきり言うと、OOとは逆の考え方だ。
>>393 ちなみにMVCモデルに利点はない。

　　MVCモデルは、世界最初のオブジェクト指向環境Smalltalk上で、
　　アプリケーションモデルと表示を分離するフレームワークとして開発され、
　　その後のデスクトップアプリの多くで採用されてきました。
　　マイクロソフト社のDocumentViewアーキテクチャは、MVCのバリエーションに過ぎません。

>>406 マイクロカーネルはオブジェクト指向を語る上では良い失敗作である。
>>406 マイクロカーネルについては自称研究者によって何年も研究されたが、
　　　　　Linuxの開発者によって見事に叩き潰された。

　　マイクロカーネルの一つMach OSは、
　　コンピュータサイエンス研究の最高峰の一つであるカーネギーメロン大学の
　　分散処理プロジェクトで開発されました。
　　このプロジェクトは、Xerox PARCをはじめとするオブジェクト指向研究とは全く関係ありません。
　　MachOSカーネルの開発者は、後にMicrosoft社に移籍し、
　　現在使用されているWindowsのOSカーネルを設計しました。
　　また、AppleコンピュータのMacOS Xでは、Mach OSそのものが採用されています。

　　これに対しLinuxは枯れた設計をコミュニティーで育てる、という全く別のアプローチを行い、
　　マイクロカーネル全盛の現在において、なかなか健闘している、と言えるでしょう。

　　私はLinux 0.01の頃からLinuxカーネルを眺め、ハックし、利用してきましたが、
　　Mach OSはLinuxの設計にもいろいろな意味で影響を与えていると認識しています。

↑いっぱいグクったなぁ

>>420
わかったから病院池
もしくは氏ね

>>421
過去の記憶をまとめただけだよ。

>>422
健常者に危害を加える恐れがあるので、措置入院すべきですね。

>>423
はやく氏んでね

>>418
ここで 62式おじゃば と呼ばれている奴は、
1962年生まれのコテ「おじゃばさま」の事であって、
62式おさんの中の人とは別人かもね。

結論： おじゃばさまは、反論できなくなったり嘘がばれるとスレを荒す。非常に判り易い。

マジ？おじゃばって62年生まれなのか？

>>426
わかったわかった。氏ね。

>>427
すくなくとも、今のスレで発言してるおじゃばさまは、
1962年生まれの似非コンサルとそっくりだな、発言内容が。

>>429
へえー。そいつの発言みれるとこない？

【関連スレ】
http://pc11.2ch.net/test/read.cgi/tech/1091350633/589-641
http://mimizun.com/search/perl/dattohtml.pl?http://mimizun.com:81/log/2ch/infosys/science2.2ch.net/infosys/kako/1001/10018/1001867356.dat
http://science6.2ch.net/test/read.cgi/infosys/1077451506/
新着レス 2007/03/16(金) 23:25
【関連サイト1】
幻のTucker!サイト http://web.archive.org/web/19990221135319/www.tky.threewebnet.or.jp/~tucker

62式おじゃばさま はさーん

> 初心者にデザパタ覚えろと言う奴

これは　たかひろ　の発言だな。

>>420
説明ごくろうさん。
コンサルを名乗る輩の中に、
とんでもない奴が居る事がよく判った

>>429

どれがおじゃばかわかんねーよ。つか憂鬱本の著者＝おじゃばってこと？
んなアホな。

たかひろ 偽装書き込み 乙

おじゃばさまの中の人が誰か知らないけど、
言ってる内容見れば判る。
こいつは自分の都合だけで嘘を平気でつく詐欺師だって

62式おじゃばさま　涙目ｗｗｗｗ

(´・ω・`)ぜ〜んぶ大域変数でやれば楽やと思うねん

その前におじゃばさまを始末しないと。

>>437
どのレスのこといってんの？
つか2chで嘘ついてなんかメリットあんの？

おじゃばさまは自分より知識や経験がある人が来ると
突然相手を中傷し始めたり、スレを荒し始めるから判りやすい。

自分の無知を冷静に眺めて成長するのが普通の社会人。
自分の無知に気付くと、自分に無知を知らしめた相手を攻撃するのがおじゃばさま。

>>441
2chで嘘をつく理由。それは釣りだよ、釣り。
あいつは、釣りに異常な関心を持っている。
毎日釣果を日記につけているらしいぞ。
そういう意味では、今日は入れ食いだった方
じゃねぇか。

>>444
つっても池沼しか釣れてねえじゃん。

おいおじゃば、これはどの偽コンサルが言った発言なのか、
明確にしろ。

今のままじゃ、たかひろの過去発言をおじゃばが叩く構図にしか見えない。

> ちなみにMVCやマイクロカーネルマンセーとか、
> 初心者にデザパタ覚えろと言う奴とか、
> EJBやO/Rマッピングが素晴らしいとか
> 言う偽コンサルは 攻撃対象なので覚悟しておいた方がいい。

>>445
質は関係ないんだよ。奴は量しかみていない。ただ自ら巧妙に
撒餌をするから、はたからみて釣果が判りにくい時があるんだ
よな。

これがホントの自問自答？

>>406
おいおじゃば、これはどの偽コンサルが言った発言なのか、
明確にしろ。
今のままじゃ、たかひろの過去発言をおじゃばが叩く構図にしか見えない。

> ちなみにMVCやマイクロカーネルマンセーとか、
> 初心者にデザパタ覚えろと言う奴とか、
> EJBやO/Rマッピングが素晴らしいとか
> 言う偽コンサルは 攻撃対象なので覚悟しておいた方がいい。

>>406
おい、おじゃば
俺の知ってる範囲では：

> MVC (マンセーとか)
これは最初はXerox PARC、次はIBMソフトウェア事業部の発言だな。
はやく攻撃してこいｗｗｗ

> マイクロカーネルマンセーとか、
これはソフトウェア・コンサルには発言権のない領域だな。
また無知を晒したな。

> 初心者にデザパタ覚えろと言う奴とか、
これはたかひろの発言だ。
はやく攻撃してこいｗｗｗ

> EJB (が素晴らしいとか)
これはSun, Netscape, Oracle, IBM あたりの発言だな。
Netscapeはもう潰れてるけど、それ以外はまだあるから
はやく攻撃してこいｗｗｗ

> O/Rマッピングが素晴らしいとか
これはオブジェクト指向方法論者の発言だな。
ラショナル〜IBMソフトウェア事業部にいって、
攻撃してこい。
おぉーっと。古くさいODBMSの現地法人の元一関係者が
のこのこ行っても門前払いかもしれんがｗ

誰とかどれとか、属人性大好きっ子かお前は。うっせーよ。

偽おじゃばさまのとばっちりを食う元祖おじゃばさま

笑えるｗ

偽おじゃばさま＝元祖おじゃばさま＝６２式似非コンサル

たかひろ、たかひろ、たかひろ、
ここでAOP宣伝をしっかりするように
あとで豆蔵に来るように

いよいよメンヘル方面か

たかひろ の 巣　http://science6.2ch.net/test/read.cgi/infosys/1077451506/

オセロつくる話から、こんなにたくさん犠牲者出ちまったよ。
ココ電のせいだろ。

おいおまいら
スレを荒すな

煽り・荒ししかできないなら、さっさと外へ出ろ

ひでぇ荒れようだな。
それもこれも >>393, >>406 がデタラメを書き始めたからか。

匿名なら、人を中傷できる。
商売のためなら大嘘でもつける。
OO普及のためなら、いかなる犠牲も省みない。

そんな信仰者には、私はなりたくない。

おじゃばさまの特徴。
・長文の中にいかにもつっこみたくなるような微妙な勘違い表現をいれる。
・エサ投入後は置竿が基本スタンス。エサがすぐ食いついた場合は、撒餌を
　しつつ釣りを楽しむ場合もあるが、通常は、暫く放置した後、ゆっくりと
　釣果を確認するのを楽しみとしている。

ココの住人へ
まずは、憂鬱本を読んでOOを勉強するように

>>461
いまさら偽装工作やっても遅いよ。

>>393以前の発言は、彼の本心から出たものだと思う。
そして part1, part2ではそれなりにマジメに議論をやってた。(少なくとも彼は)

彼の発言を見ると、時々ネタなのかと思うほど素朴で慎ましい物の考え方が散在する。
それは、彼の人間性の根っこの部分の良さを発現しているのだと思う。
しかし、現場での彼の発言はあまりにナイーブ過ぎる。はっきり言って現実離れしている。
その結果、彼の現場は彼自身の理想とは裏腹に、泥沼にはまっていく。
それが彼の器なんだ。誰だって、己の器を大きくするのは難しいんだ。許してヤレ

あ、しまった！立て読み仕込むの忘れてマジに書いちゃったｗ

>>463
いや、あいつの発言はいつもあんな感じだぞ。何かがひみょ〜に
辺な方向にずれてんだよ。わざととしか思えん。

あいつって、どっちの事？
２ちゃんにいつも居る人の方？
それとも２ちゃんにたまに来る真剣な人の方？

マジボケがネタボケを評論する展開のよかーん

ん？　>>393のおじゃばさまのこと

↑うそ。

ネタボケがマジボケ＆ネタボケ本人を、他人の振りして評論する展開

>>469
それなら同意。
で、現場でも浮いた発言して適当にあしらわれちゃう。

例えば、OOは知らないけど実務に慣れてる下請けの人相手に、
　　初心者向けデザパタ勉強会
みたいなのをやらせて顰蹙を買う

おじゃばがどうであろうと、マジどうでもいいっつの
気に入らなきゃスルーしとけ。

おじゃばさまが御自身の御発言のスルーを御所望なされております

>>464　おじゃばのことはどうでも良い

それより、62式おじゃばと言う恐ろしい例外が発生したんだ
早く対処しないと大変なことなるぞ
早く対策を講じるるんだ

[質問]おじゃばさまの発言をスルーしますか？

[回答]
　　○ スルーしない
　　○ スルーした振りをして延々と続ける
　　○ スルーして忘れた振りをして後でネタにする
　　○ スルーしたりしなかったりする
　　○ わからない
　　

○ スルーしない

● わからない

それよりおまいら、疎結合の事例は判りましたかー？

オセロはどうなったんだよ。

>>476
>>477
わかった、気の済むまで粘着していいから余所いけよ。な？

>>478

ttp://www.ezaki-glico.com/release/20040824/

>>62式おじゃば

疎結合の事例は判ったのか　　　早く報告しろ、62式おじゃば

>>480
きめえ

それよりおまいら、疎結合の話 (>>369-371, >>375, >>380, >>391, >>387, )は判りましたかー？

オセロの疎結合設計は >>6 が正解
>>193-205, >>347 は、密結合でﾃﾞｽﾏ(>>22)にまっしぐら、ですよ。

もし判らない人が居たら、レスを読み直して復習しておく事。

本日はこれまで。

========================================================

　　　　　本日の講義はここまで

========================================================

再開ｗ

>>483 横断的関心事の考慮も忘れないように

ふむふむプレーヤは盤面の状況を見る必要はない、と。

>>471
あれには俺もビビった。

仮にも金払ってプロを雇ってて、
そんな低レベルな勉強会に時間を費やすとは何事か、と。
案の定、勉強会は大盛下がり大会。
直後に下請けからクレームが入って、勉強会は取りやめになった。

やっぱね、それくらい知ってて常識だよな、
と思ってたら、後で衝撃の事実。

その「金払って雇ってるプロ」連中、
デザパタ使ってる振りしてただけで、
実は全然使いこなせてない。

そんな現場にデザパタ持ち込むなよ〜ってオチ

>>486
ナイス突っ込み。
とりあえずコンピュータ・プレーヤからゲーム盤に矢印引っ張って、
「ゲーム盤の状態を見る()」って書いといてくれ。

いや、コンピュータプレーヤに限定せずに、
プレーヤから線引っ張った方がいいかも。

>>487 ITドカタの世界だからね、以上

オブジェクト指向というのはね。メモリとかパフォーマンスとかを無尽蔵に使って、
ドカタでも組めるような単位に分割するためにあるんだお。

人の場合は画面見るからいいんじゃねぇの？

>>488
だからおもちゃレベルの検証コードかいて
ちゃんと動くものかどうか確認せっつーの。
晒さんでいいから。

>>491
本来は出来る人間がより生産性を向上させるためのものだがな

おっさんスレは具体的なものを求めてるが、このスレは抽象的にアプローチする。
興味深い。

あくまでも、疎結合設計など重要ではない、
そんなふうに振舞うけなげなおじゃばさまであった

だが、彼の瞳が濡れているのを誰が見逃すだろうか？
明日の定例会議の荒れ様を想像して、
会議の欠席理由作りに頭を巡らすメンバー達だった。

UIという面倒な部分を見ないフリして、脳内変換してるだけですからぁ〜

おじゃばさまの場合は

健康な気配りと書いて健気(けなげ)つうよりは、

病的な気●いと書いて病気(びょーき)だろ

もしもし？底辺システムソリューションズさん？
朝一で送ってって言ったのにきてないよ？どういうこと？

>>497
ガワに意味は無い

>>500 つうか、つくれねんだろ？　楽な仕事だなおい。

ユーザーとプログラムの間でやりとりするデータやメッセージの内容が
重要なんであって設計の段階ではインターフェースなんかどうでもいいんだよ。

>>499
オブジェクト指向を理解してませんね。

>>497、>>500
実際にはViewを入れなきゃ意味が無いが
ココでは問題領域のみを扱うで良いんじゃね

>>503
お前のせいスレが荒れてどうにもならんぞ。
OO<手続きでかまわんからなんとかしろ。

現実との接点を失い、純粋な神学論争の世界に行ってしまったようですねえ。
「針の上で何人の天使が踊れるか」という有名な神学論争を思い出します。

>>503　ココ電　五目並べゲーム作ってくれよ
オセロ作ってから技術力が飛躍的に伸びてるだろ。
今のココ電の実力を、お前を蔑んでるココの香具師に見せ付けるのに良いと思うぞ

>>506
実際問題、モノが出来てるだけおめえの方がえれえわ。

五目並べってオセロより簡単ですけど・・・

後手でも必ず勝つ最強の五目並べだよ＾＾

>>509　もう、ココ電はオセロ作ったんだからオセロじゃ意味無いだろ
でも、囲碁じゃかなり難しくなるだろ、そこで、五目並べとなったわけだ
ま、あと、ココの香具師がオセロ完成出来たら奇跡と思ってる、だが、ココ電なら完成できると思ってる
で、会社の休み時間においがココ電に感謝しながら五目並べで遊ぶということだ。

あぼ〜ん表示が延々と増え続ける不思議スレ

>>502 その肝心のユーザーとやりとりするメッセージがぼやけたまんまなんですが・・・

ココ電が暴れる展開よりは、
元祖62式おじゃば が暴れる展開の方が
現実的には面白いし、読みがいがある。
part1, part2 見ればわかるとおり

む、五目並べはパターン評価が入る。
むずかしいかも。

>>515
お、じゃあそれやろうぜ

評価関数まできたけどつまった。

世界選手権とかあるんじゃん。そこそこむつかしいんじゃないの？

>>509
五目並べがオセロより簡単だって？　アホか、升目の数が全然違うんだよ。
つまり石の置き方のパターンが増えるから、速度と強さのバランスをとる
難しさがオセロの比じゃないことが分からねぇのか？

３−３　３−４止め　４止めー４止め　
で置ければいいんだよな？

>>511
何が悲しくて思考実験のために指動かさなくちゃならんのだ
アホらしい

そういや五目並べのルール忘れたわ

よしよし
３−３　３−４Ｘ　４Ｘ−４Ｘ　３　４Ｘで勝ちか

五並べ（連珠?）にもいろいろルールがあるから、やるなら要件定義が大事かと。

ｼﾞｻｸｼﾞｴﾝぱたーん

よし。きょうはここまでだ。
バイオ４やって寝る

>>526
二度と来るな

スレのレベルが下がる

ここまでさがったレベルをいまさら気にすることもねえだろ。。

下がっているのはお前のレベルだけ

本当に疎結合設計は理解できたのか？

もし判らないところがあれば、言ってみろ。

時間のある範囲で説明してやるから。

ここのOO厨は、グラフィカルなUIに弱いのが致命的だな。
グラフィックシステムも抽象化の良い題材だと思うが、
いかんせん、知識が乏しいのがなんともトホホだな。

>>530
荒しは巣に帰れ

>>529
すまん、理解できてない、なんかそれのよさを解り易く説明したサイト知らないか

ここの人達は砂のお城しか作れませんよ。砂場から出れないのです。

>>532
どのレベルで説明すれば判ってくれるんだ？
わかり易いサイトってのがよく判らん。
OSや大規模システムではよく知られた概念なんだけど。
俺が判りやすく説明するのでは不満足なのか？

みんな文句言って叩いていいものが出てこないかと待っている感じが滲み出ていて
笑える
俺としては、なぜ只で教える必要がある？って感じだ
まして２ｃｈでとかありえない
このスレが発端で２ｃｈネラーがOO得意になったりしたら市場価値は台無しだ
中には少しはわかっている奴もいるようだが、そこのところよく考えて発言するように

>>534　じゃ、頼むよ

>>532

例えば最近の流行の疎結合はこんな感じだ。
http://www-06.ibm.com/jp/developerworks/tips/ytech/tutrial_soa/002.html
俺の知り合いも、ここの講演の講師をしたりしてた。

>>535
ならだまってろよｗｗ
ただで教えるのはいやだけど、自己顕示欲だけは満たしたいってわけか？ｗｗｗ

>>535
たかひろ

お前の発言には失望するばかりだ。

俺は自分の個人的プロジェクト(Under the table projectとも呼ぶ)が
何らかの理由で続行不可能になった場合、さっさとネット上に放流する。

俺個人の考えなどというものは、俺個人の独創などではなく、
俺を取り囲む世界全体の仕組み、規則、そういったものから読み取れる
共通的なアイデアに過ぎない。

ただ、自分がそのアイデアの存在に気付いて、それを愛し育んだ、
その愛情を、ネット上の誰かと共有したい。ただそれだけの思いを込めて、
ネット上に放流する。

俺のアイデアを笑う奴もいるかもしれない。
俺のアイデアなどとうに通り過ぎた所で頑張ってる奴も居るかもしれない。
でも、俺は俺なりに考え、こうだと思った。それを発信することで、
誰かがいくばくかの共感を持ってくれたら・・・うれしい。

オープンソースの隆盛、そしてインターネットを介したゆるやかな研究開発とは
結局そういうものだ。

>>538
違うな、『発言したいなら市場価値が上がるような権威のある場所でしろ』ってことだ
お前らはOOと2chが結びついて幸せなのか？
そこんとこよくドメイン分析するように

>>537
オー、少し解って来たぞ、熱烈感謝、これすごい分かり易い例だな

>>538
>>535はね、肝心のことは何も教えないで、知らない香具師見つけて徹底的に叩いて笑いものにして楽しむ、そんな人ですよ

>>540
権威って何？
国内に、オブジェクト指向の権威などない。
オブジェクト指向になど、権威はない。
あるのは商売だけだ。
だから、俺はオブジェクト指向では権威を求めない。

話はかわるが。
おまえはc野を嫌っているようだが、
俺はすくなくともその興味の領域や活動に、
一定の共感を覚える。
だけど結局は商売人、国内では奇跡的ともいえる
ひがちゃんのプロジェクトに迷惑かけちゃう程度のタマだ、

>>541
リンク紹介が少しでも役立ったなら、うれしい。

ただ、>>535はそれなりに(多少は？)国内のオブジェクト指向知識普及に関与した(だけ)ひと、だ(たぶん)
金を貰ったかどうかはともかく、そういうこと。

なんちゃって。んなわけねぇだろ

>>540
> お前らはOOと2chが結びついて幸せなのか？

それはまさに たかひろ マター だな。

>>540は　疎結合を知らない香具師を叩くチャンスが減るから教えようとした香具師を制止したんだな

>>542　>>540の、『発言したいなら市場価値が上がるような権威のある場所でしろ』は
皆が知るとセミナーや顧客先なんかで、自分（>>540）の自慢ネタが減るということ

そうそう、ｃ野が 方法論本の権利だか印税でもめてた時、
「その方法論、たかひろ ん所で俺が言ってた話に近くて、興味覚えました」
ってblogに書いたら、その後1ヶ月　blogが止まった事がある。
あれは気のせいだったのかな。

>>547
気のせいだ

どうみても気のせいです。ほんとうにどうもありがとうございました。

どこからどうみても気のせいやな。うん。

知り合い同士の会話ですか？
何で相手がわかるわけ？　文に特徴あるのかな
？？？？？？？....？？？？？

だんだん本音書くのがだるくなって来た

> ？？？？？？？....？？？？？

こういうあり得ない記述するだけで、
充分マーキングの対象になるって

俺もわけわからん。
わかるのは>>530==>>540が糞だってことだけだ。

まちがえた>>535==>>540だ

流し読みしたが、
荒れまくってんなぁ

2chプレイヤーの審判クラスを誰かやってくれんか。
まずは議論のスコープを整理してほしいわ
齟齬が激しすぎ

>>553 ごめん、俺の脳内を文字にしただけ
やっぱ、ターゲットにされるかな、気をつけよ

いま、俺の目の前でおこったありのままの事を言うぜ。

俺が知ってる奴、これが大の２ちゃん好きで、
会社でなんかあると会社叩くスレすぐ立てちゃうヘタレなんです。
で、そいつの発言内容や文体には特徴があるから、
あ、あいつまた書いてるなぁーっていつも見てて気付くんです。
あー、そろそろ新しい会社で一悶着起こしたなー、とか、
あー、あいつまだあの事後悔してんだなー、とか。

で、そいつが今日、俺に言うんです。
> 知り合い同士の会話ですか？
> 何で相手がわかるわけ？　文に特徴あるのかな
> ？？？？？？？....？？？？？

DBのトランザクションって、OOではどうやって表現するの？
教えてｴﾛい人

あすぺくつ

OOで表現する方法が知りたいの

トランザクションまねーじゃ？

>>556
> まずは議論のスコープを整理してほしいわ
> 齟齬が激しすぎ

まるっきり無関係の事を頻繁に１行ずつ書いてるのは、単なる荒し。
話をすぐ逸らすのは、天然ボケ。
そしてこのスレのテーマは疎結合設計について。OK?

疎結合設計とスレタイは関係あるのか？

JBossSeamマンセーってことか？俺もマンセー

あるだろね。
情報隠蔽(カプセル化)というのも、疎結合の一種ってな意味で。

>>566
Ok。
じゃあ疎結合はスレタイに関係あるってことで。
しかしOOが理解できないのはそれだけが原因じゃないよな。
まずはOO設計できる技術者が育たない要因を挙げないと話が進まない。

１．疎結合が理解できてないからオブジェクト指向が理解できない。
他は？

>>564　関係あることにしてくれよ、俺、疎結合設計ついてしたいよ。
とりあえず　OO開発には疎結合設計が重要であるり、疎結合設計を心掛けなければクラス間の依存関係が強くなり、仕様変更でデスマーに陥る

クラスは部品である
一つでは用を為さず組み合わせる事によって仕事をする
その程度の粒度でなければならない

>>567
練習量が少ないせいじゃね？それなりに練習がいるとおもう。

>>567
普通にjavaをやるとOO設計が自然と身に付かないのですか
java使い＝OO使いってイメージなんですけど

>>571
断じてそれはない。

>>567
人間の常識はコンピュータの非常識
安易に現実世界を投影しようとするから上手くいかないのでは

そうですか、orz

>>567
訂正希望

> １．疎結合が理解できてないからオブジェクト指向が理解できない。

1. オブジェクト指向を理解したつもりになっていても、
　　- カプセル化のメリットや使いこなし方
　　- 疎結合設計のメリットや使いこなし方
　　を理解しないと使いこなせない

理解するのと使いこなすのとの間は、結構隔たりがあるとおもう

あっ、>>574は　>>572へのレスです。

>>575
オブジェクト同士の組み合わせの重要性

OOを理解できない理由
とりあえず列挙して、それなりに挙げ終わってから１つずつ判定しましょ

１．疎結合が理解できてないから
２．練習量（実務経験・もしくはそれに類するもの）が少ないせい
３．Javaを習得していないから
４．プログラムに現実世界を投影しようとするから
５．クラス・継承・多態性・カプセル化などのオブジェクト技術概念のメリットを理解していないから

カプセル化出来ていないOOP

五目並べだけど
パターンマッチ方式にするか、学習型にするが迷ってる。
学習型の方が美しいが、学習時間が必要だ。

>>581
どっちゃでもええわ
空気嫁

VB6でOOは無理

>>567
> OO設計できる技術者が育たない要因

小規模プロジェクトでは、OO設計できる技術者が育っている。
大規模プロジェクトでは、
　(1) メンバーの質の低さ/学習意欲の低さ
　(2) メンバーの責任領域/裁量範囲/参加期間の限定性
等の要因により、一般に技術者が育ちにくい。
また、大規模開発の発注者側の後進性、保守性も足かせになっていると思う。

空気読むのはシステム上危険なのでやめましょう。

>>584
に同意かな。
つかいきなり大規模プロジェクトを壮大なOOの実験場にすりゃ、
そりゃ後にはトラウマしか残らんだろ。

>>581
ココ電ガンバレ、ココの香具師見返せよ
どっちが良いかは判らんが、パターンマッチでも学習法でも対応できるように
他の部分をモジュール化しておくといいんじゃない、ここで言う疎結合みたいな感じかな

>>559
いくらＯＯを装ってもＤＢとは相性悪いので無理。
隠蔽するしかない。

>>585
とにかくつくれ
俺もやるきがあったらつくる
が、http://iroha.poloa.net/ref/07_02.htmの時点で難しすぎてかなり萎えたが

大規模プロジェクトは１人が担当する領域が狭いので
全体を把握しにくい傾向にある

小規模プロジェクトを一人で
全工程やって回したほうが数倍勉強になる

>>591
なる。つかそれ以外無理。

OOを理解できない理由
とりあえず列挙して、それなりに挙げ終わってから１つずつ判定しましょ
なんか聞いたことある話や思いついたのを追加してみた
あと、できればマニアックな専門用語ではなくそれなりに分かる言葉で挙げていきましょ

１．疎結合が理解できてないから
２．練習量（実務経験・もしくはそれに類するもの）が少ないせい
３．Javaを習得していないから
４．プログラムに現実世界を投影しようとするから
５．クラス・継承・多態性・カプセル化などのオブジェクト技術概念のメリットを理解していないから
６．手段であるはずのオブジェクト指向なのに、OOで作ることが目的になったPJが多いから
７．言葉の洪水でやる気が無くなるから
８．大規模PJにより各担当箇所が結局OOではなく機能分岐してしまうから
９．偽装請負による技術者の定着性の無さや玉石混交化のため
10．DBを使う現場が多い中でトランザクションはOOと相性が悪いから

>>593
ものすごく大事なことがるぞ、---頭がへたれだから---

OOを理解できない理由
とりあえず列挙して、それなりに挙げ終わってから１つずつ判定しましょ
あと、できればマニアックな専門用語ではなくそれなりに分かる言葉で挙げていきましょ
「へたれ」は荒れそうだから変えてみた

１．疎結合が理解できてないから
２．練習量（実務経験・もしくはそれに類するもの）が少ないせい
３．Javaを習得していないから
４．プログラムに現実世界を投影しようとするから
５．クラス・継承・多態性・カプセル化などのオブジェクト技術概念のメリットを理解していないから
６．手段であるはずのオブジェクト指向なのに、OOで作ることが目的になったPJが多いから
７．言葉の洪水でやる気が無くなるから
８．大規模PJにより各担当箇所が結局OOではなく機能分岐してしまうから
９．偽装請負による技術者の定着性の無さや玉石混交化のため
10．DBを使う現場が多い中でトランザクションはOOと相性が悪いから
11．学習途中で諦める技術者が多いから

いろいろ思うところがあるなー。楽しみにしつつ今日は寝る。乙。

>>567
> OO設計できる技術者が育たない要因

日本人の民族的特性＝徹底された合理的思考の不足　が原因だと考える。

日本では、徹底的に議論して優劣を付けるのを良しとしない風土がある。
その結果、各種の手法や選択肢のメリット/デメリットが明らかにされる事なく、
全てがうやむやのまま決まり、実行され、成果や失敗までもがうやむやにされる。
つまり、優劣の判断や、それに基づく経験知の共有がなされない。
これが、設計技術者が育ちにくい原因である。

年功序列制度の崩壊や、外資系企業の市場参入、新興企業の発展に伴い、
一部では実力主義と呼ばれるものも目立つようになってきたが
そこで言われている「実力」とは、実は「声の大きさ、根回しの良さ、要領の良さ」で
評価が左右される程度のものに過ぎず、
高い専門性/熟練度を要する理系分野は、むしろ敬遠されがちになっている。

最後の文、訂正。

高い専門性/熟練度を要する理系分野は、育成も評価も難しいため、
努力が報われない分野として敬遠されがちな傾向がある。

OOを理解できない理由
とりあえず列挙して、それなりに挙げ終わってから１つずつ判定しましょ
あと、できればマニアックな専門用語ではなくそれなりに分かる言葉で挙げていきましょ

１．疎結合が理解できてないから
２．練習量（実務経験・もしくはそれに類するもの）が少ないせい
３．Javaを習得していないから
４．プログラムに現実世界を投影しようとするから
５．クラス・継承・多態性・カプセル化などのオブジェクト技術概念のメリットを理解していないから
６．手段であるはずのオブジェクト指向なのに、OOで作ることが目的になったPJが多いから
７．言葉の洪水でやる気が無くなるから
８．大規模PJにより各担当箇所が結局OOではなく機能分岐してしまうから
９．偽装請負による技術者の定着性の無さや玉石混交化のため
10．DBを使う現場が多い中でトランザクションはOOと相性が悪いから
11．学習途中で諦める技術者が多いから
12．OOをやっても正当な評価を得られないと感じている技術者が多いため

>>597
１行にまとめちゃったけど不備あったら補完しちゃって。
それではオネム〜

長いよ

1.バカだから

>599
OO否定厨は 6. 辺りに多そうだな。

バグにも負けず　仕変にも負けず
２徹にも３徹にも負けぬ丈夫な体を持ち
金はなく　決してモテず
いつも菓子パンで昼をしのぐ
一日にバグ票４件と　設計書と少しのメールを読み
あらゆるソースにコメントを入れずに
よく見ず　聞かず　分からず　そして働かず
客先の　データセンタのタコ部屋の　小さな机の前にいて
東に障害あれば　仕様だｺﾞﾙｧと言い張り
西に仕変を要求する客あれば　運用でカバーしろと無理を言い
南に氏にそうな後輩あれば　さらに仕事を押し付け
北に徹夜やデスマがあれば　俺は関係ないからなと先に帰り
デグレのときは涙を流し　リストラの噂にはｶﾞｸｶﾞｸおびえ
みんなにＳヨと呼ばれ
ほめられもせず　苦にはされる
そういうものに　わたしはなりたい

> OO設計できる技術者が育たない要因

OOの解釈にはブレがあり、意見対立が生じやすいが、
国内固有の諸事情(後述)により、合理的かつ「公平さを感じさせる方法」で
意見対立を昇華し合理的かつ健全に発展させる文化的土壌がないため、設計者も育たない。

　※国内固有の諸事情：

　(1) 一般大衆レベルにはびこる島国根性、言語的鎖国、そして合理性よりも感情の重視。

　　　客観的合理性スタイル(徹底した議論/比較により優劣が明らかになる、という幻想)よりも
　　　感情に訴えるスタイルが、一般大衆には受け入れられやすい。
　　　→　この結果、合理性も教育的配慮もなしに
　　　　　「頑張ったのだから認めてあげよう」という間違った判断がなされる。

　(2) 方法論の断片的輸入による、連続性、一貫性の欠如

　　　 本来のOOは、構造化手法、データ中心手法の延長線上にある。
　　　 ただしそれは平穏に連続的に変化したわけではなく、
　　　 別々の人物によりほとんど同時並行的に発展したのだが、
　　　 その後、構造化方法論者が自身の方法論を発展させる過程で、
　　　 他の方法論を試し、受け入れる事を通じて、「連続性」や「一貫性」が発生した。

　　　 国内ではインターネットが普及するまでの間は、輸入文化商売がはびこっており、
　　　 ある時点の構造化手法、特定ベンダーに固有のデータ中心手法、
　　　 そして断片的な形でOO手法が次々と輸入された。
　　　 それらは、海外のように責任を持った方法論者が一貫した連続性を持たせる事もなく、
　　　 相互に関係のない独立した存在として、ばらばらに共存し続けている。

(つづく)

　(3) 国内ではOOは軽視されてきた

　　　 OO発展期に、国内では別の動きがあったため、結果としてOOへの取り組みが遅れた。
　　　 「別の動き」とは上は第五世代コンピュータの論理プログラミング、
　　　 下はマイコンブーム〜島国PCの閉鎖文化〜ゲーム文化の発展、である。
　　　 OOは、一握りのエリート層(東大の鈴木元教授＠元PARC、米沢教授＠元Hewitt研、慶応大の所教授、等)や
　　　 例外 (富士XeroxによるJStar商売、VSによるSmalltalkV輸入、Borland TurboC++登場、とその影響)を除き、
　　　 OOは「本気で取り組むに値しない傍流文化」という扱いを受けてきた。
　　　 この結果、海外でOOが主流の座を占め、OOがキー技術の一つになっても、
　　　 古い認識のままOOを軽視したり、古い愚かな姿勢(例えば吉田爺のOO狂想曲に代表される興味本位)で
　　　 OOに接する人が多く、OOの普及を疎外する原因となっている。

「合理的かつ公平さを感じさせる方法」
なんて書いてて、情けなくなってきた。

合理性、公平性なんてのは「感じる」ものではなく、
ディベートして説得して勝ち取るものだ。
それを「感じる」なんて書くとは、俺も「感情の国」の住人なんだな。

> OO設計できる技術者が育たない要因

・OOおよびOO業界には、知的好奇心を満足させる深みが欠落している。

90年代前半の認識として、ようやく普及しはじめたOO (GNU g++, VC++ Windowsプログラミング) よりも
新しい世代の関数型言語の発展 (SML/NJ、Haskell) の方がより重要であり、知的好奇心を満足させるものだった。

オブジェクト指向には、ラムダ計算や型推論、あるいは代数的仕様検証といった
理論的背景が欠落している。
あるのはただ「現実の世界をシミュレーション」というスローガンだけ。
(現在においても、カルデリ＠MSリサーチの Object Theoryくらいしか理論化の試みはない)

実践が理論と結びつくことで、飛躍的なアイデアを実現する高等ハッカー人種にとって、
ひたすら実践の積み重ね、クラスライブラリの積み重ねでしか事を成しえないOOは、
極めて魅力に欠けた存在だった。

知的好奇心を持つ人物へのアピールが足りない。だからOO設計者も育たない。

まず最初に言っておくが、俺は62年生まれではないし、たかひろって人も知らない。どんな人だ？

>450
まず偽コンサルの特徴として、悪い事は言わないというのがある。
まあ、雑誌や本、HPの受け売りで、本当に悪い所を知らないと言うのもあるが、どちらにせよ同罪だ。

まずMVC。Strutsの使いにくさを言わない。
Strutsは処理を変えると、大体3〜5カ所に手が入る。
JSP、リソースファイル、Strutsコンフィグ、Validation、フォームビーン、アクションビーン。
実際、ベテランでも大変だ。未経験者に説明するのは地獄である。これのどこが保守性が優れている？

マイクロカーネルは、速度が遅すぎて期待した性能が出なかったと言う事を言わない。
そのため組み込み系では全滅し、シェアではなく、分野の範囲で言えばそんなに広くないWindowsなどの
パソコン分野で使われているのにすぎない。またそれをおおげさに言う。

次に初心者にデザインパターン。
デザインパターンがOOのサンプルに過ぎないことを言わない。
それも多くが通常使わない特殊な物だと言う事を言わない。

>>608
一言聞いておくが、お前はどのような目的で発言をしているのだ？

俺はお前を論破できるが、それは時間の無駄だ。
何のために、>>405後半を主張し、>>608で言い訳をしているのか、
その目的を明らかにせよ。

× >>405後半
○ >>406後半

EJBは物凄く重いのも言わない。結局一番の目的である速度向上になってないのを言わない。
自動生成の設定ファイルをカスタマイズするのが、かなり面倒なのも言わない。
自動生成で作成されたソースが非常にデバックしにくいのも言わない。

O/Rマッピングも遅いのを言わない。
更新削除が致命的に遅いのも言わない。結合や関数使用がとても面倒なのを言わない。

>>608>>611

>>449-450の「どの偽コンサルの発言か、明確にしろ」という問いかけに答えないお前は
すでに議論で負けている。

たかひろ、って誰よ？
どっかwebページでもあるのか？
なんでこんなとこで内輪話しとるの。基地外？

> OO設計できる技術者が育たない要因

・２ちゃん等、粗悪なコミュニケーション・メディアに固執するOO方法論者の存在

かなり有名な会社の人間が、２ちゃんに固執して匿名でOO普及活動を行っていた時期がある。
しかし、匿名メディアでは責任を持った発言など期待できず、
更には匿名メディアでしか発言のできない社会的弱者 (引き篭もり、引退老人、知的障碍者)が
日頃の鬱憤を晴らす対象として粘着したため、
彼なりの高い理念に基づく普及活動が、逆効果になってしまった。
(つまり、２ちゃんで噂され叩かれる対象は、敬意を抱いて努力すべき対象に値しない、等)

OOに関する議論は、実名公開のメディア、オープンなblog等で行うべき。
現状では２ちゃんでの議論は百害あって一理なし。

>>608
それはフレームワークの問題であってMVCの問題ではない

付け加えるなら、
国内で、合理的かつ公平なディベートが徹底して行われない背景には、
本音と建前を使い分けて、相手が反論できない所で陰口を叩く、
という習慣がある。

終身雇用の安定した会社でも、期間限定のプロジェクトでも、
言うべき事を言わずに、後から内輪でブツブツ言い出す場面によく遭遇する。

知的レベルの高いコミュニティー、うまくいっているコミュニティーでは、
そのような発言を吸い上げ、改善へと役立てる努力をする人が一定数居て、
その結果、本来はネガティブな陰口まがいだった意見が、
正常なフィードバックとして有効に機能する。

他方、知的レベルが低くていつもいがみ合っていたり、
寄せ集めでコミュニケーションが不十分なコミュニティーでは、
陰口は陰口を呼び、場の雰囲気が陰険になり、
そして本来うまくいって当たり前の事すら、うまくいかなくなる。
具体的に言うと、大規模レガシー開発の現場、２ちゃんねる等がそれに当てはまる。
このようなコミュニティーでは、一見ネガティブだがコミュニティーの改善に役立つ意見を
拾い集めるのが非常に困難であり、その結果、正しいフィードバックが働かなくなり、
破綻する。

そのようなコミュニティーには近づかない、近寄らない事こそ、
賢い人生のこなし方と言えよう。

1行でまとめると

お前はダメコミュニティで持論を展開するなどアホの典型。

ダメコミュニティーで議論を始めたのは、俺ではない。
すでに数年前に、ダメコミュニティーからの撤退が始まり、
そしてそれが一段落した感があるからこそ、
今ここで数年前のアレは結局なんだったのか結論をつけ、
しめくくろうとしているのだ。

こんなダメコミュニティーで発生した各種の問題を、
通常のコミュニティー上で議論したら、それこそ「２ちゃねらー」の烙印を押されてしまう。

(；＾ω＾)・・・

既知外って自分が基地だと思わないから性質が悪い。

>>620
知的障碍者乙。
自己分析の矛盾は、やはり知的障碍によるものか。

567 名前： 564 [sage] 投稿日： 2007/03/26(月) 23:56:37
　>>566
　Ok。
　じゃあ疎結合はスレタイに関係あるってことで。
　しかしOOが理解できないのはそれだけが原因じゃないよな。

そんな話題逸らしをする前に、
お前自身は疎結合を理解し、それが必要な場面できちんと設計できているのか？

まずはそれを回答せい。

>>616
俺はこのスレはかなり勉強になってるぞ。
上手く言葉に出来ないが、OOの欠点も本来の利点もなんとなく掴めそうな気がする。
自分は元々OO厨だが、俺のOO能力も中途半端だなと痛感した。

2chの場合は各自が取捨選択するのが重要なのは周知の事実。
水掛け論もかなり多いが、不毛に見える議論にも宝が隠れてる。
ゴミの山から掘り出し物を掘り出す感じ。

本気でOO理解したかったら本読むなり、セミナーに参加するなりするっちゅうねん。
こんな嘘か本当かもわからない掲示板のカキコを真に受けるのは危険だというのは
誰でも知ってる。ただ、中には有益な情報をくれる奴もいて、だから、俺は、2chは、
憂さ晴らしと自分の技量確認の場だと思ってる。2chで叩かれるぐらいだとまだまだ
未熟なのだと。それと、質問してみると、よっぽどとぼけた質問じゃない限り、なん
らかの反応返してくれるのが、2chのいいところ。そんな感じの場だな、俺にとっては。

本当を本当と見抜けない奴は、嘘に騙されやすい。

↑これは嘘。

>>624
「憂さ晴らし」はやめてくれるとうれしいが

>>624　>>622に回答するように

デムパｷﾀ━━━━(ﾟ∀ﾟ)━━━━ !!!!!

匿名コミュニティーには匿名コミュニティーなりの特徴があると言う事だろう。
623、624が正しい匿名コミュニティーでのスタンスだろう。

ただ俺は新技術に対する雑誌や本、セミナーの内容はPGの分野においては怪しいと考えている。
例えば雑誌。まあ月刊誌ならJavaの新しいライブラリが出たとしたら、実質調査期間が数日しかないので、
付属のサンプルを動かす程度で終わる。そして開発者の示す利点を並べて終わりだろう。
まあ仕方ない。数日で保守まで見える人はいない。読む方で気をつけるしかない。

本もまずい。出版するまで時間がかかるので情報が古くなる。
また作者も出版する頃には情報が古くなるのを恐れて、問題点を曖昧に書く。
なぜなら出版する頃には改善されている可能性も高いし、特定の事を書くと時代遅れになるからだ。

あとセミナーもまずい。
利点を言うのは問題ないが、欠点を言えない。言うと後で営業から怒られる事がある。
例えばEJBが動く高性能マシンを売っているメーカーの人間が、EJBなんて要らないなどと言えないだろう。
まともなセミナーの講師は、実際の企業の技術者が出る事が多いので、言えない事がある。

結局、問題点というのが出て来ないのが書籍／セミナーの欠点だ。

おじゃば即レスか。

今日もずっとPCに張り付いてたのか。
お前はもう論破されて相手にされていないんだ。
寝言はそこまでにして、はたく就業しろ。

> 例えば雑誌。まあ月刊誌ならJavaの新しいライブラリが出たとしたら、実質調査期間が数日しかないので、

JCPで議論が始まってから、RC版が出て、正式リリースされるまで１〜２年。
実際の議論はコミュニティー周辺で数年前から始まっている。
お前の知見は恐ろしく狭い。あたかも大規模ドカタ現場の自称詳しい人レベルでしかない。

妄想を騙って他人を誤魔化し続けられるとは考えるな。
お前自身のドカタ現場、砂を噛むような作業の中から
真実を見つけろ。それが正しい道だ。

>>630　来てくれたのか、叩かれたから来ないかとオモタヨ、なんか嬉しいな、何でだろ

>雑誌や本、セミナーの内容はPGの分野においては怪しい
じゃ、何が怪しくない？　信じていいのはおじゃばさまの言われたことのみですかね。

おいアフォ
自作自演でスレ汚すな

> お前はもう論破されて相手にされていないんだ。

おじゃばってもう論破されてる詐欺師なんだね。
これ読んで納得。

http://pc11.2ch.net/test/read.cgi/prog/1174837272/81
http://pc11.2ch.net/test/read.cgi/prog/1174837272/85-89

論破･･･猫か？

おい引き篭もり

スレ汚すなと言っているのが聞こえないか？

お前は相手にされていないのだから出てくるな

>>635　それはそのときのつりネタであって、今回のつりネタ>>630じゃない
毎回、おじゃばさまのつりネタを論破することで、自分を磨くんだ
それが、おじゃばさまとの正しい付き合い方かな、と言うことで、論破者募集age

眠いし

なんだ、ここに何年も居着いてるコテ叩き偏執のヒトか。
よくあきないよね、ほんと。

ＯＯは宗教だって。
技術じゃないよ。
何だよセミナーってのは？
文書に書いてある事そのまま喋るだけじゃん。
字読めないの？

５年前のＯＯ厨が一人も生き残っていない事実を指摘しておこう。

引き篭もり学習法

1. 興味のあるネタを見つけ、
　 そのネタについて、妄想を書く

2. 叩かれる。
　 証拠をつきつけられ、コテンパンにされる

3. 表面的な知識のみ増える。
　 実は釣りでしたと言い訳する。

4. 後から場違いな場面でその知識を披露するが、
　 そもそも話が噛みあっていないので相手にされない

5. １へ戻る

あぁ教祖さま

まぁ、煽るのも煽られるのも確かに気持ちえぇが、
それに耽溺するのもどうかと思うぞ、諸君。

ネタでスレ汚す引き篭もり風情が一人前の口をきくな。

また荒れてる・・・
おまぃら学習能力なさすぎ

アニキ、学習能力ないからOOを理解できないのですよね

[オブジェクト指向]
　戦場では必要の無いもの 。世界が親亀・小亀で出来上がっているというおめでたい設計手法。
　尻尾から蛇が伸びて天蓋においでのコン猿様を支えている。無理やりこじつけるために色々な曼荼羅図表が必要だが
　ユーザの一言で連鎖的に灰塵に帰す砂上の楼閣。
　ひとたび疑義を唱えようものなら、宗教裁判が待っている『天動説』の現代版。

>>649
良いね。
出典はどこ？

[オブジェクト指向]
できなきゃ、オフショアーに対抗できず、ドーナッツが輪ゴムに・・
やったことないもの、やったことない部分は石橋を叩く(自戒含む)
そもそも、社内で熟してないものを、コン〜♪におだてられてショーバイやるのが、ヤケドのもと。
ネラーやってる暇あったら、社内ライブラリ、社内ツールの１つでも作ってこいと。

結局、一言で言うなら、慣れない事して大ヤケド(一歩手前)

前に話した基幹サーバー飛ばしてるＯＯ厨な。
とうとう会社の上層部の知られるところになったよ。
毎週落としてるのにいっこうに直そうとする気配が感じられない。
直せないんだか直したくないんだか・・・
今日別の人に問題部分の説明をやってた。別の人が直すらしい。
上司に説明してたけど「ＸＸオブジェクト」とか、「オブジェクト」を強調してた。
オブジェクト指向を知ってるとサーバー飛ばしても許されるとでも思ってるんだろうか・・・

なんで開発がサーバ飛ばすんだ？
そりゃサーバに問題あるんじゃねーの？

オブジェクト指向とは現代版天動説であり、大やけどの元になる。
OO厨は問題が発生しても自分で対処しないで、他の人に尻拭いしてもらうPGである。

OO厨、何か反論ありますか？

>>652
五目並べの進捗どうよ

ＯＯ厨の部分だけ別サーバーに隔離された。
別サーバーだけ落ちる。

>>655
きょうはやるきなし。
うまいアルゴリズムがおもいつかないのです

口だけの井の中の蛙だな

>>656
がんばれ

ココ電
つ　ttp://drudgery.s115.xrea.com/connect5.htm

>>653
バグがあれば落ちますけど。

OO厨が落とせるような「基幹サーバ」ってｗ
そんな奴に特権レベルのpg書かせてるのかよ

鯖がWinMeなんだろ

多分、ココ電球の言っている基幹系サーバはそんなに基幹系じゃないｗ

ばっちり基幹だよ
業務とまるし。

サーバーはサンのブレード

それでアホプログラムで止まっちゃうの？
どんだけスキルないんだよ。
OSはやっぱWin98か？

基幹系がまともという前提なら
逆にスキル無いと止めれんやろ

[オブジェクト指向]
　システム開発に関わる人間(主に開発者)を、人間ではなく「物(オブジェクト)」として捉え、
　非人道的な手段を取る事でコストを下げる開発手法。具体的には格安単金、サービス残業、脅迫リストラ等の事。

　オブジェクト指向開発ではNewキーワードでいくらでもオブジェクトを生成できる為、
　役に立たなくなったオブジェクトは直ちにプロジェクトから破棄される。
　偽装派遣業者が利益を上げるための常套手段。

キチガイ警報発令中

「キチガイ警報発令中」廚か
春だな

お前だ

>>567 名前： 564 [sage] 投稿日： 2007/03/26(月) 23:56:37
>　>>566
>　Ok。
>　じゃあ疎結合はスレタイに関係あるってことで。
>　しかしOOが理解できないのはそれだけが原因じゃないよな。

スレを荒すな社会生活不適応者
お前自身は疎結合を理解し、それが必要な場面できちんと設計できているのか？

まずはそれを回答せい。

>>672
スレタイ読んでから話をしてね
一応答えるけど、結合度については理解してるよ。
あと、PCを介していても相手がいることを忘れずに。
社会生活不適応者、と呼んだことを謝罪してもらいますか。人として。

>>668の書き込みは >>567の書き込みなのか？

もしお前が >>668を書いたのであれば、
お前は仕事で関わる人々を陰で中傷する
社会生活不適応者と呼ばれても仕方がない。

>>567
>>567 名前： 564 [sage] 投稿日： 2007/03/26(月) 23:56:37
>　>>566
>　Ok。
>　じゃあ疎結合はスレタイに関係あるってことで。
>　しかしOOが理解できないのはそれだけが原因じゃないよな。

>>673 名前： 567 [sage] 投稿日： 2007/03/28(水) 07:51:32
> >>672
> スレタイ読んでから話をしてね
> 一応答えるけど、結合度については理解してるよ。

お前は結合度は理解できているが、
疎結合設計は理解・実践できていないわけだ。
その結果、密結合によるどうしようもない設計を連発して
多くの犠牲者を出している、というわけだ。
そいつらに、お前は謝罪しろ

文章をちゃんと読んでね。
どこが中傷になってんの？現実の話でしょ。
嘘を書いてるなら中傷と言われても仕方ないけどね。

>>567
荒らしはスルーしれ

>>677
レスへのアンカー間違ってるYO

× >>567
○ >>674-675

>>676

>>567 名前： 564 [sage] 投稿日： 2007/03/26(月) 23:56:37
>　>>566
>　Ok。
>　じゃあ疎結合はスレタイに関係あるってことで。
>　しかしOOが理解できないのはそれだけが原因じゃないよな。

>>673 名前： 567 [sage] 投稿日： 2007/03/28(水) 07:51:32
> >>672
> スレタイ読んでから話をしてね
> 一応答えるけど、結合度については理解してるよ。

お前は結合度は理解できているが、
疎結合設計は理解・実践できていないわけだ。
その結果、密結合によるどうしようもない設計を連発して
多くの犠牲者を出している、というわけだ。
そいつらに、お前は謝罪しろ。

そういった基本動作ができないから、お前は社会生活不適合者なんだ

社会生活不適応者なのか、
社会生活不適合者なのか、
はっきりしてくれないかなあ

>>679
社会生活不適合者にまともな対応を期待すんな。

>>567は自らの知能の劣悪さが原因でいい加減な仕事をし、
その結果犠牲となったプロジェクトの人々を陰で揶揄し、
社会生活不適合者のレッテルを貼られると反発する。
そんな視野の狭いドカタに、まともな思考ができるわけないだろ

>>679
書き込みの時間を見てから物を言え。
こいつは社会生活不適合者どころか、
単なる引き篭もりだよ。

>>679
ナイス。
社会生活不適応者が「社会生活不適応者」と図星を突かれて怒っているから
言い換えたわけね。からかい方としては上等だ

一人何役もやってる奴がいるな

引き篭もり降臨中！

681=682=683
でおｋ？

社会生活不適合者>>567が社会に害悪を垂れ流してるようですね

>>567はカスだったという結論

おまいら >>567はスルーしろ。

あと業界関係者は、>>567みたいなのに揶揄されないように
お仕事頑張れ

687=688=689乙

また たかひろが関係者を中傷したのか

いつものことだ
スルーしとけ

ほおっておけばそのうち
ばばしろう叩きを始めて仲違いして自滅するだろ
おれらはそれをマターリとヲチしてればいいんだ

おれらはそれをマターリとヲチしてればいいんだ

おれら　自演乙

↑真性ﾋｷｰ降臨

おじゃばは本当にバカだな

うっさいはげ

やる気なす。
飯食い終わったし。

代わりに音作りかけでやめたミサイルコマンドをアップしとこう。

操作はＺＸＣキーだ

http://up.spawn.jp/file/up11530.lzh

ココ豆球はゲ専だということが判明した。

>>698
ココ電球はJava屋?

コボラあがりぽいな。ソースみると。

ソースはともかく、ミサイルコマンドなのがおやぢくせぇ。

こんなの、知ってる時点でかなりのおっさんだろ。

誰かが宣伝したがってる本と同じネタだなｗ
地道な宣伝活動乙

バグがあってゲーム終了すると無限カウント始めるけど
なおしといてね（はあと）

今はＶＣ
そのミサイルコマンドは１．４が出たとき、新機能を使ってみたの。
どっか書き換えると全画面表示もできる

なにこの糞ソース