-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590263デフォルトの名無しさん
2008/03/25(火) 23:21:24あとから足りないものに
気付いてメソッドを追加する、というごくありふれたケース
といいますが、これはOCPが違反しませんか？
今、Head Firstのオブジェクト指向設計とかいう本を読んでいます。
そこにはSRPの例として、車のクラスを定義する場合に
そこにwashなどのメソッドを組み込んではいけないという事になっていますが、
例えば外部で
CarWasher#wash(AutoMobile)を定義した場合、
このCarWasherクラスはAutoMobileの例えばdirtというフィールドが存在している事を知っていないければなりません。
（例えばwashというメソッドがdirtを0にするものだとすると）
これは情報の隠蔽に失敗していませんか？
それに無闇にAutoMobile#setDirtを設定してこれを受け入れれば、
他でどんな悪用をされるか分かりません。
失敗した設計だと思います。
カプセル化についてどう考えていますか？
setterはなるべく実装しない方が良いように思うので、
データについてクラスを分離するのがいいと思うのですが、
この本には振る舞いについて分離せよと書いてあります。
0264デフォルトの名無しさん
2008/03/26(水) 01:09:50拡張と一口に言っても、類似概念の追加と、メソッドの追加では意味合いが
違います。OCP を守るためにメソッドの追加ではなく継承で対応するの
では本末転倒でしょう。原則は絶対ではないのだから、柔軟に対応すれば
いいと思いますよ。
その本は読んでいないので状況が良くわかりませんが、車クラスが wash
を提供するべきではない理由が書いてあるのではありませんか? 車の主要な
責務は「人を乗せて移動する」であるとかなんとか。
まあ、いずれにしてもいい例ではない気がしますが、クラスでは概念を
完全に表現することができない以上、どこかに軸足を置く必要がある
わけです。それが「洗う」なのか「走る」なのかは目的によって変わって
くるでしょう。
カプセル化は言うまでもなくとても重要ですね。
大切なのは、自分が表現したいものをはっきりさせることです。そうすれば
自然と必要なデータや振る舞いが備わっていきますよ。
0265デフォルトの名無しさん
2008/05/14(水) 12:54:34CarWasherクラスがAutoMobileクラスのdirtフィールドを知ってなければならない
のは当たり前。
そもそも、洗車機は車の存在を前提に作られるし、皿洗浄器は皿の存在を前提
に作れる。何を？どうする？の２つを知ってないと「する側」は作れない。
てか、洗車は例えとして分かり難いぞｗ
0266デフォルトの名無しさん
2008/05/14(水) 15:08:000267デフォルトの名無しさん
2008/05/22(木) 06:02:42設計（特にクラスの設計）に関するオススメの書籍何かないでしょうか？
例えばショッピングサイト、レンタルビデオショップなどわかりやすそうなものから考えていこうとしたものの
OOPへの理解が浅いせいかどうにも戸惑ってしまっています
よろしくお願いします
0268デフォルトの名無しさん
2008/05/22(木) 12:13:26デザインパターンとともに学ぶオブジェクト指向のこころ
0269デフォルトの名無しさん
2008/05/25(日) 20:58:00大抵このUndoってコマンドパターンとかで実装されますよね？
このとき、Modelに対する変更命令が全てコマンドで実行されることをコードレベルで保障するには、
Modelに対する変更命令を受け取ってコマンドを発行するクラスを作って、
更にModel内部のデータ構造に対するアクセスを制限するための
読み取り専用ラッパークラスを作って外に公開する、という感じになるのでしょうか？
実際このようなことって業務レベルの開発では行っていたりしますか？
0270デフォルトの名無しさん
2008/05/26(月) 00:23:07個人的に、リファクタリングの実践が一番身に付きやすいと思う。
フリーソフトとかのソース落としてきてやりまくるといい。
ということで
・リファクタリング
0271デフォルトの名無しさん
2008/06/19(木) 22:55:43温度調節機能付きの水質モニターを管理するプログラムを作りたいと思っています
1分毎に水質データと水温を取得する
PCから温度の管理値を変更できる
という機能を実現したいのですがこの場合
ポートの開閉やデータの送受信を管理するCommクラス
水質データの受信要求や管理値の変更命令をCommｵﾌﾞｼﾞｪｸﾄに送る、水質モニターの機能を実現するMonitorクラス
Monitorｵﾌﾞｼﾞｪｸﾄから値を受け取り実際に表示するGUIクラス
GUIがMonitorの参照を保持して
MonitorがCommの参照を保持する
このような構造でよいのでしょうか？
0272271
2008/06/20(金) 00:31:37Monitorクラスの定期測定と管理値の変更は別のクラスの振る舞いにしたほうが良いのでしょうか
0273デフォルトの名無しさん
2008/06/20(金) 20:41:49いいと思います。あとは、水質モニターのマルチベンダー化や多重化等が
確実なら、事前に拡張性を考慮するのもあり。
0274デフォルトの名無しさん
2008/06/20(金) 22:07:46ありがとうございます
あと、新型のモニターを使用する場合も考えると
拡張機能を実装しやすいようにデコレータにしておいた方がいいですかね
0275デフォルトの名無しさん
2008/06/21(土) 00:04:07数ヶ月以内に新型が導入されるならね。さもなくば、シンプルに徹する。
0276デフォルトの名無しさん
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動けない
んで、みんなピッチャーに依存してる
ヒットも守備の重箱の隅をつつくようなところに打たないとでない
でオブジェクト指向はサッカー
監督がこういうふうに試合をしてくれって指示だけだし
あとはオブジェクトがメッセージ（ボール）をつないで試合を展開する感じ
■ このスレッドは過去ログ倉庫に格納されています