-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590276デフォルトの名無しさん
2008/06/21(土) 00:47:55二つの値を一つの文字列に合成してシリアル通信するのですが
この命令の合成と返答の翻訳はMonitorとCommクラスどちらに実装するべきでしょうか
質問続きで申し訳ありません
0277デフォルトの名無しさん
2008/06/21(土) 06:02:48"二つの値Constructor"に任せればいいんじゃない？
もしくはMul/Demultiplexerとか？
0278デフォルトの名無しさん
2008/06/21(土) 10:29:05Comm クラスは汎用的なシリアル通信だけを行うユーティリティクラスで
いいんじゃないかな。制御プロトコルの知識は Monitor に持たせる。
0279デフォルトの名無しさん
2008/06/21(土) 12:11:06おれだったら、合成と返答の翻訳を行うクラスを別途作るかな。
0280デフォルトの名無しさん
2008/08/05(火) 22:06:37>おれだったら、合成と返答の翻訳を行うクラスを別途作るかな。
メッセージI/FとパーサーI/F又はどれか一つ用意して
メッセージの詳細はベンダー毎に実装するのが一般的かと思う。
0281デフォルトの名無しさん
2008/08/08(金) 03:31:53ちょっとOO分析っぽいことやってみたかった．
# [実験]で[使用する][シリアルポート]から[遠隔操作できる]
# [温度][調節][機能]付きの[水質モニター]を[管理する]
# [1分毎]に[水質データ]と[水温]を[取得する]
# [PC]から[温度]の[管理値]を[変更できる]
必要な名詞(オブジェクト)
シリアルポート，温度，水質モニター，1分毎，水質データ，水温，温度，管理値
足りない名詞
タイマー
必要な動詞(メソッド)
操作，調節，管理，取得，変更
ここまでやったけど別に何を作ろうというわけではない
0282デフォルトの名無しさん
2008/08/10(日) 12:13:241分毎もかよー
水温・温度もかよー。
0283デフォルトの名無しさん
2008/08/10(日) 13:31:400284デフォルトの名無しさん
2008/08/20(水) 20:05:43例えば以下のような必要とされる要素が有ったとします。
(要素内容はでたらめです。)
・コード/名称/メッセージ/結果/色/高さ/幅
/追加日/更新日/削除日/…(全部で20要素ぐらい)
処理1 … コード/名称/メッセージ/結果
処理2 … コード/結果/色/高さ/幅
処理3 … 結果/色/更新日
処理4 … 削除日
各処理は、クラスに個別分類できる処理になり、各処理に少しずつ上記要素が
絡んでくる状態になります。
このような場合、どのようなクラス設計が適していますか？
現在は、コード/名称～などの20要素ぐらいをBaseクラスにして、
処理1～4までを継承させています。
ただ、こうすると必要の無い要素まで入ってしまい、もっとすっきり
させたいなと思っています。
0285デフォルトの名無しさん
2008/08/21(木) 02:24:17> ただ、こうすると必要の無い要素まで入ってしまい
この時点で継承を選ぶのがおかしい。意味のある単位に切り分けよう。
問題の切り分けじゃなくて、登場人物の切り分けを意識した方がいい。
例えば色／高さ／幅ってGUI上の属性情報なんじゃないの？
処理1と処理4でそれらの情報を使用しないってのなら、
ぱっと聞いただけでも処理１～４は継承関係上の兄弟とは思えない。
> このような場合、どのようなクラス設計が適していますか？
適切な切り分けの単位は要件仕様やその他の背景によって異なるよ。
とっかかりがないなら、それらのデータモデルを構造体化して、
処理の引数に渡してしまえばいい。
0286デフォルトの名無しさん
2008/08/21(木) 15:48:42どうもです。
いえ、GUIの属性とかではありません。
サーバーへコマンドを投げると上記の値が返ってくるイメージです。
処理1なら
1.「コマンド処理1」をサーバへ送信
2.「コード/名称/メッセージ/結果」がサーバより返ってくる。
3．処理1の処理を行う。
処理2なら … と同じ様な処理が複数あります。
0287デフォルトの名無しさん
2008/08/21(木) 23:32:47それで相手に適切なクラスの分け方を聞いたわけ？
一応必要なアドバイスは>>285に入ってるから、熟読して悩め。
>>286の情報だけで何を悩めばいいかを挙げるなら以下くらいかな
・全ての処理で共通する送受信データの基本情報（必須情報）って何なの
・送受信データ全体を木構造に表すとどうなるの（構造体のメンバに構造体を持つかなど）
・送受信データに対して、それを継承するって適切なの
（データモデルとビジネスロジックは普通分けるがね）
恐らくだが、以下みたいな感じに落ち着くんじゃないか
・処理1,2,3,4ってのは、データモデルを引数に受ける関数ポインタ（Javaでいうリスナ）になる
・コマンド処理1,2,3,4と関数ポインタ（Javaならコマンド名のgetterとリスナをセットにしたクラス）と
送信データを引数とし、受信データを戻り値とする通信クライアントクラスが必要（C++なら受信データも引数で受ける）
・送受信データ中、基本情報以外の情報（構造体メンバの構造体）で使用しないものはNULLを入れる
基本情報以外が後からいろいろ増えるなら拡張情報をMapで持つ手もある。シリアライズ（デシリアライズ）がいるが。
最近の流儀だとXMLを使うのも悪い手ではない。（個人的にはJavaやC#ならこれにするな）
あなたのプロジェクトの答えを書いたつもりはないので、参考になるなら参考にして、後は悩め。
0288デフォルトの名無しさん
2008/08/21(木) 23:34:15×受信データを戻り値とする
○受信データを関数ポインタの引数にしてその関数を実行する
0289デフォルトの名無しさん
2008/08/31(日) 16:08:07ブラウザ - Webサーバー - APサーバー - DB
という一般的な構成でのエラーチェックで質問です。
入力データのチェックをするときに、未入力や不正文字はMVCのCで
チェックして、DBに問い合わせないとわからないチェックはMでいいですよね。
注文入力をするときに、数量の未入力は前者、在庫チェックは後者です。
でですね、「数量の上限」や「不可能な注文の組み合わせ」みたいに
「ビジネスロジックだけどDBに問い合わせる必要はない」というチェックは
APになげると余計な通信が発生するのでWebサーバーでやろうと思ってます。
Webサーバー側のpackageには原則Actionクラスしかないのですが、
このpackage配下にチェッカークラスを置くのに違和感を感じます。
注文形態が複雑でActionがいっぱいあるので、注文BaseActionを
作ってTemplateMethodパターンでフローを決めてるのですが、
だらだらとバリデートを書くのもフローがわかりにくくなって嫌です。
注文クラスそのものに書くべき？
0290デフォルトの名無しさん
2008/08/31(日) 16:34:20用意してフローに組み込み、具体的なチェック内容は派生クラスで実装
すればいいんでないの?
なぜ「だらだら」になるかが知りたいところ。
0291デフォルトの名無しさん
2008/08/31(日) 16:49:46これは不可で」「数量をparseして文字列だったらこのエラーメッセージで」
みたいな処理が10以上あって、ロジックは共通なので、その個別のValidateを
BaseActionに書いてたんです。個別Validateのどれを呼ぶかは
Actionによって異なります。で、このチェッカーって切り出すべきだと
思うんだけど、actionパッケージの下にチェッカークラス置くのって
変だよなーと思って相談したわけです。
0292デフォルトの名無しさん
2008/08/31(日) 16:50:33わかりにくかったですね。すいません。
0293デフォルトの名無しさん
2008/08/31(日) 21:00:05メソッドだけ用意し、チェックメソッドは別クラスにまとめる。たぶん、
このチェッカークラスは stateless になるんじゃないかな。
派生クラスではこのチェッカーを使って個々の Validate メソッドを実装
すれば良い。チェッカークラスの置き場所はまあ、プロジェクト的な決め事
でしょう。
0294デフォルトの名無しさん
2008/09/01(月) 00:26:21今は各Actionクラスの処理の切り出しのイメージだったから
個別ValidatorでsetFieldError()してるんだけど、チェック処理の
多さからいって全public staticなクラスに切り出すべきだと思ってる。
すでにリリースされてるプロジェクトの機能追加なのであまり
リファクタリングしたくないんだけど。
で、最初の質問に戻るんだってば。actionパッケージの下には
actionクラスしかなく、serviceパッケージの下にはリモート呼び出しを
前提としたクラスとそのドメインオブジェクトしかない。
今後のプロジェクトではserviceクラスのメソッドにアノテーションつけて
ローカル実行とリモート呼び出しを分けられるようにしようかと思っていた。
そうするとやっぱ今回もあるべき論的にはserviceパッケージの下に
ローカル実行用のサービスクラスをつくるのかな。でも単純な未入力チェック
みたいのはコントローラーでやるべきだと思うし、うーん。
0295デフォルトの名無しさん
2008/09/01(月) 00:42:31Actionに入ってることがそもそもおかしい気がしてきた。
あ、いやでも注文形態によって入力パラメータの数が違うから
未入力チェックを行うならActionか。
もしかしてstrutsみたいに各フィールドのセッターでvalidationしよう
っていうのが間違っているのか？
Action -> 個別注文クラス生成 -> 個別注文クラス#Validate()呼び出し
→ OKならリモート注文ServiceのValidate()呼び出し
こうするとすごくスッキリする。略してスッキる。ActionはModelの
生成だけでロジックにはノータッチになるし。チェッカークラスが
複雑で外だしにするとしても、個別注文クラスと同じpackageに
いれればしっくりくる。略してしっくる。ドメインオブジェクトがアクセッサしか
持っていないようなドメインモデル貧血症なつくりにはしてないからね。
0296デフォルトの名無しさん
2008/11/13(木) 18:02:240297デフォルトの名無しさん
2008/11/27(木) 14:40:57パブリックヘッダファイルで提供する関数と内部で使う関数の分け方すらわかりません。
0298デフォルトの名無しさん
2008/11/28(金) 00:16:460299デフォルトの名無しさん
2008/11/28(金) 00:39:310300デフォルトの名無しさん
2008/12/06(土) 00:00:34追いづらい。
IService ← テンプレート・メソッド パターン
↑
AbstractLogic ← テンプレート・メソッド パターン
↑
BaseCollectLogic ← テンプレート・メソッド パターン
↑
FileBaseCollectLogic ← テンプレート・メソッド パターン
↑
DomainLogic
カスが
0301デフォルトの名無しさん
2008/12/06(土) 01:58:350302デフォルトの名無しさん
2008/12/06(土) 06:03:41うざったいってのはよく分かる。
IService ← テンプレート・メソッド パターン
↑
AbstractLogic ← テンプレート・メソッド パターン
↑
DomainLogic
としてBaseCollectとやらはコンポジションでもっとけと。
0303デフォルトの名無しさん
2008/12/06(土) 09:36:210304デフォルトの名無しさん
2008/12/06(土) 19:23:37クライアントは、
DomainLogic dl = new DomainLogic();
dl.Run();
あれ？スーパークラス使わないの？
IService はどうした？
IService は？
カスが
0305デフォルトの名無しさん
2008/12/06(土) 19:26:080306デフォルトの名無しさん
2008/12/06(土) 19:33:020307デフォルトの名無しさん
2008/12/06(土) 19:36:490308デフォルトの名無しさん
2008/12/06(土) 19:48:280309デフォルトの名無しさん
2009/01/25(日) 05:15:15> 全部publicでいいじゃん！ってならないようにするスレです。
あーあorz
プログラミングまだまだ初心者で、C#勉強している途中だけど、
このスレ開いて、>>1を読んでしまった・・・。忘れようとしても忘れられない。
意識しないようにすると意識してします。
将来プログラマになった際、仕事中「全部publicでいいじゃん」というレスが頭に思い浮かんで、
忘れよう忘れようとしても逆に頭にこびりついて、何かとんでもないミスをして入社早々首になりそう・・・。
逆に、記憶に逆らって、全部privateにしなきゃと意識するとコーディングが全然遅々として進まなかったり。
スレ開かなきゃ良かった・・・。
0310デフォルトの名無しさん
2009/01/25(日) 06:31:570311デフォルトの名無しさん
2009/01/25(日) 13:12:030312デフォルトの名無しさん
2009/01/25(日) 13:16:53メンバ関数はpublicが基本
0313デフォルトの名無しさん
2009/01/26(月) 19:49:32そんな性格の人はこの職業向いてないよ。
このスレのおかげで早めに気づいてよかったね。
0314デフォルトの名無しさん
2009/01/26(月) 22:33:060315デフォルトの名無しさん
2009/01/27(火) 01:07:170316デフォルトの名無しさん
2009/01/27(火) 01:54:170317デフォルトの名無しさん
2009/01/27(火) 01:57:43こんなOOPで当たり前の常識をすぐ理解できない時点で向いてない
0318デフォルトの名無しさん
2009/01/27(火) 12:47:27OOPで当たり前の常識を理解できていないとな
0319デフォルトの名無しさん
2009/01/27(火) 19:08:50その時どうしてんだ？
friendにすぐにするのか。一瞬くらいは正しかったのか？って考えるだろう
0320デフォルトの名無しさん
2009/01/27(火) 23:36:38publicかprivateで十分
早くpublic(in hoge::piyo, child)とか修飾できるようにならないかなー
0321デフォルトの名無しさん
2009/01/30(金) 16:31:51クラスライブラリなら考えると思う。
実務の仕様変更で必要となったのならなにも憂慮することなく
すぐfriendにする。
最近C++やってないなあ。
Javaの同じパッケージのクラスからだけ呼べるデフォルトスコープは
わかりにくいよね。修飾子で明示的にして欲しい。
0322デフォルトの名無しさん
2009/02/27(金) 01:47:05迷うとinterface（規格）→abstract（ひな形）→具体クラスってのが多い。
0323デフォルトの名無しさん
2009/03/15(日) 01:29:180324デフォルトの名無しさん
2009/04/08(水) 03:15:330325デフォルトの名無しさん
2009/04/08(水) 08:05:11インタフェース指向設計にも載ってるやり方だけど、
結局、Java系OOPLの現状の中での最適解って感じで
果たしてそうあるべきものかと問われると
はなはだ疑問に感じる部分だよなぁ。
0326デフォルトの名無しさん
2009/05/11(月) 23:31:23今考えてるもので、なんか結局相互依存しちゃうクラス関係orz。
今考えてるのは、ネットワークプログラミングで、
コネクションを表すclass Connectionがあって、これをベースに
class ServerConnection, class ClientConnectionがある。
で、こいつらを一つにまとめておくコンテナで、
class ConnectionManager;
というものを作った。
最初に、
ConnectionManager ConnMgmt;
ServerConnection SConn( ConnMgmt );
とかやって、
//コンストラクタで自分を登録
ServerConnection::ServerConnection( ConnMgmt ){ ConnMgmt.Add( this ); }
void ServerConnection::Accept(){
//ここで、サーバーソケットに接続してきたクライアント用のインスタンスを生成
ClientConnection *CConn = new ClientConnection( Socket_.Accept() );
//で、このクライアントコネクションをコネクションマネージャに登録するのに、
ConnMgmt_.Add( CConn );
}
みたいな、ConnectionManager <-> Connectionで相互依存っぽい気がする。
何か解決方法はないっすかね？
0327デフォルトの名無しさん
2009/05/12(火) 06:19:46徹夜明けでjavaerの俺からすると
とりあえず
・ServerConnectionはそもそもConnectionなのか
・ServerConnectionの作成はServerConnectionFactoryにしたほうがよさそう
あとManagerなのになぜにMgmtなのか不思議
0328326
2009/05/12(火) 20:53:27聞きたいのはそこじゃないw
0329デフォルトの名無しさん
2009/05/13(水) 02:21:49ServerSocketとClientConnectionはManagerを知らなくていいんじゃね？
利用側のクラスをConnectionEventListenerの派生にして
ServerSocket.AddListener(this);
EventLisner#doEvent()の中でMgmt.Add(ClientConnection);
Managerはシングルトン
0330デフォルトの名無しさん
2009/05/20(水) 00:32:18表示機クラスとして抽象化するとして、表示関数のインターフェイスについて質問があります
実際に使用する表示機は
7ｾｸﾞLEDなら1行4文字
LCDならサイズによって異なりますがY行X文字
これを踏まえると
void myPrintf(int X , int Y , const char str);
という形にして1行しか表示できないユニットに関してはYを無視する形にすればいいのかなと考えます。
しかし、今後カラーLCDを使用したり反転・点滅等のエフェクトを追加しようとすると
void myPrintf(int X , int Y , const char str , int color , int effect);
と、7ｾｸﾞLEDのような単純な表示機では使わないような引数がどんどん増えていってしまいます。
しかもインターフェイスに変更を加えることになってしまうのであまり宜しくないようにも思います。
こういう場合どういう風に設計すれば良いのか、今後の変更に備えるための工夫等はどうしたらよいでしょうか？
0331デフォルトの名無しさん
2009/05/20(水) 12:16:58java:
// 表示機
// L: "1行4文字"や"Y行X文字"といった機器ごとの表示位置の表現
abstract class Display<L extends Location> {
public abstract void print(L location, char ch);
}
// 表示位置の表現(ただのmarker interface)
interface Location { }
// 7セグLED表示機
final class LED7Segment extends Display<Location7Segment> {
public void print(Location7Segment location, ch) { location.getX()とgetY()をつかってchを表示 }
}
final class Location7Segment implements Location {
public Location7Segment(int x, int y) {...}
public void getX() {...}
public void getY() {...}
}
// LCD->にたよーなもの．
Locationは"表示の形式"ということで，もし，Windowsのウィンドウに表示するような場合などはFormatみたいな形でまとめるのもいいかも
0332デフォルトの名無しさん
2009/05/20(水) 12:30:500333デフォルトの名無しさん
2009/05/20(水) 13:01:06ああ，エフェクト追加のために今後のことを考えて設計か
「エフェクト」ってのがどういう性質なのか決めないと何も始まらないので，
そっからはじめたら？
0334デフォルトの名無しさん
2009/05/20(水) 17:07:45>>331なんておそらく難しいことはしてないと思うのだが
じゃあ、テンプレートはどういうときに使えるのか、どう実装するのか？っていわれたら自分なら全力で逃げたい
0335デフォルトの名無しさん
2009/05/22(金) 11:46:25P→V+C
C→M+α
A→データ層？
と言うように見えるけどPACのCに相当する部分がMVCのMに専念出来ないような
+αの分、不必要な作業が肥大化していきそうに思えるのは気のせいだろうか？
0336デフォルトの名無しさん
2009/05/22(金) 13:18:51まさかもう俺の考え付くソフトウェア構築モデルがあるとはしたなかった
ありがとん
0337デフォルトの名無しさん
2009/05/22(金) 13:42:33よくModelとViewの関係で例えられるけど
subjectからobserverにメッセージを送るシステムの骨組みだけ提供するから
あとはそれを継承してModelとViewで好き勝手やってくれってこと？
0338デフォルトの名無しさん
2009/05/22(金) 21:03:48レベルが違う話をごっちゃにしたらダメ
0339デフォルトの名無しさん
2009/05/22(金) 21:14:27管理責任はManagerにあるんだから、
Managerにジェネレータやファクトリーの機能を持たせればOKだと思われ。
0340デフォルトの名無しさん
2009/05/23(土) 01:14:21PACなんて10年前からあんだろ
RADツールで作成するときとか既成のボタンとか流用するから
VとCは不可分じゃね？それにMVCのMは大ざっぱ過ぎね？
機能毎にグループ分けしてグループ間の行き来はレイヤーわけようぜ
って感じじゃなかったかな。
Web開発ならVとCはキレイに分けられるし、今はMVCつっても
サービス層、Dao層とかわかれてるしグループ分けならnamespace
(Javaならpackage)で行ってるし、PACがMVCの次の世代っていう
考え方は今は当てはまらないと思うよ。
0341デフォルトの名無しさん
2009/05/23(土) 02:23:25１０年前は開発なんてしてなかった
0342デフォルトの名無しさん
2009/05/24(日) 02:14:28ロジック層との融合不可能な環境がでかくなった時代背景に
注目されたモデルだからね。
Delphi位に柔軟性があるRAD環境ではそれほどレイヤ間の分離を
意識しなくてよかったのはあるやね。
UIの強化、DB項目の追加、機能追加等に備えて無意識にPAC(って言うの?)的な
分けはやっていた人達も少なくはなかったけど。
VBだと何故か殆ど全部不可分だったけどw
0343デフォルトの名無しさん
2009/05/25(月) 02:14:10VB/Delphiのフォームにポトペタのコンポーネント思考には会わなかったけど
WebではしっくりくるからWebサービスの発達と共に浸透したんだよ。
まあ確かにそれまではUIとロジック一緒にしても保守できる程度の規模の
システムでしかなかったという見方は出来るけど。
Delphiが強力ったって、Delphiから入って仕事覚えた人はあんまりVBerと
変わらないっていう印象だなあ。フォームにポトペタで設計なんか考えない感じ。
クラス派生時に可視性を下げることしかできないっていうルールが
多態性とか検討するのを阻害するしね。Delphiの場合はTAbstractButtonみたいな
ベースで考え得る機能をできるだけ網羅して、具象化するときに機能制限して使う。
コンポーネントのひな形を全部Delphi側で用意して開発者は利用するだけという考えなら
確かにクラス数が少なくていいけど、柔軟性にかけるよね。
あーなんか言葉足らずでうまく伝わらない気がするな。ちゃんと書くと長いからいいや。
0344デフォルトの名無しさん
2009/06/04(木) 22:55:00GUIのためのMVCと、WebのMVCは全然別ものだよ。
一緒なのは名前だけ。
名言集 その４
『俺、100人規模の集団サイバーテロの主犯だったこともあるんだぜ』
http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/ のID:PVAf+dux0 ＝ 自動焼人 ★
> 965 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:02:09.35 ID:PVAf+dux0
> まぁ何だ。
> 俺の過去の経歴に比べたら、割れ厨なんて鼻くそレベルなんだけどなｗ
> 100人規模の集団サイバーテロの主犯とか、いろいろとな。
----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください
0346デフォルトの名無しさん
2009/08/17(月) 20:31:450347デフォルトの名無しさん
2010/03/05(金) 10:13:16EntryとEntryManagerという二つのクラスがあって、
EntryManagerが、複数存在するEntryインスタンスを生成、管理してます。
Entryが、他のEntryにアクセスできるようにしたいのですが、
そうなると、EntryManager<->Entryというお互いに依存関係ができてしまうと思います。
これは悪い設計でしょうか？
また、このような場合のためのデザインパターンなどはありますか？
0348デフォルトの名無しさん
2010/03/05(金) 10:25:56このような場合にインスタンスが、他の兄弟インスタンスや型を知るような依存はしたくない。
多数あるインスタンスが、多対多の関係になることは避けたい。
> そうなると、EntryManager<->Entryというお互いに依存関係ができてしまうと思います。
GoFのMediatorパターンでは、相互作用はMediatorに記述され、
ColleagueはMediatorとだけやり取りして、他のColleagueへは直接関与しない。
少なくとも一対多の関係にしておくことができる。
0349デフォルトの名無しさん
2010/04/12(月) 05:36:42経験というかバックグラウンドがちゃんとあるひとなら伝わるけど
馬鹿に伝えるのは難しいよね
0350デフォルトの名無しさん
2010/04/12(月) 16:07:490351デフォルトの名無しさん
2010/04/29(木) 21:41:13http://apr.2chan.net/jun/b/src/1272544702094.jpg
画像にあるUML図のように
AとB
どちらでプログラムを組むのがいいのでしょうか？
利点などあったら提示してくれると助かります
0352デフォルトの名無しさん
2010/04/30(金) 00:25:140353デフォルトの名無しさん
2010/04/30(金) 02:56:560354351
2010/04/30(金) 18:37:48AはMFCを参考に
Bはjavaを参考に考えました
Webサイトの解析と、それを元に一定の処理を行うというものです
作っている段階でバージョンアップ（修正）もでてくると予想してます
0355デフォルトの名無しさん
2010/04/30(金) 22:44:52継承しているのは不自然に感じるけど、MFCにそんな構造あったっけ？
もしかして、継承と関連の記号を取り違えていないか？
0356デフォルトの名無しさん
2010/05/01(土) 11:33:10「構造体に毛のはえた設計」と言ってました
Cマガは現在廃刊になってます
0357デフォルトの名無しさん
2010/05/04(火) 15:50:23DBーサーバーークライアントー表示
こういうのをクラス図として提出されてどうしようかと悩んだ
私の説明が端折り過ぎたのが原因だろうがこれはあんまりだ
0358デフォルトの名無しさん
2010/05/04(火) 18:04:52べつに いいん・・・
よくねーよｗ
0359デフォルトの名無しさん
2010/05/04(火) 19:48:070360デフォルトの名無しさん
2010/05/08(土) 15:21:19オレは最初データベースと読んでいたが、
なんとアニメの欄にＤＢの文字が・・・
まさかデータベースのアニメ（！キバヤシ風）
と思ってクリックしたらドラゴンボールだよ！
0361デフォルトの名無しさん
2010/05/08(土) 16:29:010362デフォルトの名無しさん
2010/05/23(日) 04:06:32野球ってbatファイル
ピッチャーが開始するまで誰も動かないor動けない
んで、みんなピッチャーに依存してる
ヒットも守備の重箱の隅をつつくようなところに打たないとでない
でオブジェクト指向はサッカー
監督がこういうふうに試合をしてくれって指示だけだし
あとはオブジェクトがメッセージ（ボール）をつないで試合を展開する感じ
0363デフォルトの名無しさん
2010/05/23(日) 05:54:51その辺にしておかないと大変なことになってる
0364デフォルトの名無しさん
2010/05/23(日) 06:19:180365デフォルトの名無しさん
2010/06/03(木) 17:35:34ぁぅあんっぅあああああーーーーーーーーーー
かい～いぃぃいいい～～～さああああん
0366デフォルトの名無しさん
2010/06/03(木) 23:24:58もう…おかしいでしょ。どう考えても何をねつ造しても事実はこうなのですから
↓
http://www.nicovideo.jp/watch/sm10915996
キラー小里議員、赤松広隆君不信任決議案で爆弾発言！
平成22年5月31日衆議院本会議農林水産大臣赤松広隆君不信任決議案（174国会決9賛成の討論で壇上に上がった小里泰弘議員から、爆弾発言！マスコミは一切伝えてません。
http://www.nicovideo.jp/watch/sm10815799
“独裁者”小沢一郎とフジテレビ「黒い密約」疑惑を追求②＊拡散希望
0367デフォルトの名無しさん
2010/06/12(土) 19:21:140368デフォルトの名無しさん
2010/06/12(土) 19:52:160369デフォルトの名無しさん
2010/06/12(土) 21:22:47おい！
0370デフォルトの名無しさん
2010/09/05(日) 13:57:480371デフォルトの名無しさん
2010/09/28(火) 13:24:460372デフォルトの名無しさん
2010/09/28(火) 13:32:36場当たり的に逃げ道を探して回避する(根本的な問題は完治しない)のがバッドノウハウ
本質的な部分を見直して考慮された見通しの良い(とされている)考え方がデザパタ
0373デフォルトの名無しさん
2010/09/29(水) 02:57:51なるほど
ところでデザパタに対して含みを持たせてるのは、
本質的に解決できていないものも含まれていると感じているから？
だとすると、問題を解決する方法として見たとき、バットノウハウとデザパタの境界は
案外曖昧だったりするのでしょうか
違う側面からの解説もｷﾎﾞﾝﾇ
0374デフォルトの名無しさん
2010/09/29(水) 03:07:380375デフォルトの名無しさん
2010/09/29(水) 06:20:55それが急を要しない状況で使われたとき「バッドノウハウ」と呼ばれる気がする。
0376デフォルトの名無しさん
2010/09/29(水) 07:12:03■ このスレッドは過去ログ倉庫に格納されています