オブジェクト指向は遅い

>>950
例えば今は四角形の面積だけど、三角形の面積を求めるモデルを新たに追加したいときShapeで共通のインターフェースを持っていると、
Viewは四角形や三角形を意識せず面積がある形ということだけを意識できるのでいいかなっと思ったりしました（後出しですいません

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

>>951
Facadeパターンですね
やっていることはわかるのだけど、どうしてそういう構造になっているとmainメソッドをModelに置くのかがわかりません

>>952
ホントいうと、Observerをモデルクラス本体に置かず、
君ので言えばShapeSubjectに置いとく方がいいよ。

interface ShapeSubject
{
     public interface Observer{}
     public int getArea();
}
class TrigonModel implements ShapeSubject
{
}
class SquareModel implements ShapeSubject
{
}

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

ttp://ideone.com/4qsIS
JavaのSwingを使って最小限のMVC表現を行おうとしたが…。
もともと、GUIコンポーネントをViewと言い放っていいのかどうか迷いがあったので、
それが迷ったままになってしまった。パネルの描画部分をオーバーライドして、
クラスの役割を描画であると強調したつもりだがどうだろうか。

>>955
実行イメージくれくれ

同じ画面に、ユーザーが円グラフのデータの一つを選択して
その値を表示したり変更したりする機能を付けたくなったらどうする?
データをソートしたくなったら?

>>957
ソースコードがあればユーザが自分で付け加えられるね
REPLで実行できるなら実行中に機能を追加出来てもっと良いね

これはVでこれはMみたいな議論はもう飽きた。
どうせ相手の意見を聞く気もないんだろ？

もともとはアクセサーの話だったと思うが、「MVCでもアクセサーいらないよ」派はまだ息してるの？

全部モデルにぶち込む君の糞設計は
>>929で分類されるところの「古典的MVC」

>>957
グラフに表示してるデータを編集したいってこと？
それとも、グラフに表示してるデータの複製を編集したいってこと？
それともグラフに表示してるデータの一切れ分を編集したいってこと？

>>960
ＭＶＣ自体いいのかどうなのかよくわからないし
その上にさらにマシマシした構造で必要とか言われても結局よくわからない
結局、Ｍの都合の悪いタイミングにgetしたら不味いタイミングあっちゃうのに
なんかgetつけてるって実装が大半に見えるけどね俺には

>>963
・よく分からないのに「MVCでもアクセサーいらないよ」派なのですか？
・M→Vのデータ伝播は本質的存在で、その方針は重要なインターフェイスです
・それはカプセル化や非同期処理の問題です
・日本のPGの数割はパターンに関係なくふざけたコードを書くので、間違った実装の目撃例で物事を語らないでください

ていうか「マシマシした」って何？
ラーメン？

アクセサあるだけでレースコンディション発生させちゃう男のひとって・・・

getImageというメソッドがあるとすると
都合の悪いタイミングで画像を見られるのを避けるには
ダブルバッファリングするだけ。
getterやめる必要はない。

>>964
>・M→Vのデータ伝播は本質的存在で、その方針は重要なインターフェイスです
これをget使ってやらなきゃいけないって決まりはあるの？

>>967
無いよ。get使っちゃダメって決まりも無いけど。

>>962
最終的にもとのデータを変更するかどうかは関係ないでしょ
どっちにしてもビュー固有の表示状態、編集状態、選択状態は必要

>>969
957本人？

>>968
じゃあ、普通にオブジェクト間同士の関連を実装すればいいんちゃう？
getでどんなタイミングでもアクセスしちゃえるように作るのをＭＶＣは正当化してないよねぇ？
ＭＶＣ出した人はちょっと何がいいたいのかわからないって結論になっちゃったんじゃない？
このスレ的には

だからgetあったらレースコンディション発生ってどういう理屈だよ
アホ過ぎるだろ

ビューがモデルの属性X1, ... Xnを表示でき、かつそれらを
どう組み合わせて表示するかはユーザが実行中に選べるとする
（例えばX2, X4, X6, ... だけ表示する等）

このとき、getterを使う方法とObserverパターンで
各々どういうコードになるの？

>>972
だってそれって呼ぶ側が注意しないといけないんでしょう？
しかるべき箇所でキチンとイベント決めてまとめるべきじゃないの？

>>956
ttp://ideone.com/plain/4qsIS
MvcTest.javaという名前で保存したらそのままコンパイルできます。

>>974
>>966

>>974
ビューのメソッド（内部でモデルからゲッツしてる）も全部イベントとして
コントローラ経由で起動すればいいんじゃないの？

まあ、そうだとしてもそのイベント名がgetじゃダメだよね

もうgetter派には触れるなって。ヤツらコボラーと同じで頭が固まってんだから。
getter無しで一通りプログラムを組んだこともないし、試しに組んでみようとしようもしない。
getter無しでどう組めるか想像もできないから妄想だけで否定だけしてる。
相手するだけ無駄。

>979
頭が固いのはお前では？

まず、なぜGUIに限って
getterなしにこだわるのか
その理由を答えてほしい。

>>979
ブロードキャスター君、じゃなかったナローキャスター君チーッスwww

まあ、getter無しで組める、というだけで
getter禁止を正当化する理由になると思うほどの低能は
相手するだけ無駄だよな。

モデルに全データ/処理を突っ込む
古くさーいMVCを未だに信仰してる人に
頭固いとか言われたくないですwww

副作用無くてもモナドがあれば組めるから
副作用使うの禁止、のほうが納得がいくレベル

言われたくないとか言われたいとかは所詮主観だからな

>>971
一応援護しとくと、getterを排除しとくメリットは、MVCやブロードキャスティングに利用することより、
オブジェクト自身の判断で値の渡し方を判断するって事が大きい。
object1.setValue(object2.getValue());なんて呼び出しじゃ、この値の渡し方を判断してるのは、
object1でもobject2でもない。例えば、object1.toValue(object2);と渡せるようにしてやったとすると、
値の渡し方を判断するのは、object1になる。object1は、object2が持ってるメソッドの中で、
今の自分の状態で最も適切に渡せるものを選んで渡すことができる。

モナドって外から見れば副作用そのものじゃん

オブジェクト自身の判断で値の取得方法も判断したいわあ

>>986
うん。それはgetterを使わない理由であって
getterを排除する理由じゃないね。

じゃ、次。

>object1.toValue(object2);

で、toValueの中でgetter使うんでしょw

view.reAcquisition(model) って呼び出しだと、値の受け取りを判断するのはviewになる
reAcquisitionの中でviewはmodelが持ってるgetterの中で
今の自分の状態で最も適切に受け取れるものを選んで受け取ることができる

>>986
> object1.toValue(object2);と渡せるようにしてやったとすると、

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

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

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

それが例え型がない言語であったとしても、結局はなんの関数を使うのかを
インターフェースの代わりにドキュメントにまとめなきゃいけないので
結局は同じこと。

>>991
> view.reAcquisition(model) って呼び出しだと、値の受け取りを判断するのはviewになる

それは、modelという”値” を渡しているだけ。
値が単純な値ではなく、複雑な構造の値になっているだけ。
結局値を渡しているのはコントローラ

>>990
使う必要ないだろ。なんの"為"に使うんだよ。なんの"意味"があるんだよ。
入れる余地なんざないだろ。

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

//object1が内部で整数として持っている場合
void toValue(Numeric target)
{
       target.convertFrom( 10 );
}

>>993
object1.toValue(object2) もobject1にobject2を渡してるだけですね
馬鹿じゃね？www

>>986
>>991
こんだけパラレルに書かれると分かり易いな

>>994
その関数に何の意味があるの？

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

それってさ、getterの名前を変えただけじゃね？

>>992
インターフェースが増える事になんの問題が？
そんなんだったらMVCだろうが、MVVMだろうが、MVPだろうが満足に書けんだろ。

>>998
引数に渡すときの、最小のインターフェースが
数値型とかじゃねーの？

>>701でFA

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。