- 1 名前：デフォルトの名無しさん [2005/09/24(土) 16:35:59 ]
- 全部publicでいいじゃん！ってならないようにするスレです。
- 74 名前：デフォルトの名無しさん [2005/12/11(日) 15:08:43 ]
- シーケンス図ってホントにプログラム知らないお偉いさんでも読めるの？
- 75 名前：デフォルトの名無しさん [2005/12/11(日) 15:21:18 ]
- >>74
プログラムｼﾗﾅｲお偉いさんにシーケンス図見せる時点で間違ってないか？
ユースケースとか配備図とかコラボレーション図とか…
- 76 名前：デフォルトの名無しさん [2005/12/11(日) 15:24:20 ]
- UMLの全てがユーザフレンドリーってわけではないのね
- 77 名前：デフォルトの名無しさん [2005/12/11(日) 15:26:46 ]
- >>76
えーと、UMLって単に開発で使う図に統一規格を持ち込んだだけの
話で、それ以上のものじゃないですよ。
- 78 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 15:27:29 ]
- じゃあ参考書の書き方がまずかったのかな
- 79 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 15:34:43 ]
- 書くレベル次第だな
厳密な設計書として書いているなら細かすぎて読めないかも
- 80 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 00:14:39 ]
- 日本語だらけの仕様書は曖昧さが目で見て取れるため問題に気づきやすいが
曖昧なまま書き起こされたUMLは、一見する分には完全な仕様書に見えるため問題が分かりにくい。
UMLが客が読める仕様書としてしまうのはある意味とても危険。
- 81 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 20:59:11 ]
- いやいや、そんなレベルのUMLは仕様書としないでしょ。
あくまでコミュニケーションツールの一つ。
処理の流れはこんな感じですよ〜みたいに。
- 82 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 00:53:54 ]
- ＵＭＬでは、異常系の記述がやり辛いよな。
・・・はっ！！
- 83 名前：デフォルトの名無しさん [2005/12/17(土) 02:12:04 ]
- 会計ソフト作ってみたいんだが仕訳モデルのサンプルとか無い？
3級レベルで会計ソフトって作れるのかいな？まあそっちも勉強しながらやってきます
- 84 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 13:08:09 ]
- 自分で分析したら？
- 85 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 14:39:32 ]
- 言ってることはある意味正しいが
そういうレスはこのスレの役を果たさないな
- 86 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 15:51:23 ]
- javaでアプリ作ったんだけど、関連が全部双方向になったんだけど
これってやっぱ良くないの？
- 87 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 15:59:24 ]
- > 関連が全部双方向
ここがちょっとわからないが、まぁpublic全開になるのは仕方ないんじゃないかな。
コンポーネント郡はそのまま使わず、派生させてから使えば上手くカプセルにできるかもしれん。
- 88 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 16:00:18 ]
- まぁ、初心者にありがちなパターンだな。
関連というか、メッセージ送信が双方向になるなら、そのメッセージを一度整理して、分類して、
クラス内のメッセージ受信部分をインタフェースに分離するという観点で構築しなおしたらいいんじゃないの？
- 89 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 16:12:25 ]
- 実はFlashってのはOOPの訓練に役立つ。
- 90 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 16:53:09 ]
- >>87-88
ｻﾝｸｽｺ
そうです、メッセージ送信が双方向ってことでした。
そういえばインターフェースも抽象クラスも全く使ってない。
というか使いどころもわかんね。
とりあえずそれらの勉強してみます。
ありがとうございました
- 91 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 12:54:31 ]
- >>15
漏れは何も考えずにとりあえずメソッドはpublicにしてるんだけど…
内部からしか呼ばれないのはprotectedにしてる
まずいのか？
- 92 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 16:18:57 ]
- >>91
いつの間にかぐちゃぐちゃなソースになるのが弊害かな。
- 93 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 00:10:39 ]
- アクセス権の指針
public：外から呼ぶ必要がある
protected：外から呼ぶ必要はないが派生クラスから呼ぶ必要がある
private：デフォルト
- 94 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 00:17:27 ]
- 下駄／雪駄なんて書く気しねー。
- 95 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 01:25:22 ]
- 憂鬱本ではメソッドは基本的に全部publicで問題ないって書いてあったが
- 96 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 16:07:20 ]
- >>95
その本は読んでないが、そこだけ聞いたら焚書モノだな。
- 97 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 00:45:27 ]
- >>93
その判断を誤るとややこしいことになるからすべてpublicにしておけ
って程度なんだろうね、その本>>95
- 98 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 02:03:45 ]
- もともとC++やってて、最近仕事でjavaやり始めたんだけど、
javaのprotectedって全然プロテクトじゃないんだね
最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
アクセサメソッド追加してるんだけど、まずいですか？
まともなjava技術者ならどうしてます？
- 99 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 09:34:12 ]
- >>98
全然プロテクトじゃないってどういうこと？
- 100 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 10:50:46 ]
- >>98はC++もまともに使えていないと予想する。
- 101 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 11:18:14 ]
- packageの時の扱いが違うくらいしか思いつかないけど、なんかすごい引っ掛けがあるのかな・・？
- 102 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 12:01:36 ]
- >>98
早くプロテクトじゃない理由を教えてくれよう。ﾜｸﾜｸ
- 103 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 12:20:31 ]
- ＞最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
＞アクセサメソッド追加してるんだけど、まずいですか？
C++もそうだし、オブジェクト指向もわかってないんじゃないかな
なんか、Cプログラマーみたい
グローバル変数使うなっていわれたから、プライベートにしてみました
みんなが必要とするから悪切磋つけました
そんなところでしょ
- 104 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 12:45:22 ]
- Lispを使わないなんてバカげてる
- 105 名前：デフォルトの名無しさん [2005/12/23(金) 13:14:14 ]
- サブクラスのためにその都度スーパークラスを改変するのはナンセンス
まともなC++技術者ならそんなことやらない
まともなJava技術者もそんなことやらない
まともなSmalltalkerもそんなことやらない
まともなオブジェクト指向言語使用者ならそんなことやらない
- 106 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:10:15 ]
- まともな奴なら継承は使わないってことか
- 107 名前：98 mailto:sage [2005/12/23(金) 14:10:15 ]
- 自分はまともじゃないです（つд`）
プロテクトじゃない云々は、javaのprotectedメンバは派生クラスだけでなく
同じパッケージにいるクラスでもアクセスできるのでC++のより緩いって意味です。
親クラス作るときにはメンバ変数全部に対してprotectedのアクセサ用意しとくものなのかな、と。
で、こういう設計はおかしいですか？
- 108 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:12:55 ]
- 親クラスのメンバーにサブクラスがあとあといろいろアクセスしなきゃならなくなるかもぁー。
そういうときにpribvateだと、困るから、protectedにしておいたほうが、いいのかなぁ〜。
なんっていう、下らんこと気にしているようでは、そもそもクラス抽出がうまくできているとは思えない。
- 109 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:15:50 ]
- >>106
サブクラスのためにその都度スーパークラスを改変する ってのがナンセンス。
継承前提で設計されたスーパークラスはそんな改変しょっちゅうしない。
- 110 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:17:48 ]
- >>107
？
派生からアクセスが必要になる度にアクセッサを追加してるんじゃないの？
そもそも日本語もだめだったり？
- 111 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:25:09 ]
- 俺も勉強したてでよく分からんけど、
メンバ変数全部に対してprotectedのアクセサ用意って
これはカプセル化の意味ないと思うんだが…
多分そのスーパークラスの設計から見直したほうがいいんじゃ
- 112 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:32:59 ]
- 継承前提で作るときはこういう悩みはないんですが、
工数削減の関係で仕方なく、継承させるつもりがまったくなかったクラスに
スーパークラスとして、アクセサを追加してました。
まったく継承させるつもりがなくても、あとあとのことを考えて
protectedアクセサを…ってダメダメですよね。
設計が悪かったのが理解できました。みなさんありがとう
- 113 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 00:00:27 ]
- コンストラクタはオーバーロードできないっぽくて悲しい
デフォコンだけでしょ
- 114 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 00:30:10 ]
- >>113
？
- 115 名前：デフォルトの名無しさん [2005/12/31(土) 04:53:35 ]
- >>113
∧_∧ ／￣￣￣￣￣
(ω・ )ゝ ＜ なんだって？
ノ/ / ＼＿＿＿＿＿
ノ￣ゝ
- 116 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 10:26:20 ]
- コンストラクタでHoge(String str)とかは継承されないという話
オーバーロードとは違う
- 117 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 13:39:08 ]
- StrutsのActionみたいなリクエストを処理するクラスで、思想の問題と思われるが
Aという共通抽象クラスがあって、業務Bと業務Cがあり、BとCは機能がほとんど同じ
この場合、どっちがよい？
1)A<Bと継承して、更にB<Cと継承して違うところだけは追加・オーバーライドする
2)A<B, A<Cと別々に継承する
1だと違う部分だけ書けばそれだけでいいけど、もしBの共通部分が変更になるとCにも影響する恐れがある
2だとBの共通部分が変更になってもCには影響しないが、多少かぶってしまう箇所が出てくる
個人的には2かなと思ってるけど、今の現場では1が多い
2は共通化できそうな部分だけは別クラスに作るってので対処できるし
- 118 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 13:54:44 ]
- 俺も2かな。ただしやるならDecoratorパターン。
早い話がラッピングするパターン。
www.techscore.com/tech/DesignPattern/Decorator.html
- 119 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 18:49:30 ]
- >>117
もし俺なら、(共通部分の内容と量にもよるが)もう１層括りだせないか？
と、考えてみる。
AbstractA＜抽象クラス
│
AImpl＜共通実装部分
├SubclassB＜差異
└SubclassC＜差異
- 120 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 19:11:48 ]
- 感じとして会社によってはドメインフレームワークって言ってるやつかな？
- 121 名前：117 mailto:sage [2005/12/31(土) 20:13:31 ]
- ﾚｽｻﾝｸｽ
>>118
Decoratorﾊﾟﾀｰﾝでやったことないから今度実験してみよう
>>119
2の拡張みたいな感じかな
それも検討してみたことがあるけど、サブシステム全体で共通ならいいような気がするけど
サブシステム内のある２機能だけ特別にクラスを作るってのはどうか悩んだ
- 122 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 22:41:21 ]
- そこまで差が少なければ俺は119のAImplをクラステンプレートにして、
BとCの差異をTraitsクラスにして選択できるようにするだろう。
119のように継承するのと大して差異はないけど。
- 123 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 22:54:14 ]
- >>122
C++な人？
- 124 名前：122 mailto:sage [2006/01/01(日) 13:02:39 ]
- >>123
そうだよ。
ついC++スレにいるつもりでだった。
117がC++を使っていなければすまん、使えないな。
- 125 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 13:35:23 ]
- 設計相談って難しいよね
冗談半分でSmalltalkならこうするよ
といったら怒られたｗ
Javaでやろうとするとひどく煩雑になるんだもん・・・
- 126 名前：デフォルトの名無しさん mailto:sage [2006/01/05(木) 08:46:21 ]
- 設計という分野は言語より上位だと思ったりもするんだが、
実装する言語によって良い設計が変わってしまうしね。
- 127 名前：デフォルトの名無しさん mailto:sage [2006/01/06(金) 00:19:47 ]
- >>126
言語で左右されるような実装レベルまで設計するなよ
- 128 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 00:38:38 ]
- そうなのかなぁ
どんなにすばらしい設計をしたとしても、
それを実現する手段がなければ
意味のない物になってしまうと思うんだけど
- 129 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 01:23:02 ]
- C++でtemplateで静的に解決できるものが
Javaでやるならクラスで動的解決になるし。
しかも静的動的って言葉すらも言語によって意味違うし。
>>127の思想だと最大公約数的な設計になりそう。
まぁ別にそれでも問題無いことも多い気もするけど。
- 130 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 11:47:08 ]
- 設計は二段階で
- 131 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 22:39:23 ]
- 基本設計
詳細設計
- 132 名前：デフォルトの名無しさん [2006/02/12(日) 12:27:56 ]
- デザインパターンっていつ使うの？
- 133 名前：デフォルトの名無しさん mailto:sage [2006/02/12(日) 15:23:02 ]
- パターン化したいとき
- 134 名前：デフォルトの名無しさん mailto:sage [2006/02/13(月) 03:39:02 ]
- 使えるとき（ﾏｼﾞﾚｽ）
- 135 名前：デフォルトの名無しさん mailto:sage [2006/05/18(木) 07:22:23 ]
- 私もRubyが何故ifをTrueClass/FalseClassのメソッドに
しなかったかなぁ、と思った事はあるね。
Perlとかを意識して妙な仕様にしたんだと思うが。
- 136 名前：デフォルトの名無しさん mailto:sage [2006/05/18(木) 07:24:29 ]
- ぐは、誤爆
- 137 名前：デフォルトの名無しさん [2006/07/01(土) 21:50:01 ]
- publicばっかのクラスというけれど
7割がたそうなってしまうのが人の世だと思う
- 138 名前：デフォルトの名無しさん mailto:sage [2006/07/01(土) 22:01:48 ]
- public といっても、属性と操作がある。
属性は全て private 、
操作はデフォルトで public 必要に応じて private ってのが
実装レベルでは当然と思う。
ぶっちゃけ、7割りがた属性が public なクラスなんてありえない。
- 139 名前：デフォルトの名無しさん [2006/07/01(土) 22:31:20 ]
- そら属性は7割がたprivate、残りprotectedだろうね。
- 140 名前：デフォルトの名無しさん [2006/07/04(火) 00:15:15 ]
- フィールドは本来10割がprivateだろう。
派生クラスで使用したい場合も、protectedなプロパティとして用意するべき。
- 141 名前：デフォルトの名無しさん mailto:sage [2006/07/04(火) 23:20:03 ]
- protected も無印（package） も意外と使わないんだよね。
なんか使うとしても、デバッグとかテストケース動かすためとか、
裏技的な目的が多いような・・・。
- 142 名前：デフォルトの名無しさん mailto:sage [2006/07/17(月) 03:10:02 ]
- 私はpackageは使いまくってるよ
これがないと(ていうかC++のことだが)
ユーザー公開用のファサードを用意しなきゃならなくてだるすぎる
- 143 名前：デフォルトの名無しさん mailto:sage [2006/07/22(土) 00:37:29 ]
- 俺もパッケージプライベートは良く使う
無名インナークラスでもない限りは、インナークラスは外に出すのでね
- 144 名前：デフォルトの名無しさん mailto:sage [2006/07/24(月) 23:36:10 ]
- 今日、とあるプロジェクトに加わることになって、
そのプロジェクトで利用されてるライブラリ(プロジェクトメンバーが開発)
を見たんだけど、やたらと〜Managerみたいなクラスばっかりだった。
これって、どうなのかなぁ？
例えば、ファイル入出力を司るクラスが抽象クラスで用意されてて、
そいつを必ず継承して使ってねっていう感じだった。
他の各機能も同じ。
んで、プロジェクトファイル名も〜Managerみたいなのばっかり。
(マスタデータを登録するやつだったらDataManagerとか・・)
うまく説明できないんだけど、何か違和感を感じました。
こういうのってOOPで主流(?)なんでしょうか？
ちなみに言語は.NETのC#です。
- 145 名前：デフォルトの名無しさん mailto:sage [2006/07/24(月) 23:55:10 ]
- >>144
www.radiumsoftware.com/0603.html#060330
- 146 名前：デフォルトの名無しさん mailto:sage [2006/07/24(月) 23:57:43 ]
- >144
抽象クラスを継承して使うことが、Managerが多いことの例え、
って部分が理解出来ない。
- 147 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 00:03:42 ]
- >>145
参考になりました・・・・・
明日から、どうしよ。
なんか、このライブラリを使用することを半強制されてるんだけど・・・・
(；´Д`)
- 148 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 00:23:51 ]
- 使いにくいだけのショボブラリを仕事で使わされると虐待かと思う
- 149 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 00:25:50 ]
- >>146
説明が悪くて申し訳ないす。
何というか汎用的な各機能毎にManagerがいて、
汎用的な処理を実装する機能をもつクラスが必要になる
場合はそのManagerを継承して、新たなManagerを作ってねという感じなんですよ。
んで、ファイルを読んだり、書いたりする機能がある場合だったら
必ずFileManagerとやらを継承してHogeFileManagerや、
FugaFileManagerみたいなクラスを作ろうという風になってます。
Managerと言う割には、ファイルの読み/書きの機能の為だけに
わざわざ継承するのはどうなのかなぁと。
FileManagerにHogeFileManagerやFugaFileManagerのインスタンスを
渡して処理するような事も無いみたいだし・・・
うまく説明できないけどこんな状態です・・・。
- 150 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 00:52:47 ]
- >>149
"Manager"という名前がアレだけど、それって単に物理的な何かを
抽象化してるだけでしょ。
良くある話。
- 151 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 01:07:55 ]
-
〜erみたいなクラスは確かによく見るんですが、
余りにも〜Managerがたくさんいたんで
おかしいなと、自分が考えすぎてただけなのかもしれないすね。
明日あたり、作成者の人にどういう意図で作ったのか
聞いてみます。
お騒がせしました。
- 152 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 01:22:49 ]
- やめとけ、意図と聞くと切れる。
聞いただけで否定されてる？って切れる。
- 153 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 01:10:59 ]
- ↑こういうプロになりたくないと思ったbyｱﾏﾁｭｱ
- 154 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 01:46:47 ]
- 糸は切れやすい。たしかに。
- 155 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 02:10:29 ]
- 自分の設計が最強と思ってる人間が、
同じプロジェクトに居たりすると困るよなぁ。
やたらと、自作ライブラリを使わせようとしたり、
頼んでも無いのに勝手にこれ使ってくださいとか言ってきたりする奴。
身の回りに一人居るが、
今、新人を洗脳してるw
型って何？、レベルの人間に
懇々と我流オブジェクト指向について熱く薀蓄を語っては、
新人のやる気を萎えさせてる。
おかげで、久しぶりに開発人数が増えそうなのに、
辞めてってしまいそうだ。
- 156 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 21:20:14 ]
- オブジェクト指向もデザパタも判らない奴>>155
- 157 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 21:27:46 ]
- >>155
困るなら論破すればいいのに
- 158 名前：デフォルトの名無しさん mailto:sage [2006/07/30(日) 10:03:49 ]
- >>155
俺の事言われてるのかと思ったw
まぁ、数千行の関数とかコピペで作る奴よりマシだと思ってるけど。
俺は自作ライブラリ作るときは、シンプル＆単機能な設計でUnitTestとセットで提供しているから問題ないよな。
- 159 名前：デフォルトの名無しさん mailto:sage [2006/07/30(日) 10:10:14 ]
- 田舎ライブラリ使わされるのは苦痛なだけ
そのまま作らせろ
- 160 名前：デフォルトの名無しさん mailto:sage [2006/07/31(月) 00:34:18 ]
- 155の新人は、優秀なメンテナンス要員に成長しましたとさ。
めでたしめでたし
- 161 名前：デフォルトの名無しさん [2006/08/01(火) 22:01:01 ]
- デザインパターンってどのくらい覚えるのがいいんだろうか
GoF以外のJ2EEとかマルチスレッドとか視点を絞ったパターンまでは手が出ない
- 162 名前：デフォルトの名無しさん mailto:sage [2006/08/01(火) 22:39:28 ]
- >>161
必要な時に調べて使え。覚える必要は無い
- 163 名前：デフォルトの名無しさん [2006/08/08(火) 12:54:24 ]
- >>119の
AbstractA＜抽象クラス
│
AImpl＜共通実装部分
├SubclassB＜差異
└SubclassC＜差異
のAImpl＜共通実装部分って部分ってテンプレートパターン？
どうも何パターンとかって分類するのが苦手なのよ
- 164 名前：デフォルトの名無しさん [2006/08/08(火) 13:12:16 ]
- デザパタとか本当に使ってるの？使っていてもまわり
の人が理解できてる？
Ｃ＋＋やデザパタをつかってプログラムしてもまわりが
理解できず、バグ混入の原因になっているのでは？
オタクなクラス設計やデザパタ使ってるあなたが
結果的にプロジェクトを破壊するテロリストになって
しまっているんじゃないの？
で、実際にトラブルが起きると｢こんなことも理解して
ないなんて一人前のプログラマじゃない！｣とか言って
自分の知識をひけらかしたり、失敗を人のせいにするん
だろ。ラーメン屋の亭主みたいな融通のきかない職人
じゃあるまいし。こういう職人肌みたいな人はＣ＋＋の
テンプレートと共に消えてくれ。頼むから。
｣
- 165 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 13:16:31 ]
- >>164
と、IQ80の君に言われても・・・。
- 166 名前：デフォルトの名無しさん [2006/08/08(火) 13:30:14 ]
- このスレに書かれている愚痴って、
もう2002年当時からずっと一緒。
プログラムのﾌﾟウの字も知らない煽り屋が必死に煽ってるだけなんだろ。
無意味
- 167 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 13:32:20 ]
- 10年経ってもNewbieは必ず誕生するからね。
彼らから議論の場を取り上げるのは、酷というものであろう。
- 168 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 16:13:43 ]
- 2002年なら新しい方だな
C++は1998年の仕様がまだ実装されてないんだから
- 169 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 19:43:50 ]
- 業務でManagerと名の付くクラスは大抵ろくでもないクラスだよな。
DBConnection関係のクラスをキモくラップしただけの奴とか。
これを共通で使ってくださいとか指示されると萎えるｗ
- 170 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 19:49:04 ]
- >>169
脳内業務乙。
- 171 名前：デフォルトの名無しさん [2006/08/08(火) 23:20:46 ]
- みんなクラス抽出ってどうやってんの？
ユースケースから名詞を全部抜き出して一つ一つ吟味したり、
boundary,control,entityって分類分けしたりする？
仕様書が完璧に出来てるならやってもいいけど、
仕様書が完全になるの待ってたらいつまでたっても仕事に取り掛かれないし、
仕様変更のたびにそんなんやってらんないよね。
- 172 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 10:15:03 ]
- 別会社から引き継いだソースを設計チームでレビューしてたときの話。
ソースの中に簡単なFactoryパターンが含まれていたんだが、
一人だけFactoryが分からないやつがいた（年齢だけでいえば中堅）。
まあパターンを知らないってのは別によい、知らなくてもコードを
読めば何やってるか分かるはずだからな。
と、みんな思ってたんだが、いくら説明しても伝わらない。
細かく聞いていったらどうやら継承とインスタンス化の違いが分かっていなかった
ということが判明。
そんな人を設計から外す方法を相談させてください。
- 173 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 11:02:33 ]
- 継承とインスタンス化の違いを説明できないのもﾔﾊﾞｲと思う
- 174 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 12:55:40 ]
- 分かってないポイントが遥か手前だと、そこから全て教育するのがマンドクサい
|
 |
