オブジェクト指向は遅い

高速グラフィック処理には向いてない。

作り方の問題だろ。
C++を使ってOOでつくられたグラフイックスエンジンは
いっぱいあるじゃん。

まぁ、>>1に作れと言っても無理だろうが..

Mac板でぼやいてたのはおまえか？

ゲッター、セッターの存在意義が不明
こういう余計な実装で処理速度を落としてると思うと馬鹿馬鹿しい
#define private public
#define protected public

>>1
いまどきこんな化石がいるのかｗ

>>1
オールアセンブラで全て最適化しろ

ゲッター、セッターの存在意義がわからないということは、
カプセル化の意味すら理解していないようだね。
こりゃ根本から勉強しないとダメだね。

まあ機械的に多少のムダがあっても人に理解しやすい
というのがOOPのコンセプトだからな
保守性や拡張性などのメリットがデメリットを上回るから使われる

ゲッター、セッターを付けるのがカプセル化。
値チェック処理を入れてデバッグを容易にするメリットがあるのは知ってる。

ダメだこりゃ

カプセル化の真のメリットは、リフレクションの適用やAOP、キーバリューコーディング等を用いたフレームワークやデータマネジメントへの展開にあると思う。

速度に拘ってるんだから、c++の話だよね?
getter/setterはinline展開されるように書けば
速度は落ちないと思うよ。

なんでもかんでもOOにしなきゃいんだろが。適材適所。
アクセス頻度の高い描画用データにゃゲッタ/セッタは不要。
マネージャクラスとか、モデルクラスとかにはOOを使えばいい。
つか、ゲームとかは、まさにOOにうってつけのドメインだろ。

そもそも「高速グラフィック処理」の定義が不明確。
馬鹿の一つ覚えの小学生みたいな印象しか受けない。

ここまでネタカキコなし

　　おチンチンびろーん
　　 ∩＿＿＿∩
　　 | ノ　　　　　 ヽ/⌒)
　 /⌒) (ﾟ)　　　(ﾟ)　|　.|
　/　/　 　( _●_)　 ミ/
.（　　ヽ　　|∪|　　／
　＼　　　 ヽノ　/
　 /　　　　　　/
　|　　　_つ　 /
　|　 /UJ＼　＼
　|　/ 　　　 )　 )
　∪　 　　 （　 ＼
　　　　 　　 ＼＿)

>>1
現代のパソコン等でグラフィックを高速に処理するコツは、
如何にデータをリアルタイムでベクトル化するかと、如何に並列化するか。そして、如何に計算の大部分をGPUなどのベクトル演算器にまかせるか。

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

ようするに、「オブジェクト指向を使わずに書いたから速くなりました」的な最適化は、
根本的な仕組みや数式の改良をできない、能力の低い人が、仕方なくやる類の最適化だと思うよ。

そもそもDirectXがCOMベース。

>>4
心配しなくても、ちゃんとインライン展開してくれるから。

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

実はオブジェクト指向ってしっくりこないんです！

オブジェクト指向が遅い理由は、あくまで妄想ですが、
クラスの中にプログラマが使用しないメソッドが含まれていて、
それらがインスタンス生成時にメモリー上に不必要に読み込まれるから？
一切使わないメソッドは削って、ソースを作り直せば速度が向上されるのか？

何と比べて遅いのか。
あるいは満たすべき速度の基準があって、それを満たしていないことが確認されたのか。

>>22
そのとおり。
妄想です。

配列で用足りるならオブジェクト指向じゃなくてもいいじゃん？みたいな。

>>22
恥ずかしいから口を謹んだほうがいいよwww

>>4

I/O系の低水準クラスにデータメンバー積むのかよ。
I/O系のクラスとデータ処理用のクラスを、
同じインターフェースで扱うって発想は無いんだろうな。

>>22
VTBL調べろ。

実際オブジェクトが足枷になるのは、
SIMDが上手く使えないとか、メッセージに対応する
メソッドの選択(仮想関数の呼び出し)にコストが掛かる、メモリ確保にコストが掛かるぐらいだろ。
基本的に実用上問題になるのはSIMDの問題ぐらい。
後はアルゴリズム改良の方がよっぽど効果がある　

ちょっとだけOO知ったから、にわかオブジェクト指向でプログラムしたけど。
設計がとんでもなクソなのが理解できなくて、オブジェクト指向のせいにした１デスね。
１よ！自分以外の他人のせいにすると楽だよね。でも、こんな所に出しちゃダメ。
恥かくから。

10年前だったらもうちょっと反対派も頑張ってたのになぁ

へえ

ところで、オブジェクト志向って何のことだい？

指向だったかなw

遅いとかよりも・・・オブジェクト指向って一度基本クラス
(とくにインターフェイス)の設計に失敗すると後々しんどい。
だからと言ってラッパーやリーダークラス作るくらいなら
外部のstaticメソッドにインスタンス渡して処理する形の方
が修正しやすいんだよね。
オブジェクト指向は確かに便利なんだけど、この辺なんか
いい方法はないのかね。

ちょっとでも失敗したと思ったら、どんどんリファクタリングしろよ。
面倒くさがってリファクタリングを渋るから、あとあとそれ以上に
苦労することになる。

°°ってなに？

>>36
半濁点半濁点

何かのリテラルみたいだなw

オブシコわかりやすくっていいやんけ

>>35
リファクタリングってインターフェイスを変えずに
修正するってことでしょ？そのインターフェイス
(メソッド定義)が問題なんだよね。
ほかの人も使うものだったりすると修正出来ない
からなぁ

Java最近始めたんですけど
インターフェースの存在意義がいまだにわかりません

で？

教えてください(>_<)

>>41
javaでInterface無しとか死ねるぞ

>>44
それって大人数での開発とか自分用ライブラリ作るときの話ですか？
いまかからでも使い始めた方がいいでしょうか

Javaのインタフェースは、短く言うと型と実装を分離するためのもの。
Javaプログラミングだと、インタフェースが分からないと
標準APIすら使いこなせないので、絶対に理解しなきゃだめ。

C++やPythonはクラスが複数継承できるから死なないんだな。

Pythonは知らんけどC++で多重継承なんて
そんなに使わないんじゃない？
virtual継承とか色々ややこしくなるしダイヤ
モンド継承とか問題があるらしいじゃない。

すっごいニワカ臭い発言ありがとうございます。

いえいえ、お気になさらずに

>>46
わかったようなわからないような

getInstance(笑)
Factory Methodパターン(笑)

>>52
何かおもしろいことある？

笑っていう変数を渡してるんだろ

>>54
そうか！

>>40
> リファクタリングってインターフェイスを変えずに
> 修正するってことでしょ？そのインターフェイス
> (メソッド定義)が問題なんだよね。

リファクタリング本を見てね。
メソッド定義を変えるリファクタリングは
沢山あるから。じゃ

>>40
勉強しなおせw

>294：名前は開発中のものです。：2008/12/14(日) 07:22:24 ID:HIyGZizO
>>>286
>さっき提示したコードの価値をただのサブルーチン呼び出しとか
>言っちゃってる時点でなんかもう全然わかってない。
>
>あれはShotオブジェクトにEnemyとの当たり判定を”頼んで”いるんだよ。
>この違いがわからないんならいつまでたっても素人のまま。

>299：名前は開発中のものです。：2008/12/14(日) 17:59:02 ID:17g8Fdx4
>>>294は釣りだよな？ｗ
>突っ込むところが多すぎるｗｗ
>「ShotオブジェクトにEnemyとの当たり判定を”頼んで”いる」だけでオブジェクト指向とかｗｗ
>
>ところで、ゲームをオブジェクト指向で組むのは向いてないって話題は誰がしてるの？してない気がする。。

>>48
C++だとインタフェースがないから、多重継承を使う。

×オブジェクト指向は遅い
○オブジェクト指向が良く分からないからオブジェクト指向が遅い事にしたい

インタプリタ言語は遅い

>>61
コンパイルする時間を考えるとそうとは限らない。

コンパイルの時間と実行時のスピードとなにか関係あるの?

>>63
もちろん関係ある

「このソフト遅いね、なんとかしてよ」
「インタプリタだからコンパイル時間0です。超速いです」
「?」

>>65
もっと深く考えたら？

>>66
実行時間より開発効率が重要だとか?
でも実行時間の遅さをコンパイルの時間でカバーはできないよね。

>>67
実行時間の方が長くなるようなプロダクトならインタプリタ系じゃない言語にすればいいだけっしょ？

>>68
「インタプリタは実行時間が遅い」
「コンパイル時間がないから遅いとは限らない」
ってのは、やっぱ実行時間の遅さがなんとかなるってわけじゃないわけね。
了解。

なんでネタスレにマジレスしてんの？

>>62
それはC#とかも含めて？

C/C++のインタプリタとか、Javaのネイティブコンパイラとか、色々変なものがある以上、
その言語がインタプリタ言語であるかコンパイラ言語であるかという分類は難しいと思うのだが

レジスタへのアクセスは早い。
メモリへのアクセスは遅い。
ハードディスクへのアクセスはさらに遅い。
CD/DVDへのアクセスなんてあくびが出るほど遅い。

ネットワークへのアクセスが抜けてる

enemy.update()
enemy.render()
とかやるのはもう時代遅れだな

中々いいネタスレだ。確かに遅い。コーディングに入るまでが滅茶遅いｗ

設計→開発→保守
トータルで見れば遅くない。
機械に厳しく人にやさしい

正直世の中がオブジェクト指向に傾倒していてくれていたほうが助かることが多い

>>76
え、もしかしてオブジェクト指向でモデリングとか分析とかやってる?

ユースケース、ユースケース図、シーケンス図、クラス図

これくらいはやりたい。やったことないけど
UML読める人が回りにいないんだよなー

シーケンス図って実用的か？

クラス図とかコードから起こすのはいいとして、設計段階ではなぁ。

ユースケースを図に起こすときに便利(らしいよ)

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

と思ってます。実務で使ったことないから知識だけの感想だけどね

ユースケース図を起こすのにシーケンス図が便利って意味?

いやいや
ユースケースとユースケース図は別物ですよ

>>85
ユースケース(シナリオ)だよね
めんどくさいからキライだけど。

クラス図と言っても、内部設計と外部設計では
変わって来るし。

A4の紙2,3枚渡されて「これが仕様だ」とブン投げられるくらいなら
ユースケース書きたい。

ラムだとは何だったのか

ラムだっちゃさん？

ユースケース書いとくとマニュアル作るとき便利
スクリーンショット貼り付けるだけでほぼ完成

こいつ何とかしてくれ。

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

ワロタ

あとはここが参考になる
http://studiokingyo.fc2web.com/

世界最強吹いたｗ

世界最強？

かつてはgoto, malloc/free論争で軽々と1スレ埋めていた連中も
年取ってお疲れ気味でなかなか盛り上がれなくなってきたな。

CでOOPすれば早いお！　ライブラリもパプリックヘッダーだけ公開しておけば使ってくれる人も出てくるお！

CでOOPしても遅いお！OOPの遅さは動的束縛の遅さ！
OOPのメリットは動的束縛のもたらす柔軟さ！だから切り離せないお！

速度が求められるトコだけCで書いたらよかろ

>>99
>>98

カプセル化・継承だけなら引数ひとつ増えるコスト
virtual利用なら関数呼び出しが関数ポインタ経由になるコスト

>>96
free不要で結論がついたの？

>>101
vtable参照コストじゃねーの？

>>103
それも有るだろうけどそれ以上に
ポインタによる分岐予測の外れが酷いわな。
まぁ、そこまで速度が気になるんだったら
GPUやらSIMD向けのコード書くけどな。

テンプレートで静的ポリモーフィズム使うのって、どうなんですか？

ポリリズム　ポリリズム・・・

poly-morphism
poly-rythm
全然違うじゃないｓっすかー１

>>105
コンバイル時に解決しちゃうから問題ないんじゃない？
自分で重複コード書くかコンパイラに任せるかの違いかと。
コンパイラに任せる分よしなに計らってくれてたりはくれるのかも。

>>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が返される"

OOPは最近なんか進展あった？
衝撃の新技術的なやつ

Samalltalk への回帰現象

言語単位でいえば進歩はしてるんだけど、OOPそのものは進展なし

ゴミグラマってバカだったんだな
ゴミ量産機

自己紹介乙

カリスマの存在

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

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

ぷちまとめ
ttp://www.geocities.jp/x_shortcake/

>> http://hibari.2ch.net/test/read.cgi/tech/1309621283/999
型推論がしっかりした言語はそうだよね。

>> http://hibari.2ch.net/test/read.cgi/tech/1309621283/999

なんか違うんだよね。
アヒルでもカバでも…じゃなく、アヒル未満で済む場合にそれを許す
ゆるさが欲しいのがダックタイピング。
こいつはもちろんアヒル型ではチェックを通らない。
で、部分型をアドホックに定義して通すためには
現行の型システムでは制約が多すぎる（あるいは手間がかかりすぎる）という。

全体の動きは確かに遅くなる．．．　てか　そんな高速処理はハードを利用しろ！　OOはヒューマンインタフェースの為のものだ！

age
ここ次スレでいいの？　このスレタイじゃ新規の人来ない気がするけど、part3でまた馬鹿に戻せばいいか
オブジェクト指向は馬鹿ご用達
http://hibari.2ch.net/test/read.cgi/tech/1309621283/

>>120
もとはあのスレも どうせ放置されて邪魔になるスレの再利用だったし
こちらもそのノリなんだからいいと思う。ここも放置しても、最後まで
埋まらんだろうし、最後にオブジェクト指向の総合スレにまとめちゃったら
いいかも。

いいとこどりのハイブリッドな言語ってないの？

>>122
色んな意味でC++

C#のdynamicはどうか

>>122
common lisp

>>122
ハイブリッド言語の代表
C++とCommonLispは言語仕様のお化けですが何か

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

言語の能力よりRAD環境の有無の方が楽かどうかの分かれ目。と思う今日この頃

>>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);
}

Ocamlの型推論は、前スレの主張するダックタイピングとやらを許す。
つまりあるメッセージを受け取るオブジェクトが、鳴いたり歩いたりできれば整合性に問題は無いことを推論できる。

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

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

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

ただし、どちらがやりやすいかは全く別の問題だ。
例えば、鳴いたり歩いたりできれば、アヒルでも人間でも同じ処理を加えていいというわけではない、という立場も考えられる。

ちなみにOcamlは、どちらの選択も許す。
・鳴くことができて歩くことができれば、このメソッドの引数として正しい。
というのは、自動的に検査できる。

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

どちらがいいかは、ケースバイケースだと思う。

普通に考えれば、オブジェクト指向というと、
適用できる処理の対象クラスを特定したいというのは自然だと思うけどね。

もちろん、そうでない場合を否定する気はないけど。

>>128
頭固すぎ。

Javaでも同じことはできる。
メソッドが１つだけの型を作ればいいだけ。

>>131
それ結局、明示的な型定義になっているよ。
interface hasHogeMethod { ... hoge(...) { ... } }
とか、
interface hasHogeFugaMethod { ... hoge(...) { ... } ... fuga(...) { ... } }
のようなのは、可能だしやってもいいけど、
言いたいことと少し違う。

論点にしたかったのは、メソッドに注目するか、特定の型に注目するかという点。

Javaは結局クラス=型なんだよね

>>133
うん

>>130
ポリモーフィズム全否定ですか？

nominal subtyping vs. structural subtyping

前スレ >>975 の
>型名なしで、どうやってディスパッチ先を指定するんだって話。
>シングルディスパッチだと、
>obj.method = method1;
>とか出来るから、型名要らないけど、
>それはシングルディスパッチ限定の話だよねって。

って、PythonやJSみたいな設計限定なんだよなあ。
ダックタイピングでも、メソッド≠オブジェクト、メソッド≠属性な言語はあるのだから。

>>132
> 論点にしたかったのは、メソッドに注目するか、特定の型に注目するかという点。

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

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

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

この関数があとで□メソッドを使うように変更されたら、
動的言語は辛くなるけどなｗ

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

OCamlの例は明示的に書かなくても
インターフェースを型推論するって話だろ

岡村△

だが、OCaml にはオーバーロードが出来ないという致命的欠陥がある罠。

OCaml使いはオーバーロード嫌ってるんじゃね？
あれはメリットだけじゃないからな
オーバーロード欲しいならGCamlか、いっそのこと型クラスのあるHaskellか

プログラマの会話の不快感は異常

>>143
なら、ここに来なきゃ良いでしょ
わざわざ自分から不快に思う場所にくる事もあるまいに

キモオタがキモイと言いつつアキバに通う人みたいな矛盾を感じる。。。

本当だ、↑キモイね

え、何この流れ？
Javaを批判される => 反論できないから人格批判
ってこと？

>>145
でしょ？
>>143はこれと同レベル

オタが自己嫌悪するのは極めて自然な行為なんだけど？
むしろそれが出来ないのが、いわゆるライトオタクとかいうクズ

マでやれ

>>143を具現化するスレ

オブジェクト指向言語なら、オーバーロードを許すなら
いっそのことマルチメソッドにしてくれよと思う

とくにC++0xな。あれやばすぎ。

C#は何でもできて楽しいことは楽しいんだが
C++みたいになりそうで怖い

そういや >>129 が

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

って書いてるけど、OCamlでそんな事出来たっけ？
OCamlの'O'機能はあまり使わないから自信ないけど、
型が（構造的に）一致したら通っちゃう気がするんだが

>>154
間違ってたかも。確かにOcamlで特定のクラスに名前を与える方法は見つからなかった。
モジュールシステムと勘違いしていたとおもう。

「もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」
俺気づいた。みんなこの言葉を誤解している。

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

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

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

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

型があれば、duck.walks()、duck.quacks()でいいのに。

それはね。"アヒル"というものに対する定義の仕方の違いなんだよ

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

どちらの考え方もある。君が言ってるのは前者だ
OCamlやScalaやduck typingの言語などは後者だ
そしてどちらも duck.walks() でいい

>>155
岡村(÷)

>>157
> (walks() や quacks() が呼べる）なら"アヒル"である

walks()を実際に呼んだら、6本足であるいたり、
quacks()を実際に呼んだら、キリリリリって鳴いても
それはアヒルなのですか？

じゃあDuckインターフェース(worksやquacksを含む)を実装したクラスに
6本足で歩いたりキリリリリって鳴くのを禁止するような
言語機能があるの？

structural subtypingはアヒルかどうか問題にしない。
6本足であるいたりキリリリリって鳴いたりするかどうかにかかわらず、
歩いたり鳴いたりできるかが判断の条件だ。

nominal subtypingの条件は、歩いたり鳴いたりできるかではなく、
アヒルという型名が付けられているかどうかを第一の判断の条件にする。

>>160
依存型使えばそれにそれに近いことできるかもしれない

>>160
インターフェイスの仕様でそう決めればいいだけのこと

>>162
ああ、duckとか言っててOOP脳になってたけど、
確かに依存型はそれに近いね

>>163
どうやって決めるの？「このインターフェースはDuckって名前が付いてるから
works() で6本足で歩いちゃダメ」ってドキュメントにでも書くの？

>>164
＞「このインターフェースはDuckって名前が付いてるから
＞works() で6本足で歩いちゃダメ」ってドキュメントにでも書くの？
その通り。インターフェイスメンバの仕様を決めるのは当然。
その点ダックタイピングだとメソッド名だけで仕様を制約しなきゃいかんので広範囲に適用しづらい。

なーんだ。型でチェックできるんじゃないんだ
ただ型名を人間が理解しやすくするためのタグとして扱うだけなら
structural typing でも duck typing でもいいじゃん
別にクラス名付けられないわけじゃないんだぜ？
部分型は型の構造で決まるってだけで

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

みたいに明示的に型名付けても良いんだよ？

Javaの人にも分かり易く言うと、structural subtyping は
「仮にインターフェースの名前が違っても、同じシグニチャなら交換可能」だ
そんなに毛嫌いするような機能じゃないよ

そもそも仕様を制約するならモジュールで区切っちゃえばいいしね
ドキュメントに書くより確実だ

なんというか、nominalな型システムと
structuralな型システムは一長一短なんだよね
好みの問題でもあるから喧嘩すんなよ

ふだん全然テスト書かないから
「静的型検査でチェック出来ない = ドキュメントに書くしか無い」
こんな発想になるんだよ
メソッドの仕様を検査したかったらテスト書け

え？

> こんな発想になるんだよ

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

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

それが普通の発想だよ。

でも君は他の人は「静的検査をすればその他のテストはしなくていいと考えてる」と
思ってるんでしょ？ それは明らかに君が間違ってるだけだよね。

>>138は

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

と書いてるので怪しいが……

ダックタイピングはメソッドが1つだけの
インターフェースと考えれば良い。

「これでJavaでもダックタイピング出来るんだ・・・」
とか言いながらメソッドひとつのインターフェースを
定義しまくってる姿想像してワロタwww

全然違う。インターフェースは同じインターフェースを明示的に実装してるクラスのオブジェクトしか通さないが
ダックタイピングは無関係のオブジェクトでも同名のメソッドがあれば通る
つまり他クラスのオブジェクトと多態させるためにクラス自体に何も手を入れる必要が無い点で大きく異なる

そりゃおっかねえな

scalaにもそういうのあるけどなんかあんま使われてないっぽい

それはオブジェクト指向的なポリモーフィズムは使われてないってこと？

そもそもポリモーフィズムなんて百害あって一利無しじゃん
さすが後付け機能って感じで誰も精査せずにぶち込んだ感ムンムン
こんなの崇拝してるＰＧはクズ

後付のソースください

ポリモが後付け？

>>176
> ダックタイピングは無関係のオブジェクトでも同名のメソッドがあれば通る
> つまり他クラスのオブジェクトと多態させるためにクラス自体に何も手を入れる必要が無い点で大きく異なる
無関係のオブジェクトと多態させることの
メリットを教えて下さい。

ここでいう無関係は
継承関係がないって意味だと思うよ

>>183
ビンのフタをペットボトルのキャップとして使える。

>>185
例えじゃなくて、
具体的なコードで、ありそうな話でお願いします。

なんだ、ダックタイピングって
アダプタパターンのことだったのかｗ
それならJavaでできる。

別にJavaで出来ないことが出来るから
スゴイといってるわけじゃない。より簡単に出来るってだけ

>>186
流れを読まずに、横からだけど。
実行時にオブジェクトに対して特異メソッドを定義したりできる。
メソッドがあとからくっついたりできるくらいなら、
ダックタイピングも当然あったほうがやりやすい、となるのでは。

>>187
え？

>>189
ダックタイピングが利用価値があると
説明するために特異メソッド作ったのか？ｗ

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

なぜ実行時に追加しないといかんのか。

なにができるだ
アフォだな
そんなに制限が嫌いならvoid*使うかアセンブラでもやりゃいいじゃん
全部アドレスだから型の制限なんてないぞ

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

馬鹿なの？
なんのために型作ってコンパイラでエラー出すようにしたと思ってるの？
死ねば？

>>190
え？

ほらなー。実行時に定義するのと
実行前に定義するの、
どっちでも同じ事出来るなら
実行前に定義しちゃえばいいじゃんか。
だろ。

>>192

実行時にメソッドはやす機能をつけると
実行前にエラーチェックすることができなくなっちゃう。

そのデメリット以上のメリットはないよ。

おもむろに前スレから引用してみる

> 例えば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

> 例えばDecoratorパターンなんて本来クラス作る必要は無い
作る必要がないのに作るのは、
コード上の意図を明確にするため。

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

本来作る必要はない。言ったとしても、
たしかにそうだが、作ったほうが意図が明確になるだろうという
言葉で反論が可能。

制限をつける形で進化してきたって……
静的型付けなんてプログラミング言語の最初期からあった概念だろ
静的型付けでも継承や多態が出来るようになったり、むしろ柔軟な方向に進化してるよ

分岐とジャンプがあれば構造化などいらない

>>198
Cの仕様の変遷も知らないのか

C限定の話だったのか

>>197
メソッドを動的に装飾したり追加したりするのがDecoratorパターンなんだから
>>196のコードの方がよっぽど直接的で分かりやすいと思う

まあ、分かりやすさなんて水掛け論になるから止めとくけど、
ひとつハッキリしてるのはJavaでは>>196のような簡潔なコードは書けません
他の言語では書けますし、Javaのように冗長に書く事も出来ます

LispからCOBOLまでさまざまな言語があって、
どのような制限や自由が好ましいかは、
使ってる言語の文化や適用する問題で大きく変わる

オブジェクト指向だって一種の指向に過ぎないのだから、
細かい部分を含めて絶対的な良し悪しはない

>>202
メソッドを装飾した以上、それは別のものなんだよ。
別のものは別のものとして扱わないと、
たとえばその例だとPriceは自分がPriceだと思っているのに
自分をいじられてるせいで、PriceがgetValueした結果が意図したものじゃなくなっている。

装飾はあくまで基本はそのままで、周りにつけるもの
>>196は装飾ではなく補修。補修は危険だ。動作保証がなくなる。
動作保証の点において、装飾は補修のかわりになるが補修は装飾の代わりにはならない。

>>204
じゃあ int x = 1 と int y = 2 は違う値だから型で区別しないとね
Int1 とか Int2 とか定義する？

Decoratorパターンは装飾したオブジェクトと
装飾前のオブジェクトで同じインターフェースを使う事で
「区別しなくてすむように」するパターンだぞ

>>206
おや？　分かってる人がいるじゃん。

はー、ダックタイピングのメリットが知りたいのか。
それならC++のSTLを触ってみれば良い。
静的だけど、関数のオーバーロードでダックタイピングしてるよ。
例えば、std::listの要素に何でもかんでも突っ込めるのはダックタイピングのおかげ。
さもなくば、
「std::listの要素は、std::list::elemを継承している必要があります」
とかなっちゃう。

区別する必要が無いのだからクラスを定義する必要はありませんね

>>208
節子、それテンプレートや。
パラメータごとの静的な複製や。

C++はnominalな型システムなのにtemplateで静的ダックタイピング可能という
かなりのハイブリッドさ

>>208
それだけなら普通のGenericsと変わらないのでは？

だけど、テンプレートはオーバーロード無しには成り立たないだろ？
オーバーロードは静的なダックタイピングだから参考になるだろ。

>>198
なにそれ？
void*の時代に戻りたいの？
バーカ

> オーバーロードは静的なダックタイピング

天才すぎてさっぱり意味が分からんｗｗｗ

テンプレートなんて使ってる奴って馬鹿しかみたことねぇ

structual subtypingが役に立つ時って、演算子+が定義されているオブジェクトに対して、
e1 + e2 + ... en
のような処理を一般的に適用できたりするのがいいのかな？
それとか、operator()を使ったSTLとか。
それほど必要ってほどでもないような。

CやC++の特徴って、constとかポインタの型とかの制限はありつつも、
必要があればキャストしたり、メモリを直接操作したりできるようなところ。
それが便利なこともあるし、バグの元になったりすることもある。

自分で作ったテンプレート眺めるのはすきだけど
他人の作ったテンプレートは見るのも嫌って奴しかいないな

一度でも他人の作ったオナニーテンプレートのバグ探すハメになったら
絶対テンプレートなんて使わなくなる

仮想関数よりさきにテンプレートに触れてしまった人間は、
それにしがみ付いて、OOPを受け入れようとしない。

魔王「我を受け入れろ」
みたいな奴ですか？

>>217
型名を付けなくても型の構造が合えば部分型にアップキャスト出来るので、
クロージャのような感覚でオブジェクトを生成して使えるようになります
つまりプログラミングスタイルが変わります
それが好ましいかどうかは人によりますが

>>222
動的言語や型推論ができる言語で、わざわざ型を明示する風習がない書き方をするなら、substructualでいいとおもうけど、
nomialな風習の言語では、敢えてsubstructualな機能を活用する場面ってどれだけあるかな？

そういえば最近C++0xで無名関数を使ったとき、型名を書かないといけないとしたら面倒だとはおもった。
でも、単にクロージャを作るだけなら、複数メソッドの型シグニチャまで考えなくても良さそうだし、
Javaの無名クラスも、継承元を明記するけどそれほど不便でもないような。

>>209
> 区別する必要が無いのだからクラスを定義する必要はありませんね

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

”違うクラス”を同じように扱う、逆に言えば
同じように扱うが、"違うクラス"であるということだ。

たとえば変数を使うとき、定義しないとしたら
面倒だと思った。


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

そりゃなくてもできる。だが人間は間違いをおかすもの。
間違いを犯さないために、定義をしてるんだよ。

結局宣言とか定義とかいうのは
人間が間違いをしないようなチェックであるわけで。

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

どちらが大規模、大人数の開発に向いているかなんて
言うまでもない話。

>>223
nominalな風習の言語ではnominalに書いたほうが素直なコードになると思います

動的言語や構造的部分型の言語では、シグニチャが同じならそれらは区別されません
そのため同じメソッド名は可換になるように設計する風習があります
そして、これらの言語では長いメソッド名を付けなくても済むように
高機能なモジュールシステムや名前空間を持つことが多いです

ところで部分構造型的なオブジェクト指向言語で、抽象メソッドの定義とかどうしてる？

具体的にはPythonを使ってる時に抽象クラスとして考えているクラスがあったりする場合、
不要とは分かっていても、何もしないメソッドとか、呼ぶとエラーが出るメソッドを、抽象メソッドの宣言の意味で加えたりするんだけど…

>>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型と違うことが分かって嬉しい状況が思い浮かびません

そりゃ挙動が違うって意味があるだろうに。

>>229
OCamlにはそのものずばり抽象メソッドがあります
アップキャストのためではなく継承時の制約を明示するためでしょう

>>231
挙動が違うだけならば"違うクラス"を作らなくても良い
そういう話だったのでは？

>>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

ただ、大規模な開発で型宣言することが有効であるだろうことは否定しません
そのような状況では、型宣言を強制する言語の方が良い可能性はあります

>>235
OCamlを実用に使っている方？
型推論と実行性能と関数型の利点を併せ持った言語として、昔少し使ったことがあったのだけれど、
型推論は依存型に、実行性能はCとC++に、関数型の利点はHaskellに興味が移った挙句、
業務では使えないし、個人では強力な型システムが開発の助けにならないし、もっとメジャーな言語のほうがライブラリが多いということで、Pythonなどを使うようになってしまった。

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

私自身は、型安全性によるプログラムの検証は、設計やテストのやり方に比べればプログラムのごく一部の問題であって、ほとんど品質に影響がないのではないかと思うようになってきた。

>>223
肝心なことを書き忘れていました

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

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

もちろん品質にはテストが重要だと思います。自分が>>235で型宣言が有効と書いた理由は、
それが他者がコードを読む助けになると思うからです

>199
うわ〜　はっはっは。　それを無くす為のオブジャクト化&デザパタ。　人間の思考はいくつも同時に考えられないから。

オブイェークト

「C言語？あーだめだめ。オブジェクト指向できないじゃん。
計算機は速くなったんだから、もっと抽象化できる言語使おうよ。
Java最強」

「動的言語？デザパタが簡潔に書けるほど抽象化できる構文？
あーだめだめ。抽象化なんてしちゃったらプログラム読み辛いでしょ？
それに実行遅いんだから、もっと速い言語使おうよ。
Java最強」

Javaなら存在しないメソッドを呼ぶランタイムエラー出る事無いと
思ってるやつがいるけど、Javaのぬるぽはまさにそれ

JavaサイコーｗｗｗｗJava以外の糞言語使ってるアホはマジ死ねｗｗｗｗｗｗｗｗ

>>237
頑張れ プロフェッショナル岡村！

>>242
マルチプラットフォーム以外に魅力感じないんだが。。。

nominalとsubstructualってどういう意味？

ルー語はよせ

>>244
ライブラリや周辺ツールが充実してるとかあるんじゃね？
Oracleのせいでオワコンっぽいけど

Oracle的には(難解さも含めてモロモロ)最強言語のSQLが有るからJavaはどうでもいいんでしょ。
企業様の命の次に大事なデータ様を大量に抱え込んでるんだから、すげーよな。

Java SE7 のループ最適化のバグはワロタ
やる気無さ過ぎだろOracle

>>156
それは計算機言語が felt like を理解するような状況じゃないとだめじゃね？
と、久方ぶりにTRONを見て思う(MCPがfelt like Flinnって言う台詞から)

ふぇ〜るとらいく　とかルー大柴っぽくて頭が悪そうだな。
まず、日本語の勉強をすることから始めたほうがいいじゃないか？
単語が思いつかないのだろう？

計算機言語ってなに？
プログラム言語のこと？

>>250
そいつはJavaフルボッコにされて逃走したよ
もう触れてやるな

Javaみたいな糞言語を誰がやるかヴォケ

ま、Javaはこの際置いておくとして。

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

というわけで、将来的に伸びるのはどんな特徴を持った言語だと思う？

現在メインストリームである言語と高い互換性を持つこと

それはC++みたいにCとコードレベルで互換性があるってこと？
それともScalaみたいにJavaの資産が使えるってこと？

両方

C++はCの資産が使えるしなー

>>255
いま伸び盛りなのは、JavaVMを使った並行処理が得意な言語という印象がある。
つまり、ClojureとScalaかな。前者は少し火がつきだした程度だけど、後者は
もう火がついてるよね。
個人的にはHaskellに伸びてもらいたい。関数言語系にシフトするとしたら、
JavaVM系次第かもしれないが。

CやC++と関数言語だったらFFIが定められてたりライブラリがある言語の
ほうが多いから、別に問題はないんだよね。あるのは、人のカズだけ

ちょっとしたテキスト処理くらいだったら、LLで十分だわな。

Javaとコードレベルで互換性のある次世代言語ﾃﾞｷﾀﾖｰとか言われても困るわ

Genericsの中途半端さやラムダ入れるの苦労してるの見ても
Javaとコードレベルで互換性残して発展させるのは無理筋

F#を忘れてたな。あれはMSの世界だからわかんないけど、伸びてるな。
>>263
いや、オマイらが困っても、時代は動いていくもんだ。

>>264
C++のSTLみてるとそう思う。自由を得るために複雑になって、泥沼にはいる
典型的な例だと思う。

だから、20年くらいしたら、javaの人って２１世紀のcobolerと呼ばれるかも。

もう呼ばれ始めてる

PHPとJavaはオワコン

そういう意味ではC言語は安泰だな。

>>270
言えてる
c単体で使う領域は減ってるけど、他の言語と組み合わせるから、取り敢えず覚えとけって言語の定番だよな

cやアセンブラは基盤だからなぁ。javaもjavaVMの基盤ではあるけど

C言語にとって変わる言語はいつ出てくるの？
組み込みの世界では現役過ぎて辛い

Cがあまりに正しいからだよ。
CgとかOpenCLとかみてもそう思う。

単に多くのコストが費やされてきただけだろう
特に効率とか、どんだけコンパイラに金と時間と人材が注ぎ込まれたかが9割だと思うし
同じだけ注ぎ込まれてればばpascal、lisp、fortranあたりなら今のCと同じ立場になってただろう

pascalもlispもfortranもコードの見た目が汚いから普及は無理。
C言語はTシャツに印刷してそのままデザインとして通用するぐらい
見た目が綺麗。

そりゃC系列の構文に目が慣れてるだけだろう

そんなことはないと思うよ。
大学で最初にPascalやらされて、その後C言語に移ったときの感動ったら無かったね。

そりゃお前の感覚だろう
今でもCよかDelphiの方が好きっていう人は結構いるし見た目の好き嫌いは人それぞれだよ

感覚には感覚で対抗しないと勝てないよ
一般論でうやむやにしてもせいぜい引き分けにしかならないから

感覚の話したら言ってる人を見るよな

この幼稚な舌足らずなキモさで、こいつの感覚はあてにならない
俺の感覚にあわない

ばかばっか

>>281
舌足らずはあんたも同じだろ。
会話に苦手意識ありそう。

ばっかおめー、Pascal系はDelphiが死亡してユーザ涙目なんだぞ
あんま煽んな、そしてちっとくらい煽られても優しく流せ

ここってオブジェクト指向プログラミングのスレなの？
設計の話ならドメインモデルとか普通に出てきそうなものだけど
出てないよね？　設計の話題は別？　まあ無視して話すけどｗ

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

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

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

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

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

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

オブジェクト指向ビジネスロジックを前提としたフレームワークでトランザクションスクリプトを使うのなら、
そのためやり方（考え方、オブジェクトをデータとメソッドに分離した上でフレームワークを利用する方法）が
必要なのだが残念ながらその情報が少ないから、ちょっと混乱が起きている。

ドメインモデルとトランザクションスクリプトの違いは
SQLサーバーからデータとをってきたとき、とってきたデータを
そのままただの値としてビジネスロジックで使うか、
そのデータを一旦O/Rマッパーなどでメソッドのついたオブジェクトに
変換してビジネスロジックで使うかの違い。

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

ということで俺の推奨は

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

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

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

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

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

なんてことをいうと、俺はオブジェクト指向否定派になっちゃうわけだｗ
オブジェクト指向設計は適材適所。ビジネスロジック限定の話ではない。
そしてオブジェクト指向設計を適用するのはフレームワークまでにしとけ。

>>285
StrutsとかいうFrameworkは全然オブジェクト指向型じゃないけどな。
それに追従するFrameworkも然り。使う側の問題でもあるんだろうが、
構造体同然のbeanなんて吐き気がする。
今まともにOO生かせてる機構なんてSwingや.NetのCLI、QtとGTKぐらいだろ。
既存のオブジェクトに、自前で作ったオブジェクトを差し込んで動作を変えられないなら
OOPしているとは言えない。

>>285
なげえよ馬鹿

・現在一般的なのは三層アーキテクチャで、BL層が一番下に来るのは手抜き開発です
・フレームワークと言うけど、普通はUIとDBアクセスで別のフレームワークを利用するはず
・BL層で利用する値は下の層で生成された値を使うので、生データと言っても二次元テーブルモデル程度にはラップされてるはず

大方下の層を無視するような真似をして"自称賢い人"に怒られたんじゃないの？

>>289
Web FrameworkはOOとは別問題だ帰れ。

え

> 最近ようやくオブジェクト指向設計というものが理解できてきた。

この語りだしからロクな話題を聞いたことがないなｗ

要は俺様オナニークラス作るのは止めようって事だろ
それには同意しとく

>>287
最近JavaBeansを改めて勉強したけど、setter、getter必須とか聞いてはぁ！？って思った
パーツを使い回すためって、そんな構造体的な使い回しに何の意味があるのかさっぱりだ

>>294
正解だね。ただ、まだそれに気づかせる＆ウザさを与える点でマシ。
C#なんぞはプロパティを文法で用意しちゃってる。
そこらへんがMSらしいというか、C++の臭さを見習ってるというか。

>>294
setter,getterって本来、GUIの設定を変更するためのBeanって仕組みの為のもので、
GUIに置いてはそれなりに意義は有ったんだがな。Webに関しては、java.bean.*で
手抜き仕様としてるだけで全くのクズ。

>>295
C++は関係ないだろ。そもそも、C++にget〜とかset〜って
メンバー関数持ったクラスは無いしプロパティも無い。
諸悪の根源はDelphiだな。

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

コンテナ類は別として、オブジェクトに一度入力された値が、入力されたオブジェクトから
取得できる必要なんて全くない。同じ値が必要なら、入力元のオブジェクトに再度
問い合わせればいいだけの話。問い合わせにコストが掛かるなら、一旦キャッシュになる
オブジェクトを噛ませれば済む。

そもそもsetter、getterがあるってこと自体おかしい
こんなのオブジェクト指向なんもわかってない証明だと思うんだけど

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

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

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

こんな糞みたいな仕組み作った奴の脳内にはもうオブジェクト指向なんて存在しないに違いない

>>298
作れるものを限定してバグを減らしたい人もいるが
逆に、今まで作れなかったものを作れるようになりたい人もいる
まあわざわざ型の強い言語を使うなら前者でないとおかしいわな

オブジェクト指向と手続き型思考は独立していなければならないことが
わかってないと思う。
オブジェクト・手続き型プログラミングには２つのフェーズがある。
一つ目はオブジェクトフェーズ、このフェーズではオブジェクトの性質のみで
操作されるべきで内部の情報などは一切使用してはならない。
もう一つ目が手続き型フェーズ、このフェーズではオブジェクトの性質は一切扱えず
オブジェクトの内部データのみ操作できる。
この二つの操作は完全に分けられるべきで一つのソースファイルにこの二つが共存することは
絶対にあってはいけないことなのだ。

>>299
また、void*か？
死ねよ
そんなの誰もやっていいっていってねぇんだよ

>>299
バグ云々の問題じゃない。
拡張性が下がるんだよ。
setしたものとgetしたものが同じじゃないと
いけないから

他のメソッドに足を引っ張られて拡張性が下がるってことは
メソッドが1つだけのインターフェースを定義しまくればいいんだよな

>>303
それって１つの変数がたくさんの方法でアクセスされてるってことだから普通に複雑じゃない？

全部を公開する必要は無いし
setterとgetterのどちらか一方だけ用意してもいい
一体何が問題なんだ？

>>305
イベントじゃないところ
関連として仕様書にかけない

イベントの定義は？
なんで仕様書に書けないの？書けば？

別の用途で２箇所で使われるとすでにイベントの意味ですら間違ってる

別の用途って何？意味不明なんですけど
それにイベントの定義は？

>>309
そりゃオブジェクト指向の入門書でも読んでよ
なんで俺が君にわざわざ教えてあげないといけないの？

ぷーくすくすwww
こうやって逃げるやつ居るよねwww

>>311
いいよ
じゃあ、君なりにぐぐってみて一番最初にあたったオブジェクト指向のイベントの定義でいい
これで逃げてないよね？

ほらさっさとかかってこいよｗ
オブジェクト指向理解できてないんだろ？ｗ
逃げないでよｗ

は？イベントって言い出したのお前だぜ？

>>313
だからオブジェクト指向にイベントって言葉あるだろ？
これは共通知識なんだよ
お前は四則演算の「＋」記号ってなんですか？
って質問してるから
俺は「そんな面倒臭いことから説明するのはいやだ」って話だろ

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

なんだアニオタか・・・
まともに相手してそんした

イベントって言葉自体を知らないのであれば

勉強してねｗ

で終了なので一連のレスはみなかったことにしていいぜ
そうでないなら俺はお前の認識するイベントでおｋ

OOPならイベント=メッセージングじゃねーの？違うの？

>>314
用語についてのリファレンス貼る手間は惜しむのに
漫画のリンク貼る手間は惜しまないとかキメェwww

>>317
なんでもかまわない
すきなイベントの定義があったらリンクでも貼ってくれ

>>318
いいじゃん
お前の土俵で戦ってやるっていってるんだから
自分に都合のいいの選べよｗ

逃げちゃった？ｗ

「すきなイベントの定義があったらリンクでも貼ってくれ（キリッ」

言い出しっぺのお前が貼れよwww

純粋オブジェクト指向においてはオブジェクトとその性質以外のものは
存在しない。
すなわちイベントとはある性質を持つオブジェクトに他ならないのである。

>>319
イベント=メッセージングだとsetter, getterもイベントになるが
それでいいのか？

>>323
いいよ

>>314
数学的には「+」ひとつで色んな使われ方をするんだがな
お前の知ってる+だけが+じゃないんだぜ、実はいくつか定義がある
1 + 1 = 0 だって数学の分野によっては間違ってないんだぜ

仮にその定義だったとして、setterとgetterのどちらか一方だけだと、何故仕様書に書けないんだ？

+はあくまでただの二項演算子でしかないのか
モノイド、いやマグマですら限定しすぎなのやな・・・

>>325
まあ、仮にそういう分野があったとしてもお前とは会話できないからｗ
住みやすいところへ勝手に行ってくれやｗ

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

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

ないっていうならこれ以上はあんまり会話はできねぇな
君の職場と俺の職場は違うんだね終了って話

>>328
いや、書く気があるかどうかとsetter、getterを使うかどうかは完全に別問題だろ
読み取り専用の属性なんて腐るほど存在すると思うのだが…

>>329
でも面倒臭いから
別に必要なくてもsetter、getterで書いちゃうんでしょ？
呼ばれなくても作っちゃうでしょ？
無能だから

1 + 1 = 0 になる数学の分野って何ですか？
そんなのが本当にあるのなら教えてくださいよ？
無くていえないとか？

>>331

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

http://icopipe.yaruo.info/wp-content/uploads/2010/05/res0288.jpeg

1ビット加算器とか

Wikipediaでプラス記号見るだけでも別の用法が出て来るわな

メンバ変数privateにしても、全部setter/getterで公開したら
カプセル化の意味ねーだろ的な批判は当然ある

で、それをアホが「setter/getterは絶対ダメ」って
拡大解釈しちゃったんだね

+はただの二項演算だけど組み込み型、標準ライブラリで用いられる意味との整合は考えるべきだろうな
一般的に四則演算としての意味(数値型に対する和)を期待するなら体の公理を持ってくるのが妥当だけれども、
例えば文字の連結にも+が使われているような場合、それよか少し弱めてモノイドとしての意味ぐらいでも大丈夫だと思う
でもそれ以上に弱めるのは大抵碌な結果にならんだろうな

モノイドに+を使うのは今でも違和感あるけど
文字列連結に使っちゃってる言語多いよなぁ

>>329
だったら読み取り専用のコンテナでいいじゃん。
間違ったキーを渡す可能性があるっていうなら、constantな
オブジェクトや列挙型をキーにすればいいだけだし。
速度がとか言い出すならそもそもOO Pなんてやめっちまえ。

別の方法でも実現できるってのは
setter/getterがダメな理由になってないぜ

Bean的なものにおけるgetterとsetterは、
内部の整合性を保つためにあるわけで。
例えば、文字列クラスなんかだと、
保持してる文字列とその長さのメンバ変数とで
食い違いが出ないようにしている。
だから、外部との関係とかイベントとかメッセージングとか、
そういうのとは初めから無縁。
関係ない話題で盛り上がってるってわけだ。

何でOOPの話題ではこんなに話が食い違いがちになるかというと、
JavaやC++などのメジャーなOOPでは、
「多態」も「カプセル化」も「差分プログラミング」も、
全てクラスという仕組みでやっちゃってるから。
違う目的でも、手段が同じになるから、話が食い違う。

格安バスツアーに出かけたとしよう。
旅の目的は人それぞれ。
息抜きだったり、自己啓発だったり、誰かの付き添いで嫌々だったり、
観光名所めぐりマニアだったり、ご当地食いしん坊だったり。
でも、手段はバスツアーで、皆同じ。
それぞれ違う目的を持った人たちが、バス車内に一堂に会してしまう。
そんで、暇なものだから「バスツアーとは何か」について熱く交わしているのが
このスレの状況。
探偵物なんかのドラマで2時間持たせようとするときなんかに良く使われる設定だね。
話が纏まらないから2時間引っ張れる。スレも伸びるね。

たまたま話のきっかけだっただけで
Bean的setterとgetterに話題を限定する理由が無い。
ここはJavaBeansのスレじゃないからな。

結局のところ、「多態」も「カプセル化」も「差分プログラミング」も
それぞれ単体では難しい話ではないし、使いどころを間違わなければ
とても便利な機能でしょ。
ただ問題は、メジャーなOOPLでは、
これらの機能は全てクラス設計で行うことになっちゃってる。
一堂に会しちゃってる。
だから、クラス設計の話をしだすと、途端に迷子になる。
そのほかにも、差分プログラミングのつもりでクラス設計していたつもりが、
手段が同じものだから、いつの間にやら必要の無い多態のことも頭に浮かんできたりして、
使いどころを誤ったり。これは初心者にありがちだね。

「多態」と「カプセル化」と「差分プログラミング」のそれぞれに
専用の構文を用意すべきだっただろうね。
全部が全部、クラス単位だから、話が分からなくなるし、
何でもかんでもクラス単位なのも、それはそれで面倒だ。
C言語なんかで良くやった、ソースファイル単位のカプセル化とか便利だったしね。

>>342
まさにそういうことだよ。
ちょっとしたきっかけでこんなに話が派生してしまうのは、
全ての機能がクラス機構経由になってるから。
クラスの仕組みがハブ空港になって、そっから関係ない話に飛びまくる。
気がつけば沖縄と北海道で会話してたりする。
しかもハブ空港では一緒だったものだから、
最初から目的地が違っていたことや、
既に離れ離れになってることに気がつかないでいる。

>>338
読み取り専用のコンテナ？一体どういうことを想定してるの？速度とか全然意図してないことを言われても…
もしかして連想配列でいいとか考えてるってこと？getter/setter以外のメソッドの存在は無視なの？

>>345
存在しても構わんよ。でも、それは問題じゃない。
Mapにget(〜)以外存在しないよう考えろ的なことは思ってないぞ。
ただ、複数あるメソッドのうちgetName()的なものはget(Key.name)で
取れるようにしとけばいいだろって話。

メンバーが増えても、元クラスにgetXxxx、setXxxxを追加する必要はなくなるし、
コンテナとだって互換性を持つことができる。
けどどうだい、getName()なんて固定化したらそれを利用した拡張が効かなくなる。
たとえget(Key.xxxx)を持つMapを利用するオブジェクトがあっても、
素直にそのオブジェクトを再利用できない。

>>340
beanのsetter/getterとは違うだろ。
それはStrutsとかを正当化させようとしてる言い訳だ。

beanはそもそもRAD用のjava.beanパッケージ。
JSPなんかは、構造体を実現するためにbeanを乱用してるだけ。
本来のbeanは、setXxxxを実行すると画面要素がその時点で変わる。
そのための存在。
大体Webアプリ作るときにsetterで例外出すようにして捗るようになったかい？

ずいぶんつまんないことにこだわるんだなｗ

設計なんて利便性だけで考えればいいのにｗ

>>346
うーん、言いたいことは解らんでもないが、それこそ面倒臭がりの発想じゃね？
要は属性を全部ひとつの連想配列に詰めちゃって、全てobj.get(key)の形式でアクセスするってことなんだろうけど
キーひとつひとつに属性へのアクセス方法は違いうるんだから、そんなことしちゃマズいでしょ。

>>346
それgetの戻り値で取ってこれるオブジェクトが
全部同じ型じゃないと成り立たないよね？
Javaでそういうのはちょっと……

折角の型情報を捨てよう捨てようとする人々がいる。

型自体はJavaとC++に関してはオーバーロードで済むよ。
String get(StringKey)
Int get(IntKey)
型の名前はともかくとしてこんな感じ。
get(Key.NAME);//String型
get(Key.X);//int型

すぐににっちもさっちもいかなくなるぞ、それ

大丈夫2万行超えるようなコードでも困ったことはないから。
まぁ、WindowsのWM_〜とかと似たようなもん。
Point2Dがint型一個とかあり得ないし、Nameが文字列以外になるってのも
まず無いからその辺で困ることはない。どのキーをどのクラスに持たせるか若干悩むぐらい。
C++だとグローバルのconstで良いんだけどね。

たかが2万行程度のコードなら普通にsetXXX, getXXXってやったって
困る事は無いだろうよ

そういう実装も可能ってのは分かったから、メリットは何？
ただの縛りプレイでしょ？

縛り？こっちの方が遥かに楽だけど？

他のインターフェースとの親和性、
既存のオブジェクトを変更しなくて済むことによる拡張性
get,setから識別名が独立する事によるメタ操作のしやすさ。

同じ戻り値、引数の組み合わせが複数あったらどうすんの？

>>357
さして親和性も拡張性も感じられないんだよなぁ…具体的にどんな風に拡張されたり、親和性が発揮されるのかが解らない。
それよりも色々と危険な操作が多そうで、そっちのほうが心配になる。

あ、>>358は型のことね

>>335
この主張に限ってはsetter、getterは絶対ダメでいいだろ
だって折角仕様書書いてもここには明記されてませんがsetter、getterで
記述のないクラスにもアクセスしていますなんて意味ねーだろ
担当者呼び出して作り直してレベルじゃん

イベントに限定してデータの入出力（外部のクラスへという意味）をイベントだけに限定したからこそ
イベントの記述に意味があるんでしょうが

元の主張がなんなのかよく分からんが、setter、/getter使ってますって書きゃいいじゃん

ダメですよ使っちゃ

>>361
だから、なんでsetter,getterに限って仕様書に書かねーんだよ
入出力のイベントとして書けばいいだろ
それとも名前が気に入らんのか？sendとrecvとかなら納得するか？

>>361
上半分はsetter、getterに限った話じゃなくね？

下はちょっとなに言ってるかわかんないです

>>364
イベントＡと同じことがsetter、getterを駆使してイベントＡとまったく同じことができちゃうと・・・
そういうのもなくしたいからこそのイベントなのに意味ないじゃん

イベント、という用語について合意は取れてるのか？ｗ

>>359
これで危険というならMapも使えなくなるぞ。
親和性ってのは
Map<Key,String> map = new MapKeyStringAdapter( さっきのオブジェクト );
map.get( Key.NAME );
こういう感じ。1段噛ますけどKey.NAMEってのがそのまま渡せる。
今までMapを取っていて、ジェネリクスの型が不定だったオブジェクトはそのまま再利用できるようになる。

>>365
だから見る人はこのクラスが何やってるのか？ってのが知りたいわけよ
その何やってるのか？って部分は仮にsetterやgetterをクラスから排除した場合は
イベントの一覧さえみればすべてわかるんだよな？

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

ってか、イベントのこのメリットが理解できなくてよくオブジェクト指向理解できてるつもりでいるなお前
なんていうの？アクセスさせないことでの利便性的視点が全然育ってねーのな

でもKey.NAMEが存在しないメンバを指さないようにするには
列挙型とか使うんでしょう？
結局は列挙型に識別子が移っただけですよね？
それにgetやset内部でKeyで分岐するコードは自分で書かなきゃだし、
そこで間違えてもコンパイラはエラー出さないね。

>>369
>>367

>312
> じゃあ、君なりにぐぐってみて一番最初にあたったオブジェクト指向のイベントの定義でいい

つまり、イベントの定義はなんでもいいらしい

>>369
全部のメンバ変数にget,setつける前提で話してんの？

>>369
定義されてない"イベント"で同じ情報を使いたい場合はどうすんの？
極端な話int.addTo(int)って定義しかなければ掛け算は出来ないの？

コマンドライン引数に基づいて、与えられたシェルコマンドを指定回数実行し、
ベンチの結果を出力する簡単なコードなんだが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();
}
・・・略・・・

>>372
じゃあおれはC#の宣言元 (パブリッシャ クラス) のクラスまたは
構造体内でしか呼び出せない特殊なマルチキャスト デリゲートを想定する。

やばい、今日はまともじゃない。
変体連想配列野郎とイベント野郎に全部持ってかれてる。
OOPってやっぱり頭おかしくなるのかな。

>>377
OOPがらみで香ばしくならなかった展開を見たことが無い。

>>374
メンバ変数の話をしてるときに定義されてないイベントでって言われても
イベントなかったらオブジェクトの処理はどこに書くの？

>>357
ま、楽っちゃ楽だわな。

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

折角 Java を使うのだから、静的な言語の利点というものを
よくよく考えてみるべきだね。
特に、速度よりも安全性という観点で。

>>370
別にコンパイルエラーは重要じゃないよ。
大体、Swingでも整数つかっておんなじことやってるし。
さらに言えば、Swingなんかの整数と違って継承が使えるから
適用範囲の調節もある程度はできるし。

まぁ、この1解決策は引っ張る話じゃないけど。
問題は、拡張性のないsetter/getterの無能さだし。

>>380
ふ〜んじゃ、エリートさんはsetter/getterを駆使することでどんな素晴らしい生産性を生み出してんだい？
タダの型安全？ちゃんと実装の切り替えぐらいできてるんでしょ。

別にsetter/getterだって、仮想関数で書いときゃ多態ぐらいできるだろうよ。

雪駄、下駄用語派の意見をもっと聞きたいな。
今まで上がってる具体的なメリットがしょうもないもんばっかだし。

>>376
俺もそれ想定したわ

拡張性のないsetter/getterの無能さとやらが問題なんじゃなくて、
値を入れて出す、持たせとく、という、構造体的な設計が問題なんじゃないか？
もっと他にやりようがあるのに、やっぱり構造体的なつくりになって、
個々のデータのことをいつまでのみんなが心配してるような状態。
カプセル化がうまく働いてない、隠蔽がイマイチ進んでない状態。

もちろん、構造体的なクラスはすべて間違っている、などというつもりは現時点ではないが。

>>383
無意味に実装変えられるのと、効果のある実装の切り替えができるのじゃ全く意味が違うぞ。
役に立実装の切り替えつっつっても、結局GUIのbeanぐらいだろ。

テンプレートメソッドパターンもget(key)で実装してんの？

カプセル化を働かせる為にコードを書いてる訳じゃないから、その場の判断で
柔軟に対処したら良いと思うわ

そーいや>>196はおもくそgetter使っとるな

オブジェクト間のやりとりはすべてイベントだけにすればいいんだよ

>>391
釣りなのかマジなのか分からんが、
段々面白くなって来たwww

>>387
GUIだって言ってもSwingなんて、タイトルはタイトルだし、幅は幅だし、
別に実装が変わってるわけじゃないけどな。幅やらタイトルの値を参照している
描写メソッドの実装が変わったのと、他のメンバーが増えただけ。
getter/setterは何も変わってない。

BezierPath クラスのメンバに strokeColor という変数があったとして、
setStrokeColor() メソッドをコールするのはイベントじゃないの?

もうカオスだ。ここまで荒れたことないぞ？
変体連想配列の人とコミュ障俺用語イベントの人、相当やばいと思うぞ。
ワケワカランことばかりいってないで、早く現実世界に復帰した方が良い。

今日はろくに動きもしない疑似コード(笑)が少ないからマシな方だよ

>>395
変体連想配列のほうはたぶん、誰もが一度は通るみちというか、
それで便利になるだろうと夢想したり実践したりするだろうと思うが、
イベントの人のほうは、イベントの定義からして見えてこないｗ

>>394
普通に考えて、setter/getterもイベントだよな。
その辺がもう意味不明なんだよ。やべぇ。

本人以外までイベントをメソッドの意味で使うと混乱するからやめろw

変態連想配列ねぇ・・・。
別にこっちの話はいいよ。こっちは、
これで上手くいってるからさ。
それはそうと、そこまで人を點すんだからgetterとsetterで
再利用性を高め生産性を向上させる方法を教えておくれよ。
君等のほうが優秀なんだろ。

>>398
でも大抵記述ないよね

>>400
いや、連想配列アプローチで疑問なのは「何でそれをJavaで？」の一点かと
なんというか動的型のセンスなんだよね
Java使う人ってそういうコード嫌いなんだと思ってたよ

なかなかsetとgetをしこしこ書いて満足してる人の意見が出ないなぁ。
雪駄下駄派自体は居ないのか。

unk = nko.getUnko();
unk++;
nko.setUnko(unk);

糞コードだよね？

map.put(key, new Integer(((Integer)map.get(key)).intValue() + 1));

>>403
setter / getter 書いてるよ
主に MVC の model の部分で使ってる
データの変更時に setter の中で undo の登録したりしてる

それが駄目だと思う人は、別の書き方で書いたら良いんじゃない

>>405
そんなのコメントがなきゃ見た目なにやってるのかわからないコードがむき出しになってる時点で糞コード

>>401
なんだ、ただ値を渡してるだけのアクセサを批判したい人だったのか

>>402
まぁ、Java専属じゃなからね。
一番好きなのはSmalltalkだし、仕事じゃC++やらPL/SQLやら
Perlやら色々使ってる。まぁ、そもそもsetとかgetの類は
あんまり使わない。せいぜいバカみたいなStrutsで使ってるぐらいだし。

>>405
キタネェな
こういうの関数でラップしろよ

>>404
自由に数値をいじってもらって構わないクラスなら特に問題ない。
インクリメントするという作業が必要なクラスなら設計が悪い。

>>410
そうだろうか？　これはJavaでこういうインクリメントするときの煩雑さを示したわけだが、
かといってこれをこれ以上ケアしてもしょーもないと思うが…。
あえて言うなら横に // インクリメント と書き放ってれば十分と思うが…。

別にaddUnkoもあって
setUnko、getUnko、addUnkoでうんこを突きまくります

>>406
MVCがGUIかWebの方かで話は変わるけど、
GUIの方だったら、setter/getterで拡張しづらいと感じ無かった？
>>375　にさオプションを拡張する例がでてるけど、
あんな感じで新しいオブジェクトを既存のモデルに
組み込もうとすると、getterとsetterが新しいオブジェクトとの
性質の不一致で邪魔に感じたりしなかった？

>>412
こういうキタネェのはラップするって昔から決まってるんだよ
mapとかうすぎたねぇものみせるんじゃねぇ
てめーがmapで何が表現してーのかそれがクラス名になるんだよハゲ

>>413
いや、だからね、何で見せなくてもいい変数までアクセサつける前提なの？

>>414
setter/getterも所詮インターフェースのひとつに過ぎないし、
拡張のしづらさはJavaのインターフェース一般の話じゃないのかね？

>>415
そうかなぁ？　ラップしないほうがいい例の一つだと思うけど。
マップ。ゲットして1足してプット。これをラップしだすと大変じゃね？

>>418
大変じゃなかったらやってもいいと思ってるんでしょ？
あくまでも大変だから

>>418
足し算するだけなのにキャストとnewが汚らしい

>>419
クラス海草がまた生まれちゃう。
また名前を考えなきゃいけない。
ホントに再利用される単位か？

って点で大変だわな。
気軽にクソクラスを一度つくっちゃうと、
全体がそれに引っ張られ続けるから。

それよかmapが何を体現してるものなのかコメント頼みになるところがいただけないね
stl系使うときは使用者が何考えてるのかわからないから必ずクラスでカバーしてもらうよ俺の派遣先の場合

変態連想配列の話からただの連想配列の話になってる

>>405
内部でそれをやってても別に文句はないけど
外に見せるのはちょっと、利用者に実装を意識させすぎ

>>423
普通の連想配列の話になるととたんに速度が落ちたね。

>>426
だってつまらないんだもん

ワロタｗ

はい、スタックオーバーフロー入りました。

>>417
そうでもないよ。setと書いて1要素づつ値を設定するのと、
changeやら動詞を書いて複数の値を与えるんじゃタイミングとか結構影響が違うよ。
いい例じゃないけどsetStartとsetEndなんてのより、changeBand( start, end )の方が、
startからendまでの間をchangeが呼ばれたタイミングでどうやって処理するか、
オブジェクトに任せやすい。無視するって手もオブジェクトによってはありだしね。

>>429
setStartAndEndってsetterでもいいじゃん。

changeBand -> setBand

>>430-431
getは、そこに存在しないけどね。
getが一切存在しないことが当たり前で、
setだらけって言うならそれでいいかも。
そうすると、まぁ言葉遊びだね。もはや名前に
気を使う必要が無くなる。moveもsetMoveだし
addもsetAddだし。divもsetDivだし。

そもそもsetter/getterの対象にならんような例を出すのが悪い

>>433
そう？じゃGUI MVCのオブジェクト間でsetter/getterを使う例を教えてよ。

setStart/setEndが主でchangeBandが従か、その逆かで話は変わる

setStart(int start){changeBand(start, getEnd());}なら最初からchangeBandを公開すべきだし、
changeBandが内部でsetStart/setEndの呼び出し順の条件分岐や排他制御してるんなら、定型処理をまとめた便利機能って位置づけだよね

>>434
>>433じゃないが、とりあえず位置情報

ばかばっか

>>432
>そうすると、まぁ言葉遊びだね。

まさにその通りなんじゃないの？
だから皆不思議がってたんじゃないの？
整合性を崩すようなsetter/getterはダメなんだけど、
でもそんなのは、setter/getterに限ったことではない訳で。
「整合性を崩すようなメソッドはダメだよねぇ」
「そうだねー」
で終わってた話でしょ。

setter/getterでmutableなオブジェクトをやり取りするのは鬼畜
インターフェースを通さず内部を弄れることになるから
immutableなオブジェクトならどうでもいい

イベントってイベントドリブンの用語でOOに関する用語じゃないよね

>>435
set/getとchangeBandは、排他的って捉え方だよ。
もっと言うと、changeBandで与えられた、startとendはchangeBandの中で消化される感じ。
setStartとsetEndの方は、両方が設定されてから消化される感じ。
そもそも、消化される用な用途だからMVCじゃ寧ろ使い辛いって話じゃあるんだけど。

>>441
＞両方が設定されてから消化される感じ。
それはカプセル化出来てないです

>>438
いや、明確な違いがあるでしょ。setterとgetterは
両方が存在する場合、同じ値を持つっていう。
100をsetterして50が得られるgetterは許されるって
言いたいなら知らないけどさ。

>>442
だからダメでしょ。こういう使い方には使えないでしょ。

>>436
moveって用意しといて移動距離渡したほうが良くね？
MVCなんだからModelやViewの判断委ねるでしょ大体。
Viewから座標取り出せる必要はないしね。

いやもう言ってることがいよいよ意味分からん。

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

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

カプセル化されてないsetter/getterの例だして、「ほらカプセル化されてない」って。
そりゃカプセル化されてないんだからされてないんだろうよ。
setter/getterに関わらず、カプセル化されてなきゃされてない。
そういう風に書いたってだけで、setter/getterは関係ないだろ。
逆に、適切にカプセル化されたクラスのsetter/getterなら、カプセル化されてるわな。

おいおいビューのコンポーネント間で相互調整できないぞ

現在位置からの相対位置しか指定出来ない（そして現在位置は入手出来ない）
そんなオブジェクト嫌だ

補足、
MVCなら、Viewだけが座標やら大きさやらを把握しとけばいいんだよね。
ModelがViewからはみ出すサイズでも、それを管理するのはViewだし、
Modelをどの位置に配置するかもViewの役目。View上のレイアウトもViewの役目だし、
Controllerから渡されたドラッグの指示で移動したり、画面端で止まったりするのもViewの役目。

>>445
いや、オブジェクトに入力された値がそのまま外に出ていくケースの方が珍しいって。
Stringのsubstring(10)とか読んだら、Stringと同じ文字列が帰ってくるの？
10文字切り捨てた文字が帰ってくるんじゃないの？

そもそもＭＶＣぶち上げた奴もオブジェクト指向わかってるんかよーわからんな俺は

MVCだけじゃ大規模に耐えられない。
なぜ日本人はMVCどまりなんだろうねｗ

現代のUIフレームワークのレイアウトエンジンってもっと高機能で、
子オブジェクトと再帰的にネゴシエーションして実際の配置を決めてると思うけど

>>447
現実世界のほとんどの物は、
相対的に扱われるんだけどな。

「絶対位置」なんて幻想だよ。

>>453

>>447
相対位置かどうかは、オブジェクトの判断に任せるんだよ。
そのオブジェクトを指定するのはプログラマーだから、
絶対位置になるか相対位置になるかはプログラマーは把握してるでしょ。
interface的に保証しないってだけ。もう少し、メソッドじゃなく
オブジェクトを指定して振る舞いを指定するってのを意識してみたら？

そもそもＶｉｅｗで制限したい内容をもってるのがＭｏｄｅｌだから
ＶｉｅｗとＭｏｄｅｌはわける意味がないほど癒着してしまうだろ
かりに単体で動かしたときにＭＶＣはそれぞれ別々に動作すんのか？
しねーだろ明らかに・・・
無駄に工数増えるだけだろ

みんな「俺だけがわかってる」と思い込む手法

>>455
オブジェクトしか自分の絶対位置を知らない状況で
>>452が言うようなネゴシエーションってどうやるの？

>>456
MVCをはModelとViewははっきり分かれてるよ、最近のMVVMだったかとか
COCOAのアレは知らないけどね。
例えば、「音声Model」が存在したとき、「声紋View」、「スコープView」、「スピーカーView」に接続できる。
この時、「スコープView」は「電流計Model」にも接続できる。つまり、「スコープView」は「音声View」とは
独立してて中立。この独立関係によって、「スコープView」なんかはModelを変えて再利用できるんだよ。

>>458
さぁ？ネゴシエーションするようなFrameworkというのが実際どうなってんのか知らないから
なんとも言えない。ただレイアウト自体は可能だけどね。>>375にあるコードが
オブジェクトで振る舞いを決めてるでしょ、ああいう感じ。

>>456
それはMVC止まりだからそうなるんだよ
ちゃんとレイヤー分けしていれば、隣の層だけ通信をすればいいだけになる。
クラスごとに責務が明確になり開発もしやすくなる。

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

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

あともう一つ、昔から言われている有名な教えだが、データ構造というのは
長期間安定して変わらないものだが、ロジックは変更されるもの。
それを知っていれば自然とデータとロジックは分けるべきという結論に結びつく。
別にオブジェクト指向を否定しているわけじゃないよ。使うべき場所を見極めろという話。

×つまり、「スコープView」は「音声View」とは独立してて中立。
○つまり、「スコープView」は「音声Model」とは独立してて中立。

なんか結構間違えた。ゴメン。

>>459
MとVCは機能的にはわかれている。
（VとCはわかれていない）

だけど、一方がもう一方の構造を前提に作られている
Mのインターフェースが変われば、VCにも影響が出てくる。
そのことを癒着と言っているのだろう。

>>463
インターフェースを癒着と言われるとどうしようもないよね流石に。
それを言われると、オブジェクト指向の疎結合なんてって・・・。

>>461

この文章からデスマーチの匂いを嗅ぎ取ったのは
俺だけだろうか・・・

>>464
うん。だから層が2つしかないから
癒着するしかなくなっちゃう。

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

MVCは教えるのが簡単だから
広まっているが初歩でしかない。

>>465
えーと、まず、ここに書いてあることは、
プロの間では、常識です。

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

君がアーキテクトレベルではないというだけの話。

>>463
Controllerも独立させられない訳じゃないんだけどね。

//テキストの内容を指定されたファイル名で保存するController
view.addListener( new SaveFile( textModel, fileNameModel ) );
//closeメソッドを持ったViewを閉じるController
view.addListener( new CloseView( view ) );

>>460
つまり分からないんですね
そりゃそうですよね
どうやってオブジェクト間で相互作用するんだって話ですよね

>>468
なんつークラス名だよ。そこ突っ込むのは申し訳ないが。

>>469
アレ見ても解らないか。。。
ボタンとかを格納してるウィンドウは、自分の大きさ位置を把握している。
ウィンドウは最初は何も格納していない。
ウィンドウは飽くまで自分のセオリーで格納した部品を並べる。
部品は自分の大きさはウィンドウの指示に従い決める。
ウィンドウに何を格納するかは、プログラマーが決める。
プログラマーはウィンドウがどのオブジェクトをどう並べるかは把握しており、
絶対座標になるか相対座標になるかは全て把握している。

>>470
まぁ〜ネ〜。それは自分でも思う。

つまり座標は個々のオブジェクトが管理するんじゃなくて
全て知ってるウィンドウが管理するんですね
それってオブジェクト指向？

各オブジェクトの大きさを指定できないUIとかないし、
クラスごとにサイズ設定の制約もあるとおもうけど

>>473
ウィンドウっていうかプログラマーね。
オブジェクトは誰と繋がってるか知らないから。

だから >>375の例引っ張ってきてんじゃん。
Optionたちはコンストラクターで与えられたもの以外、
誰から値を渡されるか全く知らないでしょ。

今有名なウェブ用のフレームワークのほとんどが
コントローラー作成用フレームワークになってるのが行けないんだよな。

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

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

ただフレームワークがコントローラーを作るだけのものということを理解してないから、
フレームワークに申し訳程度に付いているモデル機能だけを作って作るから複雑になる。
ユニットテストなどのことを考えると、本来はモデルはフレームワーク無しで動くように作るべきもの
フレームワークは無関係の所なので、自分で勉強して作る必要がある。

>>375のOptionたちはお互いのこと知る必要ないじゃん

>>473
> つまり座標は個々のオブジェクトが管理するんじゃなくて
> 全て知ってるウィンドウが管理するんですね
> それってオブジェクト指向？
オブジェクト指向だよｗ つかオブジェクト指向はこうだ！って決めつけてない？ｗ


座標はウインドウマネージャが決めるべきだろう。
ウインドウマネージャオブジェクト

>>477
同じようにお互いのことを知る必要ないようにできるって事。

座標を個々のオブジェクトが管理していたら、
横幅が狭くなったとき、次の段に行くなんてことができなくなる。

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

その属性をもとに座標を配置するのがウインドウマネージャ。
オブジェクトの属性と、実際の座標は切り離すべき。

つまり相互作用させるくらいならオブジェクトの情報は
外に出してトップダウンにコントロールしてしまえ、ってことですね

>>476
てかWebのMVCは微妙だよ。テーブルビューとか、グラフビューとか再利用できるビューが用意されてないし、
MVCの再利用性が全然生かされない。

>>480
ということは、個々のオブジェクトの属性をgetterで取り出せないと
ウィンドウは配置できませんね

>>483
当たり前じゃね？

>>484
そもそもsetter/getterの是非の話だったのだが

結論はWPFか？

>>485
そんな話は知らんｗ
ってか、なんの話をしているのかわからんし。

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

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

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

この名前であってもgetterだけ作ることもできるし、setterで制約違反の値を入れようとしたら
エラーを出すこともできるというJavaのsetter/getterと同じメリットを持っている。

>>483
windowManager = new WindowManager( レイアウト )
window = new Window( 〜, windowManager );
window.update();
   //update内部
   windowManager.replacement( windowの縦横の幅, 子ウィンドウリスト );

getterは全く要らんな。

あと、Javaの話。

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

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

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

だからsetter/getterが面倒なだけと言っている人は、IDEやテンプレートを
使ったことがない人だろう。

JavaがださいならScalaをつかえばいいようん

>>480>>487
えーと、>>488さんはgetter要らないって言ってますよ？

>>488
その子ウインドウリストって
getter/setter持ったオブジェクトだろ？ｗ

>>489
面倒なんでぶり返さないでください。
理由は300番台ぐらいの流れを見れば解ると思いますので、
何卒よろしくお願い致します。

>>491
俺は言ってませんよ？

WPFはコンテナに定義されたプロパティ識別子をキーとして値を子要素が持つという考え方
>>488と根本は一緒だが、よりデザイナで扱いやすくするためにそうなったんだろう

>>492
int i = 0;
while( childlen.hasNext() )
{
      window = childlen.next();
      window.movePoint( 計算した位置 );
      window.resize( 計算した幅 );
      ++i;
}

>>496
その「計算した位置」は
オブジェクトから幅をgetして計算するんだろｗ

setter/getterなくても、オブジェクト指向をやめて
C言語っぽく、関数と構造体に分ければ出来なくはないよ。

問題は、オブジェクト指向をやめるかどうかなだけ
setter/getterいらない＝オブジェクト指向を止める。
それだけの話。

>>497
>>488で既に取得している大きさとレイアウト、リストの要素数なんで
別にgetterの出番はない。

>>498
逆だよ。それじゃ構造体とおんなじだろ。ってか蒸し返すなめんどくさい。

>>499
> 既に取得している

えーと、オブジェクトのgetterから取得するの？

>>501
アルツハイマーか認知症を患ってらっしゃるんでしょうか？

>>502
質問に答えたらいかがでしょうか？

>>501
つまりsetter/getterで出し入れしなきゃダメな情報は
全部オブジェクトの外にリストとかで持っとくのさ
何のメリットがあるのか知らんけど

>>503
僭越ながら下記に手配致しましたが、下記の内容は
ご理解いただけませんでいたでしょうか?

window.update();
   //update内部
   windowManager.replacement( windowの縦横の幅, 子ウィンドウリスト );

オブジェクト指向で作るならば、
高さとか横幅という情報は、
オブジェクトが持っている。

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

オブジェクト指向で作らないのなら
適当に配列にでも入れとけよ

>>505
その子ウインドウリストってのは
オブジェクトじゃなくて、ただの配列であるということですか？

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

これは作り方の問題なのでで、オブジェクトにしないのなら
どうぞ、そのように作ってください。

>>506
だからwindowが内部で大きさと子ウィンドウのリストを持ってて、
内部で直接windowManagerに渡してるから、windowからwindowManagerが
ワザワザ取り出す必要が無いんだろうが。本当に認知症か。

>>508
だから内部で持っている変数から値を取り出してるでしょ。

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

オブジェクト指向じゃない作り方として一般的だよ。
それで作れるよ。Ｃ言語とかそうやってたんだから。

>>507
中学生かホントに。他のレスも見て考えろよ。
>>496 でもともと補足してたろ。

>>510
何を必死になってるんだ？

俺はgetterがなければ無理なんて言ってないんだが、
オブジェクト指向じゃないやり方だねって
言ってるだけなんだが。

レイアウトに必要な情報はレイアウトの方法によって違うからコンテナが持つべき
というのは間違ってないよ
それをなんとか子の属性でやろうと思えば>>495のようになる
外部でまとめて持つと宣言的に書きづらいからIDEに向きじゃないしメモリリークとか気にしないといけない

>>511
setter/getterはRAD環境の為のものであって、
OOとは関係ない。C++の標準ライブラリも、
J2と呼ばれていたJavaの大半のライブラリも
getter/setterは持っていない。Javaに関しては
RAD環境に摺り合わせるためjava.bean.*という仕組みが導入された。
その仕組みに合わせてset/getを冠するメソッドが増えているというだけ。

>>488はこうじゃないの？

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

//update内部
windowManager.replacement(this, windowの縦横の幅);
while (childlen.hasNext())
{
window = childlen.next();
window.update();
}

setter / getter って自然に使ってるわ

http://developer.apple.com/jp/documentation/cocoa/conceptual/objectivec/Articles/chapter_5_section_3.html

構文としてプロパティを取り込んだC#さんや
attr_accessorがあるRubyさんもいる

最低でもパラメータとしてのプロパティはどうやっても必要
セッターなしでどうやって人間がウィンドウのサイズを指定するんだよ

>>512
> レイアウトに必要な情報はレイアウトの方法によって違うからコンテナが持つべき
> というのは間違ってないよ

レイアウトに必要な情報は、
コンテナ特有の属性＋オブジェクトの情報。

>>518
そのコンテナ特有の情報という意味のつもりだった
コンテナ特有の属性はコンテナに持たせてもいいが、WPFのように他のクラスのプロパティを持つことができる
仕組みがあればそれでも可能だと

>>513
OOにとってはgetter,setterもただのメッセージ
一部の低能がそれを特別扱いして排除しようとしてるだけ

WPFは変態連想配列の実装であって、「○○メソッドで調整するから位置属性は公開しなくても良い」ってお花畑ではないよ

setter,getterの問題は>>386や>>404 でしょ
ロジック部分に余計なsetter,getter使うのが糞コード
連想配列君はよく分からん

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

あとMVC以外に有名なUI設計の基準はあるの？

>>404が駄目って、getterとsetterの組み合わせで出来る処理は全部呼び出し先に定義しないといけないの？

>>516
Rubyのアレはともかく、objective-CやらC#、.net上で動く言語の
プロパティーはもろDelphiの流れを汲むRAD環境用じゃん。

>>523
一応常識としてgetter、setterを組み合わせて処理を作ってはならん
>>413みたいに片やgetしてプラスしてsetしてる箇所と
片やaddUnkoなんてしてるようなときはどこでプラスされてるのか突き止めるのが困難じゃないか

>>522
>>488と似たような方法でgetter自体は排除できるよ。
上の方でも話が出てるけどその方が扱いやすい。
ブロードキャストの時にブロードキャスト処理内だけの
一時オブジェクトを作ってブロードキャストするって効率化もできるしね。

>>517
ココでsetter/getter排除できるって言ってる人は、
オブジェクトへの入力メソッドとsetterを分けて
呼んでるんだけど解ってる？
オブジェクトへの入力自体は誰も問題としてないの。

>>522
てか、getterが増えちゃうのはMとVの関係にイベントが設定されてないからじゃない？
テキトーなタイミングでテキトーに渡してるからそういうことになっちゃうんじゃない？

>>527
RADにかかわるプロパティの多くは単なるパラメータだろ
UIのレイアウトなんて実際にはRADと密接に結び付いた例を出すからおかしくなる
内部のロジックは別問題として、getterを持たないUIの要素なんかありえん

>>514
thisを渡してgetter呼ぶってか、無意味。
それどころかせっかくinterfaceで切り離してる
依存性が増えるんでかえって不味い。

>>530
thisと属性（windowの縦横の幅）をreplacementに渡してるからもうgetterを呼ぶ必要は無い
thisを渡してるのはwindowManagerがどのオブジェクトの属性が渡されたのか分からないから
ま、windowManagerがgetする代りにwindowがpushしてるだけですけどね

間違えた。煽ってゴメン。

静的型は、いらないメソッドの排除と削除を要求する
動的型は、いらないメソッドを無視する
この違いが生産性の差につながるんだろうな

setter/getter自体を問題にするのは変だと思う。扱い方が問題なのであって。

即値やそれに準ずるものを扱うsetter/getterはそれほど問題じゃなくね？
逆に多数のオブジェクトから参照され、自身も多数の変更可能な状態を持つようなオブジェクトをsetter/getterに渡すような構造はマズいだろうし。

たぶん点オブジェクトを結ぶ直線を引く時でも
始点オブジェクトに終点オブジェクトを渡して直線を生成するんだろうな
Godオブジェクトになりそうだ

てか、setgetなんてつけた時点でそもそもイベント的扱いをしない気まんまんだよね
状態も糞ももってないただの意味不明なクラスを作ろうとしてる
いつでもアクセスできるくせにアクセスしちゃダメな瞬間が存在するって
もし、一瞬だけだったら関数で十分だしね

>>526
馬鹿な俺には難しいもっと簡単な例で頼む
例えばモデルは四角形の面積を計算するもの viewでは、縦、横、面積を表示

>>528
いわゆるObserverパターンとか？

setter, getterは全てダメ派（イベントの人）と、
setXxx, getXxxて名前がダメ派（変態連想配列の人）と
入り乱れててワケ分からん

getter setterが駄目という人はオブジェクトの中の変数をそのままセットしたりゲットしたりすることが
無意識のうちに仮定されているのだと思うよ。
オブジェクト指向で大切なことはgetterやsetterは値を返すという性質だけを仮定していることだよ。

>>538
>>404のようなsetter,getterの使い方はダメ派もいる

>>540
setterとgetter両方公開しちゃったら組み合わせて
処理作られても文句言えんだろ
隠蔽したいデータは公開しなくて良いんだぜ

>>525
俺からしたらsetXXXの値のソースが何かにこだわる方が常識はずれだと思うよ
黙って引数を処理するのがメソッドの役目だろ
文句があるなら例外でも投げてみろや

あと使用法の分析なんて、シグネチャから推測できない勝手な要件を追加されてもねえ

addUnkoでしかインクリメントしたくないなら
unkoはコンストラクタで初期化したら外からset出来ちゃダメ
つまりこの場合はsetUnkoがいらん

>>541
ごめん
もちろん公開していたら、他人にこう使われても文句は言えないが少なくとも自分ではこう書かないということ
MVC利用時にgetter使わない方法がわからないからああいう書き方した

好き勝手に利用できるのは利用側のコードに対する制約が少ないということだから
必ずしも悪いことではないぞ
プルパーサとSAXの違いみたいなもんで、
プロパティ主体のライブラリを使ってプッシュ型で作るのは簡単だが逆は難しい
利用側も含めて設計できるならいいが、UIコンポーネントなんかでプロパティが好まれるのは当然

四角形の縦、横、面積を計算して表示するプログラムで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に則っていない。

続いて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());
　}
}
つづく

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が必要になる
っと思っていたんだけど、これを解決する方法はあるの？
上の方で解決できるって言ってる人がいるようだけど、よくわからん

それが嫌ならMVC使わなきゃいいんじゃないの？

>>549
これは両立できるものじゃないってことでOKなのか
MVCを使う上では、getterはやむなし

どうでもいいけど俺なら、
Model m = new FooModel();
View v = new BarView();
Conroller c = new BazController();
で
v.paint(graphicscontext, m); // 描画スレッドから呼び出し
c.update(event, m); // イベントディスパッチスレッドから呼び出し
みたいにするな。MVCの三者の関係上。
vもcもmも動的に入れ替える前提で作る。

単に目的が明確になってないから重要な決定をクラス同士でパスまわししてるようにしか見えない
ＭＶＣってなにがメリットでなにがデメリットなの？

>>552
それがオブジェクト指向のメリットだと思ってた
どう変更するかはわからないのだから、将来変更する可能性があるところを変更できるように切り分けておく

一応wikiには

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

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

ここが重要な点だから例を出すならＶｉｅｗが２つあるようなもんじゃないとダメだな
少なくとも俺にはいまでたコードだとＭＶＣは仕様が決定してねーから綺麗に見えるだけの骨ヌキクラスにしか見えなかった

>>553
そんなことどこにも書いてない
思い込みで変な発言するのやめろ

>>541
>隠蔽したいデータは公開しなくて良いんだぜ
公開しなきゃ良いじゃんって思ってしまった。
公開して問題ないものだけ公開すれば？
setter/getterもつけつつ、カプセル化も満たしとけば良い訳だからなぁ。
setter/getter==構造体的なものって発想は俺にはないわ。なんつーか短絡だよなぁ。

>>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を作ってやればいい。

>>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には手を加えず出力を変更できる

>>556
それは結局なんのイベントなの？
いつでも送るといつでも反映されるの？
それともメッセージ送ったらDoEventsでもかましてやらないと動かないの？

>>552
>>459 を見て何もメリットを感じない？
ViewはModelを新しく追加しても、前に作ったものが使えるんだよ。
ModelはViewを新しく追加しても、前に作ったものが使えるんだよ。
Controllerも作り方次第で、前に作ったControllerを新しい、ModelとViewに使えるんだよ。

>>560
実際そんなことはねーからどうでもいいんだよ
この構造は明らかにＭとＶとＣが癒着をする
おそらくＭＶＣの主張してるメリットは現場じゃメリットになってないと思う

MVCの一番の利点って、ドメインのロジック作るときに
ロジックだけに集中出来ることじゃないの？

>>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

>>559
あーはいはい。
分かった分かった。
そういう時は、setter/getterがどうとか、イベントがどうとか言わず、
シンプルかつ素直に、「俺はステートマシンが嫌いです」って言えば、
何の御幣も無く言いたいことが相手に伝わるんだよ。

>>561
>>562

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

そもそも、Cを数十行もあるクラスにしちゃいけない。
あくまで、Cが受け取ったイベントをViewとModelに伝えるだけ。
Cは　>>468　みたいな粒度で十分。

>>559
・値の取得/設定操作です。値の意味はメソッドごとに異なるので一般化はできません。
・設計次第です。でも非同期動作のトリガーとなる例はほとんどないです。
・DoEventsが必要と明記されている設計ならそうですが、一般論としては設定だけで完結した動作です。
　でも内部的にはすぐに反映せずに、実際に変更処理が必要になったときに行う実装も結構あります。

>>566
色々考えるとやってることおかしいだろ？
タイミングや状態すべてが定義されてない
設定しても無駄なタイミングもあんじゃねーの？
あんまりよく考えねーと欠陥だらけのクラス量産すんぞ気をつけな

>>563
そうだよ。MVCはいくつかのデザインパターンで構成されてる。
というか、MVCをいくつかのデザインパターンと見なせる。
MVCはデザインパターンじゃなく、その上位の存在だからね。

>>567
定義されてないんじゃなくて、メソッド別に定義すんの

>>569
やってれば問題ないなｗ

ただ、俺が担当になったらsetter、getterは全部消させてもらう（はじめから使用禁止だけど）
んで本当に必要なイベントにまとめさせてもらう
値の更新タイミングを必要な箇所だけに限定してもらう
そこでまずい場合のみ他の更新タイミングを許す

getterの存在が許せないひとって、要はオブジェクトに自身の情報を訪ねるのはアウトってこと？

あっそう
あんたの趣味はウザいほど分かったからもう妄言を吐くんじゃないよ、問題ないって認めたんだからね

getter禁止の人は、文字列クラスをデザインするときは
str.length() のかわりにオブザーバパターン使って
str.lengthBroadCast(stringListener) で length をブロードキャストするの？

>>572
値を取得してそれ単独として処理するのがおかしいということ
値を取得した時点で、元のオブジェクトからその値は関係なくなってる
何らかの処理をするならできる限りそのオブジェクトにさせろって話

>>575
だから、お前の嫌いなのはgetterではなくて、ステートマシンだろ。
初めからそういえよ。

>>572
俺はイベントのヤツじゃないけど、setter/getterは"同一の値の出し入れ"が前提になってるから否定してる。
オブジェクトに値を入力するのは構わん、オブジェクトから値を取り出すのも構わん。setterかgetterの
どっちかいづれしか常に定義しないといいたいんならそれも構わん。ただ、オブジェクトに入った値が
なんの処理もされずオブジェクトから出てくるのは肯定しない。元の値を取得したところの値を
処理を行うオブジェクトに渡せばいいだけだから。コンテナ見たいな管理をするわけでもないなら無意味。
意味があるのはGUIのようなちゃんと処理を行うものだけだ。

>>574
それはgetterではない
str.length()を使うならおｋ

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

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

getterしたクラスで処理を行うのは駄目

>>574
そのオブジェクトにsetLengthが存在するとでも？

>>577
気がついたら、そういう意味不明なクラスつくってるときあるよな。
何かに渡すパラメータ群みたいなのをグニグニ搭載してるだけのクラス。
クラス内部で処理も糞も、変数群に一貫性すら無いの。
ごった煮になって押し込まれてるだけっていう。

>>577
> ただ、オブジェクトに入った値がなんの処理もされずオブジェクトから出てくるのは肯定しない。

それってsetter/getterの定義の外の話だと思う
同じものをやり取りするセットのもの、というのは確かだけど
何の処理もしないのか、何らかの加工がされるのかを
setter/getterという存在が決めはしないでしょ
内部の処理によって入れた値は変更され得るよ
全く無加工で出てくるかも知れないが、それはsetter/getterの定義内ではないと思う

「それはgetterではない」とか言い出したよ。
setter/getterは駄目、全部イベントでやれっつって、
その「setter/getter」も「イベント」も両方がオレオレ用語なんじゃもう会話にならないよ。

>>577
純粋にパラメータの値を持つだけのプロパティなら実害はないでしょ
内部処理による変化が外に晒される(晒さないと整合性が保たれなくなる)
ことが問題だという話なんだろ?

>>579
あっても変ではないな
空いた領域を埋めるのはヌル文字なのか空白文字なのか知らんが
まあ、それもプロパティにして決めれば良いんでね

>>577
よくわからん。

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

何がそんなに気になるんだ？

>>581
object.setName("もじ");
object.getName();　→へのへのもへじ〜

こんなふうにsetした値がgetで改変されるなら
setter/getter派は絶対認めない筈だよ。
なんせsetter/getterが同じ値になるから彼らはgetter必須だと叫んでんだから。
構造体の代替品が欲しいだけ。

>>584
ちょっとビルダだから状況違うかもシレンが、
C#のStringBuilderにはLengthってプロパティがあって、
値を代入できるよな。で、クリアしたい時はゼロを代入するという。
一瞬不条理だがよく考えるとまあ許せる。

>>578
str.getLength() って書けば分かりますか？
あとこれと>>558のこれらとの違いは何ですか？
squareModel.getWidth()
squareModel.getHeight()

>>579
だれもsetterとgetterは常に両方用意しろなんていってませんよ？

>>586
だよねー
ようはプログラムの組み方が下手糞なんだよな

>こんなふうにsetした値がgetで改変されるなら、setter/getter派は絶対認めない筈だよ。

ほら、またオレオレ定義が始まった。

>>586
認めるよ、仕様として正規化されてるんなら

>>590
定義？ユーザーの態度の事だろ。

イベントイベント叫んでたのは俺だけだな
このレスの前は>>571で今日はレス終了

RADを意識するなら>>588は普通はダメ
.NETでは規約で禁止されてる

>>593
いちおう言っとこうかな…俺、あんたのレス読み飛ばしてる。
だってイベントの定義がいまだに見えてこないんだもん(´･ω･`)

訂正>>586

>>591
まぁ、そもそもそんな事仕様としてどう定義すんのかねぇ？
setName、getNameを呼び出すオブジェクトは全て、
getNameで取得される値は、setNameとは一致しない可能性が有る事を前提に
コード組むわけだ。当然2つのオブジェクトに同じ値をsetNameしても、getNameは2つの
オブジェクトで値が異なる。そういう仕様なんだよね。

>>579
java.lang.StringBufferにはあるぞ

イベントってC#のevent、つまりオブザーバーパターンのこと？

>>594
そりゃRADの為の機能だもん。もともと。

>>597
str.setLength( 10 );
str.setStr( "aaa" );
str.getLength(); //←3

>>582,>>588
ごめん 色々と俺が間違ってた

getter禁止というか　getterして加工して、setter禁止 それならその一連の流れを元のクラスにメソッドとして実装すればOK
その値そのものを取得、加工して、元のオブジェクトに影響を与えたりするのではなく、何らかの目的に利用するのには問題なし
(取得した値を画面に表示するとか、取得した値に従って他のオブジェクトを操作するとか)

>>597
あんたが作ったクラスの仕様なんか知らんよ

まともな正規化の例としては、値の丸めや境界値の反映とか

>>598
いうてもlengthと対じゃ無いけどな。
今入ってる文字列以上の値をsetLengthすると数が合わなくなる。
reserveって名前でもいいぐらいのメソッドだ。
ワザワザbeanに合わせてるけど。

>>603
ほら、setter/getterの値が変わったら困るんだろ。
机上の空論じゃん。

>>601
>str.setStr( "aaa" );
これ抜いて値変えてみろよ。

誰か getter / setter が駄目な理由を箇条書きでまとめてくらはい

まとまったら上から検討していこうぜ

イベントってRADの用意するGUIなどのイベントドリブンのコールバックのことでしょ。
OOの議論にふさわしい単語じゃないね。

>>604

StringBuffer s = new StringBuffer("abc");
System.out.println(s.length());   // 3
s.setLength(10);
System.out.println(s.length());   // 10

>>605
何で俺が>>586の弁護をしないといけないの？
たとえばDOM要素.setInnerHTML("<br>")の後にgetInnerHTML()ってやると"<br />"が返ってくるだろ？

>>602
いや、その下三行もちょっと。

難しく考えすぎだと思う。
i=i+1; が許されちゃう環境に居ることを忘れずに。
関数型言語の人なら知らんが。

>>608
どっちかというと、まずはそれを思うよなぁ(RAD関係なくね？)。
でも、彼の言うイベントって、どうもそれじゃ説明できない。

ああごめん。ここんとこの流れからRADしか頭に浮かばなかったもんで。

"イベント"はイベントの人の職場の設計書用語じゃないかなあ
getter/setterが設計書に書けないんで呼び出されるって言ってたし

まさかネット上でそんなローカル用語つかわんだろ

>>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がそれを許可しているからいいってことになるんじゃないのかな

>>616
それは使うべきでない場所にgetter/setterを適用した例でしかないので、語るような内容は無いです

>>615
本人がグローバルな用語だと勘違いしてるケース、
２ちゃん各所で多々見たがｗ

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

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

いきなりこんなこと書いてるから、ひょっとしてメッセージのことを言いたいのか？
とすらオモタｗ　だが、やはりそうでもないようであって。

議論するときは引用元を意識するということすらしないんだろうな。
日本のプログラマーのレベルｗ

>>606
抜いても、別スレッドから更新される可能性はあるよ？

>>616
それはsetter付けちゃダメな例のひとつに過ぎないだろ
setter/getterそのものを否定する理由にはなれないかと

むしろ>>404はある種間違ってないと思うが…。
下駄雪駄がよく使われてる、直交性が高いメソッドであると示してる、
とすら思えるが…。ちょっとの煩雑さのために、下手に糞メソッドを追加してしまうのは、
それはそれで危ない。よりよいメソッドがスパーンと出てくるのならまあ収まりはつくが。

>>618
いや、俺もフツーにメッセージのことだと思ったよ。
で、なんか字面で大層なモンだと幻想持ってるのかな、と感じた。

>>610
実質同じじゃん。入力を修正するってのは評価できるけどね。
じゃあ、setInnerHTMLとgetInnerHTMLをオーバーライドして
何ができるだろうね。setInnerHTMLに入力できる内容は、
setInnerHTMLを実装しているDOMオブジェクトが許容できる
値じゃないといけない。getInnerHTMLの出力は、DOMオブジェクトと
同じ値を返すようにしなきゃいけない。元々DOMオブジェクトを
利用していたオブジェクトは、DOMの仕様外の値が入出力される
事を想定していないからね。

>>620
setStr("aaa");
はsetLength(3);を呼び出してんのと同じだろ。
別のスレッドでもsetLength(3)を呼び出してることには変わらん。
別スレッドでsetLength(3)しようが、
setStrの中でsetLength(3)が実行されようが、
DOMの例のように、getLength()の値が変わるかって事なの。

>>621
nkoが指してるオブジェクトの実装が変わること考えてる？
むしろ、どう変えられるか考えてる？

>>625
実装が変わるとは？
Nko nko, nko1 = new Nko1(), nko2 = Nko2();
nko = nko1;
unk = nko.getUnko();
unk++;
nko = nko2;
nko.setUnko(unk);
みたいな話？

>>624
内部で全くlengthを管理してないとしても？
実はgetLength()はCのstrlen()読んでるだけでーすみたいなものだとしても？

>>586
setter/getterはアクセス制限を
読み込み可(getterのみ)、書き込み可(setterのみ)、読み書き可(setter/getter)
というようにコントロールでき、
オブジェクト内部を隠蔽もでき（setXxxのときにメンバ変数xxxそのものが無くても良い）、
境界条件のチェックやロギングを仕込んだりもでき、
ポリモーフィズムで処理を換えることもできる
構造体と同じとは思えないけどなぁ

>>628
>読み書き可(setter/getter)
これが問題だって言ってんだけどね。
getterだけsetterだけなら、別にtoString()みたいなもんと変わらんし問題にしてない。

>>629
それが問題になるような属性なら、読み取り専用にも出来るのが利点

>>626
概ねそんな感じ。
でも、それじゃ再利用できないから、nkoは引数で取る。
increment(new Nko1());
increment(new Nko2());
これを踏まえた上で、Nko1、Nko2の実装をどれだけ違う
ものにできるかって話。

>setStr("aaa");
>はsetLength(3);を呼び出してんのと同じだろ。

おなじじゃねぇ。setLengthでは"aaa"はセットされねぇよ。

>>630
読み取り専用、書き込み専用は問題になってないんだって。
読み書き可の状態が問題なんだから。
単に読み込み専用ならconstの構造体と変わらんだろ。

読み書きするのはコンピュータの基本だろ。

>>633
> 単に読み込み専用ならconstの構造体と変わらんだろ。

setter/getterのあるオブジェクトはsetter/getter以外のメソッドは
持ってないとでも思ってんの？

length()とsetLength()を持つせいで構造体扱いされてる
StringBufferさん可哀想www

値の受け渡し自体は必要だから発生しているってことも分かってないから、unko.setUnko(unko.getUnko() + 1)なんて例が出てくるんだよ

>>631
> Nko1、Nko2の実装をどれだけ違うものにできるかって話。

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

Nko#increaseの追加はまだマシとして、Nko#addUnkoValue(int value)みたいなの追加しちゃうのも考え物だね、
ということを続けて書いてある。addだけ追加？引くほうはマイナスを足すということもできそうだが、
かけたり割ったり、ある条件でclampさせたりするのに、全部メソッドを対応させようとするとしんどくなる。

>>635
getName()/setName()とか見たときに、他のメンバーがどうとか問題か？

>>636
StringBufferはちゃんと処理してるだろ。
GUIと同じでタダのホルダーじゃねぇ

>>623
それはプロパティじゃなくて仮想メソッド一般の制限だ

インクリメントするためだけにsetter/getterを実装してるクラスがあるなら
そりゃあアクセサ要らんからインクリメント用のメソッド作れとは皆が皆思うだろう

>>639
getValue()が在ってsetValue()が無くても
IncrValue()が在ればconstじゃねーだろ

>>640
は？じゃあsetterとgetterは両方あってもいいんだな？

>>643
もはやsetterじゃないだろ。

getter/setter否定してる連中はブリッジについてはどう考えてるんだ

>>636
lengthはsetLengthとは違う扱いだろ。
そもそもインターフェースも違うし。

>>646
このスレに何個か出てるパターンで簡単にgetterを排除できる。

>>645
だれもIncrValue()がsetterだなんて言ってねえよ
setterが無い = const構造体って短絡的考えが
setter/getter以外のメソッドの存在を考慮してないと思われてんの

>>647
>>609

>>644
GUIやら、処理をちゃんとする物は認めてるだろ。
てか、StringBufferのsetLengthなんてresizeで良かったろ。
無理やりRADに名前合わせただけじゃん。

結局、全ての getter / setter を廃止したいと思ってる人はいなかったって事か

>>651
全く認めてるように思えんなあ
getter/setterの存在そのものに異を唱えてるとしか思わなかった
ちなみにあなたはどのレスの人？

>>653
ごめんGUIでもgetterは要らんわ。
なくても困らんし。

そりゃなくてもチューリング完全だろうよ
でもあったりいけない理由は？

俺の setter / getter 満載のコードを見たら烈火の如く怒り出しちゃう様な人はいなかったって事か

>>656
見るだけなら笑う
メンテさせられたら怒る

職場が笑顔で溢れそうだw

>>654
GUIでgetter要らないとは、また斬新だな…
現在のウィンドウサイズの取得はどうすんの？

横からだが、画面全体のレイアウトマネージャなるものが一つあれば、
それが内部変数でサイズを一括管理するというの、できないかな？
配置やリサイズに関わるのは全部それが担当。

>>659
1.ウィンドウサイズは誰かが指定しているから存在している。
　そこから取得すればいい。
2.MVCならコントローラーでリサイズイベントの値を拾える。
　次回起動時その情報が必要ならサイズモデルやらベクトルモデルやらに
　渡して、モデルに保存と読み込みしてもらえばいい。

画面レイアウトに必要とかっていう話なら上のほうで散々既出なんで割愛する。

マウスイベントハンドラの中でウィンドウサイズを指定してたら、取得は無理ぽ

マウスでウインドウのサイズを変更した場合は誰かは何になるの？os?

>>661
>　そこから取得すればいい。

getWindowSize() みたいなメソッドで?

>>661
>モデルに保存と読み込みしてもらえばいい。

ウィンドウは getter 無しでモデルからどうやってウィンドウサイズを取得するの?

>>660
それ結局GUIにgetterある事にならないか

>>661
なるほど…リサイズイベントね
出来なくはないだろうが…何か、スコープの広い変数がいっこ増えるだけな気もするw

>>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 );
}

>>668
getter 無しで scaleModel からウィンドウサイズをとってくるのはどうするの?

もし setter / getter をモデルに押し込めろという話なら、
そんなのはみんなやってると思われ

>>661
> 1.ウィンドウサイズは誰かが指定しているから存在している。
> 　そこから取得すればいい。

その誰かから値をもらうわけですね。
getter使って。

つまり getter を否定している人はいなかったって事か

>>669
ウィンドウサイズ自体を管理するのはscaleModelが全面的に行う。
保存とか読み込みとかね。
ウィンドウとかにそのサイズを反映させるなら、ウィンドウをscaleModelのリスナーにすればいい。

scaleModel.addListener( view );

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

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

てな循環処理を行える。必要な処理の分だけモデルを割りこませればいい。

ホントgetterを安易に支持するヤツは、>>671みたいに視野が狭いのが多いのな。

ラムダ計算がチューリング完全な事を考えれば、結果をオブジェクトで保持してれば
関数の呼び出し連鎖で処理が可能なことぐらい分かるのにな。

でも安易な否定もおかしいと思うよ
そりゃ構造体として使ったらおかしいが、そんなのは当たり前の話であってgetter/setter以前の問題よ

ModelからViewに通知するのにListener経由にするのは分かる
ModelがViewに依存するのはインターフェースレベルでも問題だから

一方、ViewがModelのこと知りたいときにgetterじゃなく
Listener経由にするのは何のメリットがあるの？
ViewなんてインターフェースレベルじゃどうやったってModelに依存するだろよ

>>673
なるほど、getter が必要な箇所は全て先回りで登録しておくのか
i'll do this job with your info じゃなくて let you do this job with your info とするのね

毎回モデルに仕事を発注するのが激しく面倒くさそうだけど、不可能ではないね

>>675
なにいいたいのか解らない

不可能ではないが、自然ではない。
技術に凝り過ぎで、わかりやすい設計を忘れてるな。

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

プロより。

だな。それが○○なら
持っているはずべきものを
持っているのが正しい設計だ。

getterが嫌だからという理由で
設計するのは間違いだ。

>>675
可能ということと、人間が理解しやすいということは別問題。

可能不可能で言えば、アセンブラで書くことだって可能だろう。

変数の束縛の代わりに引数を使って全てを処理をする様にプログラムを書き直せる
ってのは分かるけど、それでプログラムが分かりやすく奇麗になるかは微妙だな

resizeが発生しないとウインドウサイズは取得できないん？
最初からリスナーに登録してあるならいいけど後で登録してその後まったくresize発生しなかったらずっとサイズ取得できないじゃん？

でも getter 不要論のちゃんとした根拠が聞けて良かった
明日ゆっくり考えよっと

どうもね、ソースコードは書くのは人間読むのは人間という
当たり前のことを忘れている人がいる気がするよ。

説明が必要なコードと
説明がいらないコード、
大抵の場合、後者のほうが優れてるのさ。

>>684
リサイズが発生したらリサイズイベントの引数で
高さと幅がおくられてくる。

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

面倒くさい？

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

面倒くさい？

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

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

欠点、いや欠陥。結局オブジェクトにサイズがある以上、それは外部から取得できたほうが良い。

>>684
多分、

scaleModel.processWithCurrentWindowSize(callback func)

みたいにするんでないの

>>677
1.インターフェースはモデルの最大公約数的情報を持ってる。
　これは、Viewがインターフェス越しにgetterをいくつも把握してんのと同じ。

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

3.ブロードキャストを行う時、モデル側の判断でリスナーのメソッドを選べる。
　最もViewに情報を渡すとき最も適切な渡し方は何か等はモデル側で判断できる。
　例えば情報が完全に空なら、画面にブランク状態であることを伝えてやったほうが効率的。
　但し、Viewの事を知ってる訳じゃない。受け取った内容をどうするかはView次第。

getterだってフィールドで持ってるとは限りません
情報が空ならgetterで空を伝えれば良いです

>>684
新規に登録したコントローラーにはイベントが飛ぶでしょ。
物による所はあるけど(クリックイベントは呼んでも仕方ないし)

見た目不自然とか、理解しづらいっていってる人は、結局C系統の
見方に慣れ切ってるって事だよ。もっと他の言語のOOライブラリを
見たほうがいい。

さらに言えば、ブロードキャストするのは常に一定のコストがかかるので
getterで済むならgetterの方が無駄なロスは無いでしょう

>>690
getter全てが空かViewがワザワザ調べるのかい？
それとも空を示すためのgetterを用意するのかい？
そこまでgetterにこだわる理由がさっぱり解からん。

>>691
> 見方に慣れ切ってるって事だよ。もっと他の言語のOOライブラリを
> 見たほうがいい。

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

GUIオブジェクトにサイズ取得のgetterが
存在しないものなんてないからさ。

理解し辛いのは実行コンテクストが入り乱れるからだと思われ

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

リスナー形式だと、こういう時にこれやっといて欲しいんだけど、その時はこの情報が必要ね、
それが終わったら俺がこれするから、みたいな感じでパッと見分かり辛い

その都度問い合わせればいいのと
リスナーごとに保存しとかなきゃいけないのじゃ
メモリ使用量に差が出そうかな？

>>693
あなたは>>689で
>受け取った内容をどうするかはView次第。
って書いてますよね？getterだろうがListenerだろうが情報が空のときに
Viewの判断は必要です

それに、getterの排除に拘ってるのはそっちでは？
こっちはあっても無くてもどっちでもいいです

>>692
ブロードキャストはMVCの為のもので、
呼び出しの連鎖とは切り離せるものだよ。
呼び出しだけで考えてもgetterより遅くなるということはないよ。

>>698
getterだって適当なキャッシュ機構があれば
ブロードキャストより遅くなることは無いけどな

だからぁ、リサイズ時にgetterなしでやれるということと
サイズのgetterを持つべきか否かってのは別問題なんだって。

結局、getter を使った

this.doSomethingWithCurrentColor( model.getCurrentColor() );

と、

コールバックを使った

model.doSomethingWithCurrentColor( this.doSomethingWithCurrentColor );

のどっちが奇麗かって話だよね?

>>697
全てがnullを渡すとき = clearが呼ばれるという仕様なら、
Viewからすればnullを渡してんのと変わらないし。
しかもView毎にチェックする分無駄じゃん。

getter については色々紛糾しているけど、
setter の必要性については誰も異論が無いみたいだから、とりあえず世界の半分は救われたなw

>>702
> 全てがnullを渡すとき = clearが呼ばれるという仕様なら、

これはModel側が処理を持つべき仕様なら
Modelに全てnullか問い合わせるメソッドがあればいいです
もしView側が判断する仕様ならブロードキャストだろうと
Viewが全部チェックしなきゃダメです

>>703
>>574

どーでもいいけど、MVCの概略図みるとビューからモデルへの直接的なAssociationがある
http://ja.wikipedia.org/wiki/Model_View_Controller

getterが憎くて憎くて仕方ない人は、別に好きにしたらいいけど
それはMVCじゃないよ

質問。

ボタンを押したら、そのボタンのサイズが
親ウインドウいっぱいに広がるということをしたい時、
getterなしでやるにはどうすればいいのでしょうか？

もし、getter、setterがあれば、

ボタンクリック時に、これを書けばいいだけだな。
button.setLeft(0);
button.setTop(0);
button.setWidth(parent.getWidth());
button.setHeight(parent.getHeight());

プロパティをサポートしている言語ならもっと直感的に書ける。

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());

最近Observerパターン覚えて万能感に浸っちゃってるお子様に
マジになってどうするの
何でも再帰で書ける！とかと一緒で麻疹みたいなもん
放っとけば目が覚めるよ

>>689
ListenerというよりObserverといってくれるとわかりやすい
ListenerだとControllerのEventListenerと分かり難い

>>706
getterがあることで何が問題かということだよな
Javaで用意されているObserverインターフェースではModelがViewに伝わるような機構になってるし、getterは問題ないと思う

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

あとこの点線と実線の違いは何なんだ？
結局ModelもViewのインスタンスをListとして保持していて、Modelに変更があった場合は保持しているviewに対してview.update()を実行して変更を通知するんだよね

１つずつバラバラに取得できないようにするだけでも取得箇所を１箇所に限定できる

両方実線にしたら循環参照じゃん

馬鹿がよく作るよね

>>714
それはわかるけど、具体的に点線と実線でどう実装に違いがあるのかがわからない

常人はgetter使ってMVCを実装するから

でもそうするとバグが増えるんだよね

>>717
MVCでObserverパターン使うことと、getterを使うか使わないかは関係ない

setをいくら使ってもそれが必要なのはupdate的メソッドが呼ばれたときだけなんだろ？
したらupdateの引数でまとめて渡せよ

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

結局、クラス間での受け渡しの仕様が確定してないからバラバラにsetやgetを作りたがるんだろう

>>719
普通はgetter/setterを使ったV→Mの呼び出しと、Observerを使ったM→V呼び出しの実装上の違いなんて聞かなくても分かるって意味

>>720
Vが増えたり、Mの項目が増えたりするのは全然恥ずかしいことじゃないだろ

>>721
それがわからないから教えて欲しいんだよ
具体的なコードはイメージできてるんだけど、どうしてObserverでMからVが点線で、VからMは実線なの？

>>722
Vは明示的にMを参照してるが、Mはインターフェイス経由なのでVとは認識してない

>>707
親ウィンドウの、WindowManagerを切り替える。
WindowManagerについては既出なんで他のレスを参照の事。

>>704
他のオブジェクトから受け取った値で条件分岐
結局フラグを使う手続き型から離れられられないんだな。

>>709
4回も再描写か腐ってるね。

>>721
インターフェース上の項目は勝手に増やしちゃいかんよ。
Model側の実装は増やしても構わないけど。
MVCライブラリでそれやると破綻する。

>>530って他のスレのレス番つけっぱなしだった
恥ずかち。

>>727
モデルに状態を持たせて、常に完全な状態を渡して必要な値だけ変更するとか、
あるいは値が設定されたかどうかが判定できるようになっていれば問題ない
要はモデルをステートフルにすれば回避できる依存性なんだよ

> 常に完全な状態を渡して

なんでそんな面倒なことせにゃならんの。
エンティティをまるごと扱うデカいゲッタセッタが作られてるだけじゃんソレ。

Javaだと標準でタプルが無いから
getter, setterだと数字とか文字列をひとつずつ出し入れするイメージになるのかねぇ？
別に意味的にひとまとまりだったらgetter, setter でも
まとまりをやりとりすれば良いだけなのにね。

>>725
フラグも何もどのオブジェクトがどこまで責任を持つか、の話じゃねーの？
つーか、Mが更新されたときにVにどの情報を送るべきかはMが知ってるから
> 3.ブロードキャストを行う時、モデル側の判断でリスナーのメソッドを選べる。
は正しいけど、VがMの情報を知りたい場合どの情報を知りたいかはVが知ってる。
なんでVの事情までMが判断できるんだよ。
全部M→VにするとかアホだしそれMVCじゃねーよ。

>>726
Observer使ったM→Vならブロードキャストするたび再描画だけど
getterを使ったV→Mならまとめて最後に一度だけ再描画するに決まってる。
馬鹿なの？ねえ馬鹿なの？

>>726
> 4回も再描写か腐ってるね。

意味分からん
詳しく

>>733
GUIは全てleftとかを更新したら即時に見た目に反映されるって思ってるんじゃね
即時反映を一時的に切る方法とかがあるのを見落としてるんだろ

>>723
なるほど
納得しました ありがとう

イベントの人と変態連想配列君に加えて
ブロードキャスターまで現れたのか
事態は混迷を深めていくな

>>730
モデルはエンティティをまるごと扱うインスタンスだろ
あなたの考えるMはただのビジネスロジックです

MVPはM-Vの直接の関連は無しで
P→Vがインターフェイス経由のsetter呼び出しで
V→PがObserverか直接のメソッド呼び出しだったかな

>>737
え？
いや、だからエンティティの整合性はモデルの方で面倒見てよ、
って話なんだけど、なんか変？

ヤバイ、一気にスレが埋まってく。過疎スレだったのに。
イベント君.に何か問い合わせてもマトモな情報が帰ってこない。
イベント君にはgetterが実装されてないからな。
だから、イベント君と会話のキャッチボールは成立しない。
出来ることといったら、イベント君にdoEvent発生させて、
何か独り言を書いてもらう。
俺らはそれのリスナーになって、イベント君本位の情報を得られるだけ。
こんな実装じゃ2chの会話すらままならない。
何か根本的な欠陥があるね。

とりあえずこんな人の部下にだけはなりたくねぇ。
分からないことがあって質問しても答えが返ってこない。
仕方ないので、チョッカイ出してイベント発生させて、
リスナーとなって黙って御高説を聞いとく。
話の内容から、本当に必要だった情報だけを精査して、明日に生かす。
よくある光景だね。リアルでは関わりあいたくない。

>>739
だからエンティティにgetter/setterを用意して、使わない値は単に無視すればラウンドトリップできるようになってる

>>740
俺、昨日消えてから発言してねーけど？
それにイベントはそっちがググッて見つけた定義でいいって言ったじゃんさっさとだしなよ
何逃げてんだよこの卑怯者

>>732
実際どうやんの？
setを数回呼び出して、
そのあとupdateでも呼ぶの？

>>731
モデルはメソッドを選べても、モデルはビューの事をそもそも知らないだろ。
getterで得られる値の種類がメソッドの種類に置き換わってるだけなんだから。

>>740
てめーは自分の足場が絶対安全にならないと匿名掲示板ですら人と議論もできない最悪の糞ヤローだ
自分の本質を覚えておけ

誰に育てられたのか知らないけど
育ちが悪すぎる
生まれついての糞ヤローとかよくそんな恥かしい人間に育ったなと驚く
まあ、お前自身はそんな悪意はないのかもしれないけどな

>>743
そうだよ？GUI書いた事無いの？
updateメッセージでGUIオブジェクトに一斉に再描画命令を送れるだろ
ブロードキャスター君の大好きなブロードキャストだよ

>>736
ブロードキャスターねw
結局getter推奨は一部しか見て考えてない、考えられてないってのがよく解る発言だわ。

ブロードキャスト自体は、MVCの仕組み。
getterを排除できるっていってるのは、メソッドの相互呼び出しの結果。
Observerとかブロードキャストとかとその辺とは区別できないんだね。

>>747
「4回も再描写か腐ってるね。（キリッ」

腐ってるのは貴方の頭ですwww

getter推奨というよりは、あまりに直感的でない方法にどうなのよって言ってるだけでしょ
その際に素直な方法がgetterというだけで、別にgetterだから推奨してるワケではなく

>>746
へーどのタイミングで呼ぶの？
最初から引数で渡すならそんな無駄なもん必要ないけど？

>>748
object.setX(10);
object.setY(10);
object.update();
object.setWidth(10);
object.update();

object.setX(10)だの呼ぶのはコントローラーだけではない。
他との互換性がなくなってる。
ましてや、update()がどこかで自動で呼ばれるわけでもない。
どう見てもアホにしか見えない。

えっ、GUIオブジェクトにビュー以外がsetできる設計？
なにそれこわい

↑GUIオブジェクトっていう単語を始めて聞いたｗ
コンポーネントのことかな？　でもセットなんぞどこからでもできるし。

ブロードキャスター、ブロードキャスターいってる下駄さんは、
こういうコードもブロードキャストだと思ってるんだろうな。
最も意味があるのはこの構造で、ブロードキャストは関係ないんだけど。

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

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

objectA.changeResize( 10, 20 );

最後はただのresizeで良かった。ミスった。

>>753
ビューがprivateで持ってるオブジェクトは外からセットできませんよ？
スコープの概念も無いの？

>>756
ごめん>>752から読み始めたから何のこっちゃわからない。
俺が黙っとけばよかったねごめんね。

描画は止められない、というかイベント処理が終わるまでブロックされるから1度しか発生しない
止めるのはレイアウト変更に伴う再計算
もちろん明示的に指定しなければ自動更新される

いい加減無知自慢とか糞設計ご開陳はやめてよ

GUIはそのフレームワークというか、ライブラリ、
描画、イベントディスパッチのやり方次第のとこあるからなぁ。

>>752
え？リサイズをビューがやんの？
データの描写以外も自分でやるビューて、何それ怖い。

思いっきりビューの仕事だな

>>758
イベントが終わったら自動的に実行されるって？

>>761
WebのMVCしかやったことないだろ。
・コントローラーはどうやってViewのサイズを変えるんですか？
・ビューは何を基準に自分のサイズを決めるんですか？

このスレの大半のヤツは、WebのMVCしかやったこと無いって。

>>763
MVVM専だからね
・変える必要はない
・ビュー内部の独自仕様

>>765
ああ、あの静的構造のパターンか。
MVCベースの話ししてんのに道理で、実際書いたこと無いような
的外れな事いってるわけだ。

コントローラがビューのサイズに口出しするMVCなんて初耳だが

>>767
そりゃ初耳なんだろうねぇ。SmalltalkやらKDE環境しらなきゃ初耳だろうし、
ControlerとViewがなんでUMLでは直に繋がってるか考えたことなけりゃ初耳だろうね。

実際に書いたことがあるから妥協を本質と勘違いしちゃうんだろうね

>>764
なにそれこわい。
俺は自作ゲームライブラリの自作GUIフレームワークにおける糞MVCと、
JavaのSwing上のそれと、C++とWin32APIでのそれしかやったことない。

MVVMが聖典だと思ってるヤツに言われたかねぇよ。

まあMVVMの視点ではサイズ情報をVMに配置しても何の問題もないんだけどね

今日は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);　}
　}
}

リサイズ指示を受けられないビューってなんなんだ・・・？
いやWindowManagerをコントローラーからビューに渡してやって
リサイズ〜ってのは解る。でも、コントローラーから一切リサイズ指示は受けられないんだろ。
ウィンドウサイズとか再読み込みしたり、保存したりする機能をビューに追加するんだ、
ビューがファイルレベルの操作までするとは参ったねぇ。

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メソッド実行した方がいい？

>>773
ttp://www.jac-net.com/~tarzan/smalltalkers/mvc/mvc.html
ここ読んどきなよ。そもそもObserverの無いMVCは無いから。

>>776
>>547-548はObserverパターン使ってないけど、これはMVCとは言えないとということ？

http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design.aspx

MVC, MVP, MVVM の紹介

>>547-548
はそもそも、サンプルだから要点を押さえようとだけするのはいいんだろうが、
cが無いよね、cが。MVだね。
「Cが入力を受け取る→mを変更→mが変更をv群に通知」この流れを抑えないと。

>>777
まあそうなるね。

>>779
main=Listenerと受け取ってくれると嬉しいです
KeyListenerでもActionListenerでもなんでもいいです

幅と高さが入力されて計算ボタンが押されたら計算結果が表示されるプログラム
という感じです。
今回の>>547-548では数値を入力してボタンを押すという処理は省略されていて、押されてからの処理がmainとして始まります

>>780
そうなのか
確かに>>547-548だとwikipediaの画像のModelからViewへの破線は存在しないね

Model View Controller - Wikipedia
http://ja.wikipedia.org/wiki/Model_View_Controller

http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design/MVC_MVP_MVVM_figure4.gif
あれ、コントローラーからビューのサイズ変更ができないよ？

>>780
wikipediaにもちゃんと書いてあった

>また、データの変更をviewに通知するのもmodelの責任である（modelの変更を通知するのにObserver パターンが用いられることもある）。
>>547-548はデータの変更をModelがViewに伝えていないからMVCじゃないわけだ
ただのModelとViewとControllerで分けただけの何か

>>784
分けただけの何か、を何と呼ぶかはちょい紛糾しそうだけど、
俺はそれ、別に悪くないと思うよ。元のMVCより関係が簡素になってるし、
それでうまくいってんならそれはそれでいいじゃん。

Mの通知を待たずに一秒間に60フレーム再描画するような環境もある。
その時、Mは通知のメカニズムは不要で、VがMを描画時に知っているだけでいい。

>>783
あれれ、Smalltalkだとコントローラーがビューを参照してるよ何でだろうね
ttp://www.sra.co.jp/people/nisinaka/Jun4Java/MVC/vw-mvc-class.gif

>>786
Smalltalkがガラパゴスだからだよ

>>786
VとCが癒着しきったM-VCしか想定してないから

>>783
Viewのサイズ情報をModelが持っていればできるんじゃないかな
それが正しいのかどうか知らないけど

>>784
えっとね。MVCの利点は、[サウンド]モデルを[スピーカー]ビューと、[ビジュアライザ]ビューに
つないで、音を再生すると同時に、画面に合わせたイメージを表示するとかが一貫した方法で
できるってのがあるんだ。

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

これのおかげで、Sqeak Toysなんかは、ビューとモデルとコントローラーをマウスで
つなげるだけで、簡単なアプリケーションを作れたりするんだ。

ウィンドウがリサイズされたときの小窓の再配置とかを、
Viewそのものが実行するか、Controllerが請け負うかの違いだろうな。

>>790
同時にスピーカとビジュアライザに表示するというところがMVCのObserverパターンの肝ということだよね

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

>updateメソッド内でviewメソッドを呼び出して描画を行うのは正しい？それともControllerでclacAreaメソッド実行後にviewメソッド実行した方がいい？
正しい

GUIでMVCやってると気分高まってくるよな。
「うはｗｗｗこれで実行時に入れ替え放題やんｗｗｗ
クラス階層もすっきりしまくりんぐｗｗｗメリットだらけｗｗｗ」
と、数年前の２ちゃんなら表現しただろう。

>>787
Smalltalkが本家で他は方言でしか無いんだけど。

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

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

view.addActionListener( new CloseControl( view ) );

VとCの関係がどうなってるかはそこまで重要じゃないと思うがなぁ。
だって、どうせControllerって大した仕事しないでしょ。

>>791
小窓の再配置はViewでやっても構わないんだ。
WindowManagerとか噛ますのが一番汎用的だけど。
問題は、設定として保存したウィンドウサイズの復元とか。
まぁ、モデルにウィンドウ情報渡しといて、モデルに基づいて
ウィンドウサイズ復元って手もあるけど。個人的には、これが
一番綺麗だと思う。

>>795
大したっつうか汎用的なコントローラーなら二度と作らなくて
いいところに意義があるんだけど。

>>794
それは>>786の図でいうところの Execute Event じゃないの？
ちょっと矢印の向きがどっちがどっちか分からなくなってきたw

確かにCは小さいイメージあるな。
入力をモデルの変更へ割り当てるだけだから。
汎用的というよりは、固有の処理をここに局所化したような存在かと。

ごめん。一番重要なのは、コントローラーが動的に差し替えられる事だね。
Squeak eToysみたいな感じで、実行時にドラッグアンドドロップで動作を変えられるとか、
KDEのランチャーとかもいい例だよ。

ちょっと待って俺が勘違いしているのかも試練。
MVCのCって、ボタンとかも含まれるの？
俺はてっきりそういうのは全部Vの仕事で、
Cは単なるイベントマッピング的なものかと思ってたんだが。

ウィンドウのリサイズみたいな処理はビューだけでやるんじゃないの？
コントローラやモデルが関わってしまったら、
例えばビューをウィンドウさえ無いCUI端末に切り替えるのは
不可能になりそうだけど・・・

よくよく考えたらviewをそのまま渡して意味のないことしてる。
説明ならこれで十分か。

Form view = new Form();
view.addActionListener( new CloseControl( (ClosableView) view ) );

>>801
ボタンはビューだよ。

button.addActionListener( new Controller() );

>>799
モデルへの変更を伴わない入力は
ビューがコントローラへ通知しなくても良いってこと？

>>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. 終わり

>>802
コントローラーとビューは完全に独立してる訳じゃないからね。
例えば、new CloseControl( button );なんて出来ても困るわけだし。
コントローラーも相手はある程度選ぶ。

最も、Viewの目的は↓ができる事で、それ意外のサイズとかって部分は
そもそも外のにある話なのよ。
ttp://www.sra.co.jp/people/nisinaka/Jun4Java/MVC/mvc.gif

>>805
ビューがコントローラへ通知？
GUIコンポーネント経由でコントローラへ入力イベントが通知されるなら、
それがモデルを変更するかどうかはコントローラがまさに決めることであって、
GUIコンポーネント側が判断することはできないと思う。しようとしても冗長。

サッカー見ているうちに大分話が進んでてもう付いていけないわ・・・

でもまぁ、View自体がモデルデータを持ってる、なんてヘマは普通に書いてりゃ絶対しないから、
何も考えずに書いても勝手にMVCっぽいものにはなる罠。

>>807
詳しいみたいだから恥をしのんで聞いちゃうけど、
Wikipedia（http://ja.wikipedia.org/wiki/Model_View_Controller）の
「MVCのシナリオ」の項目をみると、まずユーザの入力はビューが受け取って、
その後コントローラがビューからの入力イベントを処理するって書いてあるんですよ

そうするとモデルに関係ないイベントをビューがコントローラに通知する意味って何なのかなって
ビュー --> コントローラ --> モデル --> ビュー ってルート通らず
ビューだけで処理したほうが良いと思うんだけど

wikipediaのMVCの図に当てはめてみた

下の数字と>>806の数字は対応してるわけじゃありません
http://2ch-ita.net/upfiles/file12034.png

>>811
それしちゃうと>>807の画像で示していることができないよ
1つのデータ郡(Model)から複数のViewに表現できるっていうのがメリットなんだけど、
そのイベントを発生させたビューだけが変更されたのでは、>>807でいうその他のグラフが古いデータのままになっちゃう

イベントを発生させたビューが関連するすべてのビューに変更があったことを通知すれば可能だけど、
そんなことビューが管理するとすごい複雑になっちゃう
1つのデータ郡に対応して4つのビューがある場合、1つのビューはその他3つのビューを管理する必要がでてくる

>>813
「モデルに関係ないイベント」って書いてあるぞ

>>813
えーと、例えば>>807の画像でですね、3次元グラフをマウスでぐりぐりと
回転させたとするじゃないですか
これってモデル（データ）と何の関係も無いですよね？
こういうイベントってビューだけで処理しちゃダメなんですか？

>>811
モデルを使うか使わないかはコントローラー次第でしょ。
もしかしたら、そのイベントをコントローラーはモデルに送るかもしれない。
それと、ビューのレイアウトがビューの中で完結しちゃうと、
ビューの知らないレイアウトを追加できなくなるでしょ。
もしかしたら、ユーザー操作で動的に変わるレイアウトかもしれない。

>>806
　その理解でいいと思うよ。

>>815
グリグリさせたく無いときはどうするの？
グリグリの操作方法をグネグネに変えたい時はどうするの？

(具体的には、左右にドラッグすると、右左に行く場合と、左右ロールする場合)

つまり、CはVのコールバックだと思っとけば良いの？

グリグリはMVCの話題から離れると思う。
Vが独自にマウスイベントを拾ってステキな振る舞いを勝手にしてる、
と考えたほうがよくないかこれ。

>>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は現場に即していないと文句を言うやつは間違ってる

>>817
えーと、質問の意図がつかみきれていませんが、
ぐりぐりさせられるかどうかはビューじゃなくて
コントローラ（かモデル）が決める事って意味ですか？

>>818
そう
CはVのコールバック
VはMのコールバック
>>812の点線の部分ね
Observerパターンで実現されている

>>820
> その回転角度や位置情報もModelと捉えれば>>813も適用できると思うよ

それはもちろんそうですが、元々は２次元グラフを表示するプログラムを
３次元グラフの表示に切り替えるときに、ビューだけを切り替えれば良いのが
理想だと思うのですよ
でも、その方法だとモデルも変更する必要がありますよね

自称初心者がアホを釣っているようにしか見えない
真剣に質問してんのなら、>>815の感性で正しいからね

>>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 );

>>818
純粋なコールバックと違ってラムダのように状態をもてたり、
複数コールバック用のメソッドもってたりするけどね。

勢いあるから次スレ立てた

【OOP】オブジェクト指向総合 part3【OOA/OOD】
http://hibari.2ch.net/test/read.cgi/tech/1312982517/

>>823
ViewとModelは対応するものだから、基本的にModelが変わればViewが変わるのは問題ないことだと思うよ
Viewだけ切り替えれば良いっていうのは、クラスとしては確かにViewクラスが1つ変更されただけかもしれないけど、
MVCとして捉えればMとVが変わっているわけだから結局は同じことだと思う

もう「全部入れ替えれば問題ないよ」って言葉は聞き飽きた
汎用性はどこに行ったんだ

>>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 ) );

MVCは汎用性あんま関係ないような。
クラス間のやりとりが理解しやすい、
クラス階層がヘンなもんにならない、なりにくい、
っていう苦肉の策じゃね。複雑で癒着しがちなやりとりに対する。

>>823,829
>>812の画像でいう実線は依存だから、依存先が変更されたら依存元も変更されるのはしょうがない
依存関係があるところ以外は汎用性があるよね

まったく依存関係がないいプログラムはありえない
その中でもできる限り依存を減らして便利に使い回したり、設計しやすくしたりしたいよね　というものだと思ってる
思ってるだけで正解かどうかは知らない

>>829
「全部入れ替える」ってのが何を指してんのか解からん

例えば、Ｖｉｅｗで入力された項目やＶｉｅｗのウィンドウの配置をデータベースに覚えておく場合はどうなんだろ？

>>834
Modelの先にDBがある
ModelでDB更新時に、ViewにDB変更があったことを通知

>>834
ウィンドウの属性をモデルに持たせればいいよ。

undoデータやredoデータってのは誰がもつんかな？（もちろんＶｉｅｗ２、３も含めたね）
Ｖｉｅｗ１だけならわかるけど
Ｖｉｅｗ２、Ｖｉｅｗ３って絡んだときにこのデータってＭ確実に変わるよね？
ＭＶＣってこういうのですでに死んでると思うんだけど
Ｃ少ないかみんな？俺はＣは一番でかくなるんだけどこういう客の要望いちいち聞いてるからかなぁ？
なんか組んだことない人の臭いしちゃうんだよね？ここの人

クマー

でも、一つのモデルに複数のウィンドウなりビューなりを作れちゃうのがMVCだからなぁ。
その場合モデルはビューのインスタンスと情報の対応表を持つことになるね。

ぱっきゅらおん

>>833
「(クラスを)全部入れ替えれば(追加要件があっても)問題ないよ」ってことで

>>837
モデルのUndo,Redoならモデルに、ViewのUndo,Redoなら、Undo,Redo用のモデルをViewに絡ませとく。

>>841
今までのレスだと、どんなの？

すっとやっぱり
大元のＭ
Ｖ１用のＭＶ１
Ｖ２用のＭＶ２
Ｖ３用のＭＶ３
が必要になるよね
っていうか現実としてなってる
ちなみに俺は面倒なので現実にはこんなクラスは作ってなくて
ＭがＶｉｅｗ１、２，３が存在する前提の作りになっちゃってる
色んなデータが必要になるから
わざわざＶｉｅｗが値保持しないって設計守ってやってるせいもあってか
もうＭＶＣにしてるメリット欠片もないけどねｗ

まー確かにView固有の情報をModelに持たせるってのは、なんかアレだよな。

>>843

>>823>>829に対する>>832

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

はじめのインターフェースがどうとかってのは多分絵に描いた餅で終わってるんじゃないだろうか？

>>846 よく解からんけど、解ったわ。

>>848
お、他の人が答えてくれてるｗ

あとgetter否定派の疑似コードに突っ込むと高確率で「メソッド追加すれば対応できる」って言うよ
他のスレでイベントの人っぽいのが暴れてた時は酷かった

GUIって力技で何とかなっちゃうし
こんな重箱の隅の話より人間工学的な話のほうが有意義だよね。

>>847
まぁ、MSはマトモにMVCなんてしてないからね。
本当にしてるんだったら、汎用コントローラーとモデルをいくつか用意しとくべきだし。
DBのデータ表示する程度なら、既存のモデルとコントローラーの組み合わせで作れるぐらいにしとくべきだ。

>>850
たとえば？

View固有の情報をViewだけで処理せず
頑にControllerやModelへ結びつけるのは何故？
無駄に依存させておいて「依存関係があるのは仕方ない」とか言って
Viewを追加するたびにControllerやModelも拡張するとかナンセンスすぎる

>>853
フツーはしないから。
だからこそ、Vがでかくなるんだ。

context_controller.set( model_key, view_key, context );
みたいなコントローラがあれば良いかもね。
model_keyはモデル中の何かの要素をあらわしたもの。ポインタで良いかな。
view_keyはビューのインスタンスを表したもの。これもポインタで良いかな。
contextは対応付けたい情報。構造体へのポインタとかで良いでしょ。

>>853
View固有の情報ってなに？
その情報をファイルとか外部と入出力するときもViewで行うの？

>>856
ぶっちゃけそのほうがいいんじゃないか？

>>854
基本Vはでかいけど、例えばグラフ描画ソフトなんかだと
Mがもっとでかいから相対的に気にならないんだけどね
MがDBからデータ引っ張ってくるだけだと、
Vばかり大きくてアンバランスな気がするかもね

処理に必要なデータは、できるだけ処理の近くに置き、
隠蔽しておけるのなら、喜んで隠蔽しておく。
ビューに必要な内部構造を隠しておくのは、ビューに他ならない。

>>854
モデルとビューで同じような構造のデータを二重に持つことになるからね。
モデルにおいておいたほうが楽っちゃ楽だわな。
機能レイヤー視点での切り分けは悪くなるがな。
array of structure と structure of array の違い。

>>857
したいんならすればいいんじゃないとも思わんでもないけど、
俺は、出力先が、XMLだったり、レジストリだったりってのはMVCに基づいてモデルに抽出するわ。
いちいちViewを継承したりして静的に拡張したくない。実行時に差し替えたりも効かなくなるし。

> モデルとビューで同じような構造のデータを二重に持つことになるからね。

なるか？ｗ
固有の描画のための固有の内部構造を追加で持つだけでは？

Ｖｉｅｗの位置情報とかフォーカス、履歴（Ｖｉｅｗ特有の情報）をＤＢのユーザデータに残しておきたいときとかも
やっぱり保存するのはＶｉｅｗの役目ってほうがすっきりするな
ＭＣはリストラでｗ

>>863
Modelでも同じ情報もってたら構造が重複するけどね。
3Dモデルなんかだと、Model自身の向きと、Viewによる向きの2つあるし。
他にも照明のセッティングだの色々重複するね。

>>862
エクスプローラのようなものを考えた場合、
モデルはフォルダ階層をノードで表したものになるだろう。
で、ツリービューを考えると、「開いてる/閉じてる」の情報を覚えておくために、
ツリービュー自身もやっぱりフォルダ階層をノードで表したものを持つ羽目になる。
木構造を二重に持つのはしんどいし、
ツリービューのどのノードがモデルのどのノードに対応するか判断するための参照も必要かもしれないし、
うぜぇ。
モデルのノードにこっそりbool extended;って追加したくなる気もわかる。

>>864
特有の情報の話だけだってば

>>865
なるほどね。
俺ならノードごとに map<* node, bool>みたいなんを内部に持たせといて終わりかな。
んで、描画時にモデルから要素をたどりつつ、上記の内部構造を使う。そーいう話？

↑アスタリスク消し忘れ。

>>865
超デジャビュー
それを頑なに「やってくれないと金払えない」的な勢いで押し込んできた客いたなぁ
（まあ、あのフォルダたくさんあったから開くたびに開きなおしとか勘弁してくれってのはあったけどね）

>>867
実際には俺もそうするけどね。
>>855で書いたとおり。

>>870
結局そっちのほうが何倍も清々しいもんね。

なんかこのスレをさらーっとナナメ読みしてると、所々懐かしのDoc-Viewを思い出すなぁ

Docいらねーし
Viewだけ書くよ

>>871
ビューが複数になったときにも対応できるしね。
エクスプローラみたいなものなら、モデル一つで窓一杯って普通にありえるもんね。
こう言う　structure of array 的な発想って、多々出てくるから、
そろそろ言語レベルで何とかサポートして欲しいよ。
それかデザインパターン化して、大手を振れるようにして欲しい。

その場合ってＭとＶを循環参照させるの？
それともＣを巨大化？

>>865
ツリービューのGUIコンポーネントの描画実装のメンドさに比べりゃ

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

なんて誤差の範囲だけどねー

>>875
どっちでもいいんじゃない？
Viewに持たせた方が参照一回分早いからオシシメ。

言語レベルｗ

>>876
２つもって同期までとること考えたら２つもつのはありえんなｗ

>>879
そのとおりだね。
ツリービューとリストビューがフォルダ開閉の情報を共有するなら
モデルに持つべきだし、
それぞれのビューが独立にフォルダ開閉の情報を持つなら
ビューが持つべき。
つまり要求される仕様による。

>>874
よくわかんないけど.NETのバインディングじゃダメなん？

いい加減TreeViewにクラス突っ込めるようにして欲しい。

>>807で、ひとつのグラフを回転させたら
全部のグラフが回転し始めたら、俺なら笑っちゃうかもしれんw

>>882
ステキやん？　とも一瞬オモタｗ

>>880
こういうやり方もあるけどね。
TreeModel model = new TreeModel();
new ContextTreeModel( model ).addModelListener( view1 );
new ContextTreeModel( model ).addModelListener( view2 );
new ContextTreeModel( model ).addModelListener( view3 );

View固有の情報をView自身に持たせるのは、
モジュールの独立性の観点からは良いんだけど、
唯一の難点はViewが複雑になるところだね。
Viewって自動テストしにくいから、なるべく状態とか
持たせて複雑にしたくない。

>>884
こういうやりかたもあるけどね、ってそのままじゃん。
クラス名にXxxModelって書いとけばモデルが持ってる事になるのかい？

>>885
どっかが複雑さを請け負うことによって、
他がスッとするというのは、俺はもう黙って受け入れることにした。
Mediatorパターンとかもね。そのクラス単体は複雑になるけれど、
クラス間のやりとりが単純になるほうが恩恵がドでかいもんねぇ。

色んな考え方があるな

>>886
そうだね。ContextTreeModel自体はオブジェクトとして別々のツリーを持ってるって事。
Viewに持たせず外だしにしてるだけ。

なんかControllerとViewについては出尽くした感じがするけど、
Modelの掘り下げはあんまりないね。どういう変更メソッド持たせるとか、
粒度とか、Modelのネストとか。

そこいくとまたgetter/setter（←だれかそろそろ略語生み出してくれ）の話題に戻りそうだが…。

>>882
さすがにそれはModel分けるだろｗ
グラフデータを保持するModel
View1の位置情報Model
View2の位置情報Model
View3の位置情報Model

1つのViewに対して1つのModelってことはない

>>891
アクセッサーor アクセサー

アクセサーとは : JavaA2Z
http://www.kab-studio.biz/Programing/JavaA2Z/Word/00000346.html

結局V固有情報をVから出さずに複雑な処理をする場合、V内にVMが出来てM→VM⇔Vになるんじゃないかな
V→Mだけ申し訳程度にCを経由するけど

もはやモデルとは何か、うごごご……のレベル

>>892
二次元グラフと三次元グラフでは位置情報のデータ構造は違う
また折れ線グラフは拡大表示できるが、棒グラフは拡大できないとかも
あるかもしれない
つまりビュー固有の情報はビュー毎に情報の在り様が異なる

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

それぞれのビュー固有の情報まで何々情報モデルと呼ぶのは勝手だけど、
それは状態を持つものはビューと呼びたくない、と言ってるだけで
本質的にはビューが持ってるも同然