トップページ⇒tech
1001コメント365KB

オブジェクト指向は遅い

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2010/12/25(土) 17:12:27
高速グラフィック処理には向いてない。
0002デフォルトの名無しさん2010/12/25(土) 17:21:21
作り方の問題だろ。
C++を使ってOOでつくられたグラフイックスエンジンは
いっぱいあるじゃん。

まぁ、>>1に作れと言っても無理だろうが..
0003デフォルトの名無しさん2010/12/25(土) 17:25:13
Mac板でぼやいてたのはおまえか？
0004デフォルトの名無しさん2010/12/25(土) 17:52:28
ゲッター、セッターの存在意義が不明
こういう余計な実装で処理速度を落としてると思うと馬鹿馬鹿しい
#define private public
#define protected public
0005デフォルトの名無しさん2010/12/25(土) 17:52:56
>>1
いまどきこんな化石がいるのかｗ
0006デフォルトの名無しさん2010/12/25(土) 17:59:32
>>1
オールアセンブラで全て最適化しろ
0007デフォルトの名無しさん2010/12/25(土) 18:06:36
ゲッター、セッターの存在意義がわからないということは、
カプセル化の意味すら理解していないようだね。
こりゃ根本から勉強しないとダメだね。
0008デフォルトの名無しさん2010/12/25(土) 18:19:58
まあ機械的に多少のムダがあっても人に理解しやすい
というのがOOPのコンセプトだからな
保守性や拡張性などのメリットがデメリットを上回るから使われる
0009デフォルトの名無しさん2010/12/25(土) 18:22:39
ゲッター、セッターを付けるのがカプセル化。
値チェック処理を入れてデバッグを容易にするメリットがあるのは知ってる。
0010デフォルトの名無しさん2010/12/25(土) 18:26:01
ダメだこりゃ
0011デフォルトの名無しさん2010/12/25(土) 18:33:26
カプセル化の真のメリットは、リフレクションの適用やAOP、キーバリューコーディング等を用いたフレームワークやデータマネジメントへの展開にあると思う。
0012デフォルトの名無しさん2010/12/25(土) 18:39:57
速度に拘ってるんだから、c++の話だよね?
getter/setterはinline展開されるように書けば
速度は落ちないと思うよ。
0013デフォルトの名無しさん2010/12/25(土) 18:47:10
なんでもかんでもOOにしなきゃいんだろが。適材適所。
アクセス頻度の高い描画用データにゃゲッタ/セッタは不要。
マネージャクラスとか、モデルクラスとかにはOOを使えばいい。
つか、ゲームとかは、まさにOOにうってつけのドメインだろ。
0014デフォルトの名無しさん2010/12/25(土) 18:53:56
そもそも「高速グラフィック処理」の定義が不明確。
馬鹿の一つ覚えの小学生みたいな印象しか受けない。
0015デフォルトの名無しさん2010/12/25(土) 20:10:44
ここまでネタカキコなし
0016デフォルトの名無しさん2010/12/25(土) 20:22:50
　　おチンチンびろーん
　　 ∩＿＿＿∩
　　 | ノ　　　　　 ヽ/⌒)
　 /⌒) (ﾟ)　　　(ﾟ)　|　.|
　/　/　 　( _●_)　 ミ/
.（　　ヽ　　|∪|　　／
　＼　　　 ヽノ　/
　 /　　　　　　/
　|　　　_つ　 /
　|　 /UJ＼　＼
　|　/ 　　　 )　 )
　∪　 　　 （　 ＼
　　　　 　　 ＼＿)
0017デフォルトの名無しさん2010/12/25(土) 20:39:24
>>1
現代のパソコン等でグラフィックを高速に処理するコツは、
如何にデータをリアルタイムでベクトル化するかと、如何に並列化するか。そして、如何に計算の大部分をGPUなどのベクトル演算器にまかせるか。

これを如何に上手く設計するかであって、
つまり、GPU以外の部分を、たとえばアセンブラで書いたところで、そんな高速化は誤差みたいなレベル。
「配列への連続的な参照を a[i] じゃなくて *a++ でやって高速化だぞ〜・・・うへへ」って風な小手先の（そしておそらくコンパイラにさえ可能であるような）高速化じゃなくて、
もっと、演算の大部分を如何にGPUに詰め込むか？や、数式そのものの効率化とか。そういう知性と創造性が必要な高速化をできる人がホンモノ。

ようするに、「オブジェクト指向を使わずに書いたから速くなりました」的な最適化は、
根本的な仕組みや数式の改良をできない、能力の低い人が、仕方なくやる類の最適化だと思うよ。
0018デフォルトの名無しさん2010/12/25(土) 21:05:37
そもそもDirectXがCOMベース。
0019デフォルトの名無しさん2010/12/26(日) 05:02:45
>>4
心配しなくても、ちゃんとインライン展開してくれるから。
0020デフォルトの名無しさん2010/12/26(日) 06:38:10
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0021デフォルトの名無しさん2010/12/26(日) 07:46:29
実はオブジェクト指向ってしっくりこないんです！
0022デフォルトの名無しさん2010/12/26(日) 13:27:44
オブジェクト指向が遅い理由は、あくまで妄想ですが、
クラスの中にプログラマが使用しないメソッドが含まれていて、
それらがインスタンス生成時にメモリー上に不必要に読み込まれるから？
一切使わないメソッドは削って、ソースを作り直せば速度が向上されるのか？
0023デフォルトの名無しさん2010/12/26(日) 14:11:18
何と比べて遅いのか。
あるいは満たすべき速度の基準があって、それを満たしていないことが確認されたのか。
0024デフォルトの名無しさん2010/12/26(日) 14:38:16
>>22
そのとおり。
妄想です。
0025デフォルトの名無しさん2010/12/26(日) 17:22:35
配列で用足りるならオブジェクト指向じゃなくてもいいじゃん？みたいな。
0026デフォルトの名無しさん2010/12/26(日) 17:49:30
>>22
恥ずかしいから口を謹んだほうがいいよwww
0027デフォルトの名無しさん2010/12/26(日) 18:24:24
>>4

I/O系の低水準クラスにデータメンバー積むのかよ。
I/O系のクラスとデータ処理用のクラスを、
同じインターフェースで扱うって発想は無いんだろうな。
0028デフォルトの名無しさん2010/12/26(日) 19:42:10
>>22
VTBL調べろ。

実際オブジェクトが足枷になるのは、
SIMDが上手く使えないとか、メッセージに対応する
メソッドの選択(仮想関数の呼び出し)にコストが掛かる、メモリ確保にコストが掛かるぐらいだろ。
基本的に実用上問題になるのはSIMDの問題ぐらい。
後はアルゴリズム改良の方がよっぽど効果がある　
0029デフォルトの名無しさん2010/12/26(日) 21:11:35
ちょっとだけOO知ったから、にわかオブジェクト指向でプログラムしたけど。
設計がとんでもなクソなのが理解できなくて、オブジェクト指向のせいにした１デスね。
１よ！自分以外の他人のせいにすると楽だよね。でも、こんな所に出しちゃダメ。
恥かくから。
0030デフォルトの名無しさん2010/12/27(月) 02:06:41
10年前だったらもうちょっと反対派も頑張ってたのになぁ
0031デフォルトの名無しさん2010/12/27(月) 15:24:55
へえ
0032Prolog工作員2010/12/27(月) 15:32:07
ところで、オブジェクト志向って何のことだい？
0033Prolog工作員2010/12/27(月) 15:33:24
指向だったかなw
0034デフォルトの名無しさん2010/12/27(月) 18:06:08
遅いとかよりも・・・オブジェクト指向って一度基本クラス
(とくにインターフェイス)の設計に失敗すると後々しんどい。
だからと言ってラッパーやリーダークラス作るくらいなら
外部のstaticメソッドにインスタンス渡して処理する形の方
が修正しやすいんだよね。
オブジェクト指向は確かに便利なんだけど、この辺なんか
いい方法はないのかね。
0035デフォルトの名無しさん2010/12/27(月) 19:11:30
ちょっとでも失敗したと思ったら、どんどんリファクタリングしろよ。
面倒くさがってリファクタリングを渋るから、あとあとそれ以上に
苦労することになる。
0036デフォルトの名無しさん2010/12/27(月) 19:38:57
°°ってなに？
0037デフォルトの名無しさん2010/12/28(火) 00:50:35
>>36
半濁点半濁点
0038デフォルトの名無しさん2010/12/28(火) 06:24:51
何かのリテラルみたいだなw
0039デフォルトの名無しさん2010/12/28(火) 08:04:03
オブシコわかりやすくっていいやんけ
0040デフォルトの名無しさん2010/12/28(火) 12:17:10
>>35
リファクタリングってインターフェイスを変えずに
修正するってことでしょ？そのインターフェイス
(メソッド定義)が問題なんだよね。
ほかの人も使うものだったりすると修正出来ない
からなぁ
0041デフォルトの名無しさん2010/12/28(火) 12:38:40
Java最近始めたんですけど
インターフェースの存在意義がいまだにわかりません
0042デフォルトの名無しさん2010/12/28(火) 12:57:41
で？
0043デフォルトの名無しさん2010/12/28(火) 13:14:02
教えてください(>_<)
0044デフォルトの名無しさん2010/12/28(火) 13:54:02
>>41
javaでInterface無しとか死ねるぞ
0045デフォルトの名無しさん2010/12/28(火) 14:30:04
>>44
それって大人数での開発とか自分用ライブラリ作るときの話ですか？
いまかからでも使い始めた方がいいでしょうか
0046デフォルトの名無しさん2010/12/28(火) 14:49:53
Javaのインタフェースは、短く言うと型と実装を分離するためのもの。
Javaプログラミングだと、インタフェースが分からないと
標準APIすら使いこなせないので、絶対に理解しなきゃだめ。
0047デフォルトの名無しさん2010/12/28(火) 15:00:06
C++やPythonはクラスが複数継承できるから死なないんだな。
0048デフォルトの名無しさん2010/12/28(火) 17:29:03
Pythonは知らんけどC++で多重継承なんて
そんなに使わないんじゃない？
virtual継承とか色々ややこしくなるしダイヤ
モンド継承とか問題があるらしいじゃない。
0049デフォルトの名無しさん2010/12/28(火) 17:44:27
すっごいニワカ臭い発言ありがとうございます。
0050デフォルトの名無しさん2010/12/28(火) 17:51:02
いえいえ、お気になさらずに
0051デフォルトの名無しさん2010/12/28(火) 18:52:05
>>46
わかったようなわからないような
0052デフォルトの名無しさん2010/12/28(火) 19:25:25
getInstance(笑)
Factory Methodパターン(笑)
0053デフォルトの名無しさん2010/12/28(火) 19:56:31
>>52
何かおもしろいことある？
0054デフォルトの名無しさん2010/12/28(火) 20:55:33
笑っていう変数を渡してるんだろ
0055デフォルトの名無しさん2010/12/28(火) 21:05:51
>>54
そうか！
0056デフォルトの名無しさん2010/12/28(火) 22:34:32
>>40
> リファクタリングってインターフェイスを変えずに
> 修正するってことでしょ？そのインターフェイス
> (メソッド定義)が問題なんだよね。

リファクタリング本を見てね。
メソッド定義を変えるリファクタリングは
沢山あるから。じゃ
0057デフォルトの名無しさん2010/12/29(水) 04:58:53
>>40
勉強しなおせw
0058デフォルトの名無しさん2010/12/29(水) 14:02:21
>294：名前は開発中のものです。：2008/12/14(日) 07:22:24 ID:HIyGZizO
>>>286
>さっき提示したコードの価値をただのサブルーチン呼び出しとか
>言っちゃってる時点でなんかもう全然わかってない。
>
>あれはShotオブジェクトにEnemyとの当たり判定を”頼んで”いるんだよ。
>この違いがわからないんならいつまでたっても素人のまま。

>299：名前は開発中のものです。：2008/12/14(日) 17:59:02 ID:17g8Fdx4
>>>294は釣りだよな？ｗ
>突っ込むところが多すぎるｗｗ
>「ShotオブジェクトにEnemyとの当たり判定を”頼んで”いる」だけでオブジェクト指向とかｗｗ
>
>ところで、ゲームをオブジェクト指向で組むのは向いてないって話題は誰がしてるの？してない気がする。。
0059デフォルトの名無しさん2010/12/29(水) 18:58:36
>>48
C++だとインタフェースがないから、多重継承を使う。
0060デフォルトの名無しさん2010/12/29(水) 19:20:11
×オブジェクト指向は遅い
○オブジェクト指向が良く分からないからオブジェクト指向が遅い事にしたい
0061デフォルトの名無しさん2010/12/29(水) 19:54:03
インタプリタ言語は遅い
0062デフォルトの名無しさん2010/12/29(水) 20:57:12
>>61
コンパイルする時間を考えるとそうとは限らない。
0063デフォルトの名無しさん2010/12/29(水) 21:00:03
コンパイルの時間と実行時のスピードとなにか関係あるの?
0064デフォルトの名無しさん2010/12/29(水) 21:05:07
>>63
もちろん関係ある
0065デフォルトの名無しさん2010/12/29(水) 21:11:15
「このソフト遅いね、なんとかしてよ」
「インタプリタだからコンパイル時間0です。超速いです」
「?」
0066デフォルトの名無しさん2010/12/29(水) 21:12:43
>>65
もっと深く考えたら？
0067デフォルトの名無しさん2010/12/29(水) 21:25:33
>>66
実行時間より開発効率が重要だとか?
でも実行時間の遅さをコンパイルの時間でカバーはできないよね。
0068デフォルトの名無しさん2010/12/29(水) 21:27:40
>>67
実行時間の方が長くなるようなプロダクトならインタプリタ系じゃない言語にすればいいだけっしょ？
0069デフォルトの名無しさん2010/12/29(水) 21:36:09
>>68
「インタプリタは実行時間が遅い」
「コンパイル時間がないから遅いとは限らない」
ってのは、やっぱ実行時間の遅さがなんとかなるってわけじゃないわけね。
了解。
0070デフォルトの名無しさん2010/12/29(水) 21:42:59
なんでネタスレにマジレスしてんの？
0071デフォルトの名無しさん2010/12/29(水) 22:26:52
>>62
それはC#とかも含めて？
0072デフォルトの名無しさん2010/12/29(水) 22:36:12
C/C++のインタプリタとか、Javaのネイティブコンパイラとか、色々変なものがある以上、
その言語がインタプリタ言語であるかコンパイラ言語であるかという分類は難しいと思うのだが
0073デフォルトの名無しさん2010/12/30(木) 16:03:46
レジスタへのアクセスは早い。
メモリへのアクセスは遅い。
ハードディスクへのアクセスはさらに遅い。
CD/DVDへのアクセスなんてあくびが出るほど遅い。
0074デフォルトの名無しさん2010/12/31(金) 17:47:48
ネットワークへのアクセスが抜けてる
0075デフォルトの名無しさん2011/02/21(月) 00:38:55.45
enemy.update()
enemy.render()
とかやるのはもう時代遅れだな
0076デフォルトの名無しさん2011/04/29(金) 02:31:17.00
中々いいネタスレだ。確かに遅い。コーディングに入るまでが滅茶遅いｗ
0077デフォルトの名無しさん2011/04/29(金) 22:40:16.04
設計→開発→保守
トータルで見れば遅くない。
機械に厳しく人にやさしい
0078デフォルトの名無しさん2011/05/01(日) 09:46:20.75
正直世の中がオブジェクト指向に傾倒していてくれていたほうが助かることが多い
0079デフォルトの名無しさん2011/05/01(日) 10:06:28.08
>>76
え、もしかしてオブジェクト指向でモデリングとか分析とかやってる?
0080デフォルトの名無しさん2011/05/01(日) 17:49:27.69
ユースケース、ユースケース図、シーケンス図、クラス図

これくらいはやりたい。やったことないけど
UML読める人が回りにいないんだよなー
0081デフォルトの名無しさん2011/05/01(日) 19:21:04.44
シーケンス図って実用的か？
0082デフォルトの名無しさん2011/05/01(日) 19:37:14.50
クラス図とかコードから起こすのはいいとして、設計段階ではなぁ。
0083デフォルトの名無しさん2011/05/01(日) 19:41:15.27
ユースケースを図に起こすときに便利(らしいよ)

インスタンス間のメッセージのやり取りやインスタンスの生成と削除
この辺がシーケンス図はわかりやすい

と思ってます。実務で使ったことないから知識だけの感想だけどね
0084デフォルトの名無しさん2011/05/01(日) 19:43:53.07
ユースケース図を起こすのにシーケンス図が便利って意味?
0085デフォルトの名無しさん2011/05/01(日) 19:49:02.45
いやいや
ユースケースとユースケース図は別物ですよ
0086デフォルトの名無しさん2011/05/03(火) 13:51:42.51
>>85
ユースケース(シナリオ)だよね
めんどくさいからキライだけど。

クラス図と言っても、内部設計と外部設計では
変わって来るし。
0087デフォルトの名無しさん2011/05/03(火) 20:43:34.01
A4の紙2,3枚渡されて「これが仕様だ」とブン投げられるくらいなら
ユースケース書きたい。
0088デフォルトの名無しさん2011/05/03(火) 22:29:56.82
ラムだとは何だったのか
0089デフォルトの名無しさん2011/05/03(火) 23:11:02.70
ラムだっちゃさん？
0090デフォルトの名無しさん2011/05/09(月) 22:31:29.04
ユースケース書いとくとマニュアル作るとき便利
スクリーンショット貼り付けるだけでほぼ完成
0091デフォルトの名無しさん2011/05/19(木) 02:24:23.40
こいつ何とかしてくれ。

http://wonderfulsky.web.fc2.com/memo.html

0092デフォルトの名無しさん2011/05/19(木) 21:52:51.71
ワロタ
0093デフォルトの名無しさん2011/05/20(金) 02:28:29.48
あとはここが参考になる
http://studiokingyo.fc2web.com/
0094デフォルトの名無しさん2011/05/20(金) 12:14:16.55
世界最強吹いたｗ
0095デフォルトの名無しさん2011/05/20(金) 14:33:14.41
世界最強？
0096デフォルトの名無しさん2011/05/20(金) 15:37:56.76
かつてはgoto, malloc/free論争で軽々と1スレ埋めていた連中も
年取ってお疲れ気味でなかなか盛り上がれなくなってきたな。
0097デフォルトの名無しさん2011/05/22(日) 08:34:15.62
CでOOPすれば早いお！　ライブラリもパプリックヘッダーだけ公開しておけば使ってくれる人も出てくるお！
0098デフォルトの名無しさん2011/05/22(日) 09:36:06.89
CでOOPしても遅いお！OOPの遅さは動的束縛の遅さ！
OOPのメリットは動的束縛のもたらす柔軟さ！だから切り離せないお！
0099デフォルトの名無しさん2011/05/24(火) 19:49:41.36
速度が求められるトコだけCで書いたらよかろ
0100デフォルトの名無しさん2011/05/25(水) 11:26:52.81
>>99
>>98
0101デフォルトの名無しさん2011/05/27(金) 08:56:07.92
カプセル化・継承だけなら引数ひとつ増えるコスト
virtual利用なら関数呼び出しが関数ポインタ経由になるコスト
0102デフォルトの名無しさん2011/05/27(金) 12:53:09.68
>>96
free不要で結論がついたの？
0103デフォルトの名無しさん2011/05/27(金) 12:54:25.57
>>101
vtable参照コストじゃねーの？
0104デフォルトの名無しさん2011/05/27(金) 21:48:22.49
>>103
それも有るだろうけどそれ以上に
ポインタによる分岐予測の外れが酷いわな。
まぁ、そこまで速度が気になるんだったら
GPUやらSIMD向けのコード書くけどな。
0105デフォルトの名無しさん2011/05/29(日) 20:16:51.38
テンプレートで静的ポリモーフィズム使うのって、どうなんですか？
0106デフォルトの名無しさん2011/05/30(月) 13:57:18.57
ポリリズム　ポリリズム・・・
0107デフォルトの名無しさん2011/05/30(月) 14:32:47.10
poly-morphism
poly-rythm
全然違うじゃないｓっすかー１
0108デフォルトの名無しさん2011/05/30(月) 19:12:03.29
>>105
コンバイル時に解決しちゃうから問題ないんじゃない？
自分で重複コード書くかコンパイラに任せるかの違いかと。
コンパイラに任せる分よしなに計らってくれてたりはくれるのかも。
0109デフォルトの名無しさん2011/05/30(月) 22:33:58.67
>>105
　静的ポリモフィズムってオブジェクト指向とは別もんな気がする。
静的なポリモフィズム、静的なポリモフィズムなんかそういう世界じゃね。
こういうsmalltalkのオブジェクト指向入門にでてくるような典型的なサンプルコードは書けないしね。

"=演算子は次のTrue,Falseのうちいずれかのオブジェクトを返す。"
True := [:x :y|^x value]. "xにvalueメッセージを送りxのブロックを実行"
False := [:x :y|^y value]. "yにvalueメッセージを送りyのブロックを実行"

5 = 5 value:[^ 'true'] value:[^ 'false'].. "trueが返される"
5 = 6 value:[^ 'true'] value:[^ 'false'].. "falseが返される"
0110デフォルトの名無しさん2011/06/18(土) 21:30:38.29
OOPは最近なんか進展あった？
衝撃の新技術的なやつ
0111デフォルトの名無しさん2011/06/18(土) 21:42:01.89
Samalltalk への回帰現象
0112デフォルトの名無しさん2011/06/19(日) 18:40:11.67
言語単位でいえば進歩はしてるんだけど、OOPそのものは進展なし
0113天使 ◆uL5esZLBSE 2011/07/03(日) 18:42:32.93
ゴミグラマってバカだったんだな
ゴミ量産機
0114デフォルトの名無しさん2011/07/03(日) 19:51:37.72
自己紹介乙
0115デフォルトの名無しさん2011/07/27(水) 10:17:27.87
カリスマの存在
0116ななし。2011/07/27(水) 11:59:01.65

--pixiv / カオスラウンジ騒動--

他人のイラストを無断使用
ttp://blog.esuteru.com/archives/4115418.html
ttp://omasoku.blog90.fc2.com/blog-entry-576.html

ぷちまとめ
ttp://www.geocities.jp/x_shortcake/
0117デフォルトの名無しさん2011/07/30(土) 12:47:02.05
>> http://hibari.2ch.net/test/read.cgi/tech/1309621283/999
型推論がしっかりした言語はそうだよね。
0118デフォルトの名無しさん2011/07/30(土) 13:25:34.12
>> http://hibari.2ch.net/test/read.cgi/tech/1309621283/999

なんか違うんだよね。
アヒルでもカバでも…じゃなく、アヒル未満で済む場合にそれを許す
ゆるさが欲しいのがダックタイピング。
こいつはもちろんアヒル型ではチェックを通らない。
で、部分型をアドホックに定義して通すためには
現行の型システムでは制約が多すぎる（あるいは手間がかかりすぎる）という。
0119デフォルトの名無しさん2011/07/30(土) 16:57:52.13
全体の動きは確かに遅くなる．．．　てか　そんな高速処理はハードを利用しろ！　OOはヒューマンインタフェースの為のものだ！
0120デフォルトの名無しさん2011/07/30(土) 18:30:15.89
age
ここ次スレでいいの？　このスレタイじゃ新規の人来ない気がするけど、part3でまた馬鹿に戻せばいいか
オブジェクト指向は馬鹿ご用達
http://hibari.2ch.net/test/read.cgi/tech/1309621283/
0121デフォルトの名無しさん2011/07/30(土) 19:39:07.08
>>120
もとはあのスレも どうせ放置されて邪魔になるスレの再利用だったし
こちらもそのノリなんだからいいと思う。ここも放置しても、最後まで
埋まらんだろうし、最後にオブジェクト指向の総合スレにまとめちゃったら
いいかも。
0122デフォルトの名無しさん2011/07/30(土) 20:21:37.21
いいとこどりのハイブリッドな言語ってないの？
0123デフォルトの名無しさん2011/07/30(土) 20:33:53.53
>>122
色んな意味でC++
0124デフォルトの名無しさん2011/07/30(土) 20:56:33.01
C#のdynamicはどうか
0125デフォルトの名無しさん2011/07/30(土) 21:01:24.88
>>122
common lisp
0126デフォルトの名無しさん2011/07/30(土) 21:31:04.06
>>122
ハイブリッド言語の代表
C++とCommonLispは言語仕様のお化けですが何か

現実的にはC#やjava、rubyやpython程度のハイブリッド具合が丁度良い

言語の能力よりRAD環境の有無の方が楽かどうかの分かれ目。と思う今日この頃
0127デフォルトの名無しさん2011/07/30(土) 22:34:17.26
>>118
アヒル未満を許すんじゃなくて、アヒル以上のモノをアヒルとして許すって事だよなぁ。
アヒルは明示的に宣言されてる存在じゃないから間違えてるんじゃないだろうか。

C++のtemplateの様な形で明示化してやると説明として分かりやすいかも。
template<class duck> void Cooking(duck &duck_object)
{
     duck_object.Kill();
     Cut(duck_object,Bird::Wing);
     Drip(duck_object,Animal::Blood);
     pot.Boil(duck_object);
}
0128デフォルトの名無しさん2011/07/31(日) 01:38:19.65
Ocamlの型推論は、前スレの主張するダックタイピングとやらを許す。
つまりあるメッセージを受け取るオブジェクトが、鳴いたり歩いたりできれば整合性に問題は無いことを推論できる。

一方Javaなどは、もっと厳しい制約を架していて、必要なメソッドの整合性だけでなく、それらメソッドを最低限持っている特定の型(アヒルであるかどうか)に限定する必要がある言語だ。
これは、言語上の単なるメソッド呼び出し関係の整合を越えた、さらに制約のきつい言語ということでもある。

二つの違いは、プログラムの正しさを、動作や受け取る必要のあるメッセージとして検査するか、受け取る必要のあるメッセージを、メソッドの一部として保持する特定のクラスとして検査するかの違いだ。

前者は整合性を失わずに、より柔軟な検査を実現できるが、
後者は整合性より余分な制限を課す。

ただし、どちらがやりやすいかは全く別の問題だ。
例えば、鳴いたり歩いたりできれば、アヒルでも人間でも同じ処理を加えていいというわけではない、という立場も考えられる。
0129デフォルトの名無しさん2011/07/31(日) 01:48:22.13
ちなみにOcamlは、どちらの選択も許す。
・鳴くことができて歩くことができれば、このメソッドの引数として正しい。
というのは、自動的に検査できる。

さらに、引数がアヒルのクラスだと、型を明示することで、
・鳴くことができて歩くことができたとしても、アヒルでなければ、このメソッドの引数として正しくない。
という検査をさせることもできる。

どちらがいいかは、ケースバイケースだと思う。
0130デフォルトの名無しさん2011/07/31(日) 02:09:43.72
普通に考えれば、オブジェクト指向というと、
適用できる処理の対象クラスを特定したいというのは自然だと思うけどね。

もちろん、そうでない場合を否定する気はないけど。
0131デフォルトの名無しさん2011/07/31(日) 03:27:08.90
>>128
頭固すぎ。

Javaでも同じことはできる。
メソッドが１つだけの型を作ればいいだけ。
0132デフォルトの名無しさん2011/07/31(日) 03:34:17.79
>>131
それ結局、明示的な型定義になっているよ。
interface hasHogeMethod { ... hoge(...) { ... } }
とか、
interface hasHogeFugaMethod { ... hoge(...) { ... } ... fuga(...) { ... } }
のようなのは、可能だしやってもいいけど、
言いたいことと少し違う。

論点にしたかったのは、メソッドに注目するか、特定の型に注目するかという点。
0133デフォルトの名無しさん2011/07/31(日) 06:42:56.55
Javaは結局クラス=型なんだよね
0134デフォルトの名無しさん2011/07/31(日) 06:52:21.53
>>133
うん
0135デフォルトの名無しさん2011/07/31(日) 07:58:40.86
>>130
ポリモーフィズム全否定ですか？
0136デフォルトの名無しさん2011/07/31(日) 09:13:10.21
nominal subtyping vs. structural subtyping
0137デフォルトの名無しさん2011/07/31(日) 09:24:46.87
前スレ >>975 の
>型名なしで、どうやってディスパッチ先を指定するんだって話。
>シングルディスパッチだと、
>obj.method = method1;
>とか出来るから、型名要らないけど、
>それはシングルディスパッチ限定の話だよねって。

って、PythonやJSみたいな設計限定なんだよなあ。
ダックタイピングでも、メソッド≠オブジェクト、メソッド≠属性な言語はあるのだから。
0138デフォルトの名無しさん2011/07/31(日) 09:35:32.33
>>132
> 論点にしたかったのは、メソッドに注目するか、特定の型に注目するかという点。

そんなのを論点にする必要はない。

コードに着目すれば、何かのオブジェクトの
Aというメソッドと、Bというメソッドを使うコードがあるとすれば、
それはAとBというインターフェースを持ったオブジェクトであるということ。

あとは、それをコード上で「○インターフェースを使用します（○型です）」と明確にするか、
「この関数は○メソッドと△メソッドと・・・を使用します」と
ドキュメントに書くしかないかの違いでしかない。

この関数があとで□メソッドを使うように変更されたら、
動的言語は辛くなるけどなｗ
0139デフォルトの名無しさん2011/07/31(日) 09:45:21.12
>>138
> あとは、それをコード上で「○インターフェースを使用します（○型です）」と明確にするか、
> 「この関数は○メソッドと△メソッドと・・・を使用します」と
> ドキュメントに書くしかないかの違いでしかない。

OCamlの例は明示的に書かなくても
インターフェースを型推論するって話だろ
0140デフォルトの名無しさん2011/07/31(日) 10:37:52.32
岡村△
0141デフォルトの名無しさん2011/07/31(日) 10:46:59.64
だが、OCaml にはオーバーロードが出来ないという致命的欠陥がある罠。
0142デフォルトの名無しさん2011/07/31(日) 10:58:52.99
OCaml使いはオーバーロード嫌ってるんじゃね？
あれはメリットだけじゃないからな
オーバーロード欲しいならGCamlか、いっそのこと型クラスのあるHaskellか
0143デフォルトの名無しさん2011/07/31(日) 12:25:07.75
プログラマの会話の不快感は異常
0144デフォルトの名無しさん2011/07/31(日) 12:38:17.07
>>143
なら、ここに来なきゃ良いでしょ
わざわざ自分から不快に思う場所にくる事もあるまいに

キモオタがキモイと言いつつアキバに通う人みたいな矛盾を感じる。。。
0145デフォルトの名無しさん2011/07/31(日) 13:18:57.56
本当だ、↑キモイね
0146デフォルトの名無しさん2011/07/31(日) 13:42:50.33
え、何この流れ？
Javaを批判される => 反論できないから人格批判
ってこと？
0147デフォルトの名無しさん2011/07/31(日) 13:57:03.60
>>145
でしょ？
>>143はこれと同レベル
0148デフォルトの名無しさん2011/07/31(日) 16:53:38.61
オタが自己嫌悪するのは極めて自然な行為なんだけど？
むしろそれが出来ないのが、いわゆるライトオタクとかいうクズ
0149デフォルトの名無しさん2011/07/31(日) 17:52:54.30
マでやれ
0150デフォルトの名無しさん2011/07/31(日) 18:16:43.63
>>143を具現化するスレ
0151デフォルトの名無しさん2011/07/31(日) 18:44:12.39
オブジェクト指向言語なら、オーバーロードを許すなら
いっそのことマルチメソッドにしてくれよと思う
0152デフォルトの名無しさん2011/07/31(日) 19:02:49.75
とくにC++0xな。あれやばすぎ。
0153デフォルトの名無しさん2011/07/31(日) 20:03:54.22
C#は何でもできて楽しいことは楽しいんだが
C++みたいになりそうで怖い
0154デフォルトの名無しさん2011/07/31(日) 22:06:19.79
そういや >>129 が

> さらに、引数がアヒルのクラスだと、型を明示することで、
> ・鳴くことができて歩くことができたとしても、アヒルでなければ、このメソッドの引数として正しくない。
> という検査をさせることもできる。

って書いてるけど、OCamlでそんな事出来たっけ？
OCamlの'O'機能はあまり使わないから自信ないけど、
型が（構造的に）一致したら通っちゃう気がするんだが
0155デフォルトの名無しさん2011/08/01(月) 00:09:11.17
>>154
間違ってたかも。確かにOcamlで特定のクラスに名前を与える方法は見つからなかった。
モジュールシステムと勘違いしていたとおもう。
0156デフォルトの名無しさん2011/08/01(月) 00:33:02.12
「もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」
俺気づいた。みんなこの言葉を誤解している。

「歩き」「鳴く」のならそれはアヒルである。とは言っていない。
「アヒルのように歩き」「アヒルのように鳴く」のならそれはアヒルと言っている。

つまり、duck.walks_like_duck()、duck.quacks_like_duck()、この二つを実行できた場合にアヒルということ。

何が言いたいかというと、名前が長い。

それも当たり前の話。鳴いて歩いたからと言ってアヒルとは限らない。
アヒルであるという情報が必要。それがメソッド名の*_like_duck()

型があれば、duck.walks()、duck.quacks()でいいのに。
0157デフォルトの名無しさん2011/08/01(月) 00:49:48.90
それはね。"アヒル"というものに対する定義の仕方の違いなんだよ

(a) "アヒル"と「名付けられた」型に属するオブジェクトは"アヒル"である
(b) オブジェクトが"アヒル"の挙動を要求する場面でそのように振る舞える
    (walks() や quacks() が呼べる）なら"アヒル"である

どちらの考え方もある。君が言ってるのは前者だ
OCamlやScalaやduck typingの言語などは後者だ
そしてどちらも duck.walks() でいい
0158デフォルトの名無しさん2011/08/01(月) 00:51:01.41
>>155
岡村(÷)
0159デフォルトの名無しさん2011/08/01(月) 00:59:33.23
>>157
> (walks() や quacks() が呼べる）なら"アヒル"である

walks()を実際に呼んだら、6本足であるいたり、
quacks()を実際に呼んだら、キリリリリって鳴いても
それはアヒルなのですか？
0160デフォルトの名無しさん2011/08/01(月) 01:04:59.03
じゃあDuckインターフェース(worksやquacksを含む)を実装したクラスに
6本足で歩いたりキリリリリって鳴くのを禁止するような
言語機能があるの？
0161デフォルトの名無しさん2011/08/01(月) 01:21:21.85
structural subtypingはアヒルかどうか問題にしない。
6本足であるいたりキリリリリって鳴いたりするかどうかにかかわらず、
歩いたり鳴いたりできるかが判断の条件だ。

nominal subtypingの条件は、歩いたり鳴いたりできるかではなく、
アヒルという型名が付けられているかどうかを第一の判断の条件にする。
0162デフォルトの名無しさん2011/08/01(月) 01:23:35.21
>>160
依存型使えばそれにそれに近いことできるかもしれない
0163デフォルトの名無しさん2011/08/01(月) 01:23:51.79
>>160
インターフェイスの仕様でそう決めればいいだけのこと
0164デフォルトの名無しさん2011/08/01(月) 01:33:30.60
>>162
ああ、duckとか言っててOOP脳になってたけど、
確かに依存型はそれに近いね

>>163
どうやって決めるの？「このインターフェースはDuckって名前が付いてるから
works() で6本足で歩いちゃダメ」ってドキュメントにでも書くの？
0165デフォルトの名無しさん2011/08/01(月) 01:39:15.95
>>164
＞「このインターフェースはDuckって名前が付いてるから
＞works() で6本足で歩いちゃダメ」ってドキュメントにでも書くの？
その通り。インターフェイスメンバの仕様を決めるのは当然。
その点ダックタイピングだとメソッド名だけで仕様を制約しなきゃいかんので広範囲に適用しづらい。
0166デフォルトの名無しさん2011/08/01(月) 01:56:50.80
なーんだ。型でチェックできるんじゃないんだ
ただ型名を人間が理解しやすくするためのタグとして扱うだけなら
structural typing でも duck typing でもいいじゃん
別にクラス名付けられないわけじゃないんだぜ？
部分型は型の構造で決まるってだけで

class duck = object method work () = () end
let f (obj : #duck) = obj#work ()

みたいに明示的に型名付けても良いんだよ？
0167デフォルトの名無しさん2011/08/01(月) 02:06:06.28
Javaの人にも分かり易く言うと、structural subtyping は
「仮にインターフェースの名前が違っても、同じシグニチャなら交換可能」だ
そんなに毛嫌いするような機能じゃないよ
0168デフォルトの名無しさん2011/08/01(月) 02:16:38.70
そもそも仕様を制約するならモジュールで区切っちゃえばいいしね
ドキュメントに書くより確実だ
0169デフォルトの名無しさん2011/08/01(月) 02:29:12.95
なんというか、nominalな型システムと
structuralな型システムは一長一短なんだよね
好みの問題でもあるから喧嘩すんなよ
0170デフォルトの名無しさん2011/08/01(月) 13:18:20.30
ふだん全然テスト書かないから
「静的型検査でチェック出来ない = ドキュメントに書くしか無い」
こんな発想になるんだよ
メソッドの仕様を検査したかったらテスト書け
0171デフォルトの名無しさん2011/08/01(月) 13:42:16.66
え？
0172デフォルトの名無しさん2011/08/02(火) 00:41:44.33
> こんな発想になるんだよ

こんな発想をしているのはお前だけじゃね？

静的検査とユニットテストと統合テストと
テストの種類や呼び方はいろいろあるけれど、
これらは全部やる。

それが普通の発想だよ。

でも君は他の人は「静的検査をすればその他のテストはしなくていいと考えてる」と
思ってるんでしょ？ それは明らかに君が間違ってるだけだよね。
0173デフォルトの名無しさん2011/08/02(火) 01:18:29.69
>>138は

> あとは、それをコード上で「○インターフェースを使用します（○型です）」と明確にするか、
> 「この関数は○メソッドと△メソッドと・・・を使用します」と
> ドキュメントに書くしかないかの違いでしかない。

と書いてるので怪しいが……
0174デフォルトの名無しさん2011/08/02(火) 03:34:12.95
ダックタイピングはメソッドが1つだけの
インターフェースと考えれば良い。
0175デフォルトの名無しさん2011/08/02(火) 09:55:36.27
「これでJavaでもダックタイピング出来るんだ・・・」
とか言いながらメソッドひとつのインターフェースを
定義しまくってる姿想像してワロタwww
0176デフォルトの名無しさん2011/08/02(火) 20:06:25.18
全然違う。インターフェースは同じインターフェースを明示的に実装してるクラスのオブジェクトしか通さないが
ダックタイピングは無関係のオブジェクトでも同名のメソッドがあれば通る
つまり他クラスのオブジェクトと多態させるためにクラス自体に何も手を入れる必要が無い点で大きく異なる
0177デフォルトの名無しさん2011/08/02(火) 20:33:49.60
そりゃおっかねえな
0178デフォルトの名無しさん2011/08/02(火) 20:53:49.99
scalaにもそういうのあるけどなんかあんま使われてないっぽい
0179デフォルトの名無しさん2011/08/02(火) 21:41:51.41
それはオブジェクト指向的なポリモーフィズムは使われてないってこと？
0180デフォルトの名無しさん2011/08/02(火) 22:08:01.33
そもそもポリモーフィズムなんて百害あって一利無しじゃん
さすが後付け機能って感じで誰も精査せずにぶち込んだ感ムンムン
こんなの崇拝してるＰＧはクズ
0181デフォルトの名無しさん2011/08/02(火) 22:12:58.61
後付のソースください
0182デフォルトの名無しさん2011/08/02(火) 22:20:08.79
ポリモが後付け？
0183デフォルトの名無しさん2011/08/02(火) 22:27:09.32
>>176
> ダックタイピングは無関係のオブジェクトでも同名のメソッドがあれば通る
> つまり他クラスのオブジェクトと多態させるためにクラス自体に何も手を入れる必要が無い点で大きく異なる
無関係のオブジェクトと多態させることの
メリットを教えて下さい。

0184デフォルトの名無しさん2011/08/02(火) 22:32:36.54
ここでいう無関係は
継承関係がないって意味だと思うよ
0185デフォルトの名無しさん2011/08/02(火) 22:37:12.94
>>183
ビンのフタをペットボトルのキャップとして使える。
0186デフォルトの名無しさん2011/08/02(火) 22:46:50.44
>>185
例えじゃなくて、
具体的なコードで、ありそうな話でお願いします。
0187デフォルトの名無しさん2011/08/02(火) 22:56:18.36
なんだ、ダックタイピングって
アダプタパターンのことだったのかｗ
それならJavaでできる。
0188デフォルトの名無しさん2011/08/02(火) 23:03:55.62
別にJavaで出来ないことが出来るから
スゴイといってるわけじゃない。より簡単に出来るってだけ
0189デフォルトの名無しさん2011/08/02(火) 23:07:47.08
>>186
流れを読まずに、横からだけど。
実行時にオブジェクトに対して特異メソッドを定義したりできる。
メソッドがあとからくっついたりできるくらいなら、
ダックタイピングも当然あったほうがやりやすい、となるのでは。

>>187
え？
0190デフォルトの名無しさん2011/08/02(火) 23:13:22.73
>>189
ダックタイピングが利用価値があると
説明するために特異メソッド作ったのか？ｗ

そもそも特異メソッドは必要なのか？
普通に継承すればいいじゃん。

なぜ実行時に追加しないといかんのか。
0191デフォルトの名無しさん2011/08/02(火) 23:14:52.47
なにができるだ
アフォだな
そんなに制限が嫌いならvoid*使うかアセンブラでもやりゃいいじゃん
全部アドレスだから型の制限なんてないぞ

そもそも言語ってのは制限をつける形で進化してきたのに
最近言語を習いはじめた奴って何も考えずに制限をはずすことばっかり
頭がいっちゃってるよね

馬鹿なの？
なんのために型作ってコンパイラでエラー出すようにしたと思ってるの？
死ねば？
0192デフォルトの名無しさん2011/08/02(火) 23:27:20.16
>>190
え？
0193デフォルトの名無しさん2011/08/02(火) 23:30:42.04
ほらなー。実行時に定義するのと
実行前に定義するの、
どっちでも同じ事出来るなら
実行前に定義しちゃえばいいじゃんか。
だろ。
0194デフォルトの名無しさん2011/08/02(火) 23:31:31.03
>>192
0195デフォルトの名無しさん2011/08/02(火) 23:32:32.07
実行時にメソッドはやす機能をつけると
実行前にエラーチェックすることができなくなっちゃう。

そのデメリット以上のメリットはないよ。
0196デフォルトの名無しさん2011/08/02(火) 23:42:32.88
おもむろに前スレから引用してみる

> 例えばDecoratorパターンなんて本来クラス作る必要は無い
> (Javaの例：http://ja.wikipedia.org/wiki/Decorator_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3#.E5.88.A9.E7.94.A8.E4.BE.8B)
>
> import new
> class Price(object):
>     def __init__(self, value):
>         self.value = value
>     def getValue(self):
>         return self.value
> 
> p = Price(120)
> p.getValue = new.instancemethod(lambda _, f=p.getValue: f() * 2, p, Price)
> p.getValue = new.instancemethod(lambda _, f=p.getValue: f() + 80, p, Price)
> print p.getValue() # 320
0197デフォルトの名無しさん2011/08/02(火) 23:47:50.44
> 例えばDecoratorパターンなんて本来クラス作る必要は無い
作る必要がないのに作るのは、
コード上の意図を明確にするため。

たとえば、変数名なんて本来aでもbでもどんなものでもいい。
だけど、人間にとってわかり易くするために、
長い名前をつける。

本来作る必要はない。言ったとしても、
たしかにそうだが、作ったほうが意図が明確になるだろうという
言葉で反論が可能。
0198デフォルトの名無しさん2011/08/02(火) 23:51:08.14
制限をつける形で進化してきたって……
静的型付けなんてプログラミング言語の最初期からあった概念だろ
静的型付けでも継承や多態が出来るようになったり、むしろ柔軟な方向に進化してるよ
0199デフォルトの名無しさん2011/08/02(火) 23:52:07.34
分岐とジャンプがあれば構造化などいらない
0200デフォルトの名無しさん2011/08/02(火) 23:52:52.72
>>198
Cの仕様の変遷も知らないのか
0201デフォルトの名無しさん2011/08/02(火) 23:56:08.10
C限定の話だったのか
0202デフォルトの名無しさん2011/08/03(水) 00:00:06.47
>>197
メソッドを動的に装飾したり追加したりするのがDecoratorパターンなんだから
>>196のコードの方がよっぽど直接的で分かりやすいと思う

まあ、分かりやすさなんて水掛け論になるから止めとくけど、
ひとつハッキリしてるのはJavaでは>>196のような簡潔なコードは書けません
他の言語では書けますし、Javaのように冗長に書く事も出来ます
0203デフォルトの名無しさん2011/08/03(水) 00:08:55.35
LispからCOBOLまでさまざまな言語があって、
どのような制限や自由が好ましいかは、
使ってる言語の文化や適用する問題で大きく変わる

オブジェクト指向だって一種の指向に過ぎないのだから、
細かい部分を含めて絶対的な良し悪しはない
0204デフォルトの名無しさん2011/08/03(水) 00:11:00.75
>>202
メソッドを装飾した以上、それは別のものなんだよ。
別のものは別のものとして扱わないと、
たとえばその例だとPriceは自分がPriceだと思っているのに
自分をいじられてるせいで、PriceがgetValueした結果が意図したものじゃなくなっている。

装飾はあくまで基本はそのままで、周りにつけるもの
>>196は装飾ではなく補修。補修は危険だ。動作保証がなくなる。
動作保証の点において、装飾は補修のかわりになるが補修は装飾の代わりにはならない。
0205デフォルトの名無しさん2011/08/03(水) 00:17:35.94
>>204
じゃあ int x = 1 と int y = 2 は違う値だから型で区別しないとね
Int1 とか Int2 とか定義する？
0206デフォルトの名無しさん2011/08/03(水) 00:20:13.65
Decoratorパターンは装飾したオブジェクトと
装飾前のオブジェクトで同じインターフェースを使う事で
「区別しなくてすむように」するパターンだぞ
0207デフォルトの名無しさん2011/08/03(水) 00:21:35.66
>>206
おや？　分かってる人がいるじゃん。
0208デフォルトの名無しさん2011/08/03(水) 00:22:49.82
はー、ダックタイピングのメリットが知りたいのか。
それならC++のSTLを触ってみれば良い。
静的だけど、関数のオーバーロードでダックタイピングしてるよ。
例えば、std::listの要素に何でもかんでも突っ込めるのはダックタイピングのおかげ。
さもなくば、
「std::listの要素は、std::list::elemを継承している必要があります」
とかなっちゃう。
0209デフォルトの名無しさん2011/08/03(水) 00:23:55.18
区別する必要が無いのだからクラスを定義する必要はありませんね
0210デフォルトの名無しさん2011/08/03(水) 00:26:40.07
>>208
節子、それテンプレートや。
パラメータごとの静的な複製や。
0211デフォルトの名無しさん2011/08/03(水) 00:27:46.73
C++はnominalな型システムなのにtemplateで静的ダックタイピング可能という
かなりのハイブリッドさ
0212デフォルトの名無しさん2011/08/03(水) 00:27:59.08
>>208
それだけなら普通のGenericsと変わらないのでは？
0213デフォルトの名無しさん2011/08/03(水) 00:28:16.24
だけど、テンプレートはオーバーロード無しには成り立たないだろ？
オーバーロードは静的なダックタイピングだから参考になるだろ。
0214デフォルトの名無しさん2011/08/03(水) 00:34:23.02
>>198
なにそれ？
void*の時代に戻りたいの？
バーカ
0215デフォルトの名無しさん2011/08/03(水) 00:36:24.80
> オーバーロードは静的なダックタイピング

天才すぎてさっぱり意味が分からんｗｗｗ
0216デフォルトの名無しさん2011/08/03(水) 00:39:19.74
テンプレートなんて使ってる奴って馬鹿しかみたことねぇ
0217デフォルトの名無しさん2011/08/03(水) 00:40:05.11
structual subtypingが役に立つ時って、演算子+が定義されているオブジェクトに対して、
e1 + e2 + ... en
のような処理を一般的に適用できたりするのがいいのかな？
それとか、operator()を使ったSTLとか。
それほど必要ってほどでもないような。

CやC++の特徴って、constとかポインタの型とかの制限はありつつも、
必要があればキャストしたり、メモリを直接操作したりできるようなところ。
それが便利なこともあるし、バグの元になったりすることもある。
0218デフォルトの名無しさん2011/08/03(水) 00:41:24.92
自分で作ったテンプレート眺めるのはすきだけど
他人の作ったテンプレートは見るのも嫌って奴しかいないな
0219デフォルトの名無しさん2011/08/03(水) 00:44:13.94
一度でも他人の作ったオナニーテンプレートのバグ探すハメになったら
絶対テンプレートなんて使わなくなる
0220デフォルトの名無しさん2011/08/03(水) 00:47:05.48
仮想関数よりさきにテンプレートに触れてしまった人間は、
それにしがみ付いて、OOPを受け入れようとしない。
0221デフォルトの名無しさん2011/08/03(水) 00:50:46.06
魔王「我を受け入れろ」
みたいな奴ですか？
0222デフォルトの名無しさん2011/08/03(水) 01:05:29.53
>>217
型名を付けなくても型の構造が合えば部分型にアップキャスト出来るので、
クロージャのような感覚でオブジェクトを生成して使えるようになります
つまりプログラミングスタイルが変わります
それが好ましいかどうかは人によりますが
0223デフォルトの名無しさん2011/08/03(水) 01:14:50.56
>>222
動的言語や型推論ができる言語で、わざわざ型を明示する風習がない書き方をするなら、substructualでいいとおもうけど、
nomialな風習の言語では、敢えてsubstructualな機能を活用する場面ってどれだけあるかな？
0224デフォルトの名無しさん2011/08/03(水) 01:19:56.80
そういえば最近C++0xで無名関数を使ったとき、型名を書かないといけないとしたら面倒だとはおもった。
でも、単にクロージャを作るだけなら、複数メソッドの型シグニチャまで考えなくても良さそうだし、
Javaの無名クラスも、継承元を明記するけどそれほど不便でもないような。
0225デフォルトの名無しさん2011/08/03(水) 01:30:54.51
>>209
> 区別する必要が無いのだからクラスを定義する必要はありませんね

多態を否定しているの？
区別する必要がないのとクラス定義は全く別の話。

”違うクラス”を同じように扱う、逆に言えば
同じように扱うが、"違うクラス"であるということだ。
0226デフォルトの名無しさん2011/08/03(水) 01:33:04.91
たとえば変数を使うとき、定義しないとしたら
面倒だと思った。


結局これと同じで、型も間違いをなくすために
定義をすると考えよう。

そりゃなくてもできる。だが人間は間違いをおかすもの。
間違いを犯さないために、定義をしてるんだよ。
0227デフォルトの名無しさん2011/08/03(水) 01:37:16.58
結局宣言とか定義とかいうのは
人間が間違いをしないようなチェックであるわけで。

ちゃんと宣言していればこういう間違いが防げるよね？
（例、まったく無関係想定外のオブジェクトを変数に入れて、存在しない
メソッドを呼んでしまうこと。そういうミスが実行するまで気づかないこと）
という話に対して、俺はそんな間違いしないもん。って言ってるにすぎないんだよ。

どちらが大規模、大人数の開発に向いているかなんて
言うまでもない話。
0228デフォルトの名無しさん2011/08/03(水) 01:41:17.01
>>223
nominalな風習の言語ではnominalに書いたほうが素直なコードになると思います

動的言語や構造的部分型の言語では、シグニチャが同じならそれらは区別されません
そのため同じメソッド名は可換になるように設計する風習があります
そして、これらの言語では長いメソッド名を付けなくても済むように
高機能なモジュールシステムや名前空間を持つことが多いです
0229デフォルトの名無しさん2011/08/03(水) 01:51:03.81
ところで部分構造型的なオブジェクト指向言語で、抽象メソッドの定義とかどうしてる？

具体的にはPythonを使ってる時に抽象クラスとして考えているクラスがあったりする場合、
不要とは分かっていても、何もしないメソッドとか、呼ぶとエラーが出るメソッドを、抽象メソッドの宣言の意味で加えたりするんだけど…
0230デフォルトの名無しさん2011/08/03(水) 01:54:15.68
>>225
>>196のデコレータの例は"違うクラスである"ことに何か意味がありますか？
リンク先を見ると、Javaのコードは
new WholesalePrice(new DoublePrice(new WholesalePrice(new DoublePrice(new PrimePrice(120)),80)),200).getValue()
となっていました。これは明らかに
new WholesalePrice(new DoublePrice(new PrimePrice(120))).getValue()
のオブジェクトと型では判別不可能です
またPrimePrice型やDoublePrice型と違うことが分かって嬉しい状況が思い浮かびません
0231デフォルトの名無しさん2011/08/03(水) 02:00:00.93
そりゃ挙動が違うって意味があるだろうに。
0232デフォルトの名無しさん2011/08/03(水) 02:02:46.35
>>229
OCamlにはそのものずばり抽象メソッドがあります
アップキャストのためではなく継承時の制約を明示するためでしょう
0233デフォルトの名無しさん2011/08/03(水) 02:04:12.60
>>231
挙動が違うだけならば"違うクラス"を作らなくても良い
そういう話だったのでは？
0234デフォルトの名無しさん2011/08/03(水) 02:25:02.14
>>227
OCamlで似たようなコードを書いてみました
Pythonとほとんど変わらないですが、静的に型安全です

class ['a] price (value:'a) =
object
  method get_value = value
end

let p =
  let x = new price 120
  in let y = object method get_value = x#get_value * 2 end
  in object method get_value = y#get_value + 80 end

let print_price x = print_int x#get_value
let _ = print_price p
0235デフォルトの名無しさん2011/08/03(水) 02:42:02.72
ただ、大規模な開発で型宣言することが有効であるだろうことは否定しません
そのような状況では、型宣言を強制する言語の方が良い可能性はあります
0236デフォルトの名無しさん2011/08/03(水) 03:12:44.96
>>235
OCamlを実用に使っている方？
型推論と実行性能と関数型の利点を併せ持った言語として、昔少し使ったことがあったのだけれど、
型推論は依存型に、実行性能はCとC++に、関数型の利点はHaskellに興味が移った挙句、
業務では使えないし、個人では強力な型システムが開発の助けにならないし、もっとメジャーな言語のほうがライブラリが多いということで、Pythonなどを使うようになってしまった。

ただ、こういった型推論による安全性などがあるということは、もっと知られるべきと思っている。
現場のレベルの人がnominalで安全な言語を指向する割には、OCamlにあるようなパターンマッチや、
プログラム証明には目が向けられていないように思う。

私自身は、型安全性によるプログラムの検証は、設計やテストのやり方に比べればプログラムのごく一部の問題であって、ほとんど品質に影響がないのではないかと思うようになってきた。
0237デフォルトの名無しさん2011/08/03(水) 04:04:20.38
>>223
肝心なことを書き忘れていました

動的言語などがモジュールシステム等で名前空間を分ける一方、
nominalな言語はクラス名がその役割も果たしています
そのような言語で敢えてsubstructualにプログラミングしようとすると
名前空間がフラットになりすぎて問題が起こるかもしれません
あまり詳しくないですが、C++のテンプレートとADLに関する問題も
その一種だと思います

>>236
仕事でOCamlを使わせてもらってます
デフォルトでは正格に書けて、遅延評価したいときはLazyMonadで書いたりと
融通が利きますね。でもHaskellはかっこいいですよね

もちろん品質にはテストが重要だと思います。自分が>>235で型宣言が有効と書いた理由は、
それが他者がコードを読む助けになると思うからです
0238デフォルトの名無しさん2011/08/03(水) 08:55:02.96
>199
うわ〜　はっはっは。　それを無くす為のオブジャクト化&デザパタ。　人間の思考はいくつも同時に考えられないから。
0239デフォルトの名無しさん2011/08/03(水) 09:10:04.81
オブイェークト
0240デフォルトの名無しさん2011/08/03(水) 10:11:17.26
「C言語？あーだめだめ。オブジェクト指向できないじゃん。
計算機は速くなったんだから、もっと抽象化できる言語使おうよ。
Java最強」

「動的言語？デザパタが簡潔に書けるほど抽象化できる構文？
あーだめだめ。抽象化なんてしちゃったらプログラム読み辛いでしょ？
それに実行遅いんだから、もっと速い言語使おうよ。
Java最強」
0241デフォルトの名無しさん2011/08/03(水) 11:26:16.93
Javaなら存在しないメソッドを呼ぶランタイムエラー出る事無いと
思ってるやつがいるけど、Javaのぬるぽはまさにそれ
0242デフォルトの名無しさん2011/08/03(水) 19:07:35.44
JavaサイコーｗｗｗｗJava以外の糞言語使ってるアホはマジ死ねｗｗｗｗｗｗｗｗ
0243デフォルトの名無しさん2011/08/03(水) 19:20:50.82
>>237
頑張れ プロフェッショナル岡村！
0244デフォルトの名無しさん2011/08/03(水) 19:51:34.41
>>242
マルチプラットフォーム以外に魅力感じないんだが。。。
0245デフォルトの名無しさん2011/08/03(水) 21:48:40.18
nominalとsubstructualってどういう意味？
0246デフォルトの名無しさん2011/08/04(木) 00:49:04.43
ルー語はよせ
0247デフォルトの名無しさん2011/08/04(木) 11:43:02.99
>>244
ライブラリや周辺ツールが充実してるとかあるんじゃね？
Oracleのせいでオワコンっぽいけど
0248デフォルトの名無しさん2011/08/04(木) 19:19:43.71
Oracle的には(難解さも含めてモロモロ)最強言語のSQLが有るからJavaはどうでもいいんでしょ。
企業様の命の次に大事なデータ様を大量に抱え込んでるんだから、すげーよな。
0249デフォルトの名無しさん2011/08/04(木) 19:51:58.95
Java SE7 のループ最適化のバグはワロタ
やる気無さ過ぎだろOracle
0250デフォルトの名無しさん2011/08/05(金) 00:09:39.35
>>156
それは計算機言語が felt like を理解するような状況じゃないとだめじゃね？
と、久方ぶりにTRONを見て思う(MCPがfelt like Flinnって言う台詞から)
0251デフォルトの名無しさん2011/08/05(金) 00:15:12.41
ふぇ〜るとらいく　とかルー大柴っぽくて頭が悪そうだな。
まず、日本語の勉強をすることから始めたほうがいいじゃないか？
単語が思いつかないのだろう？
0252デフォルトの名無しさん2011/08/05(金) 00:16:22.93
計算機言語ってなに？
プログラム言語のこと？
0253デフォルトの名無しさん2011/08/05(金) 00:23:33.45
>>250
そいつはJavaフルボッコにされて逃走したよ
もう触れてやるな
0254デフォルトの名無しさん2011/08/05(金) 15:54:04.15
Javaみたいな糞言語を誰がやるかヴォケ
0255デフォルトの名無しさん2011/08/05(金) 16:54:46.35
ま、Javaはこの際置いておくとして。

静的型言語も型推論で簡潔さと柔軟さを確保しつつあるし、
動的型言語も実行速度の問題が改善されつつある。
ユニットテストのフレームワークも大抵の言語にはある。
だから型付けだけで簡単に優劣を語れなくなってきてると思う。

というわけで、将来的に伸びるのはどんな特徴を持った言語だと思う？
0256デフォルトの名無しさん2011/08/05(金) 17:12:56.82
現在メインストリームである言語と高い互換性を持つこと
0257デフォルトの名無しさん2011/08/05(金) 17:41:11.61
それはC++みたいにCとコードレベルで互換性があるってこと？
それともScalaみたいにJavaの資産が使えるってこと？
0258デフォルトの名無しさん2011/08/05(金) 17:58:32.53
両方
0259デフォルトの名無しさん2011/08/05(金) 18:15:42.49
C++はCの資産が使えるしなー
0260デフォルトの名無しさん2011/08/05(金) 18:16:44.96
>>255
いま伸び盛りなのは、JavaVMを使った並行処理が得意な言語という印象がある。
つまり、ClojureとScalaかな。前者は少し火がつきだした程度だけど、後者は
もう火がついてるよね。
個人的にはHaskellに伸びてもらいたい。関数言語系にシフトするとしたら、
JavaVM系次第かもしれないが。
0261デフォルトの名無しさん2011/08/05(金) 18:17:35.43
CやC++と関数言語だったらFFIが定められてたりライブラリがある言語の
ほうが多いから、別に問題はないんだよね。あるのは、人のカズだけ
0262デフォルトの名無しさん2011/08/05(金) 18:18:28.40
ちょっとしたテキスト処理くらいだったら、LLで十分だわな。
0263デフォルトの名無しさん2011/08/05(金) 18:38:31.27
Javaとコードレベルで互換性のある次世代言語ﾃﾞｷﾀﾖｰとか言われても困るわ
0264デフォルトの名無しさん2011/08/05(金) 18:48:49.28
Genericsの中途半端さやラムダ入れるの苦労してるの見ても
Javaとコードレベルで互換性残して発展させるのは無理筋
0265デフォルトの名無しさん2011/08/05(金) 18:49:29.13
F#を忘れてたな。あれはMSの世界だからわかんないけど、伸びてるな。
>>263
いや、オマイらが困っても、時代は動いていくもんだ。
0266デフォルトの名無しさん2011/08/05(金) 18:50:56.67
>>264
C++のSTLみてるとそう思う。自由を得るために複雑になって、泥沼にはいる
典型的な例だと思う。
0267デフォルトの名無しさん2011/08/05(金) 18:59:06.15
だから、20年くらいしたら、javaの人って２１世紀のcobolerと呼ばれるかも。
0268デフォルトの名無しさん2011/08/05(金) 19:00:35.12
もう呼ばれ始めてる
0269デフォルトの名無しさん2011/08/05(金) 19:12:34.25
PHPとJavaはオワコン
0270デフォルトの名無しさん2011/08/05(金) 19:12:39.57
そういう意味ではC言語は安泰だな。
0271デフォルトの名無しさん2011/08/05(金) 20:34:52.49
>>270
言えてる
c単体で使う領域は減ってるけど、他の言語と組み合わせるから、取り敢えず覚えとけって言語の定番だよな
0272デフォルトの名無しさん2011/08/05(金) 21:19:55.38
cやアセンブラは基盤だからなぁ。javaもjavaVMの基盤ではあるけど
0273デフォルトの名無しさん2011/08/06(土) 20:47:05.17
C言語にとって変わる言語はいつ出てくるの？
組み込みの世界では現役過ぎて辛い
0274デフォルトの名無しさん2011/08/06(土) 21:19:17.40
Cがあまりに正しいからだよ。
CgとかOpenCLとかみてもそう思う。
0275デフォルトの名無しさん2011/08/07(日) 07:16:27.11
単に多くのコストが費やされてきただけだろう
特に効率とか、どんだけコンパイラに金と時間と人材が注ぎ込まれたかが9割だと思うし
同じだけ注ぎ込まれてればばpascal、lisp、fortranあたりなら今のCと同じ立場になってただろう
0276デフォルトの名無しさん2011/08/07(日) 09:07:27.52
pascalもlispもfortranもコードの見た目が汚いから普及は無理。
C言語はTシャツに印刷してそのままデザインとして通用するぐらい
見た目が綺麗。
0277デフォルトの名無しさん2011/08/07(日) 09:13:06.57
そりゃC系列の構文に目が慣れてるだけだろう
0278デフォルトの名無しさん2011/08/07(日) 09:24:52.54
そんなことはないと思うよ。
大学で最初にPascalやらされて、その後C言語に移ったときの感動ったら無かったね。
0279デフォルトの名無しさん2011/08/07(日) 09:36:50.66
そりゃお前の感覚だろう
今でもCよかDelphiの方が好きっていう人は結構いるし見た目の好き嫌いは人それぞれだよ
0280デフォルトの名無しさん2011/08/07(日) 10:32:36.77
感覚には感覚で対抗しないと勝てないよ
一般論でうやむやにしてもせいぜい引き分けにしかならないから
0281デフォルトの名無しさん2011/08/07(日) 10:50:51.38
感覚の話したら言ってる人を見るよな

この幼稚な舌足らずなキモさで、こいつの感覚はあてにならない
俺の感覚にあわない
0282デフォルトの名無しさん2011/08/07(日) 11:07:04.97
ばかばっか
0283デフォルトの名無しさん2011/08/07(日) 11:31:40.62
>>281
舌足らずはあんたも同じだろ。
会話に苦手意識ありそう。
0284デフォルトの名無しさん2011/08/07(日) 11:35:05.66
ばっかおめー、Pascal系はDelphiが死亡してユーザ涙目なんだぞ
あんま煽んな、そしてちっとくらい煽られても優しく流せ
0285デフォルトの名無しさん2011/08/07(日) 16:40:41.92
ここってオブジェクト指向プログラミングのスレなの？
設計の話ならドメインモデルとか普通に出てきそうなものだけど
出てないよね？　設計の話題は別？　まあ無視して話すけどｗ

最近ようやくオブジェクト指向設計というものが理解できてきた。
そもそもわかりにくいのは世間で言われている用語がごちゃごちゃ。
そこでまとめてみる。内容を伴っているなら、ツッコミは大歓迎。

一般的にオブジェクト指向による設計が〜という設計の話はビジネスロジックの話。
つまり業務システムをモデリングした時の設計をどうするかという話がメインになっている。
ビジネスロジック部分をオブジェクト指向で設計すると、それはドメインモデルとなる。
業務システムを非ドメインモデルで行うと（よく使われるのが）トランザクションスクリプト(手続き型)となる。

だけどシステムを構成する要素はビジネスロジック部分だけじゃない。
フレームワークやライブラリもある。現在では一般的にフレームワークやライブラリは
オブジェクト指向で設計されている。つまり以下のような構成もありうる

オブジェクト指向言語＋各種ライブラリ（オブジェクト指向）＋フレームワーク（オブジェクト指向）＋ビジネスロジック（手続き型）

実は現在の日本ではこの構成で作られていることが非常に多い。オブジェクト指向で
設計していると思っていたとしてもこうなっている場合が多いし、俺も推奨する。
オブジェクト指向だと、最初から完璧なものを作らないと破綻しやすいので作るのも把握するのも時間がかかる。

だけど困ったこと現在のフレームワークは、ビジネスロジックがオブジェクト指向であることを
前提に作られているものが多い。フレームワークがビジネスロジックを（オブジェクト指向で）作る
仕組みを用意している。たとえばRubyOnRailsのActiveRecordとか。
その仕組みに従って使うとビジネスロジックでオブジェクトがでてくることになる。

オブジェクト指向ビジネスロジックを前提としたフレームワークでトランザクションスクリプトを使うのなら、
そのためやり方（考え方、オブジェクトをデータとメソッドに分離した上でフレームワークを利用する方法）が
必要なのだが残念ながらその情報が少ないから、ちょっと混乱が起きている。
0286デフォルトの名無しさん2011/08/07(日) 16:41:27.39
ドメインモデルとトランザクションスクリプトの違いは
SQLサーバーからデータとをってきたとき、とってきたデータを
そのままただの値としてビジネスロジックで使うか、
そのデータを一旦O/Rマッパーなどでメソッドのついたオブジェクトに
変換してビジネスロジックで使うかの違い。

SQLサーバー・ファイルなどストレージからデータを取ってきたとき、
それはオブジェクトではなくただのデータなんだから、わざわざ
オブジェクトに変換すんなと思う。その値を簡単に加工する関数作って
そのままビジネスロジックで値を使えばいいじゃねぇか。

ということで俺の推奨は

オブジェクト指向言語 ＋ 各種ライブラリ（オブジェクト指向）
＋ フレームワーク（オブジェクト指向） ＋ ビジネスロジック（トランザクションスクリプト・手続き型）

なんだけど、これやると自称賢い人からはオブジェクト指向じゃない的な
言われ方をするから困るよねｗ

よっぽど時間があってとか研究目的でってなら、ビジネスロジックまで
オブジェクト指向設計（ドメインモデル）やればと思うがおすすめはしない。

ビジネスロジック以外はオブジェクト指向なのでその仕組みを理解したり
フレームワーク・ライブラリで足りない部分を補うためには、
オブジェクト指向の知識はどうしても必要。

でもそのオブジェクト指向ってのはフレームワークまでに全部押し込んじゃえって思う。
ビジネスロジック部分は、単純で理解しやすい手続き型のトランザクションスクリプトがいい。

なんてことをいうと、俺はオブジェクト指向否定派になっちゃうわけだｗ
オブジェクト指向設計は適材適所。ビジネスロジック限定の話ではない。
そしてオブジェクト指向設計を適用するのはフレームワークまでにしとけ。
0287デフォルトの名無しさん2011/08/07(日) 16:56:25.83
>>285
StrutsとかいうFrameworkは全然オブジェクト指向型じゃないけどな。
それに追従するFrameworkも然り。使う側の問題でもあるんだろうが、
構造体同然のbeanなんて吐き気がする。
今まともにOO生かせてる機構なんてSwingや.NetのCLI、QtとGTKぐらいだろ。
既存のオブジェクトに、自前で作ったオブジェクトを差し込んで動作を変えられないなら
OOPしているとは言えない。
0288デフォルトの名無しさん2011/08/07(日) 17:23:28.00
>>285
なげえよ馬鹿
0289デフォルトの名無しさん2011/08/07(日) 18:01:32.20
・現在一般的なのは三層アーキテクチャで、BL層が一番下に来るのは手抜き開発です
・フレームワークと言うけど、普通はUIとDBアクセスで別のフレームワークを利用するはず
・BL層で利用する値は下の層で生成された値を使うので、生データと言っても二次元テーブルモデル程度にはラップされてるはず

大方下の層を無視するような真似をして"自称賢い人"に怒られたんじゃないの？
0290デフォルトの名無しさん2011/08/07(日) 18:44:45.69
>>289
Web FrameworkはOOとは別問題だ帰れ。
0291デフォルトの名無しさん2011/08/07(日) 18:46:50.66
え
0292デフォルトの名無しさん2011/08/07(日) 18:56:55.41
> 最近ようやくオブジェクト指向設計というものが理解できてきた。

この語りだしからロクな話題を聞いたことがないなｗ
0293デフォルトの名無しさん2011/08/07(日) 20:49:52.17
要は俺様オナニークラス作るのは止めようって事だろ
それには同意しとく
0294デフォルトの名無しさん2011/08/07(日) 23:07:57.33
>>287
最近JavaBeansを改めて勉強したけど、setter、getter必須とか聞いてはぁ！？って思った
パーツを使い回すためって、そんな構造体的な使い回しに何の意味があるのかさっぱりだ
0295デフォルトの名無しさん2011/08/07(日) 23:31:24.67
>>294
正解だね。ただ、まだそれに気づかせる＆ウザさを与える点でマシ。
C#なんぞはプロパティを文法で用意しちゃってる。
そこらへんがMSらしいというか、C++の臭さを見習ってるというか。
0296デフォルトの名無しさん2011/08/07(日) 23:45:35.31
>>294
setter,getterって本来、GUIの設定を変更するためのBeanって仕組みの為のもので、
GUIに置いてはそれなりに意義は有ったんだがな。Webに関しては、java.bean.*で
手抜き仕様としてるだけで全くのクズ。
0297デフォルトの名無しさん2011/08/08(月) 00:19:05.98
>>295
C++は関係ないだろ。そもそも、C++にget〜とかset〜って
メンバー関数持ったクラスは無いしプロパティも無い。
諸悪の根源はDelphiだな。

setter,getterの一番の問題は、setしたものがget出来なければならない、または、getしたものが
同じプロパティにset出来なければならない(RGBを1つの変数で返すか、3つの変数で返すか選択できる等)。
この2つが暗黙的に強制されてるとこだよ。

コンテナ類は別として、オブジェクトに一度入力された値が、入力されたオブジェクトから
取得できる必要なんて全くない。同じ値が必要なら、入力元のオブジェクトに再度
問い合わせればいいだけの話。問い合わせにコストが掛かるなら、一旦キャッシュになる
オブジェクトを噛ませれば済む。
0298デフォルトの名無しさん2011/08/08(月) 10:49:17.03
そもそもsetter、getterがあるってこと自体おかしい
こんなのオブジェクト指向なんもわかってない証明だと思うんだけど

折角オブジェクト同士の関連を出してわざわざ情報のアクセスを限定して
バグを減らしているのにこんな内部の情報に対してどこからでもアクセスできるような
スッカスカの状態にして一体何がうれしいんだろうか？

こんな構造作った奴ってオブジェクト指向理解してるんだろうか？

イベント（まあ、メンバ関数なんだが）でやりとりするのに
setterはなんのイベントなんだろうか？
getterはなんのイベントなんだろうか？

こんな糞みたいな仕組み作った奴の脳内にはもうオブジェクト指向なんて存在しないに違いない
0299デフォルトの名無しさん2011/08/08(月) 11:56:50.70
>>298
作れるものを限定してバグを減らしたい人もいるが
逆に、今まで作れなかったものを作れるようになりたい人もいる
まあわざわざ型の強い言語を使うなら前者でないとおかしいわな
0300デフォルトの名無しさん2011/08/08(月) 12:02:02.29
オブジェクト指向と手続き型思考は独立していなければならないことが
わかってないと思う。
オブジェクト・手続き型プログラミングには２つのフェーズがある。
一つ目はオブジェクトフェーズ、このフェーズではオブジェクトの性質のみで
操作されるべきで内部の情報などは一切使用してはならない。
もう一つ目が手続き型フェーズ、このフェーズではオブジェクトの性質は一切扱えず
オブジェクトの内部データのみ操作できる。
この二つの操作は完全に分けられるべきで一つのソースファイルにこの二つが共存することは
絶対にあってはいけないことなのだ。
0301デフォルトの名無しさん2011/08/08(月) 12:14:07.39
>>299
また、void*か？
死ねよ
そんなの誰もやっていいっていってねぇんだよ
0302デフォルトの名無しさん2011/08/08(月) 13:11:45.15
>>299
バグ云々の問題じゃない。
拡張性が下がるんだよ。
setしたものとgetしたものが同じじゃないと
いけないから
0303デフォルトの名無しさん2011/08/08(月) 14:38:13.66
他のメソッドに足を引っ張られて拡張性が下がるってことは
メソッドが1つだけのインターフェースを定義しまくればいいんだよな
0304デフォルトの名無しさん2011/08/08(月) 14:43:32.15
>>303
それって１つの変数がたくさんの方法でアクセスされてるってことだから普通に複雑じゃない？
0305デフォルトの名無しさん2011/08/08(月) 15:14:31.20
全部を公開する必要は無いし
setterとgetterのどちらか一方だけ用意してもいい
一体何が問題なんだ？
0306デフォルトの名無しさん2011/08/08(月) 15:22:27.34
>>305
イベントじゃないところ
関連として仕様書にかけない
0307デフォルトの名無しさん2011/08/08(月) 15:26:07.42
イベントの定義は？
なんで仕様書に書けないの？書けば？
0308デフォルトの名無しさん2011/08/08(月) 15:29:38.28
別の用途で２箇所で使われるとすでにイベントの意味ですら間違ってる
0309デフォルトの名無しさん2011/08/08(月) 15:32:13.14
別の用途って何？意味不明なんですけど
それにイベントの定義は？
0310デフォルトの名無しさん2011/08/08(月) 15:33:10.80
>>309
そりゃオブジェクト指向の入門書でも読んでよ
なんで俺が君にわざわざ教えてあげないといけないの？
0311デフォルトの名無しさん2011/08/08(月) 15:33:56.69
ぷーくすくすwww
こうやって逃げるやつ居るよねwww
0312デフォルトの名無しさん2011/08/08(月) 15:35:19.00
>>311
いいよ
じゃあ、君なりにぐぐってみて一番最初にあたったオブジェクト指向のイベントの定義でいい
これで逃げてないよね？

ほらさっさとかかってこいよｗ
オブジェクト指向理解できてないんだろ？ｗ
逃げないでよｗ
0313デフォルトの名無しさん2011/08/08(月) 15:37:09.07
は？イベントって言い出したのお前だぜ？
0314デフォルトの名無しさん2011/08/08(月) 15:42:11.95
>>313
だからオブジェクト指向にイベントって言葉あるだろ？
これは共通知識なんだよ
お前は四則演算の「＋」記号ってなんですか？
って質問してるから
俺は「そんな面倒臭いことから説明するのはいやだ」って話だろ

まあ、こういう嫌がらせをお前はしてるわけよ
http://icopipe.yaruo.info/wp-content/uploads/2010/05/res0288.jpeg

0315デフォルトの名無しさん2011/08/08(月) 15:44:03.01
なんだアニオタか・・・
まともに相手してそんした
0316デフォルトの名無しさん2011/08/08(月) 15:44:15.75
イベントって言葉自体を知らないのであれば

勉強してねｗ

で終了なので一連のレスはみなかったことにしていいぜ
そうでないなら俺はお前の認識するイベントでおｋ
0317デフォルトの名無しさん2011/08/08(月) 15:44:47.72
OOPならイベント=メッセージングじゃねーの？違うの？
0318デフォルトの名無しさん2011/08/08(月) 15:46:41.76
>>314
用語についてのリファレンス貼る手間は惜しむのに
漫画のリンク貼る手間は惜しまないとかキメェwww
0319デフォルトの名無しさん2011/08/08(月) 15:48:04.76
>>317
なんでもかまわない
すきなイベントの定義があったらリンクでも貼ってくれ

>>318
いいじゃん
お前の土俵で戦ってやるっていってるんだから
自分に都合のいいの選べよｗ
0320デフォルトの名無しさん2011/08/08(月) 15:51:35.91
逃げちゃった？ｗ
0321デフォルトの名無しさん2011/08/08(月) 15:53:25.46
「すきなイベントの定義があったらリンクでも貼ってくれ（キリッ」

言い出しっぺのお前が貼れよwww
0322デフォルトの名無しさん2011/08/08(月) 15:53:27.56
純粋オブジェクト指向においてはオブジェクトとその性質以外のものは
存在しない。
すなわちイベントとはある性質を持つオブジェクトに他ならないのである。
0323デフォルトの名無しさん2011/08/08(月) 15:56:29.33
>>319
イベント=メッセージングだとsetter, getterもイベントになるが
それでいいのか？
0324デフォルトの名無しさん2011/08/08(月) 16:23:59.67
>>323
いいよ
0325デフォルトの名無しさん2011/08/08(月) 16:27:23.08
>>314
数学的には「+」ひとつで色んな使われ方をするんだがな
お前の知ってる+だけが+じゃないんだぜ、実はいくつか定義がある
1 + 1 = 0 だって数学の分野によっては間違ってないんだぜ
0326デフォルトの名無しさん2011/08/08(月) 16:28:39.41
仮にその定義だったとして、setterとgetterのどちらか一方だけだと、何故仕様書に書けないんだ？
0327デフォルトの名無しさん2011/08/08(月) 16:29:44.48
+はあくまでただの二項演算子でしかないのか
モノイド、いやマグマですら限定しすぎなのやな・・・
0328デフォルトの名無しさん2011/08/08(月) 16:32:11.24
>>325
まあ、仮にそういう分野があったとしてもお前とは会話できないからｗ
住みやすいところへ勝手に行ってくれやｗ

>>326
いや、書く気があるならかまわんよ
でも書かないでしょ？ｗ
書いてるならいいよｗ

でも書く気がまるでないからsetter、getterなんでしょ？
だって別の自由に読んじゃえるメッセージ、それでいて仕様が変わらないっておかしいものねぇ
結果としてsetter、getterを実装してしまった部分のオブジェクト同士の関連ってのは
見えなくなるんじゃないか？
って運用上の不具合があるよね

ないっていうならこれ以上はあんまり会話はできねぇな
君の職場と俺の職場は違うんだね終了って話
0329デフォルトの名無しさん2011/08/08(月) 16:36:30.07
>>328
いや、書く気があるかどうかとsetter、getterを使うかどうかは完全に別問題だろ
読み取り専用の属性なんて腐るほど存在すると思うのだが…
0330デフォルトの名無しさん2011/08/08(月) 16:40:50.00
>>329
でも面倒臭いから
別に必要なくてもsetter、getterで書いちゃうんでしょ？
呼ばれなくても作っちゃうでしょ？
無能だから
0331デフォルトの名無しさん2011/08/08(月) 16:41:05.67
1 + 1 = 0 になる数学の分野って何ですか？
そんなのが本当にあるのなら教えてくださいよ？
無くていえないとか？
0332デフォルトの名無しさん2011/08/08(月) 16:43:12.73
>>331

おれは >>314 じゃないけど・・・

http://icopipe.yaruo.info/wp-content/uploads/2010/05/res0288.jpeg
0333デフォルトの名無しさん2011/08/08(月) 16:43:55.73
1ビット加算器とか
0334デフォルトの名無しさん2011/08/08(月) 16:56:48.17
Wikipediaでプラス記号見るだけでも別の用法が出て来るわな
0335デフォルトの名無しさん2011/08/08(月) 16:56:53.79
メンバ変数privateにしても、全部setter/getterで公開したら
カプセル化の意味ねーだろ的な批判は当然ある

で、それをアホが「setter/getterは絶対ダメ」って
拡大解釈しちゃったんだね
0336デフォルトの名無しさん2011/08/08(月) 17:05:44.13
+はただの二項演算だけど組み込み型、標準ライブラリで用いられる意味との整合は考えるべきだろうな
一般的に四則演算としての意味(数値型に対する和)を期待するなら体の公理を持ってくるのが妥当だけれども、
例えば文字の連結にも+が使われているような場合、それよか少し弱めてモノイドとしての意味ぐらいでも大丈夫だと思う
でもそれ以上に弱めるのは大抵碌な結果にならんだろうな
0337デフォルトの名無しさん2011/08/08(月) 17:08:50.75
モノイドに+を使うのは今でも違和感あるけど
文字列連結に使っちゃってる言語多いよなぁ
0338デフォルトの名無しさん2011/08/08(月) 19:01:14.71
>>329
だったら読み取り専用のコンテナでいいじゃん。
間違ったキーを渡す可能性があるっていうなら、constantな
オブジェクトや列挙型をキーにすればいいだけだし。
速度がとか言い出すならそもそもOO Pなんてやめっちまえ。
0339デフォルトの名無しさん2011/08/08(月) 19:09:53.97
別の方法でも実現できるってのは
setter/getterがダメな理由になってないぜ
0340デフォルトの名無しさん2011/08/08(月) 19:34:36.15
Bean的なものにおけるgetterとsetterは、
内部の整合性を保つためにあるわけで。
例えば、文字列クラスなんかだと、
保持してる文字列とその長さのメンバ変数とで
食い違いが出ないようにしている。
だから、外部との関係とかイベントとかメッセージングとか、
そういうのとは初めから無縁。
関係ない話題で盛り上がってるってわけだ。

何でOOPの話題ではこんなに話が食い違いがちになるかというと、
JavaやC++などのメジャーなOOPでは、
「多態」も「カプセル化」も「差分プログラミング」も、
全てクラスという仕組みでやっちゃってるから。
違う目的でも、手段が同じになるから、話が食い違う。
0341デフォルトの名無しさん2011/08/08(月) 19:44:16.40
格安バスツアーに出かけたとしよう。
旅の目的は人それぞれ。
息抜きだったり、自己啓発だったり、誰かの付き添いで嫌々だったり、
観光名所めぐりマニアだったり、ご当地食いしん坊だったり。
でも、手段はバスツアーで、皆同じ。
それぞれ違う目的を持った人たちが、バス車内に一堂に会してしまう。
そんで、暇なものだから「バスツアーとは何か」について熱く交わしているのが
このスレの状況。
探偵物なんかのドラマで2時間持たせようとするときなんかに良く使われる設定だね。
話が纏まらないから2時間引っ張れる。スレも伸びるね。
0342デフォルトの名無しさん2011/08/08(月) 19:50:34.05
たまたま話のきっかけだっただけで
Bean的setterとgetterに話題を限定する理由が無い。
ここはJavaBeansのスレじゃないからな。
0343デフォルトの名無しさん2011/08/08(月) 19:59:15.52
結局のところ、「多態」も「カプセル化」も「差分プログラミング」も
それぞれ単体では難しい話ではないし、使いどころを間違わなければ
とても便利な機能でしょ。
ただ問題は、メジャーなOOPLでは、
これらの機能は全てクラス設計で行うことになっちゃってる。
一堂に会しちゃってる。
だから、クラス設計の話をしだすと、途端に迷子になる。
そのほかにも、差分プログラミングのつもりでクラス設計していたつもりが、
手段が同じものだから、いつの間にやら必要の無い多態のことも頭に浮かんできたりして、
使いどころを誤ったり。これは初心者にありがちだね。

「多態」と「カプセル化」と「差分プログラミング」のそれぞれに
専用の構文を用意すべきだっただろうね。
全部が全部、クラス単位だから、話が分からなくなるし、
何でもかんでもクラス単位なのも、それはそれで面倒だ。
C言語なんかで良くやった、ソースファイル単位のカプセル化とか便利だったしね。
0344デフォルトの名無しさん2011/08/08(月) 20:04:18.14
>>342
まさにそういうことだよ。
ちょっとしたきっかけでこんなに話が派生してしまうのは、
全ての機能がクラス機構経由になってるから。
クラスの仕組みがハブ空港になって、そっから関係ない話に飛びまくる。
気がつけば沖縄と北海道で会話してたりする。
しかもハブ空港では一緒だったものだから、
最初から目的地が違っていたことや、
既に離れ離れになってることに気がつかないでいる。
0345デフォルトの名無しさん2011/08/08(月) 20:04:24.09
>>338
読み取り専用のコンテナ？一体どういうことを想定してるの？速度とか全然意図してないことを言われても…
もしかして連想配列でいいとか考えてるってこと？getter/setter以外のメソッドの存在は無視なの？
0346デフォルトの名無しさん2011/08/08(月) 20:29:46.84
>>345
存在しても構わんよ。でも、それは問題じゃない。
Mapにget(〜)以外存在しないよう考えろ的なことは思ってないぞ。
ただ、複数あるメソッドのうちgetName()的なものはget(Key.name)で
取れるようにしとけばいいだろって話。

メンバーが増えても、元クラスにgetXxxx、setXxxxを追加する必要はなくなるし、
コンテナとだって互換性を持つことができる。
けどどうだい、getName()なんて固定化したらそれを利用した拡張が効かなくなる。
たとえget(Key.xxxx)を持つMapを利用するオブジェクトがあっても、
素直にそのオブジェクトを再利用できない。
0347デフォルトの名無しさん2011/08/08(月) 20:44:21.05
>>340
beanのsetter/getterとは違うだろ。
それはStrutsとかを正当化させようとしてる言い訳だ。

beanはそもそもRAD用のjava.beanパッケージ。
JSPなんかは、構造体を実現するためにbeanを乱用してるだけ。
本来のbeanは、setXxxxを実行すると画面要素がその時点で変わる。
そのための存在。
大体Webアプリ作るときにsetterで例外出すようにして捗るようになったかい？
0348デフォルトの名無しさん2011/08/08(月) 20:57:49.10
ずいぶんつまんないことにこだわるんだなｗ

設計なんて利便性だけで考えればいいのにｗ
0349デフォルトの名無しさん2011/08/08(月) 20:58:26.83
>>346
うーん、言いたいことは解らんでもないが、それこそ面倒臭がりの発想じゃね？
要は属性を全部ひとつの連想配列に詰めちゃって、全てobj.get(key)の形式でアクセスするってことなんだろうけど
キーひとつひとつに属性へのアクセス方法は違いうるんだから、そんなことしちゃマズいでしょ。
0350デフォルトの名無しさん2011/08/08(月) 21:01:16.21
>>346
それgetの戻り値で取ってこれるオブジェクトが
全部同じ型じゃないと成り立たないよね？
Javaでそういうのはちょっと……
0351デフォルトの名無しさん2011/08/08(月) 21:13:26.21
折角の型情報を捨てよう捨てようとする人々がいる。
0352デフォルトの名無しさん2011/08/08(月) 21:13:59.39
型自体はJavaとC++に関してはオーバーロードで済むよ。
String get(StringKey)
Int get(IntKey)
型の名前はともかくとしてこんな感じ。
get(Key.NAME);//String型
get(Key.X);//int型
0353デフォルトの名無しさん2011/08/08(月) 21:18:29.26
すぐににっちもさっちもいかなくなるぞ、それ
0354デフォルトの名無しさん2011/08/08(月) 21:26:55.62
大丈夫2万行超えるようなコードでも困ったことはないから。
まぁ、WindowsのWM_〜とかと似たようなもん。
Point2Dがint型一個とかあり得ないし、Nameが文字列以外になるってのも
まず無いからその辺で困ることはない。どのキーをどのクラスに持たせるか若干悩むぐらい。
C++だとグローバルのconstで良いんだけどね。
0355デフォルトの名無しさん2011/08/08(月) 21:28:08.88
たかが2万行程度のコードなら普通にsetXXX, getXXXってやったって
困る事は無いだろうよ
0356デフォルトの名無しさん2011/08/08(月) 21:34:38.25
そういう実装も可能ってのは分かったから、メリットは何？
ただの縛りプレイでしょ？
0357デフォルトの名無しさん2011/08/08(月) 21:38:49.31
縛り？こっちの方が遥かに楽だけど？

他のインターフェースとの親和性、
既存のオブジェクトを変更しなくて済むことによる拡張性
get,setから識別名が独立する事によるメタ操作のしやすさ。
0358デフォルトの名無しさん2011/08/08(月) 21:52:14.69
同じ戻り値、引数の組み合わせが複数あったらどうすんの？
0359デフォルトの名無しさん2011/08/08(月) 21:52:40.02
>>357
さして親和性も拡張性も感じられないんだよなぁ…具体的にどんな風に拡張されたり、親和性が発揮されるのかが解らない。
それよりも色々と危険な操作が多そうで、そっちのほうが心配になる。
0360デフォルトの名無しさん2011/08/08(月) 22:02:00.27
あ、>>358は型のことね
0361デフォルトの名無しさん2011/08/08(月) 22:03:28.16
>>335
この主張に限ってはsetter、getterは絶対ダメでいいだろ
だって折角仕様書書いてもここには明記されてませんがsetter、getterで
記述のないクラスにもアクセスしていますなんて意味ねーだろ
担当者呼び出して作り直してレベルじゃん

イベントに限定してデータの入出力（外部のクラスへという意味）をイベントだけに限定したからこそ
イベントの記述に意味があるんでしょうが
0362デフォルトの名無しさん2011/08/08(月) 22:06:43.08
元の主張がなんなのかよく分からんが、setter、/getter使ってますって書きゃいいじゃん
0363デフォルトの名無しさん2011/08/08(月) 22:08:44.48
ダメですよ使っちゃ
0364デフォルトの名無しさん2011/08/08(月) 22:10:58.58
>>361
だから、なんでsetter,getterに限って仕様書に書かねーんだよ
入出力のイベントとして書けばいいだろ
それとも名前が気に入らんのか？sendとrecvとかなら納得するか？
0365デフォルトの名無しさん2011/08/08(月) 22:12:16.55
>>361
上半分はsetter、getterに限った話じゃなくね？

下はちょっとなに言ってるかわかんないです
0366デフォルトの名無しさん2011/08/08(月) 22:13:16.71
>>364
イベントＡと同じことがsetter、getterを駆使してイベントＡとまったく同じことができちゃうと・・・
そういうのもなくしたいからこそのイベントなのに意味ないじゃん
0367デフォルトの名無しさん2011/08/08(月) 22:14:41.52
イベント、という用語について合意は取れてるのか？ｗ
0368デフォルトの名無しさん2011/08/08(月) 22:14:41.73
>>359
これで危険というならMapも使えなくなるぞ。
親和性ってのは
Map<Key,String> map = new MapKeyStringAdapter( さっきのオブジェクト );
map.get( Key.NAME );
こういう感じ。1段噛ますけどKey.NAMEってのがそのまま渡せる。
今までMapを取っていて、ジェネリクスの型が不定だったオブジェクトはそのまま再利用できるようになる。
0369デフォルトの名無しさん2011/08/08(月) 22:16:47.05
>>365
だから見る人はこのクラスが何やってるのか？ってのが知りたいわけよ
その何やってるのか？って部分は仮にsetterやgetterをクラスから排除した場合は
イベントの一覧さえみればすべてわかるんだよな？

それができなくなっちゃうのがsetterとgetterという害悪

ってか、イベントのこのメリットが理解できなくてよくオブジェクト指向理解できてるつもりでいるなお前
なんていうの？アクセスさせないことでの利便性的視点が全然育ってねーのな
0370デフォルトの名無しさん2011/08/08(月) 22:18:31.22
でもKey.NAMEが存在しないメンバを指さないようにするには
列挙型とか使うんでしょう？
結局は列挙型に識別子が移っただけですよね？
それにgetやset内部でKeyで分岐するコードは自分で書かなきゃだし、
そこで間違えてもコンパイラはエラー出さないね。
0371デフォルトの名無しさん2011/08/08(月) 22:20:41.61
>>369
>>367
0372デフォルトの名無しさん2011/08/08(月) 22:21:58.64
>312
> じゃあ、君なりにぐぐってみて一番最初にあたったオブジェクト指向のイベントの定義でいい

つまり、イベントの定義はなんでもいいらしい
0373デフォルトの名無しさん2011/08/08(月) 22:24:25.11
>>369
全部のメンバ変数にget,setつける前提で話してんの？
0374デフォルトの名無しさん2011/08/08(月) 22:24:32.86
>>369
定義されてない"イベント"で同じ情報を使いたい場合はどうすんの？
極端な話int.addTo(int)って定義しかなければ掛け算は出来ないの？
0375デフォルトの名無しさん2011/08/08(月) 22:25:28.00
コマンドライン引数に基づいて、与えられたシェルコマンドを指定回数実行し、
ベンチの結果を出力する簡単なコードなんだがsetter/getter派がこういうコード見たら相当乏してくるんだろうな・・・。
〜Optionというクラスのオブジェクトに基づいて動作を決めてるんで、表面上のオブジェクト間のやりとりは消す事が可能だ。

List<String>
        parameter = new java.util.LinkedList<String>();
ExecuteOption
        command = new ExecuteOption( parameter );
RepeatOption<Object>
        commandRepeat = new RepeatOption<Object>( new BenchiExecute<Object>( command ), 1 );
HelpOption
        help = new HelpOption();

Map<Opt.Key,Opt.Option>
        options = new java.util.TreeMap<Opt.Key,Opt.Option>();

options.put( help.keyTell( "c", "command" ), new EchoOptionAdapter( command ) );
options.put( help.keyTell( "r", "repeat" ), new EchoOptionAdapter( new Opt.IntOptionAdapter( commandRepeat ) ) );
options.put( help.keyTell( "h", "help" ), help );

Arg.Argument
        argument = new Arg.GOArgument( java.util.Arrays.asList( args ) );

try
{
        argument.parseTo( parameter, new Opt.OptionMapAdapter( options ) );
        commandRepeat.call();
}
・・・略・・・
0376デフォルトの名無しさん2011/08/08(月) 22:25:43.16
>>372
じゃあおれはC#の宣言元 (パブリッシャ クラス) のクラスまたは
構造体内でしか呼び出せない特殊なマルチキャスト デリゲートを想定する。
0377デフォルトの名無しさん2011/08/08(月) 22:26:42.27
やばい、今日はまともじゃない。
変体連想配列野郎とイベント野郎に全部持ってかれてる。
OOPってやっぱり頭おかしくなるのかな。
0378デフォルトの名無しさん2011/08/08(月) 22:29:05.31
>>377
OOPがらみで香ばしくならなかった展開を見たことが無い。
0379デフォルトの名無しさん2011/08/08(月) 22:30:01.23
>>374
メンバ変数の話をしてるときに定義されてないイベントでって言われても
イベントなかったらオブジェクトの処理はどこに書くの？
0380デフォルトの名無しさん2011/08/08(月) 22:30:58.06
>>357
ま、楽っちゃ楽だわな。

DB のカラムを全て文字型にしておくみたいな、
いかにも土方的な発想で。

折角 Java を使うのだから、静的な言語の利点というものを
よくよく考えてみるべきだね。
特に、速度よりも安全性という観点で。
0381デフォルトの名無しさん2011/08/08(月) 22:34:34.84
>>370
別にコンパイルエラーは重要じゃないよ。
大体、Swingでも整数つかっておんなじことやってるし。
さらに言えば、Swingなんかの整数と違って継承が使えるから
適用範囲の調節もある程度はできるし。

まぁ、この1解決策は引っ張る話じゃないけど。
問題は、拡張性のないsetter/getterの無能さだし。
0382デフォルトの名無しさん2011/08/08(月) 22:37:45.71
>>380
ふ〜んじゃ、エリートさんはsetter/getterを駆使することでどんな素晴らしい生産性を生み出してんだい？
タダの型安全？ちゃんと実装の切り替えぐらいできてるんでしょ。
0383デフォルトの名無しさん2011/08/08(月) 22:39:41.07
別にsetter/getterだって、仮想関数で書いときゃ多態ぐらいできるだろうよ。
0384デフォルトの名無しさん2011/08/08(月) 22:41:57.36
雪駄、下駄用語派の意見をもっと聞きたいな。
今まで上がってる具体的なメリットがしょうもないもんばっかだし。
0385デフォルトの名無しさん2011/08/08(月) 22:43:50.56
>>376
俺もそれ想定したわ
0386デフォルトの名無しさん2011/08/08(月) 22:44:00.99
拡張性のないsetter/getterの無能さとやらが問題なんじゃなくて、
値を入れて出す、持たせとく、という、構造体的な設計が問題なんじゃないか？
もっと他にやりようがあるのに、やっぱり構造体的なつくりになって、
個々のデータのことをいつまでのみんなが心配してるような状態。
カプセル化がうまく働いてない、隠蔽がイマイチ進んでない状態。

もちろん、構造体的なクラスはすべて間違っている、などというつもりは現時点ではないが。
0387デフォルトの名無しさん2011/08/08(月) 22:44:19.16
>>383
無意味に実装変えられるのと、効果のある実装の切り替えができるのじゃ全く意味が違うぞ。
役に立実装の切り替えつっつっても、結局GUIのbeanぐらいだろ。
0388デフォルトの名無しさん2011/08/08(月) 22:45:35.42
テンプレートメソッドパターンもget(key)で実装してんの？
0389デフォルトの名無しさん2011/08/08(月) 22:45:41.63
カプセル化を働かせる為にコードを書いてる訳じゃないから、その場の判断で
柔軟に対処したら良いと思うわ
0390デフォルトの名無しさん2011/08/08(月) 22:45:45.83
そーいや>>196はおもくそgetter使っとるな
0391デフォルトの名無しさん2011/08/08(月) 22:46:30.54
オブジェクト間のやりとりはすべてイベントだけにすればいいんだよ
0392デフォルトの名無しさん2011/08/08(月) 22:47:33.48
>>391
釣りなのかマジなのか分からんが、
段々面白くなって来たwww
0393デフォルトの名無しさん2011/08/08(月) 22:48:28.38
>>387
GUIだって言ってもSwingなんて、タイトルはタイトルだし、幅は幅だし、
別に実装が変わってるわけじゃないけどな。幅やらタイトルの値を参照している
描写メソッドの実装が変わったのと、他のメンバーが増えただけ。
getter/setterは何も変わってない。
0394デフォルトの名無しさん2011/08/08(月) 22:48:34.57
BezierPath クラスのメンバに strokeColor という変数があったとして、
setStrokeColor() メソッドをコールするのはイベントじゃないの?
0395デフォルトの名無しさん2011/08/08(月) 22:50:16.74
もうカオスだ。ここまで荒れたことないぞ？
変体連想配列の人とコミュ障俺用語イベントの人、相当やばいと思うぞ。
ワケワカランことばかりいってないで、早く現実世界に復帰した方が良い。
0396デフォルトの名無しさん2011/08/08(月) 22:51:32.85
今日はろくに動きもしない疑似コード(笑)が少ないからマシな方だよ
0397デフォルトの名無しさん2011/08/08(月) 22:52:16.63
>>395
変体連想配列のほうはたぶん、誰もが一度は通るみちというか、
それで便利になるだろうと夢想したり実践したりするだろうと思うが、
イベントの人のほうは、イベントの定義からして見えてこないｗ
0398デフォルトの名無しさん2011/08/08(月) 22:52:24.80
>>394
普通に考えて、setter/getterもイベントだよな。
その辺がもう意味不明なんだよ。やべぇ。
0399デフォルトの名無しさん2011/08/08(月) 22:54:17.50
本人以外までイベントをメソッドの意味で使うと混乱するからやめろw
0400デフォルトの名無しさん2011/08/08(月) 22:54:21.33
変態連想配列ねぇ・・・。
別にこっちの話はいいよ。こっちは、
これで上手くいってるからさ。
それはそうと、そこまで人を點すんだからgetterとsetterで
再利用性を高め生産性を向上させる方法を教えておくれよ。
君等のほうが優秀なんだろ。
0401デフォルトの名無しさん2011/08/08(月) 22:57:02.64
>>398
でも大抵記述ないよね
0402デフォルトの名無しさん2011/08/08(月) 22:57:36.96
>>400
いや、連想配列アプローチで疑問なのは「何でそれをJavaで？」の一点かと
なんというか動的型のセンスなんだよね
Java使う人ってそういうコード嫌いなんだと思ってたよ
0403デフォルトの名無しさん2011/08/08(月) 22:59:23.56
なかなかsetとgetをしこしこ書いて満足してる人の意見が出ないなぁ。
雪駄下駄派自体は居ないのか。
0404デフォルトの名無しさん2011/08/08(月) 23:00:43.22
unk = nko.getUnko();
unk++;
nko.setUnko(unk);

糞コードだよね？
0405デフォルトの名無しさん2011/08/08(月) 23:03:01.52
map.put(key, new Integer(((Integer)map.get(key)).intValue() + 1));
0406デフォルトの名無しさん2011/08/08(月) 23:04:05.69
>>403
setter / getter 書いてるよ
主に MVC の model の部分で使ってる
データの変更時に setter の中で undo の登録したりしてる

それが駄目だと思う人は、別の書き方で書いたら良いんじゃない
0407デフォルトの名無しさん2011/08/08(月) 23:04:14.94
>>405
そんなのコメントがなきゃ見た目なにやってるのかわからないコードがむき出しになってる時点で糞コード
0408デフォルトの名無しさん2011/08/08(月) 23:04:27.53
>>401
なんだ、ただ値を渡してるだけのアクセサを批判したい人だったのか
0409デフォルトの名無しさん2011/08/08(月) 23:05:49.36
>>402
まぁ、Java専属じゃなからね。
一番好きなのはSmalltalkだし、仕事じゃC++やらPL/SQLやら
Perlやら色々使ってる。まぁ、そもそもsetとかgetの類は
あんまり使わない。せいぜいバカみたいなStrutsで使ってるぐらいだし。
0410デフォルトの名無しさん2011/08/08(月) 23:07:24.16
>>405
キタネェな
こういうの関数でラップしろよ
0411デフォルトの名無しさん2011/08/08(月) 23:07:40.89
>>404
自由に数値をいじってもらって構わないクラスなら特に問題ない。
インクリメントするという作業が必要なクラスなら設計が悪い。
0412デフォルトの名無しさん2011/08/08(月) 23:10:47.49
>>410
そうだろうか？　これはJavaでこういうインクリメントするときの煩雑さを示したわけだが、
かといってこれをこれ以上ケアしてもしょーもないと思うが…。
あえて言うなら横に // インクリメント と書き放ってれば十分と思うが…。
0413デフォルトの名無しさん2011/08/08(月) 23:11:17.68
別にaddUnkoもあって
setUnko、getUnko、addUnkoでうんこを突きまくります
0414デフォルトの名無しさん2011/08/08(月) 23:12:37.95
>>406
MVCがGUIかWebの方かで話は変わるけど、
GUIの方だったら、setter/getterで拡張しづらいと感じ無かった？
>>375　にさオプションを拡張する例がでてるけど、
あんな感じで新しいオブジェクトを既存のモデルに
組み込もうとすると、getterとsetterが新しいオブジェクトとの
性質の不一致で邪魔に感じたりしなかった？
0415デフォルトの名無しさん2011/08/08(月) 23:13:42.47
>>412
こういうキタネェのはラップするって昔から決まってるんだよ
mapとかうすぎたねぇものみせるんじゃねぇ
てめーがmapで何が表現してーのかそれがクラス名になるんだよハゲ
0416デフォルトの名無しさん2011/08/08(月) 23:15:04.04
>>413
いや、だからね、何で見せなくてもいい変数までアクセサつける前提なの？
0417デフォルトの名無しさん2011/08/08(月) 23:16:21.01
>>414
setter/getterも所詮インターフェースのひとつに過ぎないし、
拡張のしづらさはJavaのインターフェース一般の話じゃないのかね？
0418デフォルトの名無しさん2011/08/08(月) 23:16:58.46
>>415
そうかなぁ？　ラップしないほうがいい例の一つだと思うけど。
マップ。ゲットして1足してプット。これをラップしだすと大変じゃね？
0419デフォルトの名無しさん2011/08/08(月) 23:17:53.52
>>418
大変じゃなかったらやってもいいと思ってるんでしょ？
あくまでも大変だから
0420デフォルトの名無しさん2011/08/08(月) 23:19:46.62
>>418
足し算するだけなのにキャストとnewが汚らしい
0421デフォルトの名無しさん2011/08/08(月) 23:20:34.33
>>419
クラス海草がまた生まれちゃう。
また名前を考えなきゃいけない。
ホントに再利用される単位か？

って点で大変だわな。
気軽にクソクラスを一度つくっちゃうと、
全体がそれに引っ張られ続けるから。
0422デフォルトの名無しさん2011/08/08(月) 23:21:40.35
それよかmapが何を体現してるものなのかコメント頼みになるところがいただけないね
stl系使うときは使用者が何考えてるのかわからないから必ずクラスでカバーしてもらうよ俺の派遣先の場合
0423デフォルトの名無しさん2011/08/08(月) 23:22:07.28
変態連想配列の話からただの連想配列の話になってる
0424デフォルトの名無しさん2011/08/08(月) 23:24:48.15
>>405
内部でそれをやってても別に文句はないけど
外に見せるのはちょっと、利用者に実装を意識させすぎ
0425デフォルトの名無しさん2011/08/08(月) 23:24:53.29
>>423
普通の連想配列の話になるととたんに速度が落ちたね。
0426デフォルトの名無しさん2011/08/08(月) 23:27:07.83
>>426
だってつまらないんだもん
0427デフォルトの名無しさん2011/08/08(月) 23:28:09.90
ワロタｗ
0428デフォルトの名無しさん2011/08/08(月) 23:29:23.56
はい、スタックオーバーフロー入りました。
0429デフォルトの名無しさん2011/08/08(月) 23:31:48.63
>>417
そうでもないよ。setと書いて1要素づつ値を設定するのと、
changeやら動詞を書いて複数の値を与えるんじゃタイミングとか結構影響が違うよ。
いい例じゃないけどsetStartとsetEndなんてのより、changeBand( start, end )の方が、
startからendまでの間をchangeが呼ばれたタイミングでどうやって処理するか、
オブジェクトに任せやすい。無視するって手もオブジェクトによってはありだしね。
0430デフォルトの名無しさん2011/08/08(月) 23:36:54.77
>>429
setStartAndEndってsetterでもいいじゃん。
0431デフォルトの名無しさん2011/08/08(月) 23:41:57.11
changeBand -> setBand
0432デフォルトの名無しさん2011/08/08(月) 23:48:16.03
>>430-431
getは、そこに存在しないけどね。
getが一切存在しないことが当たり前で、
setだらけって言うならそれでいいかも。
そうすると、まぁ言葉遊びだね。もはや名前に
気を使う必要が無くなる。moveもsetMoveだし
addもsetAddだし。divもsetDivだし。
0433デフォルトの名無しさん2011/08/08(月) 23:51:19.40
そもそもsetter/getterの対象にならんような例を出すのが悪い
0434デフォルトの名無しさん2011/08/08(月) 23:57:17.22
>>433
そう？じゃGUI MVCのオブジェクト間でsetter/getterを使う例を教えてよ。
0435デフォルトの名無しさん2011/08/08(月) 23:57:20.42
setStart/setEndが主でchangeBandが従か、その逆かで話は変わる

setStart(int start){changeBand(start, getEnd());}なら最初からchangeBandを公開すべきだし、
changeBandが内部でsetStart/setEndの呼び出し順の条件分岐や排他制御してるんなら、定型処理をまとめた便利機能って位置づけだよね
0436デフォルトの名無しさん2011/08/08(月) 23:58:59.48
>>434
>>433じゃないが、とりあえず位置情報
0437デフォルトの名無しさん2011/08/08(月) 23:59:32.28
ばかばっか
0438デフォルトの名無しさん2011/08/08(月) 23:59:35.50
>>432
>そうすると、まぁ言葉遊びだね。

まさにその通りなんじゃないの？
だから皆不思議がってたんじゃないの？
整合性を崩すようなsetter/getterはダメなんだけど、
でもそんなのは、setter/getterに限ったことではない訳で。
「整合性を崩すようなメソッドはダメだよねぇ」
「そうだねー」
で終わってた話でしょ。
0439デフォルトの名無しさん2011/08/09(火) 00:00:12.67
setter/getterでmutableなオブジェクトをやり取りするのは鬼畜
インターフェースを通さず内部を弄れることになるから
immutableなオブジェクトならどうでもいい
0440デフォルトの名無しさん2011/08/09(火) 00:06:53.00
イベントってイベントドリブンの用語でOOに関する用語じゃないよね
0441デフォルトの名無しさん2011/08/09(火) 00:07:32.77
>>435
set/getとchangeBandは、排他的って捉え方だよ。
もっと言うと、changeBandで与えられた、startとendはchangeBandの中で消化される感じ。
setStartとsetEndの方は、両方が設定されてから消化される感じ。
そもそも、消化される用な用途だからMVCじゃ寧ろ使い辛いって話じゃあるんだけど。
0442デフォルトの名無しさん2011/08/09(火) 00:11:34.36
>>441
＞両方が設定されてから消化される感じ。
それはカプセル化出来てないです
0443デフォルトの名無しさん2011/08/09(火) 00:17:19.16
>>438
いや、明確な違いがあるでしょ。setterとgetterは
両方が存在する場合、同じ値を持つっていう。
100をsetterして50が得られるgetterは許されるって
言いたいなら知らないけどさ。

>>442
だからダメでしょ。こういう使い方には使えないでしょ。
0444デフォルトの名無しさん2011/08/09(火) 00:24:13.98
>>436
moveって用意しといて移動距離渡したほうが良くね？
MVCなんだからModelやViewの判断委ねるでしょ大体。
Viewから座標取り出せる必要はないしね。
0445デフォルトの名無しさん2011/08/09(火) 00:27:53.34
いやもう言ってることがいよいよ意味分からん。

>100をsetterして50が得られるgetterは許されるって
>言いたいなら知らないけどさ。

そんなもんはsetter/getterじゃなくても許されないだろ。
とはいえ、元々反映が遅延するような仕様なんだったら許される場合もあるだろうし。
でもそれも、普通のメソッドでも同じことだし。
つーか、setter/getterってただのメソッドだし。

カプセル化されてないsetter/getterの例だして、「ほらカプセル化されてない」って。
そりゃカプセル化されてないんだからされてないんだろうよ。
setter/getterに関わらず、カプセル化されてなきゃされてない。
そういう風に書いたってだけで、setter/getterは関係ないだろ。
逆に、適切にカプセル化されたクラスのsetter/getterなら、カプセル化されてるわな。
0446デフォルトの名無しさん2011/08/09(火) 00:28:16.71
おいおいビューのコンポーネント間で相互調整できないぞ
0447デフォルトの名無しさん2011/08/09(火) 00:29:08.84
現在位置からの相対位置しか指定出来ない（そして現在位置は入手出来ない）
そんなオブジェクト嫌だ
04484442011/08/09(火) 00:31:25.15
補足、
MVCなら、Viewだけが座標やら大きさやらを把握しとけばいいんだよね。
ModelがViewからはみ出すサイズでも、それを管理するのはViewだし、
Modelをどの位置に配置するかもViewの役目。View上のレイアウトもViewの役目だし、
Controllerから渡されたドラッグの指示で移動したり、画面端で止まったりするのもViewの役目。
0449デフォルトの名無しさん2011/08/09(火) 00:35:30.54
>>445
いや、オブジェクトに入力された値がそのまま外に出ていくケースの方が珍しいって。
Stringのsubstring(10)とか読んだら、Stringと同じ文字列が帰ってくるの？
10文字切り捨てた文字が帰ってくるんじゃないの？
0450デフォルトの名無しさん2011/08/09(火) 00:35:40.67
そもそもＭＶＣぶち上げた奴もオブジェクト指向わかってるんかよーわからんな俺は
0451デフォルトの名無しさん2011/08/09(火) 00:36:24.60
MVCだけじゃ大規模に耐えられない。
なぜ日本人はMVCどまりなんだろうねｗ
0452デフォルトの名無しさん2011/08/09(火) 00:36:38.81
現代のUIフレームワークのレイアウトエンジンってもっと高機能で、
子オブジェクトと再帰的にネゴシエーションして実際の配置を決めてると思うけど
0453デフォルトの名無しさん2011/08/09(火) 00:36:52.65
>>447
現実世界のほとんどの物は、
相対的に扱われるんだけどな。

「絶対位置」なんて幻想だよ。
0454デフォルトの名無しさん2011/08/09(火) 00:38:09.61
>>453
0455デフォルトの名無しさん2011/08/09(火) 00:38:11.88
>>447
相対位置かどうかは、オブジェクトの判断に任せるんだよ。
そのオブジェクトを指定するのはプログラマーだから、
絶対位置になるか相対位置になるかはプログラマーは把握してるでしょ。
interface的に保証しないってだけ。もう少し、メソッドじゃなく
オブジェクトを指定して振る舞いを指定するってのを意識してみたら？
0456デフォルトの名無しさん2011/08/09(火) 00:39:17.65
そもそもＶｉｅｗで制限したい内容をもってるのがＭｏｄｅｌだから
ＶｉｅｗとＭｏｄｅｌはわける意味がないほど癒着してしまうだろ
かりに単体で動かしたときにＭＶＣはそれぞれ別々に動作すんのか？
しねーだろ明らかに・・・
無駄に工数増えるだけだろ
0457デフォルトの名無しさん2011/08/09(火) 00:40:31.17
みんな「俺だけがわかってる」と思い込む手法
0458デフォルトの名無しさん2011/08/09(火) 00:41:55.23
>>455
オブジェクトしか自分の絶対位置を知らない状況で
>>452が言うようなネゴシエーションってどうやるの？
0459デフォルトの名無しさん2011/08/09(火) 00:48:16.00
>>456
MVCをはModelとViewははっきり分かれてるよ、最近のMVVMだったかとか
COCOAのアレは知らないけどね。
例えば、「音声Model」が存在したとき、「声紋View」、「スコープView」、「スピーカーView」に接続できる。
この時、「スコープView」は「電流計Model」にも接続できる。つまり、「スコープView」は「音声View」とは
独立してて中立。この独立関係によって、「スコープView」なんかはModelを変えて再利用できるんだよ。
0460デフォルトの名無しさん2011/08/09(火) 00:51:53.03
>>458
さぁ？ネゴシエーションするようなFrameworkというのが実際どうなってんのか知らないから
なんとも言えない。ただレイアウト自体は可能だけどね。>>375にあるコードが
オブジェクトで振る舞いを決めてるでしょ、ああいう感じ。
0461デフォルトの名無しさん2011/08/09(火) 00:53:04.50
>>456
それはMVC止まりだからそうなるんだよ
ちゃんとレイヤー分けしていれば、隣の層だけ通信をすればいいだけになる。
クラスごとに責務が明確になり開発もしやすくなる。

勘違いしている人多いけど、MVCはレイヤーで言うと2層だからね。
VC合わせて、プレゼンテーション層、Mがビジネスロジック層
隣の層とだけ通信すればいいのだけれど、2層しかないから癒着するのは当然。

癒着を回避したければ、MVCを卒業し、プレゼンテーション層、サービス層、
ビジネスロジック層、データアクセス層、物理層。これぐらいに細分化しないといけない。

あともう一つ、昔から言われている有名な教えだが、データ構造というのは
長期間安定して変わらないものだが、ロジックは変更されるもの。
それを知っていれば自然とデータとロジックは分けるべきという結論に結びつく。
別にオブジェクト指向を否定しているわけじゃないよ。使うべき場所を見極めろという話。
04624592011/08/09(火) 00:55:20.35
×つまり、「スコープView」は「音声View」とは独立してて中立。
○つまり、「スコープView」は「音声Model」とは独立してて中立。

なんか結構間違えた。ゴメン。
0463デフォルトの名無しさん2011/08/09(火) 00:55:30.70
>>459
MとVCは機能的にはわかれている。
（VとCはわかれていない）

だけど、一方がもう一方の構造を前提に作られている
Mのインターフェースが変われば、VCにも影響が出てくる。
そのことを癒着と言っているのだろう。
0464デフォルトの名無しさん2011/08/09(火) 00:58:00.91
>>463
インターフェースを癒着と言われるとどうしようもないよね流石に。
それを言われると、オブジェクト指向の疎結合なんてって・・・。
0465デフォルトの名無しさん2011/08/09(火) 01:00:27.12
>>461

この文章からデスマーチの匂いを嗅ぎ取ったのは
俺だけだろうか・・・
0466デフォルトの名無しさん2011/08/09(火) 01:00:35.56
>>464
うん。だから層が2つしかないから
癒着するしかなくなっちゃう。

これでは大規模には耐えられない。
もっと層を分けるべきなのだ。

MVCは教えるのが簡単だから
広まっているが初歩でしかない。
0467デフォルトの名無しさん2011/08/09(火) 01:02:03.91
>>465
えーと、まず、ここに書いてあることは、
プロの間では、常識です。

調べてみましょう。ちゃんと資料見つかるから。

君がアーキテクトレベルではないというだけの話。
0468デフォルトの名無しさん2011/08/09(火) 01:02:52.09
>>463
Controllerも独立させられない訳じゃないんだけどね。

//テキストの内容を指定されたファイル名で保存するController
view.addListener( new SaveFile( textModel, fileNameModel ) );
//closeメソッドを持ったViewを閉じるController
view.addListener( new CloseView( view ) );
0469デフォルトの名無しさん2011/08/09(火) 01:03:38.81
>>460
つまり分からないんですね
そりゃそうですよね
どうやってオブジェクト間で相互作用するんだって話ですよね
0470デフォルトの名無しさん2011/08/09(火) 01:05:53.98
>>468
なんつークラス名だよ。そこ突っ込むのは申し訳ないが。
0471デフォルトの名無しさん2011/08/09(火) 01:12:20.48
>>469
アレ見ても解らないか。。。
ボタンとかを格納してるウィンドウは、自分の大きさ位置を把握している。
ウィンドウは最初は何も格納していない。
ウィンドウは飽くまで自分のセオリーで格納した部品を並べる。
部品は自分の大きさはウィンドウの指示に従い決める。
ウィンドウに何を格納するかは、プログラマーが決める。
プログラマーはウィンドウがどのオブジェクトをどう並べるかは把握しており、
絶対座標になるか相対座標になるかは全て把握している。
0472デフォルトの名無しさん2011/08/09(火) 01:13:46.76
>>470
まぁ〜ネ〜。それは自分でも思う。
0473デフォルトの名無しさん2011/08/09(火) 01:14:55.95
つまり座標は個々のオブジェクトが管理するんじゃなくて
全て知ってるウィンドウが管理するんですね
それってオブジェクト指向？
0474デフォルトの名無しさん2011/08/09(火) 01:18:23.54
各オブジェクトの大きさを指定できないUIとかないし、
クラスごとにサイズ設定の制約もあるとおもうけど
0475デフォルトの名無しさん2011/08/09(火) 01:20:08.72
>>473
ウィンドウっていうかプログラマーね。
オブジェクトは誰と繋がってるか知らないから。

だから >>375の例引っ張ってきてんじゃん。
Optionたちはコンストラクターで与えられたもの以外、
誰から値を渡されるか全く知らないでしょ。
0476デフォルトの名無しさん2011/08/09(火) 01:20:20.27
今有名なウェブ用のフレームワークのほとんどが
コントローラー作成用フレームワークになってるのが行けないんだよな。

そのフレームワークを使ってもコントローラしか作れない。
その証拠に、ビューは外部のテンプレートエンジンに投げることができるし、
モデルも、O/Rマッパーを兼用してるだけ。

もちろんフレームワークの役目としてはこれでいいし、
コントローラー以外はフレームワークに依存するべきではない
そこは自分で作るところなんだ。

ただフレームワークがコントローラーを作るだけのものということを理解してないから、
フレームワークに申し訳程度に付いているモデル機能だけを作って作るから複雑になる。
ユニットテストなどのことを考えると、本来はモデルはフレームワーク無しで動くように作るべきもの
フレームワークは無関係の所なので、自分で勉強して作る必要がある。
0477デフォルトの名無しさん2011/08/09(火) 01:21:38.74
>>375のOptionたちはお互いのこと知る必要ないじゃん
0478デフォルトの名無しさん2011/08/09(火) 01:23:02.61
>>473
> つまり座標は個々のオブジェクトが管理するんじゃなくて
> 全て知ってるウィンドウが管理するんですね
> それってオブジェクト指向？
オブジェクト指向だよｗ つかオブジェクト指向はこうだ！って決めつけてない？ｗ


座標はウインドウマネージャが決めるべきだろう。
ウインドウマネージャオブジェクト
0479デフォルトの名無しさん2011/08/09(火) 01:24:05.87
>>477
同じようにお互いのことを知る必要ないようにできるって事。
0480デフォルトの名無しさん2011/08/09(火) 01:29:11.37
座標を個々のオブジェクトが管理していたら、
横幅が狭くなったとき、次の段に行くなんてことができなくなる。

個々のオブジェクトは、親からどのような形で配置されているか
という属性を持つべき。どのような形とは、親のボックスの中の
上とか右下とか横幅いっぱいとか、具体的な座標を属性として
持っていることもあるそれはあくまで属性。

その属性をもとに座標を配置するのがウインドウマネージャ。
オブジェクトの属性と、実際の座標は切り離すべき。
0481デフォルトの名無しさん2011/08/09(火) 01:29:17.60
つまり相互作用させるくらいならオブジェクトの情報は
外に出してトップダウンにコントロールしてしまえ、ってことですね
0482デフォルトの名無しさん2011/08/09(火) 01:30:24.14
>>476
てかWebのMVCは微妙だよ。テーブルビューとか、グラフビューとか再利用できるビューが用意されてないし、
MVCの再利用性が全然生かされない。
0483デフォルトの名無しさん2011/08/09(火) 01:31:05.12
>>480
ということは、個々のオブジェクトの属性をgetterで取り出せないと
ウィンドウは配置できませんね
0484デフォルトの名無しさん2011/08/09(火) 01:31:51.08
>>483
当たり前じゃね？
0485デフォルトの名無しさん2011/08/09(火) 01:33:12.87
>>484
そもそもsetter/getterの是非の話だったのだが
0486デフォルトの名無しさん2011/08/09(火) 01:35:49.44
結論はWPFか？
0487デフォルトの名無しさん2011/08/09(火) 01:40:02.94
>>485
そんな話は知らんｗ
ってか、なんの話をしているのかわからんし。

流れ読まずに、setter/getterの話をするが、本質的にはsetter/getterは関数と同じ。
だから関数だけでもいいのだけれど、人間は動詞と名詞を分けたがる。
だから人間がわかりやすいためにあるのがsetter/getter。

Javaは関数名の頭にsetやgetを付けないといけないという
”構文”がださいと思っている。

C#のように人が感じるままに、名詞の名前(setXXXではなく、単にXXXで良い）で
かけるほうがいい。この名前はインターフェース名でもある。

この名前であってもgetterだけ作ることもできるし、setterで制約違反の値を入れようとしたら
エラーを出すこともできるというJavaのsetter/getterと同じメリットを持っている。
0488デフォルトの名無しさん2011/08/09(火) 01:43:57.02
>>483
windowManager = new WindowManager( レイアウト )
window = new Window( 〜, windowManager );
window.update();
   //update内部
   windowManager.replacement( windowの縦横の幅, 子ウィンドウリスト );

getterは全く要らんな。
0489デフォルトの名無しさん2011/08/09(火) 01:45:55.42
あと、Javaの話。

setter/getterだけど、これはこういう名前を
つけると決まっているので、その決まりを守っている
ものだと利点がある。

IDEでsetXXX、getXXXではなく、XXXという設定画面から設定できる。
テンプレートでgetXXXとかで値を表示しなくても、obj.XXXとかで表示できる。

ぶっちゃけC#みたいにプロパティという構文を用意しておけばよかったんだろうけど。
今はsetter/getterは、言語が不足している機能を補って、簡単に開発するための機能でもある。

だからsetter/getterが面倒なだけと言っている人は、IDEやテンプレートを
使ったことがない人だろう。
0490デフォルトの名無しさん2011/08/09(火) 01:46:33.15
JavaがださいならScalaをつかえばいいようん
0491デフォルトの名無しさん2011/08/09(火) 01:47:31.25
>>480>>487
えーと、>>488さんはgetter要らないって言ってますよ？
0492デフォルトの名無しさん2011/08/09(火) 01:48:38.90
>>488
その子ウインドウリストって
getter/setter持ったオブジェクトだろ？ｗ
0493デフォルトの名無しさん2011/08/09(火) 01:48:44.25
>>489
面倒なんでぶり返さないでください。
理由は300番台ぐらいの流れを見れば解ると思いますので、
何卒よろしくお願い致します。
0494デフォルトの名無しさん2011/08/09(火) 01:49:04.90
>>491
俺は言ってませんよ？
0495デフォルトの名無しさん2011/08/09(火) 01:49:09.31
WPFはコンテナに定義されたプロパティ識別子をキーとして値を子要素が持つという考え方
>>488と根本は一緒だが、よりデザイナで扱いやすくするためにそうなったんだろう
0496デフォルトの名無しさん2011/08/09(火) 01:53:18.67
>>492
int i = 0;
while( childlen.hasNext() )
{
      window = childlen.next();
      window.movePoint( 計算した位置 );
      window.resize( 計算した幅 );
      ++i;
}
0497デフォルトの名無しさん2011/08/09(火) 01:54:27.30
>>496
その「計算した位置」は
オブジェクトから幅をgetして計算するんだろｗ
0498デフォルトの名無しさん2011/08/09(火) 01:56:57.96
setter/getterなくても、オブジェクト指向をやめて
C言語っぽく、関数と構造体に分ければ出来なくはないよ。

問題は、オブジェクト指向をやめるかどうかなだけ
setter/getterいらない＝オブジェクト指向を止める。
それだけの話。
0499デフォルトの名無しさん2011/08/09(火) 01:57:33.88
>>497
>>488で既に取得している大きさとレイアウト、リストの要素数なんで
別にgetterの出番はない。
0500デフォルトの名無しさん2011/08/09(火) 01:58:35.54
>>498
逆だよ。それじゃ構造体とおんなじだろ。ってか蒸し返すなめんどくさい。
0501デフォルトの名無しさん2011/08/09(火) 01:58:44.35
>>499
> 既に取得している

えーと、オブジェクトのgetterから取得するの？
0502デフォルトの名無しさん2011/08/09(火) 01:59:35.09
>>501
アルツハイマーか認知症を患ってらっしゃるんでしょうか？
0503デフォルトの名無しさん2011/08/09(火) 02:00:04.53
>>502
質問に答えたらいかがでしょうか？
0504デフォルトの名無しさん2011/08/09(火) 02:01:14.69
>>501
つまりsetter/getterで出し入れしなきゃダメな情報は
全部オブジェクトの外にリストとかで持っとくのさ
何のメリットがあるのか知らんけど
0505デフォルトの名無しさん2011/08/09(火) 02:01:39.44
>>503
僭越ながら下記に手配致しましたが、下記の内容は
ご理解いただけませんでいたでしょうか?

window.update();
   //update内部
   windowManager.replacement( windowの縦横の幅, 子ウィンドウリスト );
0506デフォルトの名無しさん2011/08/09(火) 02:01:40.78
オブジェクト指向で作るならば、
高さとか横幅という情報は、
オブジェクトが持っている。

ならばgetterがいる。それだけの話なのに
なんで何回も蒸し返してるの？

オブジェクト指向で作らないのなら
適当に配列にでも入れとけよ
0507デフォルトの名無しさん2011/08/09(火) 02:03:33.25
>>505
その子ウインドウリストってのは
オブジェクトじゃなくて、ただの配列であるということですか？

普通、オブジェクト指向ならば、子ウインドウのリストといえば、
子ウインドウのオブジェクトであり、そのオブジェクトから
getterを使って値を取得しますよ。

これは作り方の問題なのでで、オブジェクトにしないのなら
どうぞ、そのように作ってください。
0508デフォルトの名無しさん2011/08/09(火) 02:04:58.03
>>506
だからwindowが内部で大きさと子ウィンドウのリストを持ってて、
内部で直接windowManagerに渡してるから、windowからwindowManagerが
ワザワザ取り出す必要が無いんだろうが。本当に認知症か。
0509デフォルトの名無しさん2011/08/09(火) 02:08:48.38
>>508
だから内部で持っている変数から値を取り出してるでしょ。

その取り出し元の変数が、オブジェクト型の変数じゃなくて
ただの単純な型の変数ってことなだけでしょ。

オブジェクト指向じゃない作り方として一般的だよ。
それで作れるよ。Ｃ言語とかそうやってたんだから。
0510デフォルトの名無しさん2011/08/09(火) 02:09:11.92
>>507
中学生かホントに。他のレスも見て考えろよ。
>>496 でもともと補足してたろ。
0511デフォルトの名無しさん2011/08/09(火) 02:14:34.25
>>510
何を必死になってるんだ？

俺はgetterがなければ無理なんて言ってないんだが、
オブジェクト指向じゃないやり方だねって
言ってるだけなんだが。
0512デフォルトの名無しさん2011/08/09(火) 02:19:27.44
レイアウトに必要な情報はレイアウトの方法によって違うからコンテナが持つべき
というのは間違ってないよ
それをなんとか子の属性でやろうと思えば>>495のようになる
外部でまとめて持つと宣言的に書きづらいからIDEに向きじゃないしメモリリークとか気にしないといけない
0513デフォルトの名無しさん2011/08/09(火) 02:22:26.46
>>511
setter/getterはRAD環境の為のものであって、
OOとは関係ない。C++の標準ライブラリも、
J2と呼ばれていたJavaの大半のライブラリも
getter/setterは持っていない。Javaに関しては
RAD環境に摺り合わせるためjava.bean.*という仕組みが導入された。
その仕組みに合わせてset/getを冠するメソッドが増えているというだけ。
0514デフォルトの名無しさん2011/08/09(火) 02:26:15.17
>>488はこうじゃないの？

windowManager = new WindowManager(レイアウト)
window = new Window(〜, windowManager);
window.update();

//update内部
windowManager.replacement(this, windowの縦横の幅);
while (childlen.hasNext())
{
window = childlen.next();
window.update();
}
0515デフォルトの名無しさん2011/08/09(火) 02:31:48.12
setter / getter って自然に使ってるわ

http://developer.apple.com/jp/documentation/cocoa/conceptual/objectivec/Articles/chapter_5_section_3.html
0516デフォルトの名無しさん2011/08/09(火) 02:36:18.21
構文としてプロパティを取り込んだC#さんや
attr_accessorがあるRubyさんもいる
0517デフォルトの名無しさん2011/08/09(火) 02:39:38.22
最低でもパラメータとしてのプロパティはどうやっても必要
セッターなしでどうやって人間がウィンドウのサイズを指定するんだよ
0518デフォルトの名無しさん2011/08/09(火) 02:46:56.06
>>512
> レイアウトに必要な情報はレイアウトの方法によって違うからコンテナが持つべき
> というのは間違ってないよ

レイアウトに必要な情報は、
コンテナ特有の属性＋オブジェクトの情報。
0519デフォルトの名無しさん2011/08/09(火) 02:54:41.92
>>518
そのコンテナ特有の情報という意味のつもりだった
コンテナ特有の属性はコンテナに持たせてもいいが、WPFのように他のクラスのプロパティを持つことができる
仕組みがあればそれでも可能だと
0520デフォルトの名無しさん2011/08/09(火) 03:38:37.46
>>513
OOにとってはgetter,setterもただのメッセージ
一部の低能がそれを特別扱いして排除しようとしてるだけ
0521デフォルトの名無しさん2011/08/09(火) 06:41:40.64
WPFは変態連想配列の実装であって、「○○メソッドで調整するから位置属性は公開しなくても良い」ってお花畑ではないよ
0522デフォルトの名無しさん2011/08/09(火) 06:47:05.64
setter,getterの問題は>>386や>>404 でしょ
ロジック部分に余計なsetter,getter使うのが糞コード
連想配列君はよく分からん

MVCでMからVに値を渡すためにgetterが比較的増えやすいけど、これはしょうがないものだよね
これ解決する方法あるの？

あとMVC以外に有名なUI設計の基準はあるの？
0523デフォルトの名無しさん2011/08/09(火) 07:06:44.81
>>404が駄目って、getterとsetterの組み合わせで出来る処理は全部呼び出し先に定義しないといけないの？
0524デフォルトの名無しさん2011/08/09(火) 07:17:58.38
>>516
Rubyのアレはともかく、objective-CやらC#、.net上で動く言語の
プロパティーはもろDelphiの流れを汲むRAD環境用じゃん。
0525デフォルトの名無しさん2011/08/09(火) 07:19:46.33
>>523
一応常識としてgetter、setterを組み合わせて処理を作ってはならん
>>413みたいに片やgetしてプラスしてsetしてる箇所と
片やaddUnkoなんてしてるようなときはどこでプラスされてるのか突き止めるのが困難じゃないか
0526デフォルトの名無しさん2011/08/09(火) 07:26:48.56
>>522
>>488と似たような方法でgetter自体は排除できるよ。
上の方でも話が出てるけどその方が扱いやすい。
ブロードキャストの時にブロードキャスト処理内だけの
一時オブジェクトを作ってブロードキャストするって効率化もできるしね。
0527デフォルトの名無しさん2011/08/09(火) 07:32:37.13
>>517
ココでsetter/getter排除できるって言ってる人は、
オブジェクトへの入力メソッドとsetterを分けて
呼んでるんだけど解ってる？
オブジェクトへの入力自体は誰も問題としてないの。
0528デフォルトの名無しさん2011/08/09(火) 07:37:00.65
>>522
てか、getterが増えちゃうのはMとVの関係にイベントが設定されてないからじゃない？
テキトーなタイミングでテキトーに渡してるからそういうことになっちゃうんじゃない？
0529デフォルトの名無しさん2011/08/09(火) 08:04:43.73
>>527
RADにかかわるプロパティの多くは単なるパラメータだろ
UIのレイアウトなんて実際にはRADと密接に結び付いた例を出すからおかしくなる
内部のロジックは別問題として、getterを持たないUIの要素なんかありえん
0530デフォルトの名無しさん2011/08/09(火) 08:06:31.75
>>514
thisを渡してgetter呼ぶってか、無意味。
それどころかせっかくinterfaceで切り離してる
依存性が増えるんでかえって不味い。
0531デフォルトの名無しさん2011/08/09(火) 08:18:15.87
>>530
thisと属性（windowの縦横の幅）をreplacementに渡してるからもうgetterを呼ぶ必要は無い
thisを渡してるのはwindowManagerがどのオブジェクトの属性が渡されたのか分からないから
ま、windowManagerがgetする代りにwindowがpushしてるだけですけどね
05325302011/08/09(火) 08:18:38.26
間違えた。煽ってゴメン。
0533デフォルトの名無しさん2011/08/09(火) 08:43:44.33
静的型は、いらないメソッドの排除と削除を要求する
動的型は、いらないメソッドを無視する
この違いが生産性の差につながるんだろうな
0534デフォルトの名無しさん2011/08/09(火) 09:46:32.99
setter/getter自体を問題にするのは変だと思う。扱い方が問題なのであって。

即値やそれに準ずるものを扱うsetter/getterはそれほど問題じゃなくね？
逆に多数のオブジェクトから参照され、自身も多数の変更可能な状態を持つようなオブジェクトをsetter/getterに渡すような構造はマズいだろうし。
0535デフォルトの名無しさん2011/08/09(火) 09:54:39.72
たぶん点オブジェクトを結ぶ直線を引く時でも
始点オブジェクトに終点オブジェクトを渡して直線を生成するんだろうな
Godオブジェクトになりそうだ
0536デフォルトの名無しさん2011/08/09(火) 10:11:09.06
てか、setgetなんてつけた時点でそもそもイベント的扱いをしない気まんまんだよね
状態も糞ももってないただの意味不明なクラスを作ろうとしてる
いつでもアクセスできるくせにアクセスしちゃダメな瞬間が存在するって
もし、一瞬だけだったら関数で十分だしね
0537デフォルトの名無しさん2011/08/09(火) 11:04:00.78
>>526
馬鹿な俺には難しいもっと簡単な例で頼む
例えばモデルは四角形の面積を計算するもの viewでは、縦、横、面積を表示

>>528
いわゆるObserverパターンとか？
0538デフォルトの名無しさん2011/08/09(火) 11:13:55.33
setter, getterは全てダメ派（イベントの人）と、
setXxx, getXxxて名前がダメ派（変態連想配列の人）と
入り乱れててワケ分からん
0539デフォルトの名無しさん2011/08/09(火) 11:21:30.19
getter setterが駄目という人はオブジェクトの中の変数をそのままセットしたりゲットしたりすることが
無意識のうちに仮定されているのだと思うよ。
オブジェクト指向で大切なことはgetterやsetterは値を返すという性質だけを仮定していることだよ。
0540デフォルトの名無しさん2011/08/09(火) 12:12:53.58
>>538
>>404のようなsetter,getterの使い方はダメ派もいる
0541デフォルトの名無しさん2011/08/09(火) 12:30:37.48
>>540
setterとgetter両方公開しちゃったら組み合わせて
処理作られても文句言えんだろ
隠蔽したいデータは公開しなくて良いんだぜ
0542デフォルトの名無しさん2011/08/09(火) 12:40:30.35
>>525
俺からしたらsetXXXの値のソースが何かにこだわる方が常識はずれだと思うよ
黙って引数を処理するのがメソッドの役目だろ
文句があるなら例外でも投げてみろや

あと使用法の分析なんて、シグネチャから推測できない勝手な要件を追加されてもねえ
0543デフォルトの名無しさん2011/08/09(火) 12:45:43.81
addUnkoでしかインクリメントしたくないなら
unkoはコンストラクタで初期化したら外からset出来ちゃダメ
つまりこの場合はsetUnkoがいらん
0544デフォルトの名無しさん2011/08/09(火) 12:59:49.58
>>541
ごめん
もちろん公開していたら、他人にこう使われても文句は言えないが少なくとも自分ではこう書かないということ
MVC利用時にgetter使わない方法がわからないからああいう書き方した
0545デフォルトの名無しさん2011/08/09(火) 14:39:19.95
好き勝手に利用できるのは利用側のコードに対する制約が少ないということだから
必ずしも悪いことではないぞ
プルパーサとSAXの違いみたいなもんで、
プロパティ主体のライブラリを使ってプッシュ型で作るのは簡単だが逆は難しい
利用側も含めて設計できるならいいが、UIコンポーネントなんかでプロパティが好まれるのは当然
05465372011/08/09(火) 21:00:19.52
四角形の縦、横、面積を計算して表示するプログラムでMVCやgetter,setterについて考えてみた
まずはオブジェクト指向だけを気にしてMVCを無視した場合
public class SquareModelView {
private int width;
private int height;
public SquareModelView(int width, int height) {
this.width = width;
this.height = height;
}
private int calcArea() {
return width * height;
}
public void view() {
System.out.println("width = " + width);
System.out.println("height = " + height);
System.out.println("area = " + calcArea());
}
public static void main(String[] args) {
SquareModelView squareModelView = new SquareModelView(3, 5);
squareModelView.view();
}
}
結果
width = 3
height = 5
area = 15

これなら>>404のような糞コードではない(getter必要なし)
しかしこれではModelとViewが混在しておりMVCに則っていない。

05475372011/08/09(火) 21:02:36.92
続いてMVC
public class SquareModel {
　private int width;
　private int height;
　public SquareModel(int width, int height) {
　　this.width = width;
　　this.height = height;
　}
　public int calcArea() {
　　return width * height;
　}
　public int getWidth() {
　　return width;
　}
　public int getHeight() {
　　return height;
　}
}

public class SquareView {
　private SquareModel squareModel;
　public SquareView(SquareModel squareModel) {
　　this.squareModel = squareModel;
　}
　public void view() {
　　System.out.println("width = " + squareModel.getWidth());
　　System.out.println("height = " + squareModel.getHeight());
　　System.out.println("area = " + squareModel.calcArea());
　}
}
つづく
05485372011/08/09(火) 21:05:25.38
public class Controller {
　public static void main(String[] args) {
　　SquareModel squareModel = new SquareModel(3, 5);
　　SquareView squareView = new SquareView(squareModel);
　　squareView.view();
　}
}

MVCにするとModelからViewが離れるおかげでViewがModelの値を取得するのにgetterが必要になる
っと思っていたんだけど、これを解決する方法はあるの？
上の方で解決できるって言ってる人がいるようだけど、よくわからん
0549デフォルトの名無しさん2011/08/09(火) 21:08:50.73
それが嫌ならMVC使わなきゃいいんじゃないの？
0550デフォルトの名無しさん2011/08/09(火) 21:13:10.48
>>549
これは両立できるものじゃないってことでOKなのか
MVCを使う上では、getterはやむなし
0551デフォルトの名無しさん2011/08/09(火) 21:14:22.82
どうでもいいけど俺なら、
Model m = new FooModel();
View v = new BarView();
Conroller c = new BazController();
で
v.paint(graphicscontext, m); // 描画スレッドから呼び出し
c.update(event, m); // イベントディスパッチスレッドから呼び出し
みたいにするな。MVCの三者の関係上。
vもcもmも動的に入れ替える前提で作る。
0552デフォルトの名無しさん2011/08/09(火) 21:28:50.80
単に目的が明確になってないから重要な決定をクラス同士でパスまわししてるようにしか見えない
ＭＶＣってなにがメリットでなにがデメリットなの？
0553デフォルトの名無しさん2011/08/09(火) 21:33:12.88
>>552
それがオブジェクト指向のメリットだと思ってた
どう変更するかはわからないのだから、将来変更する可能性があるところを変更できるように切り分けておく
0554デフォルトの名無しさん2011/08/09(火) 21:34:09.64
一応wikiには

各モジュールが比較的截然と分かれ、プログラムの見通しがよくなるとともに、
ユーザインタフェース (UI) 部分を別のモジュールに取り替えることが容易となるのが利点である。

って書いてあるから少なくともＶｉｅｗを２つは作らないとＭＶＣのメリットは見えてこないよね？
じゃ、Ｖｉｅｗが１つのときはプログラムの見通しがよくならなかったらこの構造はゴミなんだよね？

ここが重要な点だから例を出すならＶｉｅｗが２つあるようなもんじゃないとダメだな
少なくとも俺にはいまでたコードだとＭＶＣは仕様が決定してねーから綺麗に見えるだけの骨ヌキクラスにしか見えなかった
0555デフォルトの名無しさん2011/08/09(火) 21:36:25.99
>>553
そんなことどこにも書いてない
思い込みで変な発言するのやめろ
0556デフォルトの名無しさん2011/08/09(火) 21:39:35.74
>>541
>隠蔽したいデータは公開しなくて良いんだぜ
公開しなきゃ良いじゃんって思ってしまった。
公開して問題ないものだけ公開すれば？
setter/getterもつけつつ、カプセル化も満たしとけば良い訳だからなぁ。
setter/getter==構造体的なものって発想は俺にはないわ。なんつーか短絡だよなぁ。
0557デフォルトの名無しさん2011/08/09(火) 21:46:58.35
>>537

//モデル側 モデルが更新されるとこのメソッドを呼ぶ
private void broadCast()
{
      int area = width * height;
      //SquareListenerがView
     for( SquareListener l : listener )
     {
          l.changeScale( width,  height, area );
     }
}

本来こんな四角見たいなインターフェースは定義しないけど、
その形に合わせるならこんな感じかな。もっとも、実際は(width height)と(area)
ってな感じでそれぞれ別のモデルとして分けるけど。areaを必要とするViewは、
areaのリスナーオブジェクトにしてやればいい。
ViewとModelの形が合わない場合は、その間に緩衝材となるViewを挟むか、
ギャップのあるModelを包むModelを作ってやればいい。
05585372011/08/09(火) 21:48:56.52
>>554
MVCの善し悪しを議論するために書いたんじゃなくて、getter不要論が上にでてたからMVCではどうすればいいの？って聞きたかっただけだからViewは1つしか示さなかった

2つめの例
public class SquareViewOneLine {
private SquareModel squareModel;
public SquareViewOneLine(SquareModel squareModel) {
this.squareModel = squareModel;
}
public void view() {
System.out.print("width = " + squareModel.getWidth() + " ");
System.out.print("height = " + squareModel.getHeight()+ " ");
System.out.print("area = " + squareModel.calcArea()+ " ");
}
}

public class Controller {
public static void main(String[] args) {
SquareModel squareModel = new SquareModel(3, 5);
SquareViewOneLine squareViewOneLine = new SquareViewOneLine(squareModel);
squareViewOneLine.view();
}
}

出力結果
width = 3 height = 5 area = 15

Modelには手を加えず出力を変更できる
0559デフォルトの名無しさん2011/08/09(火) 21:50:39.21
>>556
それは結局なんのイベントなの？
いつでも送るといつでも反映されるの？
それともメッセージ送ったらDoEventsでもかましてやらないと動かないの？
0560デフォルトの名無しさん2011/08/09(火) 21:51:11.97
>>552
>>459 を見て何もメリットを感じない？
ViewはModelを新しく追加しても、前に作ったものが使えるんだよ。
ModelはViewを新しく追加しても、前に作ったものが使えるんだよ。
Controllerも作り方次第で、前に作ったControllerを新しい、ModelとViewに使えるんだよ。
0561デフォルトの名無しさん2011/08/09(火) 21:52:55.26
>>560
実際そんなことはねーからどうでもいいんだよ
この構造は明らかにＭとＶとＣが癒着をする
おそらくＭＶＣの主張してるメリットは現場じゃメリットになってないと思う
0562デフォルトの名無しさん2011/08/09(火) 21:57:17.08
MVCの一番の利点って、ドメインのロジック作るときに
ロジックだけに集中出来ることじゃないの？
05635372011/08/09(火) 22:04:45.97
>>557
これってObserverパターンだよね
Javaでは、↓のMVC概念図の破線がObserverパターンを利用して実装されていたり(○○Listenerとか)、インターフェース(ObserverObservable)が用意されてる。

Model View Controller - Wikipedia
http://ja.wikipedia.org/wiki/Model_View_Controller
Observer パターン - Wikipedia
http://ja.wikipedia.org/wiki/Observer_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
0564デフォルトの名無しさん2011/08/09(火) 22:06:19.08
>>559
あーはいはい。
分かった分かった。
そういう時は、setter/getterがどうとか、イベントがどうとか言わず、
シンプルかつ素直に、「俺はステートマシンが嫌いです」って言えば、
何の御幣も無く言いたいことが相手に伝わるんだよ。
0565デフォルトの名無しさん2011/08/09(火) 22:06:46.62
>>561
>>562

それは、WebのなんちゃってMVCの事だろ。
だいたい、GUIのMVCじゃVとCは簡単に切り離せる。

そもそも、Cを数十行もあるクラスにしちゃいけない。
あくまで、Cが受け取ったイベントをViewとModelに伝えるだけ。
Cは　>>468　みたいな粒度で十分。
0566デフォルトの名無しさん2011/08/09(火) 22:06:58.34
>>559
・値の取得/設定操作です。値の意味はメソッドごとに異なるので一般化はできません。
・設計次第です。でも非同期動作のトリガーとなる例はほとんどないです。
・DoEventsが必要と明記されている設計ならそうですが、一般論としては設定だけで完結した動作です。
　でも内部的にはすぐに反映せずに、実際に変更処理が必要になったときに行う実装も結構あります。
0567デフォルトの名無しさん2011/08/09(火) 22:09:17.96
>>566
色々考えるとやってることおかしいだろ？
タイミングや状態すべてが定義されてない
設定しても無駄なタイミングもあんじゃねーの？
あんまりよく考えねーと欠陥だらけのクラス量産すんぞ気をつけな
0568デフォルトの名無しさん2011/08/09(火) 22:10:26.15
>>563
そうだよ。MVCはいくつかのデザインパターンで構成されてる。
というか、MVCをいくつかのデザインパターンと見なせる。
MVCはデザインパターンじゃなく、その上位の存在だからね。
0569デフォルトの名無しさん2011/08/09(火) 22:11:52.72
>>567
定義されてないんじゃなくて、メソッド別に定義すんの
0570デフォルトの名無しさん2011/08/09(火) 22:17:26.53
>>569
やってれば問題ないなｗ
0571デフォルトの名無しさん2011/08/09(火) 22:20:26.40
ただ、俺が担当になったらsetter、getterは全部消させてもらう（はじめから使用禁止だけど）
んで本当に必要なイベントにまとめさせてもらう
値の更新タイミングを必要な箇所だけに限定してもらう
そこでまずい場合のみ他の更新タイミングを許す
0572デフォルトの名無しさん2011/08/09(火) 22:22:03.89
getterの存在が許せないひとって、要はオブジェクトに自身の情報を訪ねるのはアウトってこと？
0573デフォルトの名無しさん2011/08/09(火) 22:23:07.71
あっそう
あんたの趣味はウザいほど分かったからもう妄言を吐くんじゃないよ、問題ないって認めたんだからね
0574デフォルトの名無しさん2011/08/09(火) 22:26:56.56
getter禁止の人は、文字列クラスをデザインするときは
str.length() のかわりにオブザーバパターン使って
str.lengthBroadCast(stringListener) で length をブロードキャストするの？
0575デフォルトの名無しさん2011/08/09(火) 22:27:46.76
>>572
値を取得してそれ単独として処理するのがおかしいということ
値を取得した時点で、元のオブジェクトからその値は関係なくなってる
何らかの処理をするならできる限りそのオブジェクトにさせろって話
0576デフォルトの名無しさん2011/08/09(火) 22:31:58.03
>>575
だから、お前の嫌いなのはgetterではなくて、ステートマシンだろ。
初めからそういえよ。
0577デフォルトの名無しさん2011/08/09(火) 22:33:18.31
>>572
俺はイベントのヤツじゃないけど、setter/getterは"同一の値の出し入れ"が前提になってるから否定してる。
オブジェクトに値を入力するのは構わん、オブジェクトから値を取り出すのも構わん。setterかgetterの
どっちかいづれしか常に定義しないといいたいんならそれも構わん。ただ、オブジェクトに入った値が
なんの処理もされずオブジェクトから出てくるのは肯定しない。元の値を取得したところの値を
処理を行うオブジェクトに渡せばいいだけだから。コンテナ見たいな管理をするわけでもないなら無意味。
意味があるのはGUIのようなちゃんと処理を行うものだけだ。
0578デフォルトの名無しさん2011/08/09(火) 22:35:51.04
>>574
それはgetterではない
str.length()を使うならおｋ

viewに反映させる話は別の話

これが駄目
str.getterString() //わかりやすくgetter風に書いてるけどようはstrってこと
strの文字数をカウントする処理

getterしたクラスで処理を行うのは駄目
0579デフォルトの名無しさん2011/08/09(火) 22:36:27.11
>>574
そのオブジェクトにsetLengthが存在するとでも？
0580デフォルトの名無しさん2011/08/09(火) 22:38:04.99
>>577
気がついたら、そういう意味不明なクラスつくってるときあるよな。
何かに渡すパラメータ群みたいなのをグニグニ搭載してるだけのクラス。
クラス内部で処理も糞も、変数群に一貫性すら無いの。
ごった煮になって押し込まれてるだけっていう。
0581デフォルトの名無しさん2011/08/09(火) 22:41:35.22
>>577
> ただ、オブジェクトに入った値がなんの処理もされずオブジェクトから出てくるのは肯定しない。

それってsetter/getterの定義の外の話だと思う
同じものをやり取りするセットのもの、というのは確かだけど
何の処理もしないのか、何らかの加工がされるのかを
setter/getterという存在が決めはしないでしょ
内部の処理によって入れた値は変更され得るよ
全く無加工で出てくるかも知れないが、それはsetter/getterの定義内ではないと思う
0582デフォルトの名無しさん2011/08/09(火) 22:43:11.23
「それはgetterではない」とか言い出したよ。
setter/getterは駄目、全部イベントでやれっつって、
その「setter/getter」も「イベント」も両方がオレオレ用語なんじゃもう会話にならないよ。
0583デフォルトの名無しさん2011/08/09(火) 22:43:46.42
>>577
純粋にパラメータの値を持つだけのプロパティなら実害はないでしょ
内部処理による変化が外に晒される(晒さないと整合性が保たれなくなる)
ことが問題だという話なんだろ?
0584デフォルトの名無しさん2011/08/09(火) 22:44:12.59
>>579
あっても変ではないな
空いた領域を埋めるのはヌル文字なのか空白文字なのか知らんが
まあ、それもプロパティにして決めれば良いんでね
0585デフォルトの名無しさん2011/08/09(火) 22:45:39.90
>>577
よくわからん。

getter、setterだろうとそうじゃないメソッドだろうと、
使う時にクラス内部を気にしなきゃならないのはクソだろ。
そうじゃなきゃ別に入れた値がそのまま出て来たって
気にする必要ないじゃん。

何がそんなに気になるんだ？
0586デフォルトの名無しさん2011/08/09(火) 22:46:23.09
>>581
object.setName("もじ");
object.getName();　→へのへのもへじ〜

こんなふうにsetした値がgetで改変されるなら
setter/getter派は絶対認めない筈だよ。
なんせsetter/getterが同じ値になるから彼らはgetter必須だと叫んでんだから。
構造体の代替品が欲しいだけ。
0587デフォルトの名無しさん2011/08/09(火) 22:46:35.72
>>584
ちょっとビルダだから状況違うかもシレンが、
C#のStringBuilderにはLengthってプロパティがあって、
値を代入できるよな。で、クリアしたい時はゼロを代入するという。
一瞬不条理だがよく考えるとまあ許せる。
0588デフォルトの名無しさん2011/08/09(火) 22:46:59.97
>>578
str.getLength() って書けば分かりますか？
あとこれと>>558のこれらとの違いは何ですか？
squareModel.getWidth()
squareModel.getHeight()

>>579
だれもsetterとgetterは常に両方用意しろなんていってませんよ？
0589デフォルトの名無しさん2011/08/09(火) 22:48:26.96
>>586
だよねー
ようはプログラムの組み方が下手糞なんだよな
0590デフォルトの名無しさん2011/08/09(火) 22:50:05.86
>こんなふうにsetした値がgetで改変されるなら、setter/getter派は絶対認めない筈だよ。

ほら、またオレオレ定義が始まった。
0591デフォルトの名無しさん2011/08/09(火) 22:50:27.03
>>586
認めるよ、仕様として正規化されてるんなら
0592デフォルトの名無しさん2011/08/09(火) 22:54:48.04
>>590
定義？ユーザーの態度の事だろ。
0593デフォルトの名無しさん2011/08/09(火) 22:55:54.52
イベントイベント叫んでたのは俺だけだな
このレスの前は>>571で今日はレス終了
0594デフォルトの名無しさん2011/08/09(火) 22:59:16.57
RADを意識するなら>>588は普通はダメ
.NETでは規約で禁止されてる
0595デフォルトの名無しさん2011/08/09(火) 22:59:33.32
>>593
いちおう言っとこうかな…俺、あんたのレス読み飛ばしてる。
だってイベントの定義がいまだに見えてこないんだもん(´･ω･`)
05965942011/08/09(火) 22:59:48.54
訂正>>586
0597デフォルトの名無しさん2011/08/09(火) 23:02:02.75
>>591
まぁ、そもそもそんな事仕様としてどう定義すんのかねぇ？
setName、getNameを呼び出すオブジェクトは全て、
getNameで取得される値は、setNameとは一致しない可能性が有る事を前提に
コード組むわけだ。当然2つのオブジェクトに同じ値をsetNameしても、getNameは2つの
オブジェクトで値が異なる。そういう仕様なんだよね。
0598デフォルトの名無しさん2011/08/09(火) 23:02:43.70
>>579
java.lang.StringBufferにはあるぞ
0599デフォルトの名無しさん2011/08/09(火) 23:02:55.28
イベントってC#のevent、つまりオブザーバーパターンのこと？
0600デフォルトの名無しさん2011/08/09(火) 23:04:23.09
>>594
そりゃRADの為の機能だもん。もともと。
0601デフォルトの名無しさん2011/08/09(火) 23:05:43.67
>>597
str.setLength( 10 );
str.setStr( "aaa" );
str.getLength(); //←3
0602デフォルトの名無しさん2011/08/09(火) 23:05:49.09
>>582,>>588
ごめん 色々と俺が間違ってた

getter禁止というか　getterして加工して、setter禁止 それならその一連の流れを元のクラスにメソッドとして実装すればOK
その値そのものを取得、加工して、元のオブジェクトに影響を与えたりするのではなく、何らかの目的に利用するのには問題なし
(取得した値を画面に表示するとか、取得した値に従って他のオブジェクトを操作するとか)
0603デフォルトの名無しさん2011/08/09(火) 23:06:38.87
>>597
あんたが作ったクラスの仕様なんか知らんよ

まともな正規化の例としては、値の丸めや境界値の反映とか
0604デフォルトの名無しさん2011/08/09(火) 23:10:14.84
>>598
いうてもlengthと対じゃ無いけどな。
今入ってる文字列以上の値をsetLengthすると数が合わなくなる。
reserveって名前でもいいぐらいのメソッドだ。
ワザワザbeanに合わせてるけど。
0605デフォルトの名無しさん2011/08/09(火) 23:12:58.38
>>603
ほら、setter/getterの値が変わったら困るんだろ。
机上の空論じゃん。
0606デフォルトの名無しさん2011/08/09(火) 23:14:35.03
>>601
>str.setStr( "aaa" );
これ抜いて値変えてみろよ。
0607デフォルトの名無しさん2011/08/09(火) 23:16:07.59
誰か getter / setter が駄目な理由を箇条書きでまとめてくらはい

まとまったら上から検討していこうぜ
0608デフォルトの名無しさん2011/08/09(火) 23:17:16.73
イベントってRADの用意するGUIなどのイベントドリブンのコールバックのことでしょ。
OOの議論にふさわしい単語じゃないね。
0609デフォルトの名無しさん2011/08/09(火) 23:17:24.55
>>604

StringBuffer s = new StringBuffer("abc");
System.out.println(s.length());   // 3
s.setLength(10);
System.out.println(s.length());   // 10
0610デフォルトの名無しさん2011/08/09(火) 23:18:37.58
>>605
何で俺が>>586の弁護をしないといけないの？
たとえばDOM要素.setInnerHTML("<br>")の後にgetInnerHTML()ってやると"<br />"が返ってくるだろ？
0611デフォルトの名無しさん2011/08/09(火) 23:19:05.29
>>602
いや、その下三行もちょっと。

難しく考えすぎだと思う。
i=i+1; が許されちゃう環境に居ることを忘れずに。
関数型言語の人なら知らんが。
0612デフォルトの名無しさん2011/08/09(火) 23:19:53.72
>>608
どっちかというと、まずはそれを思うよなぁ(RAD関係なくね？)。
でも、彼の言うイベントって、どうもそれじゃ説明できない。
0613デフォルトの名無しさん2011/08/09(火) 23:24:39.41
ああごめん。ここんとこの流れからRADしか頭に浮かばなかったもんで。
0614デフォルトの名無しさん2011/08/09(火) 23:26:36.86
"イベント"はイベントの人の職場の設計書用語じゃないかなあ
getter/setterが設計書に書けないんで呼び出されるって言ってたし
0615デフォルトの名無しさん2011/08/09(火) 23:28:27.70
まさかネット上でそんなローカル用語つかわんだろ
0616デフォルトの名無しさん2011/08/09(火) 23:34:04.27
>>607

>>404について考えると
getterしてsetterできるということは、unko++で1個ずつ増えていくはずだったunkoが、想定していない数で増えてしまうことが許可されてしまう。

ケツの穴は1つと想定
//必ずunkoは1つずつ増えることを保証するクラス
Class Dappun{
　int unko;
　void buri(){
　　unko++
　}
　int getUnko(){
　　return unko;
　}
}

// これでも1個ずつUkno可能だが(getしてから++してset)
// 気がついたらUnkoが2個同時にでてしまう(getしてからunko = ukno+2してset)かもしれないクラス
Class Dappun{
　int unko;
　void setUnko(int unko){
　　this.unko = unko;
　}
　int getUnko(){
　　return unko;
　}
}

>>611
プリミティブ型はどうなんだろう？
それはintがそれを許可しているからいいってことになるんじゃないのかな
0617デフォルトの名無しさん2011/08/09(火) 23:39:24.80
>>616
それは使うべきでない場所にgetter/setterを適用した例でしかないので、語るような内容は無いです
0618デフォルトの名無しさん2011/08/09(火) 23:40:23.75
>>615
本人がグローバルな用語だと勘違いしてるケース、
２ちゃん各所で多々見たがｗ

>>614
ちょっとまえの>>314を見ると、

> だからオブジェクト指向にイベントって言葉あるだろ？

いきなりこんなこと書いてるから、ひょっとしてメッセージのことを言いたいのか？
とすらオモタｗ　だが、やはりそうでもないようであって。
0619デフォルトの名無しさん2011/08/09(火) 23:42:34.83
議論するときは引用元を意識するということすらしないんだろうな。
日本のプログラマーのレベルｗ
0620デフォルトの名無しさん2011/08/09(火) 23:43:35.56
>>606
抜いても、別スレッドから更新される可能性はあるよ？

>>616
それはsetter付けちゃダメな例のひとつに過ぎないだろ
setter/getterそのものを否定する理由にはなれないかと
0621デフォルトの名無しさん2011/08/09(火) 23:44:16.60
むしろ>>404はある種間違ってないと思うが…。
下駄雪駄がよく使われてる、直交性が高いメソッドであると示してる、
とすら思えるが…。ちょっとの煩雑さのために、下手に糞メソッドを追加してしまうのは、
それはそれで危ない。よりよいメソッドがスパーンと出てくるのならまあ収まりはつくが。
0622デフォルトの名無しさん2011/08/09(火) 23:47:05.17
>>618
いや、俺もフツーにメッセージのことだと思ったよ。
で、なんか字面で大層なモンだと幻想持ってるのかな、と感じた。
0623デフォルトの名無しさん2011/08/10(水) 00:01:30.59
>>610
実質同じじゃん。入力を修正するってのは評価できるけどね。
じゃあ、setInnerHTMLとgetInnerHTMLをオーバーライドして
何ができるだろうね。setInnerHTMLに入力できる内容は、
setInnerHTMLを実装しているDOMオブジェクトが許容できる
値じゃないといけない。getInnerHTMLの出力は、DOMオブジェクトと
同じ値を返すようにしなきゃいけない。元々DOMオブジェクトを
利用していたオブジェクトは、DOMの仕様外の値が入出力される
事を想定していないからね。
0624デフォルトの名無しさん2011/08/10(水) 00:05:09.69
>>620
setStr("aaa");
はsetLength(3);を呼び出してんのと同じだろ。
別のスレッドでもsetLength(3)を呼び出してることには変わらん。
別スレッドでsetLength(3)しようが、
setStrの中でsetLength(3)が実行されようが、
DOMの例のように、getLength()の値が変わるかって事なの。
0625デフォルトの名無しさん2011/08/10(水) 00:08:56.89
>>621
nkoが指してるオブジェクトの実装が変わること考えてる？
むしろ、どう変えられるか考えてる？
0626デフォルトの名無しさん2011/08/10(水) 00:12:40.48
>>625
実装が変わるとは？
Nko nko, nko1 = new Nko1(), nko2 = Nko2();
nko = nko1;
unk = nko.getUnko();
unk++;
nko = nko2;
nko.setUnko(unk);
みたいな話？
0627デフォルトの名無しさん2011/08/10(水) 00:13:09.65
>>624
内部で全くlengthを管理してないとしても？
実はgetLength()はCのstrlen()読んでるだけでーすみたいなものだとしても？
0628デフォルトの名無しさん2011/08/10(水) 00:17:59.18
>>586
setter/getterはアクセス制限を
読み込み可(getterのみ)、書き込み可(setterのみ)、読み書き可(setter/getter)
というようにコントロールでき、
オブジェクト内部を隠蔽もでき（setXxxのときにメンバ変数xxxそのものが無くても良い）、
境界条件のチェックやロギングを仕込んだりもでき、
ポリモーフィズムで処理を換えることもできる
構造体と同じとは思えないけどなぁ
0629デフォルトの名無しさん2011/08/10(水) 00:22:27.26
>>628
>読み書き可(setter/getter)
これが問題だって言ってんだけどね。
getterだけsetterだけなら、別にtoString()みたいなもんと変わらんし問題にしてない。
0630デフォルトの名無しさん2011/08/10(水) 00:25:49.26
>>629
それが問題になるような属性なら、読み取り専用にも出来るのが利点
0631デフォルトの名無しさん2011/08/10(水) 00:26:35.24
>>626
概ねそんな感じ。
でも、それじゃ再利用できないから、nkoは引数で取る。
increment(new Nko1());
increment(new Nko2());
これを踏まえた上で、Nko1、Nko2の実装をどれだけ違う
ものにできるかって話。
0632デフォルトの名無しさん2011/08/10(水) 00:26:37.92
>setStr("aaa");
>はsetLength(3);を呼び出してんのと同じだろ。

おなじじゃねぇ。setLengthでは"aaa"はセットされねぇよ。
0633デフォルトの名無しさん2011/08/10(水) 00:28:50.49
>>630
読み取り専用、書き込み専用は問題になってないんだって。
読み書き可の状態が問題なんだから。
単に読み込み専用ならconstの構造体と変わらんだろ。
0634デフォルトの名無しさん2011/08/10(水) 00:30:37.78
読み書きするのはコンピュータの基本だろ。
0635デフォルトの名無しさん2011/08/10(水) 00:32:09.22
>>633
> 単に読み込み専用ならconstの構造体と変わらんだろ。

setter/getterのあるオブジェクトはsetter/getter以外のメソッドは
持ってないとでも思ってんの？
0636デフォルトの名無しさん2011/08/10(水) 00:36:03.50
length()とsetLength()を持つせいで構造体扱いされてる
StringBufferさん可哀想www
0637デフォルトの名無しさん2011/08/10(水) 00:37:12.05
値の受け渡し自体は必要だから発生しているってことも分かってないから、unko.setUnko(unko.getUnko() + 1)なんて例が出てくるんだよ
0638デフォルトの名無しさん2011/08/10(水) 00:37:23.07
>>631
> Nko1、Nko2の実装をどれだけ違うものにできるかって話。

急に話が分からなくなったｗ　>>621の時点でまず横入りして言ってるのは、
下駄雪駄は、わりかし使いやすい、組み合わせて使ったりしやすいメソッドだね、
組み合わせて使う分にはわりか便利に見えるね、っていう程度のこと。まずはそのこと。

Nko#increaseの追加はまだマシとして、Nko#addUnkoValue(int value)みたいなの追加しちゃうのも考え物だね、
ということを続けて書いてある。addだけ追加？引くほうはマイナスを足すということもできそうだが、
かけたり割ったり、ある条件でclampさせたりするのに、全部メソッドを対応させようとするとしんどくなる。
0639デフォルトの名無しさん2011/08/10(水) 00:40:04.12
>>635
getName()/setName()とか見たときに、他のメンバーがどうとか問題か？
0640デフォルトの名無しさん2011/08/10(水) 00:42:37.88
>>636
StringBufferはちゃんと処理してるだろ。
GUIと同じでタダのホルダーじゃねぇ
0641デフォルトの名無しさん2011/08/10(水) 00:45:11.45
>>623
それはプロパティじゃなくて仮想メソッド一般の制限だ
0642デフォルトの名無しさん2011/08/10(水) 00:50:04.96
インクリメントするためだけにsetter/getterを実装してるクラスがあるなら
そりゃあアクセサ要らんからインクリメント用のメソッド作れとは皆が皆思うだろう
0643デフォルトの名無しさん2011/08/10(水) 00:50:59.93
>>639
getValue()が在ってsetValue()が無くても
IncrValue()が在ればconstじゃねーだろ
0644デフォルトの名無しさん2011/08/10(水) 00:53:23.28
>>640
は？じゃあsetterとgetterは両方あってもいいんだな？
0645デフォルトの名無しさん2011/08/10(水) 00:53:47.61
>>643
もはやsetterじゃないだろ。
0646デフォルトの名無しさん2011/08/10(水) 00:55:15.64
getter/setter否定してる連中はブリッジについてはどう考えてるんだ
0647デフォルトの名無しさん2011/08/10(水) 00:55:42.62
>>636
lengthはsetLengthとは違う扱いだろ。
そもそもインターフェースも違うし。
0648デフォルトの名無しさん2011/08/10(水) 00:57:40.24
>>646
このスレに何個か出てるパターンで簡単にgetterを排除できる。
0649デフォルトの名無しさん2011/08/10(水) 00:59:35.42
>>645
だれもIncrValue()がsetterだなんて言ってねえよ
setterが無い = const構造体って短絡的考えが
setter/getter以外のメソッドの存在を考慮してないと思われてんの
0650デフォルトの名無しさん2011/08/10(水) 01:01:01.74
>>647
>>609
0651デフォルトの名無しさん2011/08/10(水) 01:02:52.12
>>644
GUIやら、処理をちゃんとする物は認めてるだろ。
てか、StringBufferのsetLengthなんてresizeで良かったろ。
無理やりRADに名前合わせただけじゃん。
0652デフォルトの名無しさん2011/08/10(水) 01:05:17.11
結局、全ての getter / setter を廃止したいと思ってる人はいなかったって事か
0653デフォルトの名無しさん2011/08/10(水) 01:08:25.39
>>651
全く認めてるように思えんなあ
getter/setterの存在そのものに異を唱えてるとしか思わなかった
ちなみにあなたはどのレスの人？
0654デフォルトの名無しさん2011/08/10(水) 01:13:59.60
>>653
ごめんGUIでもgetterは要らんわ。
なくても困らんし。
0655デフォルトの名無しさん2011/08/10(水) 01:15:27.58
そりゃなくてもチューリング完全だろうよ
でもあったりいけない理由は？
0656デフォルトの名無しさん2011/08/10(水) 01:17:51.79
俺の setter / getter 満載のコードを見たら烈火の如く怒り出しちゃう様な人はいなかったって事か
0657デフォルトの名無しさん2011/08/10(水) 01:19:09.88
>>656
見るだけなら笑う
メンテさせられたら怒る
0658デフォルトの名無しさん2011/08/10(水) 01:20:57.72
職場が笑顔で溢れそうだw
0659デフォルトの名無しさん2011/08/10(水) 01:26:08.42
>>654
GUIでgetter要らないとは、また斬新だな…
現在のウィンドウサイズの取得はどうすんの？
0660デフォルトの名無しさん2011/08/10(水) 01:31:21.26
横からだが、画面全体のレイアウトマネージャなるものが一つあれば、
それが内部変数でサイズを一括管理するというの、できないかな？
配置やリサイズに関わるのは全部それが担当。
0661デフォルトの名無しさん2011/08/10(水) 01:32:20.77
>>659
1.ウィンドウサイズは誰かが指定しているから存在している。
　そこから取得すればいい。
2.MVCならコントローラーでリサイズイベントの値を拾える。
　次回起動時その情報が必要ならサイズモデルやらベクトルモデルやらに
　渡して、モデルに保存と読み込みしてもらえばいい。

画面レイアウトに必要とかっていう話なら上のほうで散々既出なんで割愛する。
0662デフォルトの名無しさん2011/08/10(水) 01:35:24.85
マウスイベントハンドラの中でウィンドウサイズを指定してたら、取得は無理ぽ
0663デフォルトの名無しさん2011/08/10(水) 01:35:57.81
マウスでウインドウのサイズを変更した場合は誰かは何になるの？os?
0664デフォルトの名無しさん2011/08/10(水) 01:36:12.39
>>661
>　そこから取得すればいい。

getWindowSize() みたいなメソッドで?
0665デフォルトの名無しさん2011/08/10(水) 01:38:48.85
>>661
>モデルに保存と読み込みしてもらえばいい。

ウィンドウは getter 無しでモデルからどうやってウィンドウサイズを取得するの?
0666デフォルトの名無しさん2011/08/10(水) 01:42:01.37
>>660
それ結局GUIにgetterある事にならないか
0667デフォルトの名無しさん2011/08/10(水) 01:45:14.59
>>661
なるほど…リサイズイベントね
出来なくはないだろうが…何か、スコープの広い変数がいっこ増えるだけな気もするw
0668デフォルトの名無しさん2011/08/10(水) 01:49:27.01
>>663
void action(int x,int y)
{
     this.size = new Vector( x, y );
     this.control.globalResize( x, y );
}

>>664
void resize(int width, int height)
{
     this.scaleModel.resize( width, height );
}
0669デフォルトの名無しさん2011/08/10(水) 01:55:14.75
>>668
getter 無しで scaleModel からウィンドウサイズをとってくるのはどうするの?
0670デフォルトの名無しさん2011/08/10(水) 01:57:06.39
もし setter / getter をモデルに押し込めろという話なら、
そんなのはみんなやってると思われ
0671デフォルトの名無しさん2011/08/10(水) 01:57:56.88
>>661
> 1.ウィンドウサイズは誰かが指定しているから存在している。
> 　そこから取得すればいい。

その誰かから値をもらうわけですね。
getter使って。
0672デフォルトの名無しさん2011/08/10(水) 02:00:40.56
つまり getter を否定している人はいなかったって事か
0673デフォルトの名無しさん2011/08/10(水) 02:03:48.25
>>669
ウィンドウサイズ自体を管理するのはscaleModelが全面的に行う。
保存とか読み込みとかね。
ウィンドウとかにそのサイズを反映させるなら、ウィンドウをscaleModelのリスナーにすればいい。

scaleModel.addListener( view );

ウィンドウ→resize→コントローラ→resize→モデル→resize→ウィンドウ

またモデル内なら
モデル1→resize→モデル2→計算メソッド→モデル3→resize→モデル1

てな循環処理を行える。必要な処理の分だけモデルを割りこませればいい。
0674デフォルトの名無しさん2011/08/10(水) 02:06:59.08
ホントgetterを安易に支持するヤツは、>>671みたいに視野が狭いのが多いのな。
0675デフォルトの名無しさん2011/08/10(水) 02:12:53.79
ラムダ計算がチューリング完全な事を考えれば、結果をオブジェクトで保持してれば
関数の呼び出し連鎖で処理が可能なことぐらい分かるのにな。
0676デフォルトの名無しさん2011/08/10(水) 02:13:08.34
でも安易な否定もおかしいと思うよ
そりゃ構造体として使ったらおかしいが、そんなのは当たり前の話であってgetter/setter以前の問題よ
0677デフォルトの名無しさん2011/08/10(水) 02:13:56.73
ModelからViewに通知するのにListener経由にするのは分かる
ModelがViewに依存するのはインターフェースレベルでも問題だから

一方、ViewがModelのこと知りたいときにgetterじゃなく
Listener経由にするのは何のメリットがあるの？
ViewなんてインターフェースレベルじゃどうやったってModelに依存するだろよ
0678デフォルトの名無しさん2011/08/10(水) 02:15:49.21
>>673
なるほど、getter が必要な箇所は全て先回りで登録しておくのか
i'll do this job with your info じゃなくて let you do this job with your info とするのね

毎回モデルに仕事を発注するのが激しく面倒くさそうだけど、不可能ではないね
0679デフォルトの名無しさん2011/08/10(水) 02:18:20.59
>>675
なにいいたいのか解らない
0680デフォルトの名無しさん2011/08/10(水) 02:23:36.10
不可能ではないが、自然ではない。
技術に凝り過ぎで、わかりやすい設計を忘れてるな。

直感的な設計を心がけよ。

プロより。
0681デフォルトの名無しさん2011/08/10(水) 02:26:45.00
だな。それが○○なら
持っているはずべきものを
持っているのが正しい設計だ。

getterが嫌だからという理由で
設計するのは間違いだ。
0682デフォルトの名無しさん2011/08/10(水) 02:27:51.86
>>675
可能ということと、人間が理解しやすいということは別問題。

可能不可能で言えば、アセンブラで書くことだって可能だろう。
0683デフォルトの名無しさん2011/08/10(水) 02:27:54.66
変数の束縛の代わりに引数を使って全てを処理をする様にプログラムを書き直せる
ってのは分かるけど、それでプログラムが分かりやすく奇麗になるかは微妙だな
0684デフォルトの名無しさん2011/08/10(水) 02:30:21.53
resizeが発生しないとウインドウサイズは取得できないん？
最初からリスナーに登録してあるならいいけど後で登録してその後まったくresize発生しなかったらずっとサイズ取得できないじゃん？
0685デフォルトの名無しさん2011/08/10(水) 02:30:30.32
でも getter 不要論のちゃんとした根拠が聞けて良かった
明日ゆっくり考えよっと
0686デフォルトの名無しさん2011/08/10(水) 02:30:47.06
どうもね、ソースコードは書くのは人間読むのは人間という
当たり前のことを忘れている人がいる気がするよ。

説明が必要なコードと
説明がいらないコード、
大抵の場合、後者のほうが優れてるのさ。
0687デフォルトの名無しさん2011/08/10(水) 02:35:21.22
>>684
リサイズが発生したらリサイズイベントの引数で
高さと幅がおくられてくる。

あとはそれをメンバ変数に保存しておくコードを書けば
あとからいくらでも取得は可能。

面倒くさい？

このGUIオブジェクトを継承したら、
もちろん継承先でも、リサイズイベントが発生したときに
メンバ変数に保存するコードを書かないといけない。

面倒くさい？

でも面倒くさいだけでしょ。　　　　　　できるんだよーーーーーーーーーー！（笑）

ま、このオブジェクトのサイズを、リサイズイベントの送信者と受信者以外の
第三者から知りたいと思ってもわからいんだけどね。

欠点、いや欠陥。結局オブジェクトにサイズがある以上、それは外部から取得できたほうが良い。
0688デフォルトの名無しさん2011/08/10(水) 02:37:21.48
>>684
多分、

scaleModel.processWithCurrentWindowSize(callback func)

みたいにするんでないの
0689デフォルトの名無しさん2011/08/10(水) 02:37:32.54
>>677
1.インターフェースはモデルの最大公約数的情報を持ってる。
　これは、Viewがインターフェス越しにgetterをいくつも把握してんのと同じ。

2.インターフェースで渡す情報をモデルがフィールドとして持っているとは限らない。
　リスナーにブロードキャストするときに生成する事もできる。しかも、getterと違って、
　Viewが情報取得するときに計算するんじゃなく、一回のブロードキャスト毎に
　情報を生成する事ができる。これにより無駄なロスが減る。

3.ブロードキャストを行う時、モデル側の判断でリスナーのメソッドを選べる。
　最もViewに情報を渡すとき最も適切な渡し方は何か等はモデル側で判断できる。
　例えば情報が完全に空なら、画面にブランク状態であることを伝えてやったほうが効率的。
　但し、Viewの事を知ってる訳じゃない。受け取った内容をどうするかはView次第。
0690デフォルトの名無しさん2011/08/10(水) 02:44:02.59
getterだってフィールドで持ってるとは限りません
情報が空ならgetterで空を伝えれば良いです
0691デフォルトの名無しさん2011/08/10(水) 02:45:09.86
>>684
新規に登録したコントローラーにはイベントが飛ぶでしょ。
物による所はあるけど(クリックイベントは呼んでも仕方ないし)

見た目不自然とか、理解しづらいっていってる人は、結局C系統の
見方に慣れ切ってるって事だよ。もっと他の言語のOOライブラリを
見たほうがいい。
0692デフォルトの名無しさん2011/08/10(水) 02:46:04.99
さらに言えば、ブロードキャストするのは常に一定のコストがかかるので
getterで済むならgetterの方が無駄なロスは無いでしょう
0693デフォルトの名無しさん2011/08/10(水) 02:47:18.10
>>690
getter全てが空かViewがワザワザ調べるのかい？
それとも空を示すためのgetterを用意するのかい？
そこまでgetterにこだわる理由がさっぱり解からん。
0694デフォルトの名無しさん2011/08/10(水) 02:48:10.68
>>691
> 見方に慣れ切ってるって事だよ。もっと他の言語のOOライブラリを
> 見たほうがいい。

お前こそ、見たほうがいいんじゃね？

GUIオブジェクトにサイズ取得のgetterが
存在しないものなんてないからさ。
0695デフォルトの名無しさん2011/08/10(水) 02:49:49.12
理解し辛いのは実行コンテクストが入り乱れるからだと思われ

getter なら、必要なデータを貰って来て俺が処理するぜというだけなので、分かりやすい

リスナー形式だと、こういう時にこれやっといて欲しいんだけど、その時はこの情報が必要ね、
それが終わったら俺がこれするから、みたいな感じでパッと見分かり辛い
0696デフォルトの名無しさん2011/08/10(水) 02:50:53.26
その都度問い合わせればいいのと
リスナーごとに保存しとかなきゃいけないのじゃ
メモリ使用量に差が出そうかな？
0697デフォルトの名無しさん2011/08/10(水) 02:52:45.22
>>693
あなたは>>689で
>受け取った内容をどうするかはView次第。
って書いてますよね？getterだろうがListenerだろうが情報が空のときに
Viewの判断は必要です

それに、getterの排除に拘ってるのはそっちでは？
こっちはあっても無くてもどっちでもいいです
0698デフォルトの名無しさん2011/08/10(水) 02:53:15.78
>>692
ブロードキャストはMVCの為のもので、
呼び出しの連鎖とは切り離せるものだよ。
呼び出しだけで考えてもgetterより遅くなるということはないよ。
0699デフォルトの名無しさん2011/08/10(水) 02:58:33.16
>>698
getterだって適当なキャッシュ機構があれば
ブロードキャストより遅くなることは無いけどな
0700デフォルトの名無しさん2011/08/10(水) 02:59:01.74
だからぁ、リサイズ時にgetterなしでやれるということと
サイズのgetterを持つべきか否かってのは別問題なんだって。
0701デフォルトの名無しさん2011/08/10(水) 02:59:49.80
結局、getter を使った

this.doSomethingWithCurrentColor( model.getCurrentColor() );

と、

コールバックを使った

model.doSomethingWithCurrentColor( this.doSomethingWithCurrentColor );

のどっちが奇麗かって話だよね?
0702デフォルトの名無しさん2011/08/10(水) 03:00:36.61
>>697
全てがnullを渡すとき = clearが呼ばれるという仕様なら、
Viewからすればnullを渡してんのと変わらないし。
しかもView毎にチェックする分無駄じゃん。
0703デフォルトの名無しさん2011/08/10(水) 03:04:08.66
getter については色々紛糾しているけど、
setter の必要性については誰も異論が無いみたいだから、とりあえず世界の半分は救われたなw
0704デフォルトの名無しさん2011/08/10(水) 03:06:20.05
>>702
> 全てがnullを渡すとき = clearが呼ばれるという仕様なら、

これはModel側が処理を持つべき仕様なら
Modelに全てnullか問い合わせるメソッドがあればいいです
もしView側が判断する仕様ならブロードキャストだろうと
Viewが全部チェックしなきゃダメです
0705デフォルトの名無しさん2011/08/10(水) 03:07:56.39
>>703
>>574
0706デフォルトの名無しさん2011/08/10(水) 03:14:30.37
どーでもいいけど、MVCの概略図みるとビューからモデルへの直接的なAssociationがある
http://ja.wikipedia.org/wiki/Model_View_Controller

getterが憎くて憎くて仕方ない人は、別に好きにしたらいいけど
それはMVCじゃないよ
0707デフォルトの名無しさん2011/08/10(水) 03:18:31.55
質問。

ボタンを押したら、そのボタンのサイズが
親ウインドウいっぱいに広がるということをしたい時、
getterなしでやるにはどうすればいいのでしょうか？
0708デフォルトの名無しさん2011/08/10(水) 03:23:18.11
もし、getter、setterがあれば、

ボタンクリック時に、これを書けばいいだけだな。
button.setLeft(0);
button.setTop(0);
button.setWidth(parent.getWidth());
button.setHeight(parent.getHeight());
0709デフォルトの名無しさん2011/08/10(水) 03:26:20.16
プロパティをサポートしている言語ならもっと直感的に書ける。

button.left = 0;
button.top = 0;
button.width = parent.width;
button.height = parent.height;

setter/getterでも、メソッドチェーンできるように作られていればこうなるな。
button.setLeft(0).setTop(0)
.setWidth(parent.getWidth())
.setHeight(parent.getHeight());
0710デフォルトの名無しさん2011/08/10(水) 03:49:30.03
最近Observerパターン覚えて万能感に浸っちゃってるお子様に
マジになってどうするの
何でも再帰で書ける！とかと一緒で麻疹みたいなもん
放っとけば目が覚めるよ
0711デフォルトの名無しさん2011/08/10(水) 05:09:23.43
>>689
ListenerというよりObserverといってくれるとわかりやすい
ListenerだとControllerのEventListenerと分かり難い
0712デフォルトの名無しさん2011/08/10(水) 05:34:49.28
>>706
getterがあることで何が問題かということだよな
Javaで用意されているObserverインターフェースではModelがViewに伝わるような機構になってるし、getterは問題ないと思う

getterの問題ではないけど、このときにViewからModelのロジック部分の処理を実行されてしまう可能性があることが問題かな
Modelのロジック部分はViewからは実行されたくないが、ControllerやModelからは実行を許可しなければいけない
Modelそのまま渡すのではなくgetter専用のインターフェースをViewに渡すのが正解？

あとこの点線と実線の違いは何なんだ？
結局ModelもViewのインスタンスをListとして保持していて、Modelに変更があった場合は保持しているviewに対してview.update()を実行して変更を通知するんだよね
0713デフォルトの名無しさん2011/08/10(水) 06:12:30.53
１つずつバラバラに取得できないようにするだけでも取得箇所を１箇所に限定できる
0714デフォルトの名無しさん2011/08/10(水) 06:13:04.93
両方実線にしたら循環参照じゃん
0715デフォルトの名無しさん2011/08/10(水) 06:19:00.43
馬鹿がよく作るよね
0716デフォルトの名無しさん2011/08/10(水) 06:24:10.73
>>714
それはわかるけど、具体的に点線と実線でどう実装に違いがあるのかがわからない
0717デフォルトの名無しさん2011/08/10(水) 06:29:01.41
常人はgetter使ってMVCを実装するから
0718デフォルトの名無しさん2011/08/10(水) 06:31:29.72
でもそうするとバグが増えるんだよね
0719デフォルトの名無しさん2011/08/10(水) 06:33:48.72
>>717
MVCでObserverパターン使うことと、getterを使うか使わないかは関係ない
0720デフォルトの名無しさん2011/08/10(水) 06:36:26.26
setをいくら使ってもそれが必要なのはupdate的メソッドが呼ばれたときだけなんだろ？
したらupdateの引数でまとめて渡せよ

getもバラバラに取得できる形じゃなくて構造体でドカっと渡したほうがいいと思う

結局、クラス間での受け渡しの仕様が確定してないからバラバラにsetやgetを作りたがるんだろう
0721デフォルトの名無しさん2011/08/10(水) 06:46:16.40
>>719
普通はgetter/setterを使ったV→Mの呼び出しと、Observerを使ったM→V呼び出しの実装上の違いなんて聞かなくても分かるって意味

>>720
Vが増えたり、Mの項目が増えたりするのは全然恥ずかしいことじゃないだろ
0722デフォルトの名無しさん2011/08/10(水) 07:25:27.34
>>721
それがわからないから教えて欲しいんだよ
具体的なコードはイメージできてるんだけど、どうしてObserverでMからVが点線で、VからMは実線なの？
0723デフォルトの名無しさん2011/08/10(水) 07:33:05.16
>>722
Vは明示的にMを参照してるが、Mはインターフェイス経由なのでVとは認識してない
07245302011/08/10(水) 07:44:26.99
>>707
親ウィンドウの、WindowManagerを切り替える。
WindowManagerについては既出なんで他のレスを参照の事。
07255302011/08/10(水) 07:53:04.15
>>704
他のオブジェクトから受け取った値で条件分岐
結局フラグを使う手続き型から離れられられないんだな。
07265302011/08/10(水) 07:58:28.48
>>709
4回も再描写か腐ってるね。
0727デフォルトの名無しさん2011/08/10(水) 08:03:51.28
>>721
インターフェース上の項目は勝手に増やしちゃいかんよ。
Model側の実装は増やしても構わないけど。
MVCライブラリでそれやると破綻する。
0728デフォルトの名無しさん2011/08/10(水) 08:05:55.30
>>530って他のスレのレス番つけっぱなしだった
恥ずかち。
0729デフォルトの名無しさん2011/08/10(水) 08:10:43.55
>>727
モデルに状態を持たせて、常に完全な状態を渡して必要な値だけ変更するとか、
あるいは値が設定されたかどうかが判定できるようになっていれば問題ない
要はモデルをステートフルにすれば回避できる依存性なんだよ
0730デフォルトの名無しさん2011/08/10(水) 10:01:41.02
> 常に完全な状態を渡して

なんでそんな面倒なことせにゃならんの。
エンティティをまるごと扱うデカいゲッタセッタが作られてるだけじゃんソレ。
0731デフォルトの名無しさん2011/08/10(水) 11:22:51.72
Javaだと標準でタプルが無いから
getter, setterだと数字とか文字列をひとつずつ出し入れするイメージになるのかねぇ？
別に意味的にひとまとまりだったらgetter, setter でも
まとまりをやりとりすれば良いだけなのにね。

>>725
フラグも何もどのオブジェクトがどこまで責任を持つか、の話じゃねーの？
つーか、Mが更新されたときにVにどの情報を送るべきかはMが知ってるから
> 3.ブロードキャストを行う時、モデル側の判断でリスナーのメソッドを選べる。
は正しいけど、VがMの情報を知りたい場合どの情報を知りたいかはVが知ってる。
なんでVの事情までMが判断できるんだよ。
全部M→VにするとかアホだしそれMVCじゃねーよ。
0732デフォルトの名無しさん2011/08/10(水) 11:33:18.92
>>726
Observer使ったM→Vならブロードキャストするたび再描画だけど
getterを使ったV→Mならまとめて最後に一度だけ再描画するに決まってる。
馬鹿なの？ねえ馬鹿なの？
0733デフォルトの名無しさん2011/08/10(水) 12:20:07.53
>>726
> 4回も再描写か腐ってるね。

意味分からん
詳しく
0734デフォルトの名無しさん2011/08/10(水) 12:23:08.00
>>733
GUIは全てleftとかを更新したら即時に見た目に反映されるって思ってるんじゃね
即時反映を一時的に切る方法とかがあるのを見落としてるんだろ
0735デフォルトの名無しさん2011/08/10(水) 12:39:44.35
>>723
なるほど
納得しました ありがとう
0736デフォルトの名無しさん2011/08/10(水) 12:46:17.96
イベントの人と変態連想配列君に加えて
ブロードキャスターまで現れたのか
事態は混迷を深めていくな
0737デフォルトの名無しさん2011/08/10(水) 12:51:22.34
>>730
モデルはエンティティをまるごと扱うインスタンスだろ
あなたの考えるMはただのビジネスロジックです
0738デフォルトの名無しさん2011/08/10(水) 12:59:48.11
MVPはM-Vの直接の関連は無しで
P→Vがインターフェイス経由のsetter呼び出しで
V→PがObserverか直接のメソッド呼び出しだったかな
0739デフォルトの名無しさん2011/08/10(水) 15:05:05.85
>>737
え？
いや、だからエンティティの整合性はモデルの方で面倒見てよ、
って話なんだけど、なんか変？
0740デフォルトの名無しさん2011/08/10(水) 18:25:00.15
ヤバイ、一気にスレが埋まってく。過疎スレだったのに。
イベント君.に何か問い合わせてもマトモな情報が帰ってこない。
イベント君にはgetterが実装されてないからな。
だから、イベント君と会話のキャッチボールは成立しない。
出来ることといったら、イベント君にdoEvent発生させて、
何か独り言を書いてもらう。
俺らはそれのリスナーになって、イベント君本位の情報を得られるだけ。
こんな実装じゃ2chの会話すらままならない。
何か根本的な欠陥があるね。

とりあえずこんな人の部下にだけはなりたくねぇ。
分からないことがあって質問しても答えが返ってこない。
仕方ないので、チョッカイ出してイベント発生させて、
リスナーとなって黙って御高説を聞いとく。
話の内容から、本当に必要だった情報だけを精査して、明日に生かす。
よくある光景だね。リアルでは関わりあいたくない。
0741デフォルトの名無しさん2011/08/10(水) 19:16:52.41
>>739
だからエンティティにgetter/setterを用意して、使わない値は単に無視すればラウンドトリップできるようになってる
0742デフォルトの名無しさん2011/08/10(水) 19:31:22.20
>>740
俺、昨日消えてから発言してねーけど？
それにイベントはそっちがググッて見つけた定義でいいって言ったじゃんさっさとだしなよ
何逃げてんだよこの卑怯者
0743デフォルトの名無しさん2011/08/10(水) 19:34:38.39
>>732
実際どうやんの？
setを数回呼び出して、
そのあとupdateでも呼ぶの？
0744デフォルトの名無しさん2011/08/10(水) 19:36:40.13
>>731
モデルはメソッドを選べても、モデルはビューの事をそもそも知らないだろ。
getterで得られる値の種類がメソッドの種類に置き換わってるだけなんだから。
0745デフォルトの名無しさん2011/08/10(水) 19:37:58.84
>>740
てめーは自分の足場が絶対安全にならないと匿名掲示板ですら人と議論もできない最悪の糞ヤローだ
自分の本質を覚えておけ

誰に育てられたのか知らないけど
育ちが悪すぎる
生まれついての糞ヤローとかよくそんな恥かしい人間に育ったなと驚く
まあ、お前自身はそんな悪意はないのかもしれないけどな
0746デフォルトの名無しさん2011/08/10(水) 19:44:20.48
>>743
そうだよ？GUI書いた事無いの？
updateメッセージでGUIオブジェクトに一斉に再描画命令を送れるだろ
ブロードキャスター君の大好きなブロードキャストだよ
0747デフォルトの名無しさん2011/08/10(水) 19:44:43.39
>>736
ブロードキャスターねw
結局getter推奨は一部しか見て考えてない、考えられてないってのがよく解る発言だわ。

ブロードキャスト自体は、MVCの仕組み。
getterを排除できるっていってるのは、メソッドの相互呼び出しの結果。
Observerとかブロードキャストとかとその辺とは区別できないんだね。
0748デフォルトの名無しさん2011/08/10(水) 19:46:50.87
>>747
「4回も再描写か腐ってるね。（キリッ」

腐ってるのは貴方の頭ですwww
0749デフォルトの名無しさん2011/08/10(水) 19:47:42.18
getter推奨というよりは、あまりに直感的でない方法にどうなのよって言ってるだけでしょ
その際に素直な方法がgetterというだけで、別にgetterだから推奨してるワケではなく
0750デフォルトの名無しさん2011/08/10(水) 19:49:13.16
>>746
へーどのタイミングで呼ぶの？
最初から引数で渡すならそんな無駄なもん必要ないけど？
0751デフォルトの名無しさん2011/08/10(水) 19:52:09.66
>>748
object.setX(10);
object.setY(10);
object.update();
object.setWidth(10);
object.update();

object.setX(10)だの呼ぶのはコントローラーだけではない。
他との互換性がなくなってる。
ましてや、update()がどこかで自動で呼ばれるわけでもない。
どう見てもアホにしか見えない。
0752デフォルトの名無しさん2011/08/10(水) 19:54:49.84
えっ、GUIオブジェクトにビュー以外がsetできる設計？
なにそれこわい
0753デフォルトの名無しさん2011/08/10(水) 19:57:30.75
↑GUIオブジェクトっていう単語を始めて聞いたｗ
コンポーネントのことかな？　でもセットなんぞどこからでもできるし。
0754デフォルトの名無しさん2011/08/10(水) 19:58:19.01
ブロードキャスター、ブロードキャスターいってる下駄さんは、
こういうコードもブロードキャストだと思ってるんだろうな。
最も意味があるのはこの構造で、ブロードキャストは関係ないんだけど。

X objectA = new A();
X objectB = new B();
X objectC = new C();

objectA.changeSource( objectB );
objectB.changeSource( objectC );

objectA.changeResize( 10, 20 );



07557542011/08/10(水) 19:59:24.55
最後はただのresizeで良かった。ミスった。
0756デフォルトの名無しさん2011/08/10(水) 20:00:10.06
>>753
ビューがprivateで持ってるオブジェクトは外からセットできませんよ？
スコープの概念も無いの？
0757デフォルトの名無しさん2011/08/10(水) 20:01:56.16
>>756
ごめん>>752から読み始めたから何のこっちゃわからない。
俺が黙っとけばよかったねごめんね。
0758デフォルトの名無しさん2011/08/10(水) 20:02:15.95
描画は止められない、というかイベント処理が終わるまでブロックされるから1度しか発生しない
止めるのはレイアウト変更に伴う再計算
もちろん明示的に指定しなければ自動更新される

いい加減無知自慢とか糞設計ご開陳はやめてよ
0759デフォルトの名無しさん2011/08/10(水) 20:04:30.46
GUIはそのフレームワークというか、ライブラリ、
描画、イベントディスパッチのやり方次第のとこあるからなぁ。
0760デフォルトの名無しさん2011/08/10(水) 20:05:36.14
>>752
え？リサイズをビューがやんの？
データの描写以外も自分でやるビューて、何それ怖い。
0761デフォルトの名無しさん2011/08/10(水) 20:06:19.61
思いっきりビューの仕事だな
0762デフォルトの名無しさん2011/08/10(水) 20:07:49.36
>>758
イベントが終わったら自動的に実行されるって？
0763デフォルトの名無しさん2011/08/10(水) 20:09:37.02
>>761
WebのMVCしかやったことないだろ。
・コントローラーはどうやってViewのサイズを変えるんですか？
・ビューは何を基準に自分のサイズを決めるんですか？
0764デフォルトの名無しさん2011/08/10(水) 20:10:52.55
このスレの大半のヤツは、WebのMVCしかやったこと無いって。
0765デフォルトの名無しさん2011/08/10(水) 20:11:48.12
>>763
MVVM専だからね
・変える必要はない
・ビュー内部の独自仕様
0766デフォルトの名無しさん2011/08/10(水) 20:17:34.81
>>765
ああ、あの静的構造のパターンか。
MVCベースの話ししてんのに道理で、実際書いたこと無いような
的外れな事いってるわけだ。
0767デフォルトの名無しさん2011/08/10(水) 20:20:05.38
コントローラがビューのサイズに口出しするMVCなんて初耳だが
0768デフォルトの名無しさん2011/08/10(水) 20:23:46.60
>>767
そりゃ初耳なんだろうねぇ。SmalltalkやらKDE環境しらなきゃ初耳だろうし、
ControlerとViewがなんでUMLでは直に繋がってるか考えたことなけりゃ初耳だろうね。
0769デフォルトの名無しさん2011/08/10(水) 20:25:24.98
実際に書いたことがあるから妥協を本質と勘違いしちゃうんだろうね
0770デフォルトの名無しさん2011/08/10(水) 20:26:54.54
>>764
なにそれこわい。
俺は自作ゲームライブラリの自作GUIフレームワークにおける糞MVCと、
JavaのSwing上のそれと、C++とWin32APIでのそれしかやったことない。
0771デフォルトの名無しさん2011/08/10(水) 20:27:45.18
MVVMが聖典だと思ってるヤツに言われたかねぇよ。
0772デフォルトの名無しさん2011/08/10(水) 20:32:50.31
まあMVVMの視点ではサイズ情報をVMに配置しても何の問題もないんだけどね
07735372011/08/10(水) 20:36:59.72
今日はMVCをObserverパターンで書いてみた
public interface Subject {
　public void addObserver(Observer observer);
　public void notifyObservers();
　public void calcArea();
　public int getArea();
}

public class SquareModel implements Subject {
　private List<Observer> observerList;
　private int width; 　private int height; 　private int area;
　public SquareModel(int width, int height) {
　　this.width = width; 　　this.height = height; 　observerList = new ArrayList<Observer>();
　}
　@Override
　public int getArea() {
　　return area;
　}
　@Override
　public void calcArea() {
　　this.area = width * height;
　　this.notifyObservers();
　}
　@Override
　public void addObserver(Observer observer) {
　　observerList.add(observer);
　}
　@Override
　public void notifyObservers() {
　　for (Observer observer : observerList) {　observer.update(this);　}
　}
}
0774デフォルトの名無しさん2011/08/10(水) 20:37:47.48
リサイズ指示を受けられないビューってなんなんだ・・・？
いやWindowManagerをコントローラーからビューに渡してやって
リサイズ〜ってのは解る。でも、コントローラーから一切リサイズ指示は受けられないんだろ。
ウィンドウサイズとか再読み込みしたり、保存したりする機能をビューに追加するんだ、
ビューがファイルレベルの操作までするとは参ったねぇ。
07755372011/08/10(水) 20:40:12.00
public interface Observer {
　public void update(Subject squareModel);
}

public class SquareView implements Observer {
　private Subject squareModel;
　public void view() {
　　System.out.println("area = " + squareModel.getArea());
　}
　@Override
　public void update(Subject squareModel) {
　　this.squareModel = squareModel;
　　this.view();
　}
}

public class Controller {
　public static void main(String[] args) {
　　SquareModel squareModel = new SquareModel(3, 5);
　　squareModel.addObserver(new SquareView());
　　squareModel.calcArea();
　}
}

わからないこと
ViewにModelを丸ごと渡してgetterで値を取得するのは正しい？　それとも描画に利用する値のareaだけ渡すのが正しい？
updateメソッド内でviewメソッドを呼び出して描画を行うのは正しい？それともControllerでclacAreaメソッド実行後にviewメソッド実行した方がいい？
0776デフォルトの名無しさん2011/08/10(水) 20:40:24.65
>>773
ttp://www.jac-net.com/~tarzan/smalltalkers/mvc/mvc.html
ここ読んどきなよ。そもそもObserverの無いMVCは無いから。
0777デフォルトの名無しさん2011/08/10(水) 20:43:05.04
>>776
>>547-548はObserverパターン使ってないけど、これはMVCとは言えないとということ？
0778デフォルトの名無しさん2011/08/10(水) 20:43:19.80
http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design.aspx

MVC, MVP, MVVM の紹介
0779デフォルトの名無しさん2011/08/10(水) 20:47:00.36
>>547-548
はそもそも、サンプルだから要点を押さえようとだけするのはいいんだろうが、
cが無いよね、cが。MVだね。
「Cが入力を受け取る→mを変更→mが変更をv群に通知」この流れを抑えないと。
0780デフォルトの名無しさん2011/08/10(水) 20:49:41.06
>>777
まあそうなるね。
0781デフォルトの名無しさん2011/08/10(水) 20:52:29.96
>>779
main=Listenerと受け取ってくれると嬉しいです
KeyListenerでもActionListenerでもなんでもいいです

幅と高さが入力されて計算ボタンが押されたら計算結果が表示されるプログラム
という感じです。
今回の>>547-548では数値を入力してボタンを押すという処理は省略されていて、押されてからの処理がmainとして始まります
0782デフォルトの名無しさん2011/08/10(水) 20:54:30.77
>>780
そうなのか
確かに>>547-548だとwikipediaの画像のModelからViewへの破線は存在しないね

Model View Controller - Wikipedia
http://ja.wikipedia.org/wiki/Model_View_Controller
0783デフォルトの名無しさん2011/08/10(水) 20:56:18.29
http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design/MVC_MVP_MVVM_figure4.gif
あれ、コントローラーからビューのサイズ変更ができないよ？
0784デフォルトの名無しさん2011/08/10(水) 20:56:49.28
>>780
wikipediaにもちゃんと書いてあった

>また、データの変更をviewに通知するのもmodelの責任である（modelの変更を通知するのにObserver パターンが用いられることもある）。
>>547-548はデータの変更をModelがViewに伝えていないからMVCじゃないわけだ
ただのModelとViewとControllerで分けただけの何か
0785デフォルトの名無しさん2011/08/10(水) 21:00:53.83
>>784
分けただけの何か、を何と呼ぶかはちょい紛糾しそうだけど、
俺はそれ、別に悪くないと思うよ。元のMVCより関係が簡素になってるし、
それでうまくいってんならそれはそれでいいじゃん。

Mの通知を待たずに一秒間に60フレーム再描画するような環境もある。
その時、Mは通知のメカニズムは不要で、VがMを描画時に知っているだけでいい。
0786デフォルトの名無しさん2011/08/10(水) 21:06:10.93
>>783
あれれ、Smalltalkだとコントローラーがビューを参照してるよ何でだろうね
ttp://www.sra.co.jp/people/nisinaka/Jun4Java/MVC/vw-mvc-class.gif
0787デフォルトの名無しさん2011/08/10(水) 21:07:42.60
>>786
Smalltalkがガラパゴスだからだよ
0788デフォルトの名無しさん2011/08/10(水) 21:09:41.17
>>786
VとCが癒着しきったM-VCしか想定してないから
0789デフォルトの名無しさん2011/08/10(水) 21:10:16.94
>>783
Viewのサイズ情報をModelが持っていればできるんじゃないかな
それが正しいのかどうか知らないけど
0790デフォルトの名無しさん2011/08/10(水) 21:13:22.58
>>784
えっとね。MVCの利点は、[サウンド]モデルを[スピーカー]ビューと、[ビジュアライザ]ビューに
つないで、音を再生すると同時に、画面に合わせたイメージを表示するとかが一貫した方法で
できるってのがあるんだ。

ほかにも、エクセルの表みたいなビューとグラフに同じモデルを表示するとかね。

これのおかげで、Sqeak Toysなんかは、ビューとモデルとコントローラーをマウスで
つなげるだけで、簡単なアプリケーションを作れたりするんだ。
0791デフォルトの名無しさん2011/08/10(水) 21:14:14.83
ウィンドウがリサイズされたときの小窓の再配置とかを、
Viewそのものが実行するか、Controllerが請け負うかの違いだろうな。
0792デフォルトの名無しさん2011/08/10(水) 21:16:34.71
>>790
同時にスピーカとビジュアライザに表示するというところがMVCのObserverパターンの肝ということだよね

確かにそう考えると>>775の2つめの疑問は解消できる

>updateメソッド内でviewメソッドを呼び出して描画を行うのは正しい？それともControllerでclacAreaメソッド実行後にviewメソッド実行した方がいい？
正しい
0793デフォルトの名無しさん2011/08/10(水) 21:17:18.35
GUIでMVCやってると気分高まってくるよな。
「うはｗｗｗこれで実行時に入れ替え放題やんｗｗｗ
クラス階層もすっきりしまくりんぐｗｗｗメリットだらけｗｗｗ」
と、数年前の２ちゃんなら表現しただろう。
0794デフォルトの名無しさん2011/08/10(水) 21:17:41.53
>>787
Smalltalkが本家で他は方言でしか無いんだけど。

>>788
インターフェースで分離されてるわけだけど。

Form view = new Form();
ClosableView targetView = view;

view.addActionListener( new CloseControl( view ) );
0795デフォルトの名無しさん2011/08/10(水) 21:21:40.86
VとCの関係がどうなってるかはそこまで重要じゃないと思うがなぁ。
だって、どうせControllerって大した仕事しないでしょ。
0796デフォルトの名無しさん2011/08/10(水) 21:22:21.86
>>791
小窓の再配置はViewでやっても構わないんだ。
WindowManagerとか噛ますのが一番汎用的だけど。
問題は、設定として保存したウィンドウサイズの復元とか。
まぁ、モデルにウィンドウ情報渡しといて、モデルに基づいて
ウィンドウサイズ復元って手もあるけど。個人的には、これが
一番綺麗だと思う。
0797デフォルトの名無しさん2011/08/10(水) 21:24:44.25
>>795
大したっつうか汎用的なコントローラーなら二度と作らなくて
いいところに意義があるんだけど。
0798デフォルトの名無しさん2011/08/10(水) 21:29:21.60
>>794
それは>>786の図でいうところの Execute Event じゃないの？
ちょっと矢印の向きがどっちがどっちか分からなくなってきたw
0799デフォルトの名無しさん2011/08/10(水) 21:29:40.43
確かにCは小さいイメージあるな。
入力をモデルの変更へ割り当てるだけだから。
汎用的というよりは、固有の処理をここに局所化したような存在かと。
08007972011/08/10(水) 21:30:43.76
ごめん。一番重要なのは、コントローラーが動的に差し替えられる事だね。
Squeak eToysみたいな感じで、実行時にドラッグアンドドロップで動作を変えられるとか、
KDEのランチャーとかもいい例だよ。
0801デフォルトの名無しさん2011/08/10(水) 21:32:24.83
ちょっと待って俺が勘違いしているのかも試練。
MVCのCって、ボタンとかも含まれるの？
俺はてっきりそういうのは全部Vの仕事で、
Cは単なるイベントマッピング的なものかと思ってたんだが。
0802デフォルトの名無しさん2011/08/10(水) 21:33:53.65
ウィンドウのリサイズみたいな処理はビューだけでやるんじゃないの？
コントローラやモデルが関わってしまったら、
例えばビューをウィンドウさえ無いCUI端末に切り替えるのは
不可能になりそうだけど・・・
08037942011/08/10(水) 21:34:43.65
よくよく考えたらviewをそのまま渡して意味のないことしてる。
説明ならこれで十分か。

Form view = new Form();
view.addActionListener( new CloseControl( (ClosableView) view ) );
0804デフォルトの名無しさん2011/08/10(水) 21:36:07.95
>>801
ボタンはビューだよ。

button.addActionListener( new Controller() );
0805デフォルトの名無しさん2011/08/10(水) 21:41:23.89
>>799
モデルへの変更を伴わない入力は
ビューがコントローラへ通知しなくても良いってこと？
0806デフォルトの名無しさん2011/08/10(水) 21:42:26.46
>>801
ボタンはV、ListenerがC
ボタンを押すことにより、Cｂﾌ処理が実行さｂ黷

ただ拡張MVCというM+VCっていう考え方もある

>>802
ウィンドウのリサイズだったら
1. Viewのサイズを決定する(ウィンドウズだとウィンドウの端っこを引っ張る)
2. そのときのイベントがControllerに渡る
3. Controllerはイベントから新たなウィンドウサイズを取得
4. ControllerはViewであるウィンドウのデータを保持しているModelの更新処理を行う
5. Modelは変更されるとともにViewに対して変更があったことを通知する
6. そのときModelがViewに渡る
7. ViewはModelから新たなウィンドウサイズを取得して描画
8. 終わり
0807デフォルトの名無しさん2011/08/10(水) 21:43:28.95
>>802
コントローラーとビューは完全に独立してる訳じゃないからね。
例えば、new CloseControl( button );なんて出来ても困るわけだし。
コントローラーも相手はある程度選ぶ。

最も、Viewの目的は↓ができる事で、それ意外のサイズとかって部分は
そもそも外のにある話なのよ。
ttp://www.sra.co.jp/people/nisinaka/Jun4Java/MVC/mvc.gif
0808デフォルトの名無しさん2011/08/10(水) 21:47:03.59
>>805
ビューがコントローラへ通知？
GUIコンポーネント経由でコントローラへ入力イベントが通知されるなら、
それがモデルを変更するかどうかはコントローラがまさに決めることであって、
GUIコンポーネント側が判断することはできないと思う。しようとしても冗長。
0809デフォルトの名無しさん2011/08/10(水) 21:47:38.50
サッカー見ているうちに大分話が進んでてもう付いていけないわ・・・
0810デフォルトの名無しさん2011/08/10(水) 21:49:53.32
でもまぁ、View自体がモデルデータを持ってる、なんてヘマは普通に書いてりゃ絶対しないから、
何も考えずに書いても勝手にMVCっぽいものにはなる罠。
0811デフォルトの名無しさん2011/08/10(水) 21:51:02.74
>>807
詳しいみたいだから恥をしのんで聞いちゃうけど、
Wikipedia（http://ja.wikipedia.org/wiki/Model_View_Controller）の
「MVCのシナリオ」の項目をみると、まずユーザの入力はビューが受け取って、
その後コントローラがビューからの入力イベントを処理するって書いてあるんですよ

そうするとモデルに関係ないイベントをビューがコントローラに通知する意味って何なのかなって
ビュー --> コントローラ --> モデル --> ビュー ってルート通らず
ビューだけで処理したほうが良いと思うんだけど
08128062011/08/10(水) 21:53:46.39
wikipediaのMVCの図に当てはめてみた

下の数字と>>806の数字は対応してるわけじゃありません
http://2ch-ita.net/upfiles/file12034.png
0813デフォルトの名無しさん2011/08/10(水) 21:58:03.62
>>811
それしちゃうと>>807の画像で示していることができないよ
1つのデータ郡(Model)から複数のViewに表現できるっていうのがメリットなんだけど、
そのイベントを発生させたビューだけが変更されたのでは、>>807でいうその他のグラフが古いデータのままになっちゃう

イベントを発生させたビューが関連するすべてのビューに変更があったことを通知すれば可能だけど、
そんなことビューが管理するとすごい複雑になっちゃう
1つのデータ郡に対応して4つのビューがある場合、1つのビューはその他3つのビューを管理する必要がでてくる
0814デフォルトの名無しさん2011/08/10(水) 22:01:20.04
>>813
「モデルに関係ないイベント」って書いてあるぞ
0815デフォルトの名無しさん2011/08/10(水) 22:01:58.61
>>813
えーと、例えば>>807の画像でですね、3次元グラフをマウスでぐりぐりと
回転させたとするじゃないですか
これってモデル（データ）と何の関係も無いですよね？
こういうイベントってビューだけで処理しちゃダメなんですか？
0816デフォルトの名無しさん2011/08/10(水) 22:03:23.85
>>811
モデルを使うか使わないかはコントローラー次第でしょ。
もしかしたら、そのイベントをコントローラーはモデルに送るかもしれない。
それと、ビューのレイアウトがビューの中で完結しちゃうと、
ビューの知らないレイアウトを追加できなくなるでしょ。
もしかしたら、ユーザー操作で動的に変わるレイアウトかもしれない。

>>806
　その理解でいいと思うよ。
0817デフォルトの名無しさん2011/08/10(水) 22:07:22.56
>>815
グリグリさせたく無いときはどうするの？
グリグリの操作方法をグネグネに変えたい時はどうするの？

(具体的には、左右にドラッグすると、右左に行く場合と、左右ロールする場合)
0818デフォルトの名無しさん2011/08/10(水) 22:09:16.35
つまり、CはVのコールバックだと思っとけば良いの？
0819デフォルトの名無しさん2011/08/10(水) 22:09:27.30
グリグリはMVCの話題から離れると思う。
Vが独自にマウスイベントを拾ってステキな振る舞いを勝手にしてる、
と考えたほうがよくないかこれ。
0820デフォルトの名無しさん2011/08/10(水) 22:11:17.06
>>812書いてみて思ったけど、綺麗にいくとControllerからViewへの参照って必要ないね
確かに理論上はModelの変更がない限りViewの変更は必要ないか

ControllerがModelへの参照を持ち、ModelからViewへの参照を持つだけがMVCの理想型かな


>>815
その回転角度や位置情報もModelと捉えれば>>813も適用できると思うよ
ただこれは理想型の話だから、実際にそこまで分割する意味があるのかっていうのは状況にもよると思う
もしViewに角度や位置情報を持たせるのなら、Controllerで位置変化のイベントを受け取ってViewへの更新を行うのかもね
>>812でいうControllerからViewへの実線がそれにあたる

更に手間を省くならViewにListener(Controller)の機能を持たせちゃってView内部で簡潔することも可能
これはいわゆる拡張MVCだね

ほんと現場でどれがいいかは、すべてを理解したうえで使い分けるのが正しいと思う
それを理解していないのに、拡張MVCやMVCにすらなってない設計をして、MVCは現場に即していないと文句を言うやつは間違ってる
0821デフォルトの名無しさん2011/08/10(水) 22:11:55.81
>>817
えーと、質問の意図がつかみきれていませんが、
ぐりぐりさせられるかどうかはビューじゃなくて
コントローラ（かモデル）が決める事って意味ですか？
0822デフォルトの名無しさん2011/08/10(水) 22:13:53.43
>>818
そう
CはVのコールバック
VはMのコールバック
>>812の点線の部分ね
Observerパターンで実現されている
0823デフォルトの名無しさん2011/08/10(水) 22:15:32.94
>>820
> その回転角度や位置情報もModelと捉えれば>>813も適用できると思うよ

それはもちろんそうですが、元々は２次元グラフを表示するプログラムを
３次元グラフの表示に切り替えるときに、ビューだけを切り替えれば良いのが
理想だと思うのですよ
でも、その方法だとモデルも変更する必要がありますよね
0824デフォルトの名無しさん2011/08/10(水) 22:16:52.34
自称初心者がアホを釣っているようにしか見えない
真剣に質問してんのなら、>>815の感性で正しいからね
0825デフォルトの名無しさん2011/08/10(水) 22:19:04.61
>>819
まぁ、MVCの話ではあるよ。領域としては端のほうかもしれないけどさ。

MouseControllers controllers = new MouseControllers();

Menu changeMenu = new Menu();
BoxView3D view = new BoxView3D()

controllers.addMouseListener( new PitchControl( view ) );
controllers.addMouseListener( new DragControl( view ) );
controllers.addMouseListener( new NullControl( ) );

view.addMouseListener( controllers );
changeMenu.addActionListener( new ListShiftControl( controllers );
0826デフォルトの名無しさん2011/08/10(水) 22:22:12.55
>>818
純粋なコールバックと違ってラムダのように状態をもてたり、
複数コールバック用のメソッドもってたりするけどね。
0827デフォルトの名無しさん2011/08/10(水) 22:25:10.76
勢いあるから次スレ立てた

【OOP】オブジェクト指向総合 part3【OOA/OOD】
http://hibari.2ch.net/test/read.cgi/tech/1312982517/
0828デフォルトの名無しさん2011/08/10(水) 22:29:03.10
>>823
ViewとModelは対応するものだから、基本的にModelが変わればViewが変わるのは問題ないことだと思うよ
Viewだけ切り替えれば良いっていうのは、クラスとしては確かにViewクラスが1つ変更されただけかもしれないけど、
MVCとして捉えればMとVが変わっているわけだから結局は同じことだと思う
0829デフォルトの名無しさん2011/08/10(水) 22:32:18.62
もう「全部入れ替えれば問題ないよ」って言葉は聞き飽きた
汎用性はどこに行ったんだ
0830デフォルトの名無しさん2011/08/10(水) 22:37:10.23
>>828
View自体で独立した視点を持ってるのは有りだよ。
本当に元データを弄りたい時だけ、モデルをいじればいいし。

PolygonModel model = new PolygonModel()

//ビューポート1
BoxView3D view1 = new BoxView3D();
model.addModelListener( view1 );
view1.addMouseListener( new DragControl( view1 ) );

//ビューポート2
BoxView3D view2 = new BoxView3D();
model.addModelListener( view2 );
view2.addMouseListener( new DragControl( view2 ) );

//ビューポート3
BoxView3D view3 = new BoxView3D();
model.addModelListener( view3 );
//ここだけモデルを直接弄る。
view3.addMouseListener( new EditControl( model ) );
0831デフォルトの名無しさん2011/08/10(水) 22:37:18.74
MVCは汎用性あんま関係ないような。
クラス間のやりとりが理解しやすい、
クラス階層がヘンなもんにならない、なりにくい、
っていう苦肉の策じゃね。複雑で癒着しがちなやりとりに対する。
0832デフォルトの名無しさん2011/08/10(水) 22:37:28.61
>>823,829
>>812の画像でいう実線は依存だから、依存先が変更されたら依存元も変更されるのはしょうがない
依存関係があるところ以外は汎用性があるよね

まったく依存関係がないいプログラムはありえない
その中でもできる限り依存を減らして便利に使い回したり、設計しやすくしたりしたいよね　というものだと思ってる
思ってるだけで正解かどうかは知らない
0833デフォルトの名無しさん2011/08/10(水) 22:39:24.27
>>829
「全部入れ替える」ってのが何を指してんのか解からん
0834デフォルトの名無しさん2011/08/10(水) 22:40:05.27
例えば、Ｖｉｅｗで入力された項目やＶｉｅｗのウィンドウの配置をデータベースに覚えておく場合はどうなんだろ？
0835デフォルトの名無しさん2011/08/10(水) 22:41:33.35
>>834
Modelの先にDBがある
ModelでDB更新時に、ViewにDB変更があったことを通知
0836デフォルトの名無しさん2011/08/10(水) 22:41:49.80
>>834
ウィンドウの属性をモデルに持たせればいいよ。
0837デフォルトの名無しさん2011/08/10(水) 22:43:18.32
undoデータやredoデータってのは誰がもつんかな？（もちろんＶｉｅｗ２、３も含めたね）
Ｖｉｅｗ１だけならわかるけど
Ｖｉｅｗ２、Ｖｉｅｗ３って絡んだときにこのデータってＭ確実に変わるよね？
ＭＶＣってこういうのですでに死んでると思うんだけど
Ｃ少ないかみんな？俺はＣは一番でかくなるんだけどこういう客の要望いちいち聞いてるからかなぁ？
なんか組んだことない人の臭いしちゃうんだよね？ここの人
0838デフォルトの名無しさん2011/08/10(水) 22:44:35.08
クマー
0839デフォルトの名無しさん2011/08/10(水) 22:45:08.02
でも、一つのモデルに複数のウィンドウなりビューなりを作れちゃうのがMVCだからなぁ。
その場合モデルはビューのインスタンスと情報の対応表を持つことになるね。
0840デフォルトの名無しさん2011/08/10(水) 22:45:21.80
ぱっきゅらおん
0841デフォルトの名無しさん2011/08/10(水) 22:47:36.01
>>833
「(クラスを)全部入れ替えれば(追加要件があっても)問題ないよ」ってことで
0842デフォルトの名無しさん2011/08/10(水) 22:48:24.94
>>837
モデルのUndo,Redoならモデルに、ViewのUndo,Redoなら、Undo,Redo用のモデルをViewに絡ませとく。
0843デフォルトの名無しさん2011/08/10(水) 22:50:02.92
>>841
今までのレスだと、どんなの？
0844デフォルトの名無しさん2011/08/10(水) 22:51:29.80
すっとやっぱり
大元のＭ
Ｖ１用のＭＶ１
Ｖ２用のＭＶ２
Ｖ３用のＭＶ３
が必要になるよね
っていうか現実としてなってる
ちなみに俺は面倒なので現実にはこんなクラスは作ってなくて
ＭがＶｉｅｗ１、２，３が存在する前提の作りになっちゃってる
色んなデータが必要になるから
わざわざＶｉｅｗが値保持しないって設計守ってやってるせいもあってか
もうＭＶＣにしてるメリット欠片もないけどねｗ
0845デフォルトの名無しさん2011/08/10(水) 22:58:06.90
まー確かにView固有の情報をModelに持たせるってのは、なんかアレだよな。
0846デフォルトの名無しさん2011/08/10(水) 23:01:31.96
>>843

>>823>>829に対する>>832
0847デフォルトの名無しさん2011/08/10(水) 23:04:49.25
ＭＶＣの説明にＶが複数になったときになんたらがメリットとか説明に書いてあったけど
こんな基本機能もどこにおいときゃわかんねー設計でメリットあんのかよって感じ
マイクロソフトの技術者もＶＳの画面触るだけでヌケが見えるレベル
結局、Ｖ→Ｍのデータの流れ、Ｍ→Ｖのデータの流れがあるから吸収するＣがとてつもなくでかくなる
Ｍ１Ｖ１用のＭＶＣ１、Ｍ２Ｖ２用のＭＶＣ２・・・とか作ってもいいぐらいでかい
っていうかそもそもＭＶＣとかやめろって上司の言われたのでこの構造無視してる

はじめのインターフェースがどうとかってのは多分絵に描いた餅で終わってるんじゃないだろうか？
0848デフォルトの名無しさん2011/08/10(水) 23:07:57.82
>>846 よく解からんけど、解ったわ。
0849デフォルトの名無しさん2011/08/10(水) 23:10:42.05
>>848
お、他の人が答えてくれてるｗ

あとgetter否定派の疑似コードに突っ込むと高確率で「メソッド追加すれば対応できる」って言うよ
他のスレでイベントの人っぽいのが暴れてた時は酷かった
0850デフォルトの名無しさん2011/08/10(水) 23:11:29.24
GUIって力技で何とかなっちゃうし
こんな重箱の隅の話より人間工学的な話のほうが有意義だよね。
0851デフォルトの名無しさん2011/08/10(水) 23:12:05.55
>>847
まぁ、MSはマトモにMVCなんてしてないからね。
本当にしてるんだったら、汎用コントローラーとモデルをいくつか用意しとくべきだし。
DBのデータ表示する程度なら、既存のモデルとコントローラーの組み合わせで作れるぐらいにしとくべきだ。
0852デフォルトの名無しさん2011/08/10(水) 23:12:16.24
>>850
たとえば？
0853デフォルトの名無しさん2011/08/10(水) 23:13:21.70
View固有の情報をViewだけで処理せず
頑にControllerやModelへ結びつけるのは何故？
無駄に依存させておいて「依存関係があるのは仕方ない」とか言って
Viewを追加するたびにControllerやModelも拡張するとかナンセンスすぎる
0854デフォルトの名無しさん2011/08/10(水) 23:14:14.92
>>853
フツーはしないから。
だからこそ、Vがでかくなるんだ。
0855デフォルトの名無しさん2011/08/10(水) 23:16:45.31
context_controller.set( model_key, view_key, context );
みたいなコントローラがあれば良いかもね。
model_keyはモデル中の何かの要素をあらわしたもの。ポインタで良いかな。
view_keyはビューのインスタンスを表したもの。これもポインタで良いかな。
contextは対応付けたい情報。構造体へのポインタとかで良いでしょ。
0856デフォルトの名無しさん2011/08/10(水) 23:19:15.40
>>853
View固有の情報ってなに？
その情報をファイルとか外部と入出力するときもViewで行うの？
0857デフォルトの名無しさん2011/08/10(水) 23:20:33.76
>>856
ぶっちゃけそのほうがいいんじゃないか？
0858デフォルトの名無しさん2011/08/10(水) 23:21:58.19
>>854
基本Vはでかいけど、例えばグラフ描画ソフトなんかだと
Mがもっとでかいから相対的に気にならないんだけどね
MがDBからデータ引っ張ってくるだけだと、
Vばかり大きくてアンバランスな気がするかもね
0859デフォルトの名無しさん2011/08/10(水) 23:22:02.34
処理に必要なデータは、できるだけ処理の近くに置き、
隠蔽しておけるのなら、喜んで隠蔽しておく。
ビューに必要な内部構造を隠しておくのは、ビューに他ならない。
0860デフォルトの名無しさん2011/08/10(水) 23:23:18.75
>>854
モデルとビューで同じような構造のデータを二重に持つことになるからね。
モデルにおいておいたほうが楽っちゃ楽だわな。
機能レイヤー視点での切り分けは悪くなるがな。
array of structure と structure of array の違い。
0861デフォルトの名無しさん2011/08/10(水) 23:25:08.77
>>857
したいんならすればいいんじゃないとも思わんでもないけど、
俺は、出力先が、XMLだったり、レジストリだったりってのはMVCに基づいてモデルに抽出するわ。
いちいちViewを継承したりして静的に拡張したくない。実行時に差し替えたりも効かなくなるし。
0862デフォルトの名無しさん2011/08/10(水) 23:25:28.36
> モデルとビューで同じような構造のデータを二重に持つことになるからね。

なるか？ｗ
固有の描画のための固有の内部構造を追加で持つだけでは？
0863デフォルトの名無しさん2011/08/10(水) 23:25:52.80
Ｖｉｅｗの位置情報とかフォーカス、履歴（Ｖｉｅｗ特有の情報）をＤＢのユーザデータに残しておきたいときとかも
やっぱり保存するのはＶｉｅｗの役目ってほうがすっきりするな
ＭＣはリストラでｗ
0864デフォルトの名無しさん2011/08/10(水) 23:31:27.44
>>863
Modelでも同じ情報もってたら構造が重複するけどね。
3Dモデルなんかだと、Model自身の向きと、Viewによる向きの2つあるし。
他にも照明のセッティングだの色々重複するね。
0865デフォルトの名無しさん2011/08/10(水) 23:33:15.13
>>862
エクスプローラのようなものを考えた場合、
モデルはフォルダ階層をノードで表したものになるだろう。
で、ツリービューを考えると、「開いてる/閉じてる」の情報を覚えておくために、
ツリービュー自身もやっぱりフォルダ階層をノードで表したものを持つ羽目になる。
木構造を二重に持つのはしんどいし、
ツリービューのどのノードがモデルのどのノードに対応するか判断するための参照も必要かもしれないし、
うぜぇ。
モデルのノードにこっそりbool extended;って追加したくなる気もわかる。
0866デフォルトの名無しさん2011/08/10(水) 23:33:22.23
>>864
特有の情報の話だけだってば
0867デフォルトの名無しさん2011/08/10(水) 23:35:37.10
>>865
なるほどね。
俺ならノードごとに map<* node, bool>みたいなんを内部に持たせといて終わりかな。
んで、描画時にモデルから要素をたどりつつ、上記の内部構造を使う。そーいう話？
0868デフォルトの名無しさん2011/08/10(水) 23:36:17.99
↑アスタリスク消し忘れ。
0869デフォルトの名無しさん2011/08/10(水) 23:38:00.61
>>865
超デジャビュー
それを頑なに「やってくれないと金払えない」的な勢いで押し込んできた客いたなぁ
（まあ、あのフォルダたくさんあったから開くたびに開きなおしとか勘弁してくれってのはあったけどね）
0870デフォルトの名無しさん2011/08/10(水) 23:38:10.53
>>867
実際には俺もそうするけどね。
>>855で書いたとおり。
0871デフォルトの名無しさん2011/08/10(水) 23:40:35.58
>>870
結局そっちのほうが何倍も清々しいもんね。
0872デフォルトの名無しさん2011/08/10(水) 23:43:10.51
なんかこのスレをさらーっとナナメ読みしてると、所々懐かしのDoc-Viewを思い出すなぁ
0873デフォルトの名無しさん2011/08/10(水) 23:43:51.00
Docいらねーし
Viewだけ書くよ
0874デフォルトの名無しさん2011/08/10(水) 23:48:32.91
>>871
ビューが複数になったときにも対応できるしね。
エクスプローラみたいなものなら、モデル一つで窓一杯って普通にありえるもんね。
こう言う　structure of array 的な発想って、多々出てくるから、
そろそろ言語レベルで何とかサポートして欲しいよ。
それかデザインパターン化して、大手を振れるようにして欲しい。
0875デフォルトの名無しさん2011/08/10(水) 23:52:13.89
その場合ってＭとＶを循環参照させるの？
それともＣを巨大化？
0876デフォルトの名無しさん2011/08/10(水) 23:58:23.55
>>865
ツリービューのGUIコンポーネントの描画実装のメンドさに比べりゃ

> 木構造を二重に持つのはしんどいし、

なんて誤差の範囲だけどねー
0877デフォルトの名無しさん2011/08/10(水) 23:58:42.66
>>875
どっちでもいいんじゃない？
Viewに持たせた方が参照一回分早いからオシシメ。
0878デフォルトの名無しさん2011/08/11(木) 00:01:48.98
言語レベルｗ
0879デフォルトの名無しさん2011/08/11(木) 00:02:31.57
>>876
２つもって同期までとること考えたら２つもつのはありえんなｗ
0880デフォルトの名無しさん2011/08/11(木) 00:05:39.51
>>879
そのとおりだね。
ツリービューとリストビューがフォルダ開閉の情報を共有するなら
モデルに持つべきだし、
それぞれのビューが独立にフォルダ開閉の情報を持つなら
ビューが持つべき。
つまり要求される仕様による。
0881デフォルトの名無しさん2011/08/11(木) 00:06:44.36
>>874
よくわかんないけど.NETのバインディングじゃダメなん？

いい加減TreeViewにクラス突っ込めるようにして欲しい。
0882デフォルトの名無しさん2011/08/11(木) 00:07:42.60
>>807で、ひとつのグラフを回転させたら
全部のグラフが回転し始めたら、俺なら笑っちゃうかもしれんw
0883デフォルトの名無しさん2011/08/11(木) 00:09:32.11
>>882
ステキやん？　とも一瞬オモタｗ
0884デフォルトの名無しさん2011/08/11(木) 00:19:26.17
>>880
こういうやり方もあるけどね。
TreeModel model = new TreeModel();
new ContextTreeModel( model ).addModelListener( view1 );
new ContextTreeModel( model ).addModelListener( view2 );
new ContextTreeModel( model ).addModelListener( view3 );
0885デフォルトの名無しさん2011/08/11(木) 00:22:30.95
View固有の情報をView自身に持たせるのは、
モジュールの独立性の観点からは良いんだけど、
唯一の難点はViewが複雑になるところだね。
Viewって自動テストしにくいから、なるべく状態とか
持たせて複雑にしたくない。
0886デフォルトの名無しさん2011/08/11(木) 00:32:17.98
>>884
こういうやりかたもあるけどね、ってそのままじゃん。
クラス名にXxxModelって書いとけばモデルが持ってる事になるのかい？
0887デフォルトの名無しさん2011/08/11(木) 00:40:07.07
>>885
どっかが複雑さを請け負うことによって、
他がスッとするというのは、俺はもう黙って受け入れることにした。
Mediatorパターンとかもね。そのクラス単体は複雑になるけれど、
クラス間のやりとりが単純になるほうが恩恵がドでかいもんねぇ。
0888デフォルトの名無しさん2011/08/11(木) 00:44:36.01
色んな考え方があるな
0889デフォルトの名無しさん2011/08/11(木) 00:49:00.19
>>886
そうだね。ContextTreeModel自体はオブジェクトとして別々のツリーを持ってるって事。
Viewに持たせず外だしにしてるだけ。
0890デフォルトの名無しさん2011/08/11(木) 00:52:42.72
なんかControllerとViewについては出尽くした感じがするけど、
Modelの掘り下げはあんまりないね。どういう変更メソッド持たせるとか、
粒度とか、Modelのネストとか。
0891デフォルトの名無しさん2011/08/11(木) 02:05:35.07
そこいくとまたgetter/setter（←だれかそろそろ略語生み出してくれ）の話題に戻りそうだが…。
0892デフォルトの名無しさん2011/08/11(木) 05:00:32.08
>>882
さすがにそれはModel分けるだろｗ
グラフデータを保持するModel
View1の位置情報Model
View2の位置情報Model
View3の位置情報Model

1つのViewに対して1つのModelってことはない
0893デフォルトの名無しさん2011/08/11(木) 05:09:19.26
>>891
アクセッサーor アクセサー

アクセサーとは : JavaA2Z
http://www.kab-studio.biz/Programing/JavaA2Z/Word/00000346.html
0894デフォルトの名無しさん2011/08/11(木) 07:10:46.81
結局V固有情報をVから出さずに複雑な処理をする場合、V内にVMが出来てM→VM⇔Vになるんじゃないかな
V→Mだけ申し訳程度にCを経由するけど
0895デフォルトの名無しさん2011/08/11(木) 07:55:00.26
もはやモデルとは何か、うごごご……のレベル
0896デフォルトの名無しさん2011/08/11(木) 08:30:47.61
>>892
二次元グラフと三次元グラフでは位置情報のデータ構造は違う
また折れ線グラフは拡大表示できるが、棒グラフは拡大できないとかも
あるかもしれない
つまりビュー固有の情報はビュー毎に情報の在り様が異なる

また、責務というかスコープというか、各ビューの情報にアクセスできるのは
それぞれのビューだけ（なのが望ましい）

それぞれのビュー固有の情報まで何々情報モデルと呼ぶのは勝手だけど、
それは状態を持つものはビューと呼びたくない、と言ってるだけで
本質的にはビューが持ってるも同然
0897デフォルトの名無しさん2011/08/11(木) 08:40:21.70
>>889も同じで、これをビューの外に出してるというのは
ただの言葉遊び
0898デフォルトの名無しさん2011/08/11(木) 09:00:50.79
もしもそれがモデルのように歩き、モデルのように鳴くのなら、それはモデルである
0899デフォルトの名無しさん2011/08/11(木) 09:16:22.21
Smalltalkerにとっては言葉遊びが全て（悪い意味ではなく）
0900デフォルトの名無しさん2011/08/11(木) 09:18:23.04
>>898
なにそのモデルタイピング。
0901デフォルトの名無しさん2011/08/11(木) 09:21:24.63
>>898
モデルと名付けたんだからモデルなんだい！ってのは
凄くnominalな態度で、duck-typingとは真逆なような
0902デフォルトの名無しさん2011/08/11(木) 09:47:31.48
>>896
MVCの理想型を意識して話します
MVCが設計が理想かどうかは別の話として聞いてください

viewに表示する数値も、グラフを表示するための情報も本質的にはViewの表示を決定付ける情報ということでは同様だと思う
この2つを区別しているのは人間の意識だけ
何故数値はモデルが持っていることを許せて、グラフの形の情報はモデルに持たせることが許せないのかがわからない

あとモデルとして分けたからといって、Viewがその状態を持たないというわけではない
0903デフォルトの名無しさん2011/08/11(木) 10:15:53.57
>>902
MVCのMはひとつのMを複数のVが観測できて、
Mの変化に全てのVが（同時に）反応できるというのが特徴だと思うから、だね
Vと一対一対応のデータ/処理まで（MVCの意味で）Mって呼んだら区別付かなくなる

あとwikipediaのMVCの概略図にもあるとおり、MからはVにもCにも実線が伸びてない
これは（MVCの理想型の話をするなら特に）Mは特定のVに依存してちゃダメってことでしょう

ただ、貴方のいうように解釈することも確かに可能
だからこの解釈も貴方の解釈も全部ひっくるめて、ただの言葉遊びに過ぎないんだろうね
どうせコードに落とせば同じ構造になるんだし
0904デフォルトの名無しさん2011/08/11(木) 12:40:11.09
また１つどこぞの馬鹿が考えた糞構造が暴露されたな
0905デフォルトの名無しさん2011/08/11(木) 13:16:43.11
>>902
プログラムの外から入力されるものではないから。
画面やファイルから入力出来ないものはモデルにならない。
0906デフォルトの名無しさん2011/08/11(木) 13:29:01.40
もう１つ言うと、
コントローラー=非同期入力
モデル=処理
ビュー＝出力
0907デフォルトの名無しさん2011/08/11(木) 13:51:56.47
マジレスすると、M=class V=getter C=setter
0908デフォルトの名無しさん2011/08/11(木) 14:00:34.69
>>903
1つのViewから利用されるデータはViewが持って、複数のViewから利用されるデータはModelが持つという区別はおかしいような
一カ所でしか表示されないデータって沢山あるよね
それらは全部Viewがデータを持つの？

Modelとしてクラスを用意するメリットとしては、同様のデータ形式を使い回せるということもあるよ
インスタンスレベルでは1つのViewとしか対応していなくても、同じクラスから生成された他のインスタンスが他のViewと対応しているような場合（表示したいデータが2種類、グラフも2種類のときとか）
これだと同様の表現形式だということが分かりやすい

あとMからVの破線はインターフェースを利用して通知するものであって、それは1つでも複数でも変わらないよ
0909デフォルトの名無しさん2011/08/11(木) 14:04:39.72
>>905
ウィンドウサイズを数値で入力できる場合はModelで、現在値からドラッグでサイズを変化させるときはViewということ？

後者も入力ではないのかな？
直接数値を与えていないだけで、どのくらいのサイズにするかはドラッグすることによってプログラムに与えているよね
0910デフォルトの名無しさん2011/08/11(木) 14:07:12.51
>>905

・・・んな阿呆な。まさに業務脳。

>>906

モデルは処理ではない。モデルはモデル。
脳みそが DFD を学んだ時から進歩していないんじゃねーの？

モデルを何かに喩えるならば、せめてプラトンのいう「イデア」や
アリストテレスのいう「エイドス」にすべき。
0911デフォルトの名無しさん2011/08/11(木) 14:18:11.34
イデアとか範囲が広すぎるからこの場合はドメインモデルぐらいが妥当なのでは
0912デフォルトの名無しさん2011/08/11(木) 14:21:38.84
と思ったが、エイドスはむしろ view かも・・・
誰か詳しい人、教えて。
0913デフォルトの名無しさん2011/08/11(木) 14:24:15.14
>>908
あるMのデータが「たまたま」ひとつのVでしか表示されないことと、
Vとデータが一対一対応していることは違うと思うけどね

まあ、決まりがあるわけじゃないから各自で好きに開発したらいいけど、
開発してるのがグラフ描画ソフトだったら、自分なら間違いなく
Vと一対一対応するデータはVに持たせるね
言い方を変えれば、特定の描画にしか関係しないデータ/処理をMとは呼ばない、と言ってもいい

最後に、共通の処理/アルゴリズムがあるなら好きなだけ共有したら良いよ
それはVの中だけで閉じた汎用性の話だから
0914デフォルトの名無しさん2011/08/11(木) 14:33:03.79
>>908
あと、こっちはMVCに勝手に期待してる事（各モジュールの独立性や汎用性）を元に
MVCというものを解釈してるけど、
貴方はそういうもの抜きに、ただMVCの構造だけ見て
どれだけ表現能力があるか、を言っているようにも見える
そういう意味では、貴方の方がより純粋にMVCというものを論じてるとは言えるだろうね
まさに、
> MVCの理想型を意識して話します
を実践している
0915デフォルトの名無しさん2011/08/11(木) 14:44:41.21
最後に、厳密に言えば描画に関係する処理がMに入ることはある
例えば、スプライン曲線の計算は棒グラフには関係ないけど、それでも自分ならMに実装するだろうね
一方、折れ線グラフの線の太さならVに実装する
何にしろ、グレーゾーンを意識しない意見（何々は絶対禁止とか）は往々にして極端すぎるよ
0916デフォルトの名無しさん2011/08/11(木) 15:58:26.37
このスレで糞設計披露してドヤ顔してるアホは
延々と糞設計を聞かされるこっちの身にもなれよ
0917デフォルトの名無しさん2011/08/11(木) 16:27:40.56
話題として出てるＭＶＣ自体が糞設計過ぎるからしょうがない
0918デフォルトの名無しさん2011/08/11(木) 16:55:53.48
smalltalk(笑)
0919デフォルトの名無しさん2011/08/11(木) 17:04:37.72
>>917
MVC が世間に認知される以前のソフトウエア設計は
もっと酷かったのを知っているか？

後から非難するのは簡単だよな。
0920デフォルトの名無しさん2011/08/11(木) 17:16:46.83
Smalltalkはウンコみたいな箱庭環境から出れない時点で糞
0921デフォルトの名無しさん2011/08/11(木) 17:22:21.49
>>917
良設計教えて
MVPやMVVMを詳しく知らないんだけどいいものなの？
0922デフォルトの名無しさん2011/08/11(木) 17:33:32.91
>>920
Java は？
ねぇ、Java は？
0923デフォルトの名無しさん2011/08/11(木) 17:36:28.97
>>922
JVMはウンコみたいな箱庭環境じゃないけどJavaが糞
0924デフォルトの名無しさん2011/08/11(木) 17:51:18.81
>>923
君は怖いと噂のScala使い？
0925デフォルトの名無しさん2011/08/11(木) 18:15:57.32
>>916-918
こいつニートか知識だけのガキだろ。
社会人なら働いてる時間に2chとは大したもんだ。

あと社会人なら気に入らないなら代案出すか無視するしな。
0926デフォルトの名無しさん2011/08/11(木) 18:29:07.76
>>921
Viewの状態を置く場所に困らない
名前と気分の問題
0927デフォルトの名無しさん2011/08/11(木) 18:30:39.29
>>925

俺は>>916-918ではないが、>>925が一番子供っぽいと思った。

>社会人なら働いてる時間に2chとは大したもんだ。

今年は夏休みを輪番で取る企業が多くってな。
そんなことも知らないのか？
0928デフォルトの名無しさん2011/08/11(木) 18:30:43.37
>>909
そうだよ。コントローラーはマウスとかタイマーとか
キューとかからも情報を受け取ってモデルに回す。
モデル自体も入出力はできるけど、非同期な物は
コントローラー経由で受けとる。
0929デフォルトの名無しさん2011/08/11(木) 18:50:52.54
http://ugaya40.net/wpf/mvvm-mvc-mvp-pm-eventdriven.html
分かりやすかった。
0930デフォルトの名無しさん2011/08/11(木) 19:18:41.48
MVCはSmalltalkが本家(ｷﾘｯ

時代遅れwww
0931デフォルトの名無しさん2011/08/11(木) 19:20:16.39
上みたいにこれはVでこれはMみたいな議論が起こらないように
V寄りのMはMとはっきり区別しましょうっていうのがMVPだよ
0932デフォルトの名無しさん2011/08/11(木) 19:23:23.58
Smalltalkの人は宣伝のつもりでやってんの？
はっきり言ってキチガイの使う言語って印象しか残らないけど
0933デフォルトの名無しさん2011/08/11(木) 19:29:10.54
俺はJavaっ子だからSmalltalkerの方々を尊敬するよ。
0934デフォルトの名無しさん2011/08/11(木) 19:44:20.32
海外の良書を書いてる人で現在Javaを書いているような人もSmalltalk使いが多いから尊敬してる
ただそれの過度な信者は嫌い
Macは嫌いじゃないけど過度なMac信者が嫌いなのと同じ
0935デフォルトの名無しさん2011/08/11(木) 19:58:26.13
>>910
モデル以外で何処でデータ処理する気なの？
まさか、コントローラーとビューですんのかい？
そりゃ、コントローラーも、ビューも処理っちゃ処理はするけどさ
そこで基軸となるデータ変更されたらもはやMVCはなりたたんぞ。
0936デフォルトの名無しさん2011/08/11(木) 20:22:51.36
Viewの情報も見た目もすべてMVCの原則に則ったものを実装してみた　また四角形の面積を表示するプログラム　今回は枠付き

//データのModel
public interface ShapeSubject {
　　public void addObserver(Observer observer);
　　public void notifyObservers();
　　public void calcArea();
　　public int getArea();
}

public class SquareModel implements ShapeSubject {
　　private List<Observer> observerList;　　private int width;　　private int height;　　private int area;
　　public SquareModel(int width, int height) {　　　　this.width = width;　　　　this.height = height;　　　　observerList = new ArrayList<Observer>();　　}
　　@Override
　　public int getArea() {
　　　　return area;
　　}
　　@Override
　　public void calcArea() {
　　　　this.area = width * height;
　　　　this.notifyObservers();
　　}
　　@Override
　　public void addObserver(Observer observer) {
　　　　observerList.add(observer);
　　}
　　@Override
　　public void notifyObservers() {
　　　　for (Observer observer : observerList) {　　　　　　observer.updateShape(this);　　　　}
　　}
}
0937デフォルトの名無しさん2011/08/11(木) 20:24:31.21
そこまで書くなら、codepadに貼ってきなよ。
あっちで貼ってもらったほうが見やすい。
0938デフォルトの名無しさん2011/08/11(木) 20:25:05.07
// 描画情報のModel
public interface FrameSubject {　　public void addObserver(Observer observer);　　public void notifyObservers();　　public int getFrameSize();　　public String getFrameString();　　public void changeFrame(int frameSize, String frameString);}

public class FrameModel implements FrameSubject {
　　private List<Observer> observerList;　　private int frameSize;　　private String frameString;
　　public FrameModel(int frameSize, String frameString) {　　　　this.frameSize = frameSize;　　　　this.frameString = frameString;　　　　observerList = new ArrayList<Observer>();　　}
　　@Override
　　public int getFrameSize() {
　　　　return frameSize;
　　}
　　@Override
　　public String getFrameString() {
　　　　return frameString;
　　}
　　@Override
　　public void changeFrame(int frameSize, String frameString) {
　　　　this.frameSize = frameSize;
　　　　this.frameString = frameString;
　　　　this.notifyObservers();
　　}
　　@Override
　　public void addObserver(Observer observer) {
　　　　observerList.add(observer);
　　}
　　@Override
　　public void notifyObservers() {
　　　　for (Observer observer : observerList) {
　　　　　　observer.updateFrame(this);
　　　　}
　　}
}
0939デフォルトの名無しさん2011/08/11(木) 20:27:01.69
>>936
　　public void addObserver(Observer observer);
　　public void notifyObservers();
別にこれをビューに見せる必要はないでしょ。
ましてやnotifyObserversはprivateにすべきだし。
0940デフォルトの名無しさん2011/08/11(木) 20:30:44.49
>>937
ありがとう
こりゃ便利


//データのModel
http://ideone.com/tR45i

// 描画情報のModel
http://ideone.com/rOxtr

// View
http://ideone.com/YB0ZL

// Controller
http://ideone.com/8wx1s
0941デフォルトの名無しさん2011/08/11(木) 20:33:21.38
>>939
すいません
アクセス修飾子に気を配っていませんでした
addObserverはViewには必要ないんですけどControllerに公開する必要があるのでpublicです。
notifyObservers()はprivateの方が良いですね
0942デフォルトの名無しさん2011/08/11(木) 20:39:54.42
枠の情報はMVCに則らないパターン

//データのModel >>940と変わらず
http://ideone.com/tR45i

// 描画情報のModel　変わった
http://ideone.com/4Splk

// View　>>940と変わらず
http://ideone.com/YB0ZL

// Controller 変わった
http://ideone.com/iS9QF

どっちがいいか・・・状況に寄るんだろうね
0943デフォルトの名無しさん2011/08/11(木) 20:43:28.97
>>940と>>942の出力結果
計算後に表示
枠変更後に表示



■□■□■□■□■□■□■□■□■□■□
area = 15
■□■□■□■□■□■□■□■□■□■□
--------------------
area = 15
--------------------
0944デフォルトの名無しさん2011/08/11(木) 20:43:31.12
>>940
　MVCの問題じゃなく個人的な意見だけど、
mainメソッドのあるクラスは、ControllerよりModelが良いと思う。
ModelがViewやControllerを持ってるってのはMVCに矛盾するけど、
他の言語じゃmainはクラスに属してないし、MVCの外にあるから、
それほど問題にはならない。

　で、こっからが重要なんだけど、プログラムで1つしか無いモデルが
できる事が多い。他のほとんどのモデルを格納するモデル。
プログラムの個性そのものを体現したようなモデルができる事が
割とあるんだよ。そのモデルは、2個3個つくってもあまり意味がないから、
mainクラスにしちゃう。
0945デフォルトの名無しさん2011/08/11(木) 20:45:11.26
>>941
Controller向けのインターフェースを付けたらいいじゃない。
Viewには必要最低限の情報だけ見せときゃいいよ。
0946デフォルトの名無しさん2011/08/11(木) 20:45:53.35
>>939
>>941
やっぱりnotifyObservers()はインターフェースなのでpublicでした
0947デフォルトの名無しさん2011/08/11(木) 20:51:05.57
>>946
なぜインターフェースだと思ったの？
0948デフォルトの名無しさん2011/08/11(木) 20:52:11.98
>>944
＞前半へのレス
Observer登録するところまではmainメソッドなので他のクラスでもいいですね
けどどうしてControllerよりModelの方がいいの？

面積を計算するところと枠の変更は、Listenerで受け取るところなので,Controllerの○○Listenrメソッドで実行されるのが正しいと思いますが、
今回はそこらへんは省略しています。

＞後半へのレス
すいません　よくわかりません

>>945
なるほど
addObserverメソッドとnotifyObserversメソッドはController用のインターフェース
それ以外のgetterはView用のインターフェースとするのが綺麗ですね
0949デフォルトの名無しさん2011/08/11(木) 20:54:20.05
>>947
実装を強制する意味でインターフェースにこれらのメソッドを追加しています。
0950デフォルトの名無しさん2011/08/11(木) 21:02:47.99
>>949
インターフェースはあくまで、外に見せるための物。
強制だけの目的でつくると無用な依存関係を増やすから良くないよ。
あと、更新処理をどういう形で用意するかはモデルの自由なんで、
その意味でもインターフェースにするべきじゃない。

あと、蛇足だけどインターフェースとソースの分け方がおかしい。
例えばObserversだったら、モデルと一緒に置いとけばいいし、
寧ろこういう書き方でもいい。ObserverはModelが要求してるんであって、
Viewが要求してるわけじゃないからね。

class XxxxModel
{
      public interface Observer
      {
           ・・・略・・・
      }
}

class YyyyView implements XxxxModel.Observer
{
・・・略・・・
}
0951デフォルトの名無しさん2011/08/11(木) 21:16:05.66
>>948
class ApplicationModel
        implements
             TopWindowA.Model,
             TopWindowB.Model
{
       private ModelX modelA;
       private ModelY modelB;
       ・・・メソッド省略・・・
       public void main(String arg[])
       {
              ApplicatinModel model = new ApplicationModel(); //プログラム中全てのmodelが入っている
              TopWindowA view1 = new TopWindowA();//最上位のview
              TopWindowB view2 = new TopWindowB();//最上位のview

              model.addListener( view1 );
              model.addListener( view2 );
       }
}
0952デフォルトの名無しさん2011/08/11(木) 21:33:38.94
>>950
例えば今は四角形の面積だけど、三角形の面積を求めるモデルを新たに追加したいときShapeで共通のインターフェースを持っていると、
Viewは四角形や三角形を意識せず面積がある形ということだけを意識できるのでいいかなっと思ったりしました（後出しですいません

インターフェースの置き方って意識したことがなかった
パッケージで単純に似たもの同士まとめてたんだけど、どれが要求しているかをを意識するものなんだ

>>951
Facadeパターンですね
やっていることはわかるのだけど、どうしてそういう構造になっているとmainメソッドをModelに置くのかがわかりません
0953デフォルトの名無しさん2011/08/11(木) 21:45:40.46
>>952
ホントいうと、Observerをモデルクラス本体に置かず、
君ので言えばShapeSubjectに置いとく方がいいよ。

interface ShapeSubject
{
     public interface Observer{}
     public int getArea();
}
class TrigonModel implements ShapeSubject
{
}
class SquareModel implements ShapeSubject
{
}
0954デフォルトの名無しさん2011/08/11(木) 21:56:00.60
>>952
mainが唯一の存在で有ることと、ApplicationModelが唯一で有ることから。
まぁ、ApplicationModelを他のプログラムで最利用してもいいんだけどね。
もうひとつは、コントローラーはnew MoveControl( model, view );みたいな名前に
なるんで、名前が合わないって所。まぁ、mainをコントローラーの中に入れて、
こんな使い方でもいいかもしれないけどね。

static void main(String args[])
{
        ApplicationModel model = new ApplicationModel( args );
        ApplicationControl control = new ApplicationControl( model );
        control.execute();
}
0955デフォルトの名無しさん2011/08/12(金) 00:09:46.42
ttp://ideone.com/4qsIS
JavaのSwingを使って最小限のMVC表現を行おうとしたが…。
もともと、GUIコンポーネントをViewと言い放っていいのかどうか迷いがあったので、
それが迷ったままになってしまった。パネルの描画部分をオーバーライドして、
クラスの役割を描画であると強調したつもりだがどうだろうか。
0956デフォルトの名無しさん2011/08/12(金) 05:03:13.83
>>955
実行イメージくれくれ
0957デフォルトの名無しさん2011/08/12(金) 11:11:21.84
同じ画面に、ユーザーが円グラフのデータの一つを選択して
その値を表示したり変更したりする機能を付けたくなったらどうする?
データをソートしたくなったら?
0958デフォルトの名無しさん2011/08/12(金) 11:49:26.03
>>957
ソースコードがあればユーザが自分で付け加えられるね
REPLで実行できるなら実行中に機能を追加出来てもっと良いね
0959デフォルトの名無しさん2011/08/12(金) 12:06:14.84
これはVでこれはMみたいな議論はもう飽きた。
どうせ相手の意見を聞く気もないんだろ？
0960デフォルトの名無しさん2011/08/12(金) 12:37:40.28
もともとはアクセサーの話だったと思うが、「MVCでもアクセサーいらないよ」派はまだ息してるの？
0961デフォルトの名無しさん2011/08/12(金) 12:40:47.57
全部モデルにぶち込む君の糞設計は
>>929で分類されるところの「古典的MVC」
0962デフォルトの名無しさん2011/08/12(金) 13:09:03.95
>>957
グラフに表示してるデータを編集したいってこと？
それとも、グラフに表示してるデータの複製を編集したいってこと？
それともグラフに表示してるデータの一切れ分を編集したいってこと？
0963デフォルトの名無しさん2011/08/12(金) 13:20:24.65
>>960
ＭＶＣ自体いいのかどうなのかよくわからないし
その上にさらにマシマシした構造で必要とか言われても結局よくわからない
結局、Ｍの都合の悪いタイミングにgetしたら不味いタイミングあっちゃうのに
なんかgetつけてるって実装が大半に見えるけどね俺には
0964デフォルトの名無しさん2011/08/12(金) 14:03:15.53
>>963
・よく分からないのに「MVCでもアクセサーいらないよ」派なのですか？
・M→Vのデータ伝播は本質的存在で、その方針は重要なインターフェイスです
・それはカプセル化や非同期処理の問題です
・日本のPGの数割はパターンに関係なくふざけたコードを書くので、間違った実装の目撃例で物事を語らないでください

ていうか「マシマシした」って何？
ラーメン？
0965デフォルトの名無しさん2011/08/12(金) 14:39:33.75
アクセサあるだけでレースコンディション発生させちゃう男のひとって・・・
0966デフォルトの名無しさん2011/08/12(金) 15:19:56.56
getImageというメソッドがあるとすると
都合の悪いタイミングで画像を見られるのを避けるには
ダブルバッファリングするだけ。
getterやめる必要はない。
0967デフォルトの名無しさん2011/08/12(金) 15:26:07.62
>>964
>・M→Vのデータ伝播は本質的存在で、その方針は重要なインターフェイスです
これをget使ってやらなきゃいけないって決まりはあるの？
0968デフォルトの名無しさん2011/08/12(金) 17:00:47.01
>>967
無いよ。get使っちゃダメって決まりも無いけど。
0969デフォルトの名無しさん2011/08/12(金) 17:26:50.13
>>962
最終的にもとのデータを変更するかどうかは関係ないでしょ
どっちにしてもビュー固有の表示状態、編集状態、選択状態は必要
0970デフォルトの名無しさん2011/08/12(金) 18:13:26.50
>>969
957本人？
0971デフォルトの名無しさん2011/08/12(金) 18:35:55.20
>>968
じゃあ、普通にオブジェクト間同士の関連を実装すればいいんちゃう？
getでどんなタイミングでもアクセスしちゃえるように作るのをＭＶＣは正当化してないよねぇ？
ＭＶＣ出した人はちょっと何がいいたいのかわからないって結論になっちゃったんじゃない？
このスレ的には
0972デフォルトの名無しさん2011/08/12(金) 18:52:56.52
だからgetあったらレースコンディション発生ってどういう理屈だよ
アホ過ぎるだろ
0973デフォルトの名無しさん2011/08/12(金) 19:17:42.68
ビューがモデルの属性X1, ... Xnを表示でき、かつそれらを
どう組み合わせて表示するかはユーザが実行中に選べるとする
（例えばX2, X4, X6, ... だけ表示する等）

このとき、getterを使う方法とObserverパターンで
各々どういうコードになるの？
0974デフォルトの名無しさん2011/08/12(金) 20:12:34.58
>>972
だってそれって呼ぶ側が注意しないといけないんでしょう？
しかるべき箇所でキチンとイベント決めてまとめるべきじゃないの？
0975デフォルトの名無しさん2011/08/12(金) 20:35:00.49
>>956
ttp://ideone.com/plain/4qsIS
MvcTest.javaという名前で保存したらそのままコンパイルできます。
0976デフォルトの名無しさん2011/08/12(金) 20:37:33.71
>>974
>>966
0977デフォルトの名無しさん2011/08/12(金) 20:57:41.60
>>974
ビューのメソッド（内部でモデルからゲッツしてる）も全部イベントとして
コントローラ経由で起動すればいいんじゃないの？
0978デフォルトの名無しさん2011/08/12(金) 21:58:49.95
まあ、そうだとしてもそのイベント名がgetじゃダメだよね
0979デフォルトの名無しさん2011/08/12(金) 22:13:45.96
もうgetter派には触れるなって。ヤツらコボラーと同じで頭が固まってんだから。
getter無しで一通りプログラムを組んだこともないし、試しに組んでみようとしようもしない。
getter無しでどう組めるか想像もできないから妄想だけで否定だけしてる。
相手するだけ無駄。
0980デフォルトの名無しさん2011/08/12(金) 22:16:41.34
>979
頭が固いのはお前では？

まず、なぜGUIに限って
getterなしにこだわるのか
その理由を答えてほしい。
0981デフォルトの名無しさん2011/08/12(金) 22:23:23.86
>>979
ブロードキャスター君、じゃなかったナローキャスター君チーッスwww
0982デフォルトの名無しさん2011/08/12(金) 22:28:20.74
まあ、getter無しで組める、というだけで
getter禁止を正当化する理由になると思うほどの低能は
相手するだけ無駄だよな。
0983デフォルトの名無しさん2011/08/12(金) 22:36:43.71
モデルに全データ/処理を突っ込む
古くさーいMVCを未だに信仰してる人に
頭固いとか言われたくないですwww
0984デフォルトの名無しさん2011/08/12(金) 22:56:09.50
副作用無くてもモナドがあれば組めるから
副作用使うの禁止、のほうが納得がいくレベル
0985デフォルトの名無しさん2011/08/12(金) 23:00:39.42
言われたくないとか言われたいとかは所詮主観だからな
0986デフォルトの名無しさん2011/08/12(金) 23:15:45.01
>>971
一応援護しとくと、getterを排除しとくメリットは、MVCやブロードキャスティングに利用することより、
オブジェクト自身の判断で値の渡し方を判断するって事が大きい。
object1.setValue(object2.getValue());なんて呼び出しじゃ、この値の渡し方を判断してるのは、
object1でもobject2でもない。例えば、object1.toValue(object2);と渡せるようにしてやったとすると、
値の渡し方を判断するのは、object1になる。object1は、object2が持ってるメソッドの中で、
今の自分の状態で最も適切に渡せるものを選んで渡すことができる。
0987デフォルトの名無しさん2011/08/12(金) 23:16:48.80
モナドって外から見れば副作用そのものじゃん
0988デフォルトの名無しさん2011/08/12(金) 23:17:05.86
オブジェクト自身の判断で値の取得方法も判断したいわあ
0989デフォルトの名無しさん2011/08/12(金) 23:25:27.94
>>986
うん。それはgetterを使わない理由であって
getterを排除する理由じゃないね。

じゃ、次。
0990デフォルトの名無しさん2011/08/12(金) 23:27:23.77
>object1.toValue(object2);

で、toValueの中でgetter使うんでしょw
0991デフォルトの名無しさん2011/08/12(金) 23:29:40.20
view.reAcquisition(model) って呼び出しだと、値の受け取りを判断するのはviewになる
reAcquisitionの中でviewはmodelが持ってるgetterの中で
今の自分の状態で最も適切に受け取れるものを選んで受け取ることができる
0992デフォルトの名無しさん2011/08/12(金) 23:30:53.88
>>986
> object1.toValue(object2);と渡せるようにしてやったとすると、

それをやるとオブジェクト間の依存度が強まることになる。
いったいobject1はobject2の何を必要としているの？

object1は大した情報を必要としていないのに、
object2を必要としてしまう。

toValueが必要とする値をobject2の型ではなく、インターフェースにしておけば、
必要なのは「そのインターフェース」と明確に最小限に
することもできるが、そんなことをするとインターフェースが多くなりすぎる。

それが例え型がない言語であったとしても、結局はなんの関数を使うのかを
インターフェースの代わりにドキュメントにまとめなきゃいけないので
結局は同じこと。
0993デフォルトの名無しさん2011/08/12(金) 23:34:52.29
>>991
> view.reAcquisition(model) って呼び出しだと、値の受け取りを判断するのはviewになる

それは、modelという”値” を渡しているだけ。
値が単純な値ではなく、複雑な構造の値になっているだけ。
結局値を渡しているのはコントローラ
0994デフォルトの名無しさん2011/08/12(金) 23:35:20.66
>>990
使う必要ないだろ。なんの"為"に使うんだよ。なんの"意味"があるんだよ。
入れる余地なんざないだろ。

//object1が、内部で文字列として持っている場合
void toValue(Numeric target)
{
       target.convertFrom( "100", 10 );
}

//object1が内部で整数として持っている場合
void toValue(Numeric target)
{
       target.convertFrom( 10 );
}
0995デフォルトの名無しさん2011/08/12(金) 23:36:59.00
>>993
object1.toValue(object2) もobject1にobject2を渡してるだけですね
馬鹿じゃね？www
0996デフォルトの名無しさん2011/08/12(金) 23:38:14.77
>>986
>>991
こんだけパラレルに書かれると分かり易いな
0997デフォルトの名無しさん2011/08/12(金) 23:38:23.89
>>994
その関数に何の意味があるの？

オブジェクトが内部で整数として持っている場合に、
整数で取り出すとき、わざわざconvertって名前の関数をつけるの？

それってさ、getterの名前を変えただけじゃね？
0998デフォルトの名無しさん2011/08/12(金) 23:38:31.11
>>992
インターフェースが増える事になんの問題が？
そんなんだったらMVCだろうが、MVVMだろうが、MVPだろうが満足に書けんだろ。
0999デフォルトの名無しさん2011/08/12(金) 23:39:45.83
>>998
引数に渡すときの、最小のインターフェースが
数値型とかじゃねーの？
1000デフォルトの名無しさん2011/08/12(金) 23:39:56.53
>>701でFA
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。