オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
VBとCOBOLはいまさら覚えたくねえなぁ
C系と記述が違うのに先進性は無いとか鬱になる 分かりにくい解説だな
マルチポストする前に文章を見直せ >>823
ペチパーやドザーみたいな愛称だろアスペか >>825
文脈的に、アスペルガー症候群じゃなくてアスペルガー症候群患者な >>825-826
これがアスペルガー症候群患者なんだな どうやったらこんなつまんないレスを返せるんだよ...
重症やな w どうやったらこんなつまんないレスを返せるんだよ...
重症やな w ひょっとしてガチが若いとか思ってるんじゃないよな w 若いと思ってるっつーか実際若いしな
ガチとか使う奴=低脳、バカっぽいって発想がオッサンぽい >>838
ごめん、どうみてもお前の方がおっさんだよ ww アスペクト指向プログラミングってのは具体的にどんなのかよく分からんわ
興味ないから おっさんは知識と経験と優しさでできています
残りの9割は脂肪です おっさんは別に嫌いじゃないけど>>838みたく勘違いしてる奴はキモい やっぱり青木 淳いいな
若い時に心酔して、経験積むうちに忘れていたが
ようやく言わんとすることが分かつて来た 2ちゃんねる自体、どこかの機能でデザインパターンつかわれてるの？ クラス図とER図の違いって継承関係が
あるかないかだと思ってるんだけど、
DBのテーブルって継承はないわけじゃん、
継承とか知識レベル/操作レベルってDB設計的には
どう対応するの？ いや、>>856が知らないだけで、ERモデリング技法にも
継承に相当するサブセット(部分集合)の表現は存在している
明らかに欠けているのはメソッド(ストアドプロシージャ)かな CRUDは外部的だね
データ保護に対しては各種制約を設けるしかない
それらを言語側で埋めるのがORマッピングだったりDAOパターンだったり >>857
いやそれは分かったが実際のテーブルはどうするんだよ
親クラスと 子クラスA 子クラスBのテーブル全部別々に
作るの？
ここでいいう親子は継承の親子関係のことで
外部キーでの関連のことではないものとする。 考え方次第かな？
一つのテーブルに全カラム持たせるか差分情報だけのテーブルを連結するか オブジェクト指向の考え方を教えてください
指定した2点を通る線を描画するプログラムを作ろうと思っています。
・色
・線の太さ
こんなプロパティを持つクラス「DrawLine」を考えています。
さらにこのクラスを継承を用いて
・2点間のみ線を引く線分クラス
・2点を通る直線クラス
・2点のうち片方を始点に持つ半直線クラス
を派生させようかと思っています。
これとは別に描画のインターフェースを担うクラス「LineInterface」を用意しようと思っています
・線を引く
・線を消す
・2点の位置を変更を受け付ける
・色の変更を受け付ける
・線の太さの変更を受け付ける
・線分、直線、半直線の変更を受け付ける
さて、ここで疑問なのですが、インターフェースを担うクラス「LineInterface」は
内部に色や線の太さ、線分・直線・半直線の状態を記憶するbool値型のフラグ
ないしはenum型の値（線分・直線・半直線）を持つべきでしょうか？
最初はこの手のフラグには頼らない設計を心がけてみました。
色、線の太さ、線分・直線・半直線、これらの状態が変更されるたびに
クラス「DrawLine」のインスタンスを作成し直せばいいと思ったからです。
ただすぐに壁にぶち当たりまして、たとえば色を変更しようと思いクラス「DrawLine」の
インスタンスを作り直そうと思ったとき、それが線分クラスなのか半直線クラスなのか
直線クラスなのかは状態を記録しておかないと判断できないことに気付きました。
インターフェースクラスには最低限の内部状態はbool値enum値フラグとして保持しておくべきでしょうか？ まず>>862を先に読んで「もっと何か具体的に言ってやれよｗ」と思ったが
その後>>861を頑張って読んだら、言いたい事は既に>>862に書いてあった 長文書いてしまう人はもうちょっと図や箇条書きして考えまとめた方がいいな とりあえずC#で書くとこんな感じか
class abstract LineBase{
public float width{get; private set;}
public Color color{get; private set;}
public Point start{get; private set;}
public Point end{get; private set;}
// 初期値をセット
public LineBase(引数){}
public LineBase(LineBase instance){}
// 共通メソッドを実装
public void SetWidth(int width){}
public void SetColor(Color col){}
public void SetPoint(Point start, Point end){}
public void Eraser(){}
public virtual void Draw(){} // 仮想メソッド
}
class SegmentLine: LineBase{
public SegmentLine(引数): base(引数){}
public SegmentLine(LineBase instance): base(instance){}
public overrider void Draw(){} // 線分の描画処理を実装
}
class StraightLine: LineBase{
public SegmentLine(引数): base(引数){}
public SegmentLine(LineBase instance): base(instance){}
public overrider void Draw(){} // 直線の描画処理を実装
} >>861
何のクラスかは正直どうでもいい
こんな感じで基底型のインスタンスをコンストラクタに渡してコピーしとけ
// 線分クラスを生成
LineBase segment = new SegmentLine(初期値を渡す);
// 線分のデータで直線クラスを生成
LineBase straight = new StraightLine(segment); >>869
最初線分を描いて、途中で気が変わってやっぱり直線を描きたいな、となったときは
インスタンスsegmentを消去したのち、インスタンスstraightを選択してDraw()を実行する
という理解でよろしいでしょうか？
さらにその状態で色を変えたいときはインスタンスstraightを選んだまま色を変えるということでしょうか？
インスタンスsegmentとインスタンスstraight、いま選んでいるのはどちらか？という情報は
どこかに格納しておくべきでしょうか？ >>861
・線の引き方の違いを継承で実装する
・線のデータをフラグで持つ
特にこの二点はオブジェクト指向として筋が良くない
・線の引き方はメソッドで実装
・データはフラグじゃなくオブジェクトで渡す
こっちの方がオススメ >>871
クラス「DrawLine」は単純なDraw()メソッドは廃止して代わりに
DrawStraightLine()…直線を描画するメソッド
DrawSegmentLine()…線分を描画するメソッド
DrawHalfLine()…半直線を描画するメソッド
を実装し、インターフェースからクラス「DrawLine」には
・2点の情報が格納された構造体
・色、線の太さの情報が格納された構造体
を渡す。
という理解でよろしいでしょうか？
ちなみにインターフェース上では線の引き方はフラグ等で格納しておいても構いませんか？
ユーザーがインターフェースに対して
SetSegmentLine()
などの命令を実行したらそれに応じてbool値に記憶させておくというのが常道でしょうか？ >>872
前半はそう。継承を使うのはダメじゃないんだけど
継承を使いこなすのは非常に難しいので
慣れるまではメソッドをたくさん生やす方が分かりやすい
後半はフラグとかいらない
そういう発想がまだないんだろうけど
デザインパターン勉強するとよく分かる
オブジェクトの生成と使用を分けて
なるべく値の設定を生成の一回だけで済ますと
フラグの不整合のバグが減ってソフトが安定する
これがオブジェクト指向を使うメリットのひとつ
特にオブジェクトが常に動き回るゲームとかじゃなくて
作図ソフトだったら基本的に一度オブジェクトを作ったら
そのまま静的な図になるから位置は不変データにして
もし位置を修正するときにはオブジェクトを再生成する
なんでそうするかっていうとフラグがバラバラ増えていくと
どこで値を変更したのか不明で後でメンテが困難になってくるから
できる限り生成時に一括で設定するようにするの >>873
こんな感じでどうでしょうか。
インターフェースを担うクラス「LineInterface」から
実際に線を描画するクラス「DrawLine」に向けて
新たに以下のような3番目のクラス「Information」を作成し、このインスタンスを投げようかと思います。
クラス「Information」には2点の位置座標、色、線の太さ、半直線か直線か線分かの情報が格納されています。
Class Information
{
public:
double x1, y1, x2, y2;
int color;
int lineWidth;
bool leftExtendFlag, rightExtendFlag;
};
線を描画するのに必要な情報は全てこのクラスに格納・隠蔽します。
ユーザーから線に関する新たな情報を受け付けたら あ、失礼。途中で書き込んでしまいましたorz
ユーザーから線に関する新たな情報を受け付けたら
クラスInformationに用意した専用メソッドを通してメンバ変数にデータがセットされます。
直接メンバ変数を操作するわけではないので（bool型のフラグを直接いじることはない）
安全面でも良いかと
このインスタンスを受け取った「DrawLine」クラスはメンバ変数を直接読み込み（publicで
宣言したのでアクセス可能）、線を描画します。
書き換えはせず、新たなデータを受け取とるたびに「DrawLine」クラスのインスタンスを
新規に作成しようと思います（なのでデータはコンストラクタで受け取るのみ）。
こんな感じでオブジェクト指向になるでしょうか？ >>874
>>875
細かいこと言うと第三のクラス名はまだしも「LineInfo」とかだろうね
実用ソフトだと「Line」だけじゃなく「Box」とか「Circle」とか増えてくから
細かいとこでキリがないけど
でもそれで組んでみればいいんじゃないの
OOPの要点を一言でいうと疎結合にすることで
ゴチャゴチャするようだったらまた設計を見直していく >>876
> 細かいとこでキリがないけど
> でもそれで組んでみればいいんじゃないの
了解しました、この方向で組んでみます
> OOPの要点を一言でいうと疎結合にすることで
> ゴチャゴチャするようだったらまた設計を見直していく
プログラムに関する本はちまたに溢れかえっているんですが
オブジェクト指向の設計に関する本ってなかなか見かけませんね
学ぶだけでなく説明する方も難しいのかもしれません＞オブジェクト指向 >>877
＞オブジェクト指向の設計に関する本
探せばいっぱいあるよ
でも本格的なのはたいてい翻訳書で
分厚くて高くて難しいから読むの大変だとは思う >>878
そうでしたか、本屋さん行って見ます(´･ω･｀)ノ >>877
多分そもそもオブジェクト指向を「学ぶもの」と思っている時点で間違い。
あれは悟るものだ。
>>861
おそらくOOPの練習なのだろうけど、そもそも題材も悪い。
オブジェクトの切り方は例えば .NET でも見てみればいいでしょ。
Graphicクラスに全部メソッドが付いている。
https://msdn.microsoft.com/ja-jp/library/system.drawing.graphics(v=vs.110).aspx
というか、線分と半直線と直線を別のオブジェクトにする意味が分からない。
余計使いにくくなるだけだ。何をどう抽象化(共通化)すべきなのか、全く分かってない。
ただな、OOPを「初心者」が理解するのは不可能なんだよ。
心は>>873に書いてあるとおりだが、要するに、
・なかなか複雑になってメンテが辛くなってきた物を、多少なんとかするもの
であって、
初心者が組める範囲で複雑になることなんてあり得ないから、理解しようがない。
だから、「頭でっかち」方式で最初に学ぶのはかなり無理。
デタラメでもいいからやってみて、
自分で「ああこういう事をすると苦労するのか」と地雷を全部踏んでみれば納得するだろうし、
おそらくそっちの方が早い。そうしているうちに上達もするだろうし。
OOPで一番重要なのは「分割」だ。（粗結合化）
ところが初心者が組める規模では「分割」する必要なんてないから、
初心者は常に「継承」をこねくり回して練習しようとするが、それは明確な間違いだ。
それをいくらやっても意味がない。
「分割」しないと手に負えない規模の物を早く組めるようになり、
それを上手く「分割」出来るように努力することだ。
ここら辺の話は「プログラミング言語C++」に書いてある。
(今のOOPはC++作者が再定義したものだから当然ではあるが) >>880
了解しました
とにかく書いてみます(`･ω･´) >>881
まあ君はやろうとしているだけかなりマシだよ。
やろうとせずに知ろうとだけする奴も多いからね。
そもそも、
・これこれこうで、後はよきにはからえ
と処理を投げられる物をオブジェクトにするべきであって、
逆に、そうでない物をオブジェクトにしても余計に話が混乱するだけ。
「隠蔽」も、初心者はとにかく「隠蔽」しようとするが、これも間違いで、
（外部から使うときに）そもそも見たくも知りたくもない物を「隠蔽」するんだよ。
といっても、やらないと分からないだろうから、まずは頑張れ。 >OOPはC++作者が再定義したもの
元凶だよな
Javaも再定義してるけど （第1章 はじめに 2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル アメリカのジョークはよく分からん。
きっと翻訳が悪いんだな >>883
C++（というかその設計者）はSmalltalk（同）のメッセージングのOOPを
ユーザー定義型（＝抽象データ型）のOOPとして再定義したわけだけど
JavaはOOPの何を再定義したの？ C++からSmalltalkにちょい戻したのがJavaのOOPじゃね Javaは抽象データ型のOOPをより純化させたとも言えるか smalltalkの臭すぎて堪らんところをc++で置き換えたのがJava 一番上手くやってるのは Objective-C だと思う Obj-C好きなのだが中身がC丸出しなのがなぁ…
swiftは文法モダンに！でまた“ここで処理投げてます！”が
わからないようにする悪弊組み込まれちゃったし…
(それは退歩なんだってば) 20年前はObjcet-Cなんて一部の物好きの研究者しか使ってなかった
FORTANやPascalと共に滅亡して時代はC++かJAVAの二強になると
堅く信じていた当時からすれば今のObject-Cの人気ぶりには隔世の感がある objcが人気なんじゃなくてiPhoneが人気なだけ
swiftの普及の早さを見ればわかるでしょ、みんな嫌々objcを使ってたって 使われているかどうかと人気があるかどうかは別だからね
嫌いだけど選択肢が少ないから仕方なく使っているって人も多い
だって実際に
> 嫌われる傾向が強いほかの言語には、「PHP」「Objective-C」
>「CoffeeScript」「Ruby」などが挙がっている。
https://builder.japan.zdnet.com/tool/35109803/
> Stack Overflowは、この嫌われている言語ランキングに
> 使用したデータを、求職情報ページの「Developer Story」ページから
> 集めた。Developer Storyは、開発者が自分の職歴や実績などを
> まとめて公開できるサービスだが、このページには使いたい言語と使いたくない言語のタグを追加できるようになっている。
>
> 嫌われる傾向が強いほかの言語には、「PHP」「Objective-C」
>「CoffeeScript」「Ruby」などが挙がっている。
>
> 一方、嫌う人が少ない言語には、「R」「Kotlin」「TypeScript」
>「Rust」「Bash」「Clojure」「Swift」「Python」「JavaScript」「Go」などが並んだ。 こっちは別のデータ
https://news.mynavi.jp/article/20170330-a133/
> fossBytesに3月28日(米国時間)に掲載された記事「Which Are The Most Loved and Most
> Hated Programming Languages｜2017」が、Stack Overflow Developer Survey 2017の
> 調査結果を引き合いに出し、開発者に愛されているプログラミング言語と嫌われている
> プログラミング言語のトップ25を伝えた。愛されているプログラミング言語1位は
> Rustで、これにSmalltalkとTypescript、Swift、Goが続いている。
>
> 嫌われているプログラミング言語トップ25は次のとおり。
> Visual Basic 6
> VBA
> CoffeeScript
> VB.NET
> Matlab
> Objective-C
> Assembly
> Perl
> Lua
> Hack
略 >>896
そっちも Java がスルーされてるな
CoffeeScript は悪くないと思うんだけど
D とか Julia は呼ばれてないな Smalltalkは今でも現役だよ
日本では壊滅的に過疎ってるだけで おまえの思いは要らない
現役である証拠を書けばいい お前のツッコミも余計
手ぶらの批判は誰でもできる
事実としてPharoの処理系は更新され続けてる 最近ようやくしょぼい専用VCS諦めてしょぼいGitHubクライアントを組み込みにしだしたみたいだね 更新されていたら現役なのか……
よし、Dは現役だな インスタンス造り機に「このクラスのインスタンスを作れ」ってぶち込むより
クラスに自分のインスタンス造る機能が入ってて
「おまえのコピーをこの名前で作れ」の方が個人的には関与する言語機能が減って好き。 >>902
> 事実としてPharoの処理系は更新され続けてる
更新されているからと言って現役ということにはならない
あたりまえのこと言わせんな >>906
> 「おまえのコピーをこの名前で作れ」の方が個人的には関与する言語機能が減って好き。
コピーしかできないのか？
なにもないところから作ることはできないのか？
コピーを作った後に、値を変更してインスタンスを完成させるのか？ new Test() を Test.New() にでもすんのか？ それを言うなら Test.Default().Clone() とか Test.Default().Copy() かと
> 作った後に、値を変更してインスタンスを完成させるのか？
これってプロトタイプベースだから必要なわけではなく、クラスベースでもコンストラクタで普通にやってる作業だよね？ >>908
他の言語の場合は、更新程度なら必要条件にすらならないかもしれないけれど
Smalltalkみたいにドックフードとして食らうことが避けられず
動的かつ可塑性を最大の利点にしている言語・環境に限れば
更新（変化）し提供され続けていることは少なからぬ人に使われている証拠として十分だろうね ドックフードとして食らうことが避けられず
動的かつ可塑性を最大の利点にしている言語・環境 レス数が900を超えています。1000を超えると表示できなくなるよ。
