-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590577デフォルトの名無しさん
2011/07/04(月) 22:04:56.46interface RGB
{
void change(double red,double green,double blue);
void change(int rgb);
RGB to(RGB rgb);//引数で取ったオブジェクトが帰る。
}
こういうインターフェース面白いよね。
void change(RGB source)
{
RGB fillter = source;
fillter = fillter.To( new NegativePositive() );//ネガポジ
fillter = fillter.To( new Edge(0.9) );//強調
fillter = fillter.To( new Sepia() );//セピア
fillter.To( this.color ); //最終結果をメンバーへ
}
フィルター化して幾らでも機能を拡張できる。
アクセサ中心でこういうの書こうとするとホント汚くなる。
0578デフォルトの名無しさん
2011/07/04(月) 22:08:15.340580デフォルトの名無しさん
2011/07/04(月) 22:32:26.560581デフォルトの名無しさん
2011/07/04(月) 22:39:40.30ゲッターなんていらない。
受け取り側がRGBインターフェースを実装するか、
RGBを実装したアダプターを作ればいいだけ。
ゲッターが必須と考えるのは思慮が浅い。
0582デフォルトの名無しさん
2011/07/04(月) 22:56:49.62セッタゲッタありきのクラス設計。
いただけない。
オブジェクト指向 != データ指向
カプセル化でインタフェースを突き詰めると、
そんなにプロパティ公開すべきもんでもないと気づく。
0583デフォルトの名無しさん
2011/07/04(月) 23:02:41.12オブジェクト指向の教義に反するとかコードが汚いとか俺が気に入らないとかじゃなくて具体的な問題点を挙げてよ
0584デフォルトの名無しさん
2011/07/04(月) 23:03:59.45実装は自由だからどうとでもなるよ。
class PixelDevice implements RGB
{
private Graphics device;
public PixelDevice(Graphics device)
{
this.device = deveice;
}
public void drawLine(int x1,int y1,int x2,int y2)
{
device.drawLine( x1, y1, x2, y2 );
}
public void change(double red,double green,double blue)
{
device.setColor( new Color(0xFF * red,0xFF * green,0xFF * blue) );
}
public void change(int rgb){省略}
public RGB to(RGB rgb){省略}
}
0585デフォルトの名無しさん
2011/07/04(月) 23:06:06.66要らんもの書いてないでchangeとtoを書けよ
0586デフォルトの名無しさん
2011/07/04(月) 23:06:43.73>相互でchange呼び出せば済む
これがよく分からん
インスタンスAとBがあってAをBと同じ色にしたい場合はどうやってやるの？
0587デフォルトの名無しさん
2011/07/04(月) 23:11:01.95例えば、getter,setterを排除した>>577だと、
同じ値は、基本的にオブジェクトの中に留まる。
(まぁ、同じ値でコンストラクタ呼べば作れるけどそれは別問題)
別のオブジェクトに引き渡され場合、
引き渡した先のオブジェクトがファイルやデバイスで無い限り変更される。
同じ値はオブジェクト間を右から左へ渡されることがない。
つまり実装が極めて隠蔽される。
でも、getterで取れる値は、setterに入れた値と大抵同一。
実装が外にはみ出してると言われ手も文句は言えないよね。
0588デフォルトの名無しさん
2011/07/04(月) 23:19:50.59素直に名前を付ければinterface RgbReceiver{ void ReceiveRgb(...); }ぐらいが適切だろ
でもそれにToが必要とは思えない
あと同じ値が〜とか言ってるけど、複数のインスタンスの値を集約する場合はどうなるんだよ
受け取り用インターフェイスを複数定義してプライベート変数使うの？
それとも処理フローに沿って別のクラス&インスタンスを量産するの？
0589デフォルトの名無しさん
2011/07/04(月) 23:22:38.65changeは書いたろ。
まぁ、デバイスの場合toは要らんけどな。
あのインターフェースはtoを分離したほうがいいでしょ。
ちなみに、toを使うフィルターの場合は、
こんな感じ。
class NegativePositive implements RGB
{
private int rgb;
public NegativePositive(){}
public void change(double red,double green,double blue){省略}
public void change(int rgb)
{
rgb = 0xFF - ( 0xFF & rgb );
rgb |= 0xFF00 - ( 0xFF00 & rgb );
rgb |= 0xFF0000 - ( 0xFF0000 & rgb );
}
public RGB to(RGB color)
{
color.change(rgb);
return color;
}
}
0590デフォルトの名無しさん
2011/07/04(月) 23:24:38.00オブジェクトはメッセージを受け取るものなのに、Receiverって・・・。
0591デフォルトの名無しさん
2011/07/04(月) 23:45:43.21>受け取り用インターフェイスを複数定義してプライベート変数使うの？
いってる意味がよくわかんないけどこんな感じ。
interface Vertex
{
void move(Point point);
void change(Color color);
Vertex to(Vertex vertex);
}
含まれる要素がいくら増えようと、結局処理と処理結果で成り立つから、
おんなじパターンを淡々と作っていけば済むよ。見慣れてないと、
どこかで値を取れなくなりそうでgetterを作りたい不安にかられるかもしれないけど、
割と堅実に破綻はしないんだよ。
0592デフォルトの名無しさん
2011/07/05(火) 00:05:45.18public RGB to(RGB color)
{
color.setRGB(getRGB());
return color;
}
ってやってる感じに近いんだ。
これによってgetRGBが公開されるのを防いでる。
本当にgetRGBが存在するとは限らないからね。
特にtoの所属するオブジェクトが外部からの入力関係だとね。
あと、setRGBってここでは書いたけど、
実際はsetterとは全然違うんでsetRGBとは書いちゃいけない。
setterと違って引数のcolorがtoの所属する値を持つ可能性はまず無いから。
0593デフォルトの名無しさん
2011/07/05(火) 00:08:20.42× setterと違って引数のcolorがtoの所属する値を持つ可能性はまず無いから。
○ setterと違って引数のcolorがtoの所属するオブジェクトと同じ値を持つ可能性はまず無いから。
0594デフォルトの名無しさん
2011/07/05(火) 00:21:50.91なんかColorとかPointとか未定義の型が出てきたんですけど、こいつの値はどうやって取得するの？
フィールドがパブリックになってんの？
0595デフォルトの名無しさん
2011/07/05(火) 00:25:56.29単なる複数の型の直積、直和の意味しか持たない型はパブリックフィールドでいいと思うけどね
0596デフォルトの名無しさん
2011/07/05(火) 00:27:31.94同じ形式のインターフェースをもってればいいでしょ。
簡単な話しじゃん。
interface Point
{
void move(double x,double y);
Point to(Point point);
}
interface Color
{
void change(RGB color);
void change(HSV color);//HSVも同様。
Color to(Color point);
}
0597デフォルトの名無しさん
2011/07/05(火) 00:33:23.46インターフェイスに追加はできないよね
0598デフォルトの名無しさん
2011/07/05(火) 00:34:36.97Pointの(0,0)地点ってどの空間に所属してるかで実際は変わってくる。
move(1,1)が呼び出されたPointがどの空間に所属し、どういう体系で座標系を
持ってるかで、move(1,1)が呼び出されたオブジェクトが持つオブジェクトの座標は全然変わってくる。
0599デフォルトの名無しさん
2011/07/05(火) 00:39:04.35インターフェースの機能追加自体はあり得るよ。本当に必要ならね。
最初に、既存のクラス設計と同じように最小限の最大公約数を目指して用意するんだけどね。
#最小限の最大公約数って変ねぇ。
0600デフォルトの名無しさん
2011/07/05(火) 00:45:03.16例えば >>589 の様に実装するクラスが持ってれば十分な事もあるし、
XYZ系というように構造が違うならXYZ系用のインターフェースをColorとは
別途もてば十分かもしれないしね。
0602デフォルトの名無しさん
2011/07/05(火) 00:49:06.42なんでもかんでも一つのクラスに詰め込むなよ
0603デフォルトの名無しさん
2011/07/05(火) 00:52:34.82単なる値クラスなら、HSVだろうとXYZだろうとColorクラスへのメンバ追加だけで対応できるよね
それについてはどう思う?
0604デフォルトの名無しさん
2011/07/05(火) 00:54:40.70同実装するかは、クラス次第だし。
>任意のベクトルに対する差分ベクトルに変換する変換クラス用意したらいいだけじゃん
>なんでもかんでも一つのクラスに詰め込むなよ
一応聞くけどなんで？というかどういう経緯でそう思うの？
0605デフォルトの名無しさん
2011/07/05(火) 00:57:45.18そのColorクラスは閉じてるんだよね。
こっちの場合は、必要なだけインターフェースとクラスを増やせば
元を弄る必要なくなるから楽なんだよ。>>577みたいな感じでね。
0606デフォルトの名無しさん
2011/07/05(火) 01:09:26.73HSVからRGBへ変換できるクラス、RGBからHSVへ変換できるクラス、
RGBからRGBにしか変換できないクラス。用途に応じて変換パターンを支配できる。
それから、RGBを作った数カ月後にHSVを定義しても、RGBからHSVに変換するような
処理を簡単に組み込めるよ。
interface RGB
{
void change(double r,double g,double b);
}
interface HSV
{
void change(double h,double s,double v);
}
interface RGBConvertor
{
RGB to(RGB color);
}
interface HSVConvertor
{
HSV to(HSV color);
}
0607デフォルトの名無しさん
2011/07/05(火) 01:17:02.69vはpとSに依存し、それを与える写像が存在するということだろ
これはそのまま関数に対応する
0608デフォルトの名無しさん
2011/07/05(火) 01:17:16.45プロパティと値オブジェクトでも同じようなことはできるし、別にそれが汚いとは俺は思わない
むしろ抽象的すぎるクラスやインターフェイスが増殖するほうが気持ちが悪いと感じる
0609デフォルトの名無しさん
2011/07/05(火) 01:20:30.98Genericsやtemplate, 依存型があると尚良し
0610デフォルトの名無しさん
2011/07/05(火) 01:24:10.100611デフォルトの名無しさん
2011/07/05(火) 01:31:52.25使い捨てにするような感覚が無いとキモイかもね。
オブジェクト = 関数の結果みたいな感じの設計デザインだし。
ただ、>>577みたいな感じで部品をぺきぺき組み合わせていくやり方は、
拡張が楽だし、きもちいいよ。
>>608 そう思うならそのやり方でいけばいいんじゃない？
個人的には構造体みたいな形で値が滞留するのが気持ち悪いと思うけど
逆のことを思う人は当然いるだろうし、そういう道でいいと思うよ。
0612デフォルトの名無しさん
2011/07/05(火) 01:36:57.21ん。そうなのかねぇ。
とりあえずこんなことができるのは面白そうだな。
void change(RGB source)
{
RGB fillter1 = source;
HSV fillter2;
fillter1 = fillter1.To( new NegativePositive() );//ネガポジ
fillter2 = fillter1.To( new Edge(0.9) );//強調
fillter1 = fillter2.To( new Sepia() );//セピア
fillter1.To( this.color ); //最終結果をメンバーへ
}
0613デフォルトの名無しさん
2011/07/05(火) 01:47:05.02>プロパティと値オブジェクトでも同じようなことはできるし
できるのか・・・。今までの流れだと無理臭い気が・・・。
0614デフォルトの名無しさん
2011/07/05(火) 02:13:08.68この方向なら「流れるようなインターフェース」の方が良いのでは？
流れるようなインターフェース
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FluentInterface
流れるようなインターフェースと脱CoC
http://d.hatena.ne.jp/higayasuo/20071018/1192681950
流れるようなインターフェースとメソッドチェーンは違うもの
http://d.hatena.ne.jp/higayasuo/20071025/1193319054
流れるようなインターフェース （使いやすさを高める）
http://d.hatena.ne.jp/bleis-tift/20090620/1245485402
進化するアーキテクチャーと新方式の設計: 流れるようなインターフェース
http://www.ibm.com/developerworks/jp/java/library/j-eaed14/
0615デフォルトの名無しさん
2011/07/05(火) 02:22:29.25中身見たが、流れるインターフェースっていうけどそれカリー化じゃね？
0616デフォルトの名無しさん
2011/07/05(火) 02:26:22.28変数省略してこう書いたのとは何が違うん？
void change(RGB source)
{
source
.To( new NegativePositive() )
.To( new Edge(0.9) )
.To( new Sepia() )
.To( this.color );
}
0617デフォルトの名無しさん
2011/07/05(火) 02:39:13.66>>612のように書くと合成されたフィルタができてるように見えるけど違うぞ?
フィルタを順番に即時適用してるだけだ
色を引数に取って変換後の色を返す関数を順番に呼んでるのと一緒
フィルタの実装次第では遅延評価にもできるけど、それは関数でもそういう風にはできる
むしろ高階関数使うアプローチの方が自然
0618デフォルトの名無しさん
2011/07/05(火) 03:19:46.39value = lambda();
lambda()( value );
こうやってんのと同じってのは解るよ。
いや、プロパティと値オブジェクトって書いてあったから
もっとsetから入った値がgetで別の値に変わってるような
斬新な方法駆使してんのかと思ったから無理じゃねって書いたの。
0619デフォルトの名無しさん
2011/07/05(火) 07:09:40.14実現しようとしてるアプリケーションは作れるんじゃね？
大規模開発では
＞抽象的すぎるクラスやインターフェイスが増殖するほうが気持ちが悪いと感じる
こういう人も紛れ込むし、頭いい方に合わせて底上げしようとしても
崩されたりモチベーション下げたりしてみんなが不幸になる。
割り切って構造化して「プロパティと値オブジェクト」にした方が
結果としてうまく行く場面も多いと思う。たとえ非OO的でソースが3倍にふくれあがってでも
代替要因が用意できて管理できることの方が重要なプロジェクトはある。
やりたくないけど仕事なのでそうも言ってられない
0620デフォルトの名無しさん
2011/07/05(火) 07:11:59.740621デフォルトの名無しさん
2011/07/05(火) 07:23:42.59というか操作とデータが一緒であることが理解できないっていうとOO全否定じゃね。
まぁ、OOの観点から言えば、データは余計で全部結果を生む動作でやるのが
ただしいようだけど。smalltalkの標準ライブラリとか。
0622デフォルトの名無しさん
2011/07/05(火) 07:26:29.00>>618
0623デフォルトの名無しさん
2011/07/05(火) 07:33:41.18カプセル化の範囲絞り込みが出来ず原始回帰してるだけにしか見えん。
0624デフォルトの名無しさん
2011/07/05(火) 07:53:29.87しかし状態変更メソッドしか用意されてないRGBをどうすればコンバーターで操作できんだよ
結局引数を見ずに自分の情報でchangeを呼ぶしかないけど、それすら保証されていない謎インターフェイスになってるぞ
0625デフォルトの名無しさん
2011/07/05(火) 08:13:32.38あくまで要求仕様は存在するでしょ。
0626デフォルトの名無しさん
2011/07/05(火) 08:34:37.870627デフォルトの名無しさん
2011/07/05(火) 08:38:27.430628デフォルトの名無しさん
2011/07/05(火) 10:36:47.08Builderパターンとかによくハマる。
ビルダオブジェクトに対し、コネコネ、
グニグニ操作を加えていくのが楽しい。
0629デフォルトの名無しさん
2011/07/05(火) 13:03:41.65>>589
>>627
>>584
200レスも前の話じゃないだろ、
ゆとりは掲示板すら使えないのか。
0630デフォルトの名無しさん
2011/07/05(火) 18:31:04.62お前がコードか日本語を読めないのはわかった
0631デフォルトの名無しさん
2011/07/05(火) 19:17:22.50> というか操作とデータが一緒であることが理解できないっていうとOO全否定じゃね。
CLOS全否定だなwW
0632デフォルトの名無しさん
2011/07/05(火) 19:55:03.87OOPか．．． 森羅万象 オブジェクトとしての整理できる？
0633デフォルトの名無しさん
2011/07/05(火) 20:00:01.21自分で定義したインターフェイスで何ができるかも把握できてないのにドヤ顔してた馬鹿が叩かれてるだけだ
0634デフォルトの名無しさん
2011/07/05(火) 20:44:37.41CLOSこそデータと処理が一体化してるだろ。
処理自体がデータだし。
0635デフォルトの名無しさん
2011/07/05(火) 20:48:15.25あんまりインターフェースの事解ってないように見えるし。
0636デフォルトの名無しさん
2011/07/05(火) 21:05:49.22>>606に従ってRGBをHSVに変換するとして、
class RGBToHSVConverter : RGB, HSVConverter { void RGB.change(略); HSV HSVConverter.to(HSV hsv); }
みたいにすればいいの? これどうやって実装すんの?
changeに渡された値をフィールドに保持したら結局値オブジェクトになってしまうから無意味だよね
コンストラクタかなんかでRGBConverterへの参照を渡してフィールドに持っておくとしても、
結局値オブジェクトを経由してRGB値を取ってくることになると思うんだけど
それとも、既存のRGB実装クラスにHSVへの変換をサポートさせたかったら
それぞれHSVConverterを実装しないといけないの?
で HSV to(HSV hsv) { hsv.change(Helper.rgbToHSV(this.argbval)); }みたいなのをコピペしてまわるわけ?
0637デフォルトの名無しさん
2011/07/05(火) 21:06:42.08レッテル貼りはいいから、>>606で
interface RGB{ void change(double r,double g,double b); }
interface RGBConvertor{ RGB to(RGB color); }
って定義されてるRGBConvertor(笑)が何をできるか考えてみろ
結局colorは呼び出し元に情報をもたらさないから、colorに依存しない値でchangeを呼び出すことしかできないだろ？
つまりRGBConvertorは手持ちのRGB情報を押し付けることしかできないインターフェイスだ
当然ネガポジだのセピアだのと言った変換も出来ない(出来るとしてもRGB側に実処理を書く必要がある)
このゴミ設計をどうしても使うとしたら、RGBConvertorをRGB値として使い、
RGB値を必要とするクラスでRGBを実装してロジック内で呼び出し、フィールドなりなんなりを書き換えて処理を行う必要がある
でもそれはスレッドアンセーフだから、結局別のRGBインスタンスにRGBのゲッターを公開してもらって使わないといけない
0638デフォルトの名無しさん
2011/07/05(火) 21:39:07.36HSV dest;
void RGB.change(r, g, b) { dest.change(convertRGBToHSV(r, g, b)); }
}
HSV HSVConverter.to(HSV color) {
RGBConverter rgb = this.rgbSource;
rgb.to(new ConverterImpl { dest = color });
return color;
}
意地でも値のコピー作らないならこんな感じ?
汚っw
0639デフォルトの名無しさん
2011/07/05(火) 21:57:06.23>>636と>>637はConvertorって名前に騙されてんだ。
まぁ、名前のつけ方が変ってのは確かかもな。
>>589を見ればtoで値をいじっちゃいけなくて、
change側で変更するって事が一目瞭然なのに。
0640デフォルトの名無しさん
2011/07/05(火) 21:59:29.52そんな否定することだけに必死になって盲目にならんでも。
0641デフォルトの名無しさん
2011/07/05(火) 22:06:18.22interface RGBConvertor
{
void analize(double r,double g,double b);
}
interface HSVConvertor
{
void analize(double h,double s,double v);
}
interface RGB
{
RGB to(RGBConvertor color);
}
interface HSVConvertor
{
HSV to(HSVConvertor color);
}
0642デフォルトの名無しさん
2011/07/05(火) 22:12:46.88interface RGBConvertor
{
void analize(double r,double g,double b);
}
interface HSVConvertor
{
void analize(double h,double s,double v);
}
interface RGB
{
RGBConvertor to(RGBConvertor color);
}
interface HSV
{
HSVConvertor to(HSVConvertor color);
}
0643デフォルトの名無しさん
2011/07/05(火) 22:16:14.38その理解は>>588ですでに達してるんで
で、複数のRGBをもとにanalize(笑)するときはどうすんのって話
素直にゲッター付けろよ
あと(笑)ってのは「英語力が足りないんで中学からやり直してね」って意味だからね
Converterって書いた人もいたのに何も学ばないのね
0644デフォルトの名無しさん
2011/07/05(火) 22:23:01.910645デフォルトの名無しさん
2011/07/05(火) 22:24:32.35>複数のRGBを元にanalize
?
0646デフォルトの名無しさん
2011/07/05(火) 22:28:30.380647デフォルトの名無しさん
2011/07/05(火) 22:31:30.72ぶっちゃけ引き下がるに下がれなくなったんだろうな。
0648デフォルトの名無しさん
2011/07/05(火) 22:35:56.50たとえばBitmap CreateLinearGradientImage(RGB, RGB, int, int)って処理を実装したい場合どうすんのかって話
引数別にクラスを分けるの？RGBが4つだったら？
って考えると素直にゲッター付けとけって話
0649デフォルトの名無しさん
2011/07/05(火) 22:43:45.67どうにもプログラムを英語らしく書こうとしたりする人やら、
型判別がある言語でメソッド名に型名いれたがる人とかと同じ感覚なんじゃないかな？
そんな事したらオーバーライドしづらくなるんだけど、言語機能より人間の直感での
わかりやすさが大事らしい。
0650デフォルトの名無しさん
2011/07/05(火) 22:44:52.240651デフォルトの名無しさん
2011/07/05(火) 22:47:47.87構造体的に使うクラスってやっぱ無くならないと思うし。
例えばpairみたいなやつね。
getしたりsetしたり、ってのがほとんど目的になるから。
0652デフォルトの名無しさん
2011/07/05(火) 22:49:59.55RGB,RGBはなんとなく分かるけどint,intって何に使うの？
0653デフォルトの名無しさん
2011/07/05(火) 22:51:09.66サイズのつもり
0654デフォルトの名無しさん
2011/07/05(火) 22:59:21.44縦と横？
(ベクトルならまだしも、なんであんなところに登場すんのか意味が解からん・・・。)
0655デフォルトの名無しさん
2011/07/05(火) 23:19:42.08{
GradientArea gradient = new GradientArea( this.colorArray, vector );
begin.to( new GradientBegin( gradient ) );
end.to(new GradientEnd( gradient ) );
}
つかメソッド名がきたねぇよ。なんだよCreateLinearGradientImageって。
Gradient.Paint(・・・)でいいだろうが。
0656デフォルトの名無しさん
2011/07/05(火) 23:29:59.68こういう発想( >>638 )に至るアレな子だから・・・。
0657デフォルトの名無しさん
2011/07/05(火) 23:33:46.44それは>>648で予想してるとおりの実装だから書かなくてもいいよ
そのGradientBeginって中途半端なクラスを処理フローごとに分けるのが適切なのかって話をしてるわけ
その分だとRGBを使う画像ライブラリはよく分からん中間クラスで埋め尽くされるよ
>>656
それ別人
0658デフォルトの名無しさん
2011/07/05(火) 23:38:30.880659デフォルトの名無しさん
2011/07/05(火) 23:45:24.32{
GradientArea gradient = new GradientArea( this.colorArray, vector );
begin.to( gradient );
end.to( gradient );
}
てかこうやっとけばいいじゃん。
引数でグラデーションだと一目で分かるし。
メソッド名が汚くなくて済むし。
0660デフォルトの名無しさん
2011/07/06(水) 00:14:28.40俺はフローのステップ別にクラスを作るなんてコストは払いたくない、まあこれ以上は個人の嗜好だけど
>>659
colorArray持ってるのならコンストラクターを呼んだ時点でGradientAreaは完成させられると思うけど
それにcolorArray[i].to(this)を複数回呼ぶのが嫌だから>>655になったんだろ？
あと引数で全部渡したのはこれ以外の値を使うなって意図もあったんだけど、伝わらないもんだね
0661デフォルトの名無しさん
2011/07/06(水) 00:25:36.48colorArrayがRGBの配列とは限らんけどな。
俺は、C++でBlt転送する時につかうBGR配列のようなもんを想定して書いた。
まぁBGRであることは重要じゃないけど、デバイス直属のデータ領域に転送できるって重要だかね。
InputからOutputまで完結できるってことだから。
>あと引数で全部渡したのはこれ以外の値を使うなって意図もあったんだけど、伝わらないもんだね
まぁ、雰囲気は伝わるけど、適当な形が設計レベルで違うんだからどうしようもないさ。
void method(int,int)のメソッドで値を返せって命題を投げられても無理じゃん似たようなっもんさ。
0662デフォルトの名無しさん
2011/07/06(水) 00:35:47.78{
vector.to( this.gradient );
begin.to( this.gradient );
end.to( this.gradient );
this..gradient.update();//さっき書き忘れてた
}
やや不恰好だったんでもう少し整えた。
メモリ8バイト程度のメモリを無視するなら、
最初からgradientをコンストラクタで作っとく手もあるね。
0663デフォルトの名無しさん
2011/07/09(土) 10:45:25.83これ面白いね
0664デフォルトの名無しさん
2011/07/10(日) 04:46:28.33単に高階化したら？
void Paint(RGB begin, RGB end, Vector vector)
{
GradientHolder gradient = new GradientHolder();
begin.To( gradient ); //内部でnew Gradient(int red,int green,int blue)を呼ぶ
gradient.analize( end ); //内部でGradientのanalizeを呼ぶ
}
0665デフォルトの名無しさん
2011/07/11(月) 11:55:11.51C#やJavaで抽象クラスを使うべき状況ってどんな場合なのでしょうか。
これに関する設計を行う場合、以下の4つの使い分けがあると思います。
・抽象クラス
・集約
・別々のクラスに設計、クラスの分割を見直す。
・インターフェース
・インターフェース＋集約
これらを比較した場合、抽象クラスは利点より分かりにくさの欠点のほうが目立ってしまうように思います。
実際のところどうなんでしょうか。
0666デフォルトの名無しさん
2011/07/11(月) 12:04:48.790667デフォルトの名無しさん
2011/07/11(月) 12:28:59.59まぁ違和感は感じるんですが、自作クラスで抽象クラスが旨く使われている例が殆ど無かったもので。
いや集約でいいでしょこれ？みたいなのがほとんどなのです。
0668デフォルトの名無しさん
2011/07/11(月) 20:16:12.20使い分けは、ドメインモデルからコードに起こす際に発生するんじゃねーかしら？
抽象クラス
・実体として見た場合も、継承関係が発生する物
・例としては、 「抽象クラス：自動車」 を継承した 「クラス：乗用車」「クラス：タクシー」「クラス：トラック」 等
集約
・独立して存在出来る物を、他の実体にも内包したい場合
・例としては、自動車に搭載するカーオーディオとか
インターフェース
・独立して存在出来ないが、機能としては共通する物
・例としては、自動車でも電車でも飛行機でも良いので 「エンジンを掛ける」 という行為
俺ならこんな感じかしら？
自分で見てもちょっと微妙だけど
0669デフォルトの名無しさん
2011/07/11(月) 20:26:18.53集約？←→継承
「OOPにおいて機能を再利用するためによく知られた二つの技法に、
クラス継承とオブジェクトコンポジショがある」という言い方。
インタフェースは広い意味ではオブジェクトの特性を定義したもの。
抽象クラスはそれに部分的な実装を与えたもの。
四つのうちから一つを選ぶようなものではないし、
四つ並べて語るようなものでもない。
0670デフォルトの名無しさん
2011/07/11(月) 20:35:42.37そのレベルの話で済むなら、>>665みたいな疑問は出て来ないんじゃないか。
何かしら、例が有った方が良いんじゃないかね。
0671667
2011/07/12(火) 17:29:18.58>>668
原則としてはこの説明がしっくり来るんですよね。
抽象概念に対して具象、あるいはその逆でもあれば抽象クラス、部品を持つようになっていれば集約、行為を追加したければインターフェース。
>>669
抽象度のレベルが違うのですか。
個人的には継承でなければ旨みが無いという状況でない限り、設計でも再利用でもオブジェクトコンポジションにしたくなるのです。
設計で継承しようとしたら、.NETのコントロール関連の仕組みに匹敵するプログラム的な仕組みを作らないと旨みがない気がしますし、
再利用で継承を利用しよう、という考えは割と最初に放棄してしまいます。
0672デフォルトの名無しさん
2011/07/12(火) 23:58:24.14抽象化クラスは、クラスであるためアクセス制御ができる。
やや変則的な話だけど、これを応用すると、ある抽象化クラスを
継承したクラスのオブジェクトのみしか参加できないネットワークを
構築することができる。
abstract class ChildNet
{
protected int abstract int privateValue();
protected int callPrivateValue(ChildNet group)
{
//子クラスは他の子クラスから値を抉り出す。
return group.privateValue();
}
}
これに加え、抽象化クラスなんで当然ネットワークに存在するオブジェクトに
義務を持たせる事が可能になる。
0673デフォルトの名無しさん
2011/07/13(水) 00:06:35.60他の子クラスが持ってる値を渡してやる必要はなくて、
自分で噛み砕いた値を自分の子に渡してやってもネットワークは成立するよ。
0674デフォルトの名無しさん
2011/07/14(木) 10:33:20.48もうこれはケースバイケースとしかいいようが無いような気が。
ただ、>>671の言うとおり、上手く抽象クラスがフィットするケースじゃない限り、
コンポジションで間に合うし、そのほうが無難な事が多い。
C++とかの例で言うと、継承の場合ヘッダ(.h)は *必ず* 抽象クラスのヘッダに依存するが、
コンポジションの場合、実装(.c)が部品のヘッダに依存しても、
コンポジションしたオブジェクトのヘッダは部品に依存させないようにできる。
部品の実装やインターフェースに変更が入っても全体を再コンパイルする必要はない。
抽象レベルでの話題であることは分かるんだけど、
結局これから実装するものは実装レベルでの話も考えないと依存しまくりになる。
C#とかの依存の話は詳しくないので識者がいたらPLZ。
0675デフォルトの名無しさん
2011/07/14(木) 12:56:49.20なんでもコンポジションって、オブジェクト指向っていうよりただのコンポーネント化だよね
0676デフォルトの名無しさん
2011/07/14(木) 13:21:09.21コンポジションオブジェクトのコンストラクタで部品の抽象ファクトリ渡すとかどうでもできるだろｗ
■ このスレッドは過去ログ倉庫に格納されています