1001コメント438KB

-OOP限定-プログラム設計相談室

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2005/09/24(土) 16:35:59

全部publicでいいじゃん！ってならないようにするスレです。

0605デフォルトの名無しさん

2011/07/05(火) 00:57:45.18

>>603
そのColorクラスは閉じてるんだよね。
こっちの場合は、必要なだけインターフェースとクラスを増やせば
元を弄る必要なくなるから楽なんだよ。>>577みたいな感じでね。

0606デフォルトの名無しさん

2011/07/05(火) 01:09:26.73

RGBとHSVだと前書いたtoの分離でもうすこし面白いことができる。
HSVから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.69

Point pが所属する空間Sによってある観点におけるの値vが変わるということは
vはpとSに依存し、それを与える写像が存在するということだろ
これはそのまま関数に対応する

0608デフォルトの名無しさん

2011/07/05(火) 01:17:16.45

それは特にその方法の利点にはならないだろ
プロパティと値オブジェクトでも同じようなことはできるし、別にそれが汚いとは俺は思わない
むしろ抽象的すぎるクラスやインターフェイスが増殖するほうが気持ちが悪いと感じる

0609デフォルトの名無しさん

2011/07/05(火) 01:20:30.98

キモイ抽象クラス増加させなくても一つの関数と値オブジェクトでいけるということだ
Genericsやtemplate, 依存型があると尚良し

0610デフォルトの名無しさん

2011/07/05(火) 01:24:10.10

名前さえ合ってれば特定流れの手続きに突っ込めるってことか。

0611デフォルトの名無しさん

2011/07/05(火) 01:31:52.25

関数を書き散らすが如く、インターフェースだけ最利用してクラスを
使い捨てにするような感覚が無いとキモイかもね。
オブジェクト = 関数の結果みたいな感じの設計デザインだし。

ただ、>>577みたいな感じで部品をぺきぺき組み合わせていくやり方は、
拡張が楽だし、きもちいいよ。

>>608 そう思うならそのやり方でいけばいいんじゃない？
個人的には構造体みたいな形で値が滞留するのが気持ち悪いと思うけど
逆のことを思う人は当然いるだろうし、そういう道でいいと思うよ。

0612デフォルトの名無しさん

2011/07/05(火) 01:36:57.21

>>610
ん。そうなのかねぇ。
とりあえずこんなことができるのは面白そうだな。

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

>>608
>プロパティと値オブジェクトでも同じようなことはできるし
できるのか・・・。今までの流れだと無理臭い気が・・・。

0614デフォルトの名無しさん

2011/07/05(火) 02:13:08.68

>>612
この方向なら「流れるようなインターフェース」の方が良いのでは？

流れるようなインターフェース
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

>>614
中身見たが、流れるインターフェースっていうけどそれカリー化じゃね？

0616デフォルトの名無しさん

2011/07/05(火) 02:26:22.28

>>614
変数省略してこう書いたのとは何が違うん？
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

>>613
>>612のように書くと合成されたフィルタができてるように見えるけど違うぞ?
フィルタを順番に即時適用してるだけだ
色を引数に取って変換後の色を返す関数を順番に呼んでるのと一緒
フィルタの実装次第では遅延評価にもできるけど、それは関数でもそういう風にはできる
むしろ高階関数使うアプローチの方が自然

0618デフォルトの名無しさん

2011/07/05(火) 03:19:46.39

>>617
value = lambda();
lambda()( value );
こうやってんのと同じってのは解るよ。
いや、プロパティと値オブジェクトって書いてあったから
もっとsetから入った値がgetで別の値に変わってるような
斬新な方法駆使してんのかと思ったから無理じゃねって書いたの。

0619デフォルトの名無しさん

2011/07/05(火) 07:09:40.14

>>613
実現しようとしてるアプリケーションは作れるんじゃね？
大規模開発では
＞抽象的すぎるクラスやインターフェイスが増殖するほうが気持ちが悪いと感じる
こういう人も紛れ込むし、頭いい方に合わせて底上げしようとしても
崩されたりモチベーション下げたりしてみんなが不幸になる。

割り切って構造化して「プロパティと値オブジェクト」にした方が
結果としてうまく行く場面も多いと思う。たとえ非OO的でソースが3倍にふくれあがってでも
代替要因が用意できて管理できることの方が重要なプロジェクトはある。
やりたくないけど仕事なのでそうも言ってられない

0620デフォルトの名無しさん

2011/07/05(火) 07:11:59.74

色と色コンバーターがくっ付いている方が抽象化が進んでいるという発想は理解できない

0621デフォルトの名無しさん

2011/07/05(火) 07:23:42.59

色コンバーターの結果が、色に抽象化されてるだけじゃん。
というか操作とデータが一緒であることが理解できないっていうとOO全否定じゃね。
まぁ、OOの観点から言えば、データは余計で全部結果を生む動作でやるのが
ただしいようだけど。smalltalkの標準ライブラリとか。

0622デフォルトの名無しさん

2011/07/05(火) 07:26:29.00

>>619
　>>618

0623デフォルトの名無しさん

2011/07/05(火) 07:33:41.18

>>617 インターフェースの引数を構造体みたいなもんで代用すればいいって言いたいんでしょ。
カプセル化の範囲絞り込みが出来ず原始回帰してるだけにしか見えん。

0624デフォルトの名無しさん

2011/07/05(火) 07:53:29.87

>>606を見ると、自分で色と色コンバーターに分けてるんだね
しかし状態変更メソッドしか用意されてないRGBをどうすればコンバーターで操作できんだよ
結局引数を見ずに自分の情報でchangeを呼ぶしかないけど、それすら保証されていない謎インターフェイスになってるぞ

0625デフォルトの名無しさん

2011/07/05(火) 08:13:32.38

それを言ったら下駄で内容無視してnull返しても同じじゃん。
あくまで要求仕様は存在するでしょ。

0626デフォルトの名無しさん

2011/07/05(火) 08:34:37.87

そっちは別にどうでもいいんで、どうやって引数をコンバートするのか説明してください

0627デフォルトの名無しさん

2011/07/05(火) 08:38:27.43

どうやって変換前の値を取得するんだろうな

0628デフォルトの名無しさん

2011/07/05(火) 10:36:47.08

流れるようなインタフェースって、
Builderパターンとかによくハマる。
ビルダオブジェクトに対し、コネコネ、
グニグニ操作を加えていくのが楽しい。

0629デフォルトの名無しさん

2011/07/05(火) 13:03:41.65

>>626
>>589

>>627
>>584

200レスも前の話じゃないだろ、
ゆとりは掲示板すら使えないのか。

0630デフォルトの名無しさん

2011/07/05(火) 18:31:04.62

>>629
お前がコードか日本語を読めないのはわかった

0631デフォルトの名無しさん

2011/07/05(火) 19:17:22.50

>>621
> というか操作とデータが一緒であることが理解できないっていうとOO全否定じゃね。
CLOS全否定だなwW

0632デフォルトの名無しさん

2011/07/05(火) 19:55:03.87

ソフトウェア工学を追いかける奴とソフトウェア哲学を追いかける奴のせめぎ合いか．．．　orz
OOPか．．．　森羅万象　オブジェクトとしての整理できる？

0633デフォルトの名無しさん

2011/07/05(火) 20:00:01.21

そんな高尚な話じゃないぞ
自分で定義したインターフェイスで何ができるかも把握できてないのにドヤ顔してた馬鹿が叩かれてるだけだ

0634デフォルトの名無しさん

2011/07/05(火) 20:44:37.41

>>631
CLOSこそデータと処理が一体化してるだろ。
処理自体がデータだし。

0635デフォルトの名無しさん

2011/07/05(火) 20:48:15.25

俺は>>630がおかしいとしか思えないけと。
あんまりインターフェースの事解ってないように見えるし。

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

>>635
レッテル貼りはいいから、>>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.36

class ConverterImpl implements RGB {
HSV 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

>>638は論外として、なるほどな。
>>636と>>637はConvertorって名前に騙されてんだ。
まぁ、名前のつけ方が変ってのは確かかもな。

>>589を見ればtoで値をいじっちゃいけなくて、
change側で変更するって事が一目瞭然なのに。

0640デフォルトの名無しさん

2011/07/05(火) 21:59:29.52

>>636 = >>637 = >>638 必死すぎだろ。
そんな否定することだけに必死になって盲目にならんでも。

0641デフォルトの名無しさん

2011/07/05(火) 22:06:18.22

>>606をこう書き換えてやれば彼らは納得すんじゃない？

interface 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.88

あミスった
interface 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

>>641
その理解は>>588ですでに達してるんで
で、複数のRGBをもとにanalize(笑)するときはどうすんのって話
素直にゲッター付けろよ

あと(笑)ってのは「英語力が足りないんで中学からやり直してね」って意味だからね
Converterって書いた人もいたのに何も学ばないのね

0644デフォルトの名無しさん

2011/07/05(火) 22:23:01.91

なんだずっと粘着してたのか。必死度メーターが振り切れてるぞ。

0645デフォルトの名無しさん

2011/07/05(火) 22:24:32.35

>>643
>複数のRGBを元にanalize
　?

0646デフォルトの名無しさん

2011/07/05(火) 22:28:30.38

いくら、自分が誤解してたからって >>643 の言い訳は見苦しいわなぁ。

0647デフォルトの名無しさん

2011/07/05(火) 22:31:30.72

setter/getterのためにだけにここまでアイデンティテが傷ついてる人って。
ぶっちゃけ引き下がるに下がれなくなったんだろうな。

0648デフォルトの名無しさん

2011/07/05(火) 22:35:56.50

>>645
たとえばBitmap CreateLinearGradientImage(RGB, RGB, int, int)って処理を実装したい場合どうすんのかって話
引数別にクラスを分けるの？RGBが4つだったら？

って考えると素直にゲッター付けとけって話

0649デフォルトの名無しさん

2011/07/05(火) 22:43:45.67

やっぱり下駄と雪駄に、こだわるのって一種好みなんだろうね。
どうにもプログラムを英語らしく書こうとしたりする人やら、
型判別がある言語でメソッド名に型名いれたがる人とかと同じ感覚なんじゃないかな？
そんな事したらオーバーライドしづらくなるんだけど、言語機能より人間の直感での
わかりやすさが大事らしい。

0650デフォルトの名無しさん

2011/07/05(火) 22:44:52.24

もしかして: オーバーロード

0651デフォルトの名無しさん

2011/07/05(火) 22:47:47.87

好み、というかある程度は先に分類があるかも。
構造体的に使うクラスってやっぱ無くならないと思うし。
例えばpairみたいなやつね。
getしたりsetしたり、ってのがほとんど目的になるから。

0652デフォルトの名無しさん

2011/07/05(火) 22:49:59.55

>>648
RGB,RGBはなんとなく分かるけどint,intって何に使うの？

0653デフォルトの名無しさん

2011/07/05(火) 22:51:09.66

>>652
サイズのつもり

0654デフォルトの名無しさん

2011/07/05(火) 22:59:21.44

>>653
縦と横？
(ベクトルならまだしも、なんであんなところに登場すんのか意味が解からん・・・。)

0655デフォルトの名無しさん

2011/07/05(火) 23:19:42.08

Bitmap CreateLinearGradientImage(RGB begin, RGB end, Vector vector)
{
        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

>>654

こういう発想( >>638 )に至るアレな子だから・・・。

0657デフォルトの名無しさん

2011/07/05(火) 23:33:46.44

>>655
それは>>648で予想してるとおりの実装だから書かなくてもいいよ
そのGradientBeginって中途半端なクラスを処理フローごとに分けるのが適切なのかって話をしてるわけ
その分だとRGBを使う画像ライブラリはよく分からん中間クラスで埋め尽くされるよ

>>656
それ別人

0658デフォルトの名無しさん

2011/07/05(火) 23:38:30.88

関数だったら良くてクラスだったらダメなのか。

0659デフォルトの名無しさん

2011/07/05(火) 23:45:24.32

void Paint(GradientBegin begin, GradientEnd end, Vector vector)
{
        GradientArea gradient = new GradientArea( this.colorArray, vector );
        begin.to( gradient );
        end.to( gradient );
}
てかこうやっとけばいいじゃん。
引数でグラデーションだと一目で分かるし。
メソッド名が汚くなくて済むし。

0660デフォルトの名無しさん

2011/07/06(水) 00:14:28.40

>>658
俺はフローのステップ別にクラスを作るなんてコストは払いたくない、まあこれ以上は個人の嗜好だけど

>>659
colorArray持ってるのならコンストラクターを呼んだ時点でGradientAreaは完成させられると思うけど
それにcolorArray[i].to(this)を複数回呼ぶのが嫌だから>>655になったんだろ？
あと引数で全部渡したのはこれ以外の値を使うなって意図もあったんだけど、伝わらないもんだね

0661デフォルトの名無しさん

2011/07/06(水) 00:25:36.48

>>660
colorArrayがRGBの配列とは限らんけどな。
俺は、C++でBlt転送する時につかうBGR配列のようなもんを想定して書いた。
まぁBGRであることは重要じゃないけど、デバイス直属のデータ領域に転送できるって重要だかね。
InputからOutputまで完結できるってことだから。

>あと引数で全部渡したのはこれ以外の値を使うなって意図もあったんだけど、伝わらないもんだね
まぁ、雰囲気は伝わるけど、適当な形が設計レベルで違うんだからどうしようもないさ。
void method(int,int)のメソッドで値を返せって命題を投げられても無理じゃん似たようなっもんさ。

0662デフォルトの名無しさん

2011/07/06(水) 00:35:47.78

void Paint(GradientBegin begin, GradientEnd end, Vector vector)
{
        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

http://code.google.com/p/google-singleton-detector/

これ面白いね

0664デフォルトの名無しさん

2011/07/10(日) 04:46:28.33

>>662
単に高階化したら？
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.51

ふと思ったので質問させてください。
C#やJavaで抽象クラスを使うべき状況ってどんな場合なのでしょうか。
これに関する設計を行う場合、以下の4つの使い分けがあると思います。
・抽象クラス
・集約
・別々のクラスに設計、クラスの分割を見直す。
・インターフェース
・インターフェース＋集約

これらを比較した場合、抽象クラスは利点より分かりにくさの欠点のほうが目立ってしまうように思います。
実際のところどうなんでしょうか。

0666デフォルトの名無しさん

2011/07/11(月) 12:04:48.79

その四つを並べて見せることに違和感を感じないか？

0667デフォルトの名無しさん

2011/07/11(月) 12:28:59.59

すいません、4つじゃなくて5つでしたね。
まぁ違和感は感じるんですが、自作クラスで抽象クラスが旨く使われている例が殆ど無かったもので。
いや集約でいいでしょこれ？みたいなのがほとんどなのです。

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

>>669
そのレベルの話で済むなら、>>665みたいな疑問は出て来ないんじゃないか。
何かしら、例が有った方が良いんじゃないかね。

0671667

2011/07/12(火) 17:29:18.58

みなさんレスありがとうございます。
>>668
原則としてはこの説明がしっくり来るんですよね。
抽象概念に対して具象、あるいはその逆でもあれば抽象クラス、部品を持つようになっていれば集約、行為を追加したければインターフェース。

>>669
抽象度のレベルが違うのですか。
個人的には継承でなければ旨みが無いという状況でない限り、設計でも再利用でもオブジェクトコンポジションにしたくなるのです。
設計で継承しようとしたら、.NETのコントロール関連の仕組みに匹敵するプログラム的な仕組みを作らないと旨みがない気がしますし、
再利用で継承を利用しよう、という考えは割と最初に放棄してしまいます。

0672デフォルトの名無しさん

2011/07/12(火) 23:58:24.14

>>671
抽象化クラスは、クラスであるためアクセス制御ができる。
やや変則的な話だけど、これを応用すると、ある抽象化クラスを
継承したクラスのオブジェクトのみしか参加できないネットワークを
構築することができる。

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

何で原理だけで結論つけてんだよｗ
コンポジションオブジェクトのコンストラクタで部品の抽象ファクトリ渡すとかどうでもできるだろｗ

0677デフォルトの名無しさん

2011/07/14(木) 19:19:46.23

痛いくらいのニワカ臭。

0678デフォルトの名無しさん

2011/07/14(木) 20:05:15.64

>>676
それ続けていくと　OOPの複雑さだけが協調されて　インテリセンスが無いと手に負えないOOPの世界になるんでは？
まっ　ツールがあるから使えという事も言えるが．．．　チームプロジェクトの難易度が上がるような気がするが？

0679デフォルトの名無しさん

2011/07/14(木) 22:59:55.68

>>675
実装を使い捨てにしてインタフェースを再利用すれば
多態性を持たせるのは十分だろ。

0680デフォルトの名無しさん

2011/07/16(土) 20:23:41.42

>>678
>ツールがあるから使え
俺は正にこれ派だなあ

インテリセンス無しじゃ書く気がしない、とまでは言わんが
仕事としてはやりたくないレベル

0681デフォルトの名無しさん

2011/07/19(火) 00:23:35.70

俺は最近OOの設計も断捨離で行っている。
つまり
　　断＝入ってくる要らない物を断つ
　　捨＝家にずっとある要らない物を捨てる
　　離＝物への執着から離れる
これを
　　断＝今必要なない実装をやめる
　　捨＝使っていないクラスを破棄する
　　離＝既存クラスへの執着から離れる（見切りをつけ新規につくる）

いま必要なOOの実装だけを行い。
将来必要なるかもしれないと言って実装をしない。
あれは使うかもしれないとクラスやロジックを残さない。
とにかくシンプルに作る。これがOOの設計では一番。

0682デフォルトの名無しさん

2011/07/19(火) 18:19:02.30

っ[ YAGNI ]

0683デフォルトの名無しさん

2011/07/20(水) 08:52:51.03

YANAGI

0684デフォルトの名無しさん

2011/07/20(水) 09:30:13.80

YAGNIの再発明か…こうして独自ワードが増えていく

0685デフォルトの名無しさん

2011/07/30(土) 11:35:29.22

しかし、断捨離はヨガからきているから
YAGNIの方が再発見かもしれない。

つまり真理とは古今東西、昔から変わらないということか。

0686デフォルトの名無しさん

2011/07/30(土) 22:28:00.22

みんな好きに呼べばいいのさ
俺は泥縄と呼ぶことにする

0687デフォルトの名無しさん

2011/07/30(土) 23:54:27.92

しかし、戦略もなく戦術だけで戦うのがいいことなのか？
単なる消耗戦にならないか？

0688デフォルトの名無しさん

2011/07/31(日) 08:49:02.91

>>687
一体何の話だよｗ

0689デフォルトの名無しさん

2011/07/31(日) 11:01:04.67

戦略＝将来起こりえる問題の解決/対処法。
戦術＝目の前の問題の解決/対処法。

既存プログラムを改修するときは、現実の問題に集中すればいいが
最初にベースとなるプログラムを作るときは、将来への対応も必要。
例え、９０％の労力が無駄になっても、戦術で行うにはそれ以上の労力が掛かる場合が多い。

よく経験するだろう、元の作りが悪いから修正しにくいとか
もし、ソフトが永遠につかわれたなら、そのコストが莫大になうぞ。
まっソフトの寿命なんて大半が５年もないが。

0690デフォルトの名無しさん

2011/07/31(日) 11:10:05.09

うまく例えがはまってない感じだな。

0691デフォルトの名無しさん

2011/07/31(日) 12:01:16.14

俺用語を一々使いたがる奴とは、円滑な話がし難い

0692デフォルトの名無しさん

2011/07/31(日) 12:21:24.94

それはすまない。
目の前の現実と、将来への対応と言う意味で
戦略と戦術が俺のなかでは一番ピンときたから使った。
あきらかに俺の主観だな、別の言い方を考えるは。

0693デフォルトの名無しさん

2011/07/31(日) 13:27:08.50

>>689
最後の行にはげしく同意

0694デフォルトの名無しさん

2011/07/31(日) 17:42:30.73

10年くらいは普通だろ
無理にCのをC++に（better Cではなく）置き換えてるせいで
OOP原則？ナニそれ？
みたいなソース触った経験ある

0695デフォルトの名無しさん

2011/07/31(日) 18:11:53.17

業界に寄るし、年代に寄るんじゃねーかしらね。

昔作った物は、10年超えても稼動し続ける　（稼動し続けさせられる）　様なのが多かったとしても
これから新しく作る物は、そんなに長く稼動し続ける物はそう多く無い様な気はする。

0696デフォルトの名無しさん

2011/07/31(日) 18:24:47.15

昔作ったときも、そんなに長く稼動し続けるとは思いませんでしたｗ

0697デフォルトの名無しさん

2011/07/31(日) 18:43:30.06

>>696
まあ確かになｗ

俺は、10年も前に出来た様なソフト　（Webアプリ）　の保守・アップデート案件で
ここ3年くらい専業テスターやってるけど、3年前と今年は丸々リファクタリングだわ。

0698デフォルトの名無しさん

2011/08/02(火) 07:38:46.35

>>695 プラント制御とか10年なんて当たり前

0699デフォルトの名無しさん

2011/08/02(火) 09:38:35.61

出来次第だろうな…。
俺が五年前にフルスクラッチで書いたクラサバは、
今も各所で元気に稼動しております。

0700デフォルトの名無しさん

2011/08/04(木) 18:51:24.42

5年なんて普通もいいとこ

0701デフォルトの名無しさん

2011/08/04(木) 20:13:23.20

５年というのは税制上の理由からくる場合も多い。
減価償却が５年だからな、馬鹿な経営者はソフトを作り変える。

まっ仕事も増えるから批判もできんが。

0702デフォルトの名無しさん

2011/08/06(土) 20:07:16.41

状態方程式ってのは OO 屋にはどう説明すりゃいいの？
話が噛み合わないっつか，
「ブラックボックスでええんちゃうの？」つても、
「モデル化できへん」とか
言い出すやからと仕事する羽目になったんだが

0703デフォルトの名無しさん

2011/08/06(土) 21:53:52.84

>>702
入力と状態を引数に取って出力と次の状態を返す関数だよ、くらいでいいだろ

0704デフォルトの名無しさん

2011/08/07(日) 12:58:04.51

俺には「天文学をアメリカ人にどう説明すりゃいいの？話が噛み合わない」と言っているのと同レベルの質問に思える。

■ このスレッドは過去ログ倉庫に格納されています