2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

オブジェクト指向の活用方法を教えて下さい

1 :
2014/03/25(火) 21:44:07.66 ID:AtcH5MLU
お願いします。言語は問いません。
オブジェクト指向言語じゃなくても
オブジェクト指向の話であれば問題ありません。
2 :
2014/03/25(火) 21:52:21.12 ID:EiPXCdKp
アイ オブジェクト たべたい
3 :
2014/03/25(火) 21:53:45.99 ID:pgzxn/ED
オブジェクト指向の活用方法とあらためてきかれてもな。
仕事やってるなら、オブジェクト指向以外を使うことのほうが
まれだよ。まあ空気のようなものだ。
4 :
デフォルトの名無しさん
2014/03/25(火) 22:27:48.82 ID:NjDRIK2T
ポリモーフィズム
5 :
2014/03/26(水) 00:23:07.66 ID:u5ViS8To
もしオブジェクト指向がなかった場合に困るのであれば、あなたが一体どんな風に
困るのかを教えてください。自分は困ったことがないので。
6 :
2014/03/26(水) 00:32:00.76 ID:2aKYqEvM
>>5
俺はオブジェクト指向以外の方法論を知らない。
逆にどういうのがオブジェクト指向じゃないのだ?
7 :
2014/03/26(水) 00:43:25.50 ID:q9v11IGY
SQLは関数型言語ですが何か?業務プログラマじゃないのがバレバレな発言だね。
8 :
2014/03/26(水) 00:49:07.29 ID:czRoHAkF
困るのは関数の数が数百だとか数千だとか、ある程度規模が大きい場合だな。

オブジェクト指向なんて呼び方しているけど、本質的には構造化言語でもやっていた
モジュール化だからな。大量の関数を個別に扱うなんて大変な事をするよりも、
分類してまとめたモジュールを単位として組み合わせた方がシンプルになるからね。

そういう便利なモジュール化を最初から言語仕様に取り込んで
class{} とするだけで誰でも簡単にモジュールが作れるようにしたのが
オブジェクト指向言語。
9 :
2014/03/26(水) 00:52:05.00 ID:2aKYqEvM
へー、SQLは関数型なのか。
俺は業務プログラマじゃないよw
10 :
2014/03/26(水) 00:56:46.58 ID:UFBUrpIy
SQLが関数型であるという考え方は、
C言語は関数を定義するから関数型だよね、と同じ
11 :
2014/03/26(水) 00:59:32.24 ID:rbVA5aPF
SQLは宣言型言語だったかと。HTMLもそうだけど。
12 :
2014/03/26(水) 01:47:31.32 ID:u5ViS8To
>>8
それは関数名や変数名を区分して、ネームスペースを分けるというところまでで
十分目的を達成できるように思えるのだけれど、それで達成できないことは何?
13 :
2014/03/26(水) 01:54:10.43 ID:XRtgkR6L
それで出来ないのは属性の隠蔽と、継承による親子関係だな
まあ継承には最初はそんなにお世話にならんが、ある程度のクラス群を定義してくと
それらにグループ的な物が出来てくると思う
14 :
2014/03/26(水) 05:17:45.52 ID:q9v11IGY
実は、SQLは集合論を基にしているという点で、ある種の関数型言語とも考えられる(言語と
しては制限が多すぎるにしても)。
thinkbiganalytics.com/programming-trends-to-watch-logic-and-probabilistic-programming/
15 :
2014/03/26(水) 07:05:24.48 ID:q8kXJDbw
>>12
実運用

自分1人で自分だけしか触らないプログラムだったら別にそのやり方でもある程度まで出来るだろうけど、
複数人数だとか、他の人が触るだとかするようになると、決めてたことが守られなくなってスパゲティに
なるのが常。
それをしっかりと見張って、ルールを破ったソースは絶対に許さないと監視してくれるのが、
その言語のコンパイラさん。

ちなみに俺も、1人で行うC言語の開発ではオブジェクト指向的に関数名や変数名を区分して作る。
16 :
2014/03/26(水) 07:48:30.63 ID:5lLsdkXL
>>14
集合論ベースなら論理型じゃないのか?
17 :
2014/03/26(水) 09:03:17.98 ID:isiCXEht
SQLはクエリーであって、つまり問い合わせであって
それだけでアプリケーションになるわけないしな。

実際にSQLだけでアプリを作ったことあるのかい?って話。
18 :
2014/03/26(水) 09:10:42.35 ID:isiCXEht
>>12
> それで達成できないことは何?

複雑さの低減かな。

たとえば、アセンブラ使って比較とジャンプで
ループは作れる。でも言語としてループがあれば簡単に書ける

つまりは複雑さが減ってるわけ。

オブジェクト指向も同じで、使えば複雑さが減る。

読んで考えなきゃいけないことが、
単語一つで、あぁあれね。とすぐに知ることが出来る。
そういうコードになる。
19 :
2014/03/26(水) 12:27:56.78 ID:Vvdm35l0
>>17
オセロくらいなら作れそうだな
ちょっと面白そう
20 :
2014/03/26(水) 19:13:13.84 ID:C/yXeurz
SQLはチューリング完全じゃないんでしょ
21 :
2014/03/26(水) 20:05:10.15 ID:u5ViS8To
>>18 複雑さの低減のところ、詳しく。
オブジェクト指向について書かれた本だと例題がそもそも短いので、オブジェクト
指向の導入によって逆に長い記述になってしまうし、わざとらしい例ばかりなので
これで本当に分かりやすくなったの?生産性や保守性は本当に上がったの?という
点がいつまで経っても納得がいかない。
(いまどきの学校なら、先生がちゃんと教えてくれるんだろうか?)
22 :
2014/03/26(水) 20:36:30.54 ID:65VtCojr
18じゃないが。
電気回路で例えたら、抵抗とかダイオードとかトランジスタがびっしり基板を埋め尽くす
回路を作っていたのを、ICチップ数個を配線して繋げればいいだけにした
みたいなものかな。

ICチップ自体を作るところで確かに手間はかかるけど、
そのICチップという単位で手軽に扱える便利さが出てくるよね。
23 :
2014/03/26(水) 20:54:01.45 ID:lornT58y
オブジェクト指向によるループの簡略化ってなんだ?アイテレータか?
foreach構文使える言語ならOOPしなくても簡略化できるぜ。
24 :
2014/03/26(水) 21:17:17.67 ID:lornT58y
構造化プログラミングでは「機能」で全体を切り分けてた。
それがC++などのオブジェクト指向プログラミングになると「オブジェクト」で全体を切り分けるようになる。

電気回路に例えるなら、
それぞれの機能は基盤ごと、チップごとに整理されているが電源が一つしかない状態が構造化プログラミング。
それぞれの機能が自前の電源を持ってるのがオブジェクト指向。
25 :
2014/03/26(水) 21:43:06.83 ID:dEVLbQ7F
>>23
そういうレイヤーの話じゃないんだよね。

あなた関数の中の話をしてるじゃない?関数の中の書き方の話じゃない。
関数ではないものにデータがある。データは関数ではない。
オブジェクト指向はデータにそのデータを扱う関数をまとめたもの。

関連があるものを別々に管理するよりも、まとめたほうがわかりやすい。
データと処理が一体で管理できるから、このデータを扱えることが出来る処理はどれだろう?
などと考えなくて良くなる。管理がものすごく楽になる。

このまとめた物がオブジェクト。
そしてオブジェクト指向は、そのまとめた、物 と 物。
物自体と物同士を組み合わせて使うときの考え方。

物の生成をどうするか?
物の構造をどうするか?
物の振る舞いをどうするか?
26 :
2014/03/26(水) 22:07:44.33 ID:dEVLbQ7F
>>21
たとえばゲームで考えるとね。キャラクターを横に1つ移動するはX座標をプラス1するだけ。
だけどこれだけじゃゲームとして成り立たない。キャラクターには座標以外にも色々な情報がある。

キャラクターが持ってるであろう情報にはどんなものがある?
と聞いたら、いくつも答えが出てくるでしょう?

ならそれをまとめて種類(クラス)として管理したほうが楽じゃない?
敵キャラとかキャラクター自体は一緒だけどデータ(座標など)が違うものってあるじゃない?
敵キャラという物がいてある場面になったら、この物を生成する必要があるじゃない?(敵出現)
敵と自分が戦うとしたら、それは物と物と関連があってそこである作用が発生するということ。

つまりこういうこと。

小さな処理ではなくて、巨大なアプリを作ることを考えてみよう。
座標を1動かすという小さな処理だけを見ていたら分からないが、
なにかアプリを作ろうと思ったら、その処理を沢山組み合わせて作ることになる。
その処理をバラバラに管理していたら複雑になりすぎる。複雑だと時間がかかるしバグも増える。
出来るか出来ないかではなく、複雑にならないように作るというのが実際の開発で必ず求められる要件。

じゃあ、複雑にならないようにある単位でまとめようと思うだろう?
その後はまとめた物同士をどう組み合わせるのがいいか考えるようになるだろう?
そこでオブジェクト指向を使うと自然な形でまとめやすくなるんだよ。

わからなければ実際に頭の中で考えてみたらいい。たとえばブラウザを作るってのはどう?
aタグなら〜、ulタグなら〜などと、いきなり詳細なものを考える前に、まずブラウザを構成している要素。
UI部分、HTMLレンダリング部分、JavaScript部分、CSS部分と分けて考えるでしょう?
そこから更に各部分を小さく分けて、それをまた小さく分けてって考えていくでしょう?

この時大抵の人ならデータと処理を分離せずに分けていくと思うから、それがオブジェクトになるんだよ。
オブジェクト指向でなかったら、最後にデータと処理に分けてそれを関連付ける処理まで考えなといけない。
分けるたびに数は増えるから最後は膨大になるよね。それは嫌だから一つ手前のオブジェクトにしておきましょう。
27 :
2014/03/26(水) 22:19:45.69 ID:2aKYqEvM
要は、プログラマが問題解決の為に注目するスコープを、小さくするって事だよな。
28 :
2014/03/26(水) 23:16:50.71 ID:dEVLbQ7F
オブジェクト指向使わないでも ”出来る” とかいうやつがいるけど、
出来るのは出来るんだよ。
重要なのはどれだけ複雑にしないで出来るかということ。
その複雑という観点が抜けてる意見は的外れで参考にならない。

たまに本当にオブジェクト指向じゃなくても複雑にしないで
できることもある。オブジェクト指向よりもシンプルに作れることもある。

それは問題領域が異なるから。上でSQLの話がでていたが
それはRDBMSからのデータ取得という問題だから。
SQLはその問題に特化した言語なのだから得意なのは当然。

でもアプリを作るという問題の場合は、オブジェクト指向が適していることが多い。

例題程度の短い問題で、オブジェクト指向の利点を感じないのも
短い問題だからという理由で説明できるね。
29 :
2014/03/26(水) 23:42:37.18 ID:u5ViS8To
(A) オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
 → 手間が増えるところ
(B) だけどクラス内のプロパティとメソッドの関連付けに対して名前を付ける必要がない
 → 手間が減るところ

普通、ひとつのクラスには複数(多数)のプロパティ、メソッドがあるので、

abs(B) > abs(A)

ということになり、これが「複雑さの低減」という理解で合ってますか?
30 :
2014/03/26(水) 23:52:53.55 ID:u5ViS8To
もしそうだとすると、自分がオブジェクト指向のありがたみが分からないのは

abs(B) = abs(A)

のような、1つのクラスに1つのプロパティと1つのメソッドしかないような
ものばかり作っているのが原因ではないかと思えてきました
31 :
2014/03/26(水) 23:55:51.39 ID:lornT58y
>オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
javascriptみたく、プロトタイプベースのオブジェクト指向あるから、
これは必ずしもオブジェクト指向に当てはまる性質とは違う。
もちろん、名前付けてもいいけど。
32 :
2014/03/26(水) 23:56:29.04 ID:2aKYqEvM
>>30
ちょっと違うな。 そこは大した問題じゃ無いよ。
問題にしてる複雑さっていうのは、どう頑張っても理解できない複雑な構造の事。
33 :
2014/03/27(木) 00:03:01.47 ID:gcsG9K2Q
>>29
少し微妙なところはあるけれど、

>>30
> のような、1つのクラスに1つのプロパティと1つのメソッドしかないような
> ものばかり作っているのが原因ではないかと思えてきました

ということであれば、その程度じゃ理解し難いと思うよw
処理と定義文の行が同じぐらいだろうからね。

普通は一つのクラスに、複数のプロパティとメソッドある。
関数やクラスの定義のための行よりも、処理の行数のほうが圧倒的に多い。

小さな問題なら関数さえ使わなくていい。
数行で終わる単純なスクリプトなら実際にそうする。

多くのプログラミング技術っていうのは、大きくて複雑な問題を
解決するために考えだされているものだから、
簡単な問題を使わなくても出来る というのは意味がなくて
大きな問題で比較しないといけない。
34 :
2014/03/27(木) 00:04:50.94 ID:2gDV9B/K
ICチップの例でいうなら、その中に1個のダイオードしか入っていないものを作っている
ので、ICにする意味がない(なかった)、ということです
35 :
2014/03/27(木) 00:08:07.39 ID:1568NTop
>>29
実際にやって見るのがいいと思う

C#とかなら、書き込みや読み込みを行う抽象クラスであるStreamをとるメソッドに、ファイル、メモリ、ネット、データベースなんかを区別なく渡せたりする
自分でStreamを実装したクラスを作れば、それを利用する側は一切の修正なしに自作のStreamを使える、とか。
36 :
2014/03/27(木) 00:11:02.12 ID:ZCk9J0RA
>>34
そのダイオードがオブジェクトだよ。
ダイオードには入力と出力があってダイオードの仕事をするだろう。
入出力というinterfaceがわかれば、中はブラックボックスでいい。
外から見た時に、中がどんな仕組みなのかは知らなくてもいい。
それがオブジェクト指向だ。
37 :
2014/03/27(木) 00:11:39.64 ID:j3gvVEw0
クラスを作る目的の1つは、ある変数に対してアクセスする関数群を同じクラスにまとめて、
変数自身は極力非公開にして、どこからか勝手にいじられないように隠蔽することだよ。
カプセル化というんだけどね。
38 :
2014/03/27(木) 00:14:40.12 ID:j3gvVEw0
>>36
それは関数も同じでは?
入出力が分かれば、中はブラックボックスでいいよね?

むしろ単機能という点ではダイオードはむしろ関数に近いかと。
39 :
2014/03/27(木) 00:18:11.94 ID:gcsG9K2Q
俺もダイオードは関数だと思わ。

そんな単機能のものではなく、
ダイオードなどを使って作られる製品。
ダイオードなどのパーツを組み合わせて作る製品

その製品を作るために各パーツどうやって組み合わせて効率よく作るか
という方法論としてソフトウェアではオブジェクト指向があると思うよ。
40 :
2014/03/27(木) 00:26:18.85 ID:2gDV9B/K
>>37 そうだとすると、1つのプロパティしかないような場合でもクラスにする価値が
あるということなんだろうけど、勝手にいじられるものが"変数"なのか"関数"なのか
というだけなので、結局同じに思えてしまうなあ
(暴走を引き起こすような)でたらめな値を設定できないようにするということかな?
41 :
2014/03/27(木) 00:28:46.02 ID:ZCk9J0RA
>>38,39
クラス内部もオブジェクト指向で書くんだよ。
だから関数・メソッドもオブジェクトとして捉える。
ICの中にもICが入ってるだろ?
注目するスケールが違うだけで、方法論は変わらない。
42 :
2014/03/27(木) 00:29:16.59 ID:2gDV9B/K
フリップ・フロップならオブジェクトかもしれないね
43 :
2014/03/27(木) 00:32:34.40 ID:gcsG9K2Q
一つのプロパティしかないクラスであっても
アプリ全体で、そのクラスだけしか使ってないってことはまず無い。

小さなクラスしか見てないからわからないのであって
アプリ全体という大きなもので考えよう。

小さなクラスが数個あろうが、このクラスは他のクラスと
協調して動くでしょう? そういうところまで含めて考えないとダメだよ。

小さな視点ではなく、大きな視点を持つこと。
大きな視点を持てば、たまたまプロパティが一つしか
無いクラスがあったとしても、それがシステム全体として
必要なことであればなんら不思議ではない。
44 :
2014/03/27(木) 00:39:43.19 ID:E6f/eeJ0
javaなんかだと標準出力に文字を表示するのにSystem.out.println("Hello World!"); なんてことやってるわけで
ダイオードがstreamの一種ならオブジェクトで問題ない。
仕組みの複雑さが外から見えないという意味で、ダイオードは実に成功していると言えるだろう。
45 :
2014/03/27(木) 00:41:16.91 ID:gcsG9K2Q
オブジェクト指向の話で
クラスとインスタンスの話で
終わっちゃう人がいるけど、

オブジェクト指向の話には
インスタンスとインスタンスを組み合わせて動かすという
構造の話、組み合わせ方の話も含まれるよ。
46 :
2014/03/27(木) 00:42:23.36 ID:gcsG9K2Q
インスタンスとインスタンスを組み合わせだけじゃなくて
クラスとクラスの組み合わせも。
(クラスの代わりにインターフェースだったりもする)

ほんと関数の中身などという小さな部分じゃなくて
全体を見ないとね。
47 :
2014/03/27(木) 00:43:14.26 ID:E6f/eeJ0
ハローワールドでさえオブジェクト指向の真髄に触れてるわけで、
小さいプログラムだからOOPの恩恵が無いなどということはない。
Javaでは十分に抽象化され、簡便に使えるように用意されたライブラリ群を使っているではないか。

でも何でもかんでもオブジェクトにしてしまおうとするのは疑問だな。
48 :
2014/03/27(木) 00:43:29.31 ID:ht0q0Cmu
組み合わせが固定的な場合、一見オブジェクトに見えても単なる構造化にすぎないことが
多い。新しいオブジェクトをくっつけようとして、全部のオブジェクトを書き換えるはめになる。
依存性が多すぎるのだ。究極まで依存性をなくして何でも接続できるようにしたものを、
Inversion of Control (IoC), とか dependency injection (DI) と呼ぶ。テスト環境と本番環境と
で、まったく同じモジュールを動かしてテストできるようになる。が、何もかもIoCやDIにでき
るわけではないので、本当に使えるケースはあまりない。仕掛けが大掛かりすぎて、一行の
SQLやスクリプトに負けてしまうことも多い。
49 :
2014/03/27(木) 00:47:32.14 ID:gcsG9K2Q
IoCやDIを使うところは構造に関する所だと思う。
クラスがアプリの構造を表している所だと思う。

クラス(インスタンス)を値として使う場合
たとえばBigInt型みたいな、int値の巨大版みたいな
"値" にはDIを使わない方がいい。
こういう場合は値として普通にnewした方がいい。
50 :
2014/03/27(木) 00:50:57.11 ID:2gDV9B/K
規模の話が出てきたので、アンケートをとってもよいでしょうか?

1. 作成しているアプリケーションの分野は?
2. アプリケーションの規模について
 2.1 行数
 2.2 関数の個数
 2.3 変数の個数
 2.4 複数のファイルから構成されているならば、そのファイル数

ちなみに俺は
1. テキストフィルタ
2.1 1,000行〜10,000行
2.2 5個〜20個
2.3 10個〜30個
2.4 1ファイル
です
51 :
2014/03/27(木) 01:07:11.24 ID:gcsG9K2Q
>>50
えと、そのコードを客観的に評価してもらったことある?
たとえばコードメトリクスツールで計測するとか。
その評価がないと、それ見てもなんの参考にもならない。

体育会系的に無駄で非効率な努力すれば
行数なんて稼げるしね。

コピペがだめな行為だってのは言うまでもないと思うけど、
コピペをすると簡単に行数稼げるよ。
52 :
2014/03/27(木) 01:17:32.04 ID:gcsG9K2Q
>>50
ちょうど手元に今作っているソフトのカバレッジ結果を
開いていたから書くわ。オープンソースなので詳細は伏せるけど

1. 秘密
2.1 行数 約750行
2.2 関数の数 98個
2.3 変数の数 不明 (計測する意味が無い)
2.4 ファイル数 20個
2.5 クラス 25個
3. コードメトリクス 10点満点中 9.5
4. カバレッジ 90%

ちなみに一番、評価が低い関数だけど行数32行
行数は問題ではなくて、一つの関数にifとループが
多いから(と言っても8個)評価が低くなってる。
53 :
2014/03/27(木) 01:18:19.58 ID:2gDV9B/K
関数や変数は多めに数えたんですが、こういった規模でもオブジェクト指向を活用できるのか
どうかを知りたかったのです。関数はさておき、変数はがんばって捻出しても増やせないと思
います。関数は増やせるかもしれませんが、無理をしそうな気がします。つまり不自然なソー
スになりそうです。
54 :
2014/03/27(木) 01:21:39.80 ID:gcsG9K2Q
>>50
> 2.1 1,000行〜10,000行
> 2.2 5個〜20個

1関数あたり、200行〜500行ってことでいい?

これは多い。コードを把握するために一目で
スクロールしないで見渡せることが重要なので一画面が目安。
だいたい50行〜長くても100行
55 :
2014/03/27(木) 01:23:40.03 ID:gcsG9K2Q
>>53
変数は増やす意味は無い。
それで良いコードになったりも悪いコードになったりもしない。
どちらかと言えば少ない方がいいが、
少なくするほどいいってことでもなく無駄を無くす程度でいい。
56 :
2014/03/27(木) 01:24:04.56 ID:ze0m1e8o
オブジェクト指向はプログラムの問題というより人間の問題に近い。
オブジェクト指向にすれば、人間らしい仕様変更に比較的強いというだけの話。
57 :
2014/03/27(木) 01:26:05.92 ID:2gDV9B/K
>>54 いや、違います。1関数あたり10行位です。残りがメインルーチンです。
58 :
2014/03/27(木) 01:30:04.40 ID:ZCk9J0RA
>>50
1ファイルで10000行は見通し悪くないかねw
俺のは簡単に言うとだが、シンセで80ファイル、各200から1000行程度。
電卓で50ファイル、各100から1500行ってところだな。
長い関数で120行ぐらいだよ。
59 :
2014/03/27(木) 01:31:59.53 ID:1568NTop
ものによるんじゃない?
テキストフィルターがどういうものかわからないけど、変更に強くするとか再利用できるようにするとか

ただ、無理に小分けにしても返って複雑になることもありうる
60 :
2014/03/27(木) 01:32:11.42 ID:gcsG9K2Q
アンチパターン(悪いコートパターン)本に
"メイン"ルーチン という名前がでてきたら
それはアンチパターンだって書いてあった気がするなw

1関数10行?それが5個で
1000行 - 10*5 = メインルーチンが950行?
関数20個でもメインルーチン800行だよね?

一度コード品質計測してみるといいよ。
10点満点中1点未満とか言われるだろうから。
61 :
2014/03/27(木) 01:34:26.69 ID:2gDV9B/K
着目したい変数/関数があったとき、grep するとプログラムの実行順と同じ順序で
表示されて便利です。
62 :
2014/03/27(木) 01:37:53.70 ID:gcsG9K2Q
で、なんでコードの品質の話をしたかだけど、
技術力が低い人は、良いコードとダメなコードの違いがわからないから。

>>50の内容から、君がまだ良いコードがどんなものか
わからないレベルだろうってことがわかるわけ。

だからそのレベルでオブジェクト指向の利点がわからないのも無理はないし、
現時点でオブジェクト指向は意味が無いって結論づけたらダメだよ。
単に君がまだ未熟だから(それははっきりわかった)ってだけだから。
63 :
2014/03/27(木) 01:42:00.90 ID:E6f/eeJ0
>>62
なんでそんなに追い詰められてんの?
64 :
2014/03/27(木) 01:47:38.94 ID:gcsG9K2Q
>>61
プログラムの実行順が気になる?
それは抽象化ができてないから。

長いコードがあって、その順番まで意識しないといけなくなってる。
つまりそのコードは細かい断片で考えることができないということだよ。

変数もスコープが広くなってるね。着目したい変数でgrepしてわかるということは
変数名は長くなっているはず。でないと他の変数名とかぶるはずだからね。で、関数は使われてないと。
(関数が適切に使われていれば同じ"ローカル"変数名が何度も出てくる。同じでいいから名前考える手間省けるよ?)

関数は引数と戻り値があるだけ。それはいつどのタイミングでも使っても良い。
このようになっていれば、全体のことは考えずにその関数という小さな部分で考えることが出来る。

大きなものを大きなまま作るのではなく小さな物にしていく。
そうすれば順番なんて気にすることはないよ。

順番なんて気にしていたら、ユニットテストで関数をテストするときどうするのさ?
ユニットテストではある関数を狙い撃ちでテストするのよ?
65 :
2014/03/27(木) 01:48:13.52 ID:gcsG9K2Q
>>63
なんでそう思ったの?
俺は新人に教育している気分なんだけどw
66 :
2014/03/27(木) 01:48:36.67 ID:E6f/eeJ0
LoCは何かと馬鹿にされがちだけど、
逆にCOCOMO2でとか言われても誰が答えられるってんだっていう。
つか変数や関数の数って何だよ。どうしてそれが気になる。コボラーか?
俺はどれも気にしないし、計測ツールもいれてねえよチクショウ。
67 :
2014/03/27(木) 01:49:47.41 ID:2gDV9B/K
(オブジェクト指向から離れちゃうけど)関数を一画面に収まる規模にして、複数の関数から
構成するようにすると、関数呼び出しが発生することになってしまいます。それが必然性が
ないものだったら、ロジックを追いづらいし、メンテしずらくなってしまうような気がしま
す。大体、関数の名前を考えるのに苦労してしまって、変な名前をつけちゃいそうです。
個人の技術力の問題であれば、しばらくROMってます。
68 :
2014/03/27(木) 01:53:16.02 ID:gcsG9K2Q
LoCは「同じ仕様のアプリを作った時に短いほうが優れているだろう」という
判断には使えるがそれ以外の目的では使えないよ。

LoCが多くてもは生産性が高いことにはならない
(たとえばコピペをすれば簡単に水増しできるが、これは品質を下げる行為)
69 :
2014/03/27(木) 01:55:37.34 ID:zuVXk4tw
Javaは現代のCOBOL
70 :
2014/03/27(木) 02:05:57.47 ID:gcsG9K2Q
>>67
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし

それも俺の中では答えが出てる。

それは関数呼び出しをした時、関数の中まで見ないとロジックが
わからないようなコード(関数)になっているから。

たとえば、printf()という関数、その関数の中まで追ってみないでしょう?
それは関数名さえ見れば、中を追わなくてわかるから。

追わなくてもわかるというのは、脳に記憶できているということ。
関数の仕様がわかりやすいものは記憶できるが
中で何やっているかさっぱりな関数は記憶できない。
そういう関数は複雑ということ。記憶できないような関数を作らない。

大きなアプリを作るとき、コードをいちいち読んでいたらいくら時間があっても足りない。
だから読む時間を記憶することで圧縮する。とはいっても複雑なものは記憶できないし、
数が多くても記憶できない。俺は記憶術の天才じゃないのでね。

だから、関数はできるだけ単純な機能にする。複雑で高機能なものをたくさん作るよりも
(たくさん作ると名前をつけるのに困るし)
単純なものを少数作って、それを組み合わせるほうが覚えることが少ない。
中を見ないとわからないような関数は作らない。そういうのはだめな関数。
(オブジェクト指向にする理由としてオブジェクトという単位でグループ分けしておけば、覚えやすいというのもある)

そうやって読むべき所を減らしていけばいいんだよ。関数の中を見なくて済むような
そんな関数にしていけば、関数呼び出しが発生してもロジックは追える。見なくて言い分早く追える。
71 :
2014/03/27(木) 07:13:03.30 ID:EL0PowgV
オブジェクト指向のこころは良い本だ
72 :
デフォルトの名無しさん
2014/03/27(木) 07:26:53.08 ID:6dxUJoHd
「オブジェクト」が参照なのって割と不便だよね。
73 :
2014/03/27(木) 10:03:27.48 ID:E6f/eeJ0
関数型プログラミング的に言うと、
副作用(内部情報を持つ、外部デバイスにアクセスする等)のある関数は
プログラムを複雑にする悪玉菌扱いなんだけどね。
かといって純粋関数だけでプログラムかけるかっていう現実問題はあるけど。
しかし問題の切り分け方として、データと処理がセットになることが必ずしも礼賛されるかというとそうでもない。
74 :
2014/03/27(木) 11:42:05.43 ID:pwhdAG7g
>>70
実際にはprintf()の中身は複雑なんですけどね。
https://www.sourceware.org/cgi-bin/cvsweb.cgi/libc/stdio/Attic/vfprintf.c?rev=1.30&content-type=text/x-cvsweb-markup&cvsroot=glibc
75 :
2014/03/27(木) 12:26:13.49 ID:rDeXrVt7
もっとも身近なオブジェクト指向の概念って、
ファイルやソケットのディスクリプタかな
説明もしやすいし理解も早い
76 :
2014/03/27(木) 12:52:47.48 ID:Q+RTv4Ce
ファイラー上で見るファイルオブジェクト
あれのポップアップメニューが変化するのを見せるのがよさそう
77 :
2014/03/27(木) 15:10:04.52 ID:qIhM9I6N
>>75
俺はStringクラスだと思うね。
この例を出すとどうも必ず叩かれるんだけどw

前提として長さをprivateで持ってる実装を考える(例えばjava.lang.Stringね)。
それを、連続したchar領域などと比較する。

strlenしないと長さが得られないのが後者で、
内部に既に長さを持ってるのが前者。

文字列データと、長さ、っていう非常に近い関係のものが、
内部に一緒に揃ってる。
一緒にあったほうがマシだから、一緒にある。
クラスの内側にそれを隠し持ってる。
そして、いろんなメソッドの内部でふんだんに参照してる。
78 :
2014/03/27(木) 15:29:20.56 ID:zuVXk4tw
strlenしないと長さが得られないのか、最初から長さを持ってるのか、
中身がどういう仕掛けになってるのか気にしなくていいのがオブジェクト指向なんじゃないの?
79 :
2014/03/27(木) 15:29:34.54 ID:Q+RTv4Ce
昔はそう思ったこともあるが実装とI/Fがあまりにも近すぎてよくない
80 :
デフォルトの名無しさん
2014/03/27(木) 16:23:36.30 ID:R9FKO6iJ
JavaのStringだと、lengthはフィールドじゃなくてメソッドでは?
内部で保持してるのかどうかは知らんが
81 :
2014/03/27(木) 19:09:37.68 ID:+xc3TnzN
>ファイルやソケットのディスクリプタかな
ハンドル持ち回りはCによる実装レベルでも十分確立されてるし
OO言語じゃないと実装がとても大変って例はないもんかね
82 :
2014/03/27(木) 20:16:21.85 ID:rDeXrVt7
>>77
オブジェクト指向の真髄はポリモーフィズムだと思ってるので
>>77の考え方に反逆するわ
83 :
2014/03/27(木) 20:31:07.44 ID:gcsG9K2Q
>>74
> 実際にはprintf()の中身は複雑なんですけどね。
いや、知ってるってw

複雑だけど、関数にすることで、
”中を見なくて良くなっている"

これがいい関数の例。

中を見ないと、どんなことやってるかわからないよ〜。
となってるのが、悪い関数の例。
84 :
2014/03/27(木) 21:26:09.20 ID:ZhR8Azo0
C++のストリーム演算子らへんは何をやってるのかさっぱり判らない悪い例じゃないの
85 :
2014/03/27(木) 21:34:12.95 ID:gcsG9K2Q
>>84
何をやってるのかさっぱりわからないのは、
ストリーム演算子の中身の話であって、

そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう?

関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。(関数名は例ではない)

function process() {
 initialize();
 calc_price();
 save_data()
}
86 :
2014/03/27(木) 21:55:08.72 ID:ZhR8Azo0
>>85
お話が通じないことが良く判ったよ
俺流オペレータが何をやってるのかは中を見なと判らないでしょ
だからストリーム演算子の例を出したのに「使う人は使える」

>(関数名は例ではない)
ちゃんとした関数名にすれば中身見る必要無いだろ
87 :
2014/03/27(木) 22:02:47.00 ID:ZhR8Azo0
printfも可変引数の仕組みと書式の関係が判ってようやく
初めて使えるレベルになるものだと思うけどな
それって結局中身見ないとまともに使えないでござるよ…って事にならないかね?
まさかこんなスレでprintfの中身を一度も見たことない奴なんていないだろうから
きっと錯覚してるだけだよ
88 :
2014/03/27(木) 22:06:56.92 ID:+xc3TnzN
そういう意味だと上のハンドル志向が一番解りやすい
中を見たいとも思わないし
89 :
2014/03/27(木) 22:09:08.87 ID:UpPNmNS/
誰かJava8のStreamの話をしてくれ。
90 :
2014/03/27(木) 22:12:33.90 ID:ZhR8Azo0
かなりprintf族もハンドル取るのあるだろ
いやそういうことではなくて、関数名だけでちゃんと表現できてれば中身見る必要なんてないんだよ
結局いくら関数化しても中身見ないといけないようなケースは必ず存在するんだよ
91 :
2014/03/27(木) 22:18:02.77 ID:GOaviY18
今言う中身は実装じゃね?
実装を知らなくても使い方が分かればいいと
例は良くわかんない
92 :
2014/03/27(木) 22:26:01.90 ID:ZhR8Azo0
実装を知らなくても使い方を想像できるってのは
裏返せば過去に自分が似たような物を作ったり設計書見たりとか
それなりの経験のある中の事じゃないの?
実装がさっぱり想像できないのをいくら眺めたところで
使い方が判るようになるとはとても思えないけど
93 :
2014/03/27(木) 22:27:02.26 ID:1568NTop
コメントとか仕様書とかに使い方が書いてあれば実装を見なくても済む
printfのすべての実装なんて見たことないけど、仕様書どうりの動作をするとわかっている
94 :
2014/03/27(木) 22:36:29.59 ID:GOaviY18
想像して使うってのはよく分からないけどsleep()とかsystem()はそれに近いかも?
使い方を知って、かつそれが曖昧になっても関数名や引数で思い出せるってところが分かり易さじゃない?
逆に見ても分からないってのは設計として複雑な気が
std::coutでいえば<<なら直感的だけど>>だと途端に恐怖を覚える
95 :
2014/03/27(木) 22:41:51.63 ID:zuVXk4tw
GoogleのC++スタイルガイドではストリームはやめろprintf使っとけって事になってるな。
96 :
2014/03/27(木) 23:09:47.29 ID:1568NTop
他の言語に全く採用されないところをみるに、たんに演算子いじれてすごいでしょアピールで実利はなかったんだったんだろう
97 :
2014/03/27(木) 23:29:08.64 ID:ZhR8Azo0
可変引数は呼び出し側自己申告以外にチェック機能が無いからバグの温床になりやすく
標準ライブラリからは除外したかったと昔どっかで読んだよ
正規表現みたいに書式と引数の型から判定するような仕組みは作れたはずだけど
それを言語仕様に含めてしまうと1関数でしかなかったprintfの書式文字列を
今更特別扱いするのは抵抗がとか紆余曲折あって全く別の方向に逃げた
98 :
2014/03/27(木) 23:34:55.71 ID:1568NTop
コンパイラが警告してくれるけどね
99 :
2014/03/27(木) 23:55:40.61 ID:gcsG9K2Q
>>86
> 俺流オペレータが何をやってるのかは中を見なと判らないでしょ
いつオペレータの話したの?

ストリーム演算子の話だったよね?
100 :
2014/03/27(木) 23:59:54.87 ID:zuVXk4tw
俺流オペレータの代表格だわな
101 :
2014/03/28(金) 00:09:53.54 ID:9wj0hHB8
代表格 = 同じではないという意味。
102 :
2014/03/28(金) 00:14:00.53 ID:Ek64RinZ
そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう?

関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。(関数名は例ではない)

function process() {
 initialize();
 calc_price();
 save_data()
}

定義済みのストリーム演算子は覚えればいいから、中を見ないでわかる。
俺俺オペレータで中を見ないとロジックを追えないようなものは
上に書いてあるのと同じ問題がある。

関数がダメなんじゃなくて使い方の問題。
オペレータもそれ自体がダメなんじゃなくて、使い方の問題。
中を見ないとロジック追えないような関数(オペレータも)はダメな関数。

話はこれと何も変わっとらん。反論にはなっていない。むしろ俺と同じことを言ってるだけ。
103 :
2014/03/28(金) 00:37:59.39 ID:MtUKbk72
例えばさ、AppleとかMicroSoftのAPIは実装非公開だし、実装知らなくても使ってますよみんな。

つか、中身はブラックボックスでいいって表現に語弊があるのかな。
全体の構造を見てるときは個々の中身は気にしなくてもいい、
個々の中身を検討してるときは他のオブジェクトは気にしなくてもいいって意味だよ。
スコープを小さくすればわかりやすいよねってこと。
104 :
2014/03/28(金) 00:40:38.80 ID:Ek64RinZ
そういうこと。全体の構造を見ている時に
個々の中身を気にしなくちゃいけないコードを書いているから

>>67 みたいに
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし

関数呼び出しでロジックが追いづらくなっちゃうわけ。
それは関数の作り方が悪いせいであって関数のせいじゃないんだよ。
105 :
2014/03/28(金) 00:53:28.66 ID:jDIkKEXq
本来シフト演算子なはずの << やら >> を入出力に使うっていうのが、
演算子オーバーロードの悪い使い方(=俺流オペレータ)の代表格だっていう話では。
106 :
2014/03/28(金) 01:15:21.16 ID:DmpYV1MJ
(構造化プログラミングのスレかな?)
107 :
2014/03/28(金) 01:52:09.43 ID:wFHfzfhB
(ここまでオブジェクト指向の活用方法の具体例なし)
108 :
2014/03/28(金) 01:54:17.33 ID:Ek64RinZ
>>105
話ずれてるなぁ。

良い関数と悪い関数の違いの話だよ?
自分で勝手に作った関数でその中を見ないと
呼び出し元が何やってるかわからないのがダメって話。

ストリーム演算子は普通に記憶してるじゃんか。
中見ないでしょ?
109 :
2014/03/28(金) 02:34:08.23 ID:uMoDJ17A
具体例ならエロい人のソースを覗き見…
ぐへへ
110 :
2014/03/28(金) 11:21:32.67 ID:Vf+Kze9a
>>102
> function process() {
>  initialize();
>  calc_price();
>  save_data()
> }

その三つの関数は、再利用もしないし、他からも呼ばれないんじゃないの?
だったら、中身を見る必要ないよね。
中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
111 :
2014/03/28(金) 18:36:40.74 ID:Ek64RinZ
> 中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
ほら中見てるじゃんw
112 :
2014/03/28(金) 18:44:51.50 ID:VVPQgbpw
中身を見なくていい = 機能もバグ取りもドキュメントも完成してるってことだから
今自分または開発チームが手がけてる関数は全て悪い関数ということになる。
113 :
2014/03/28(金) 18:50:33.65 ID:QLpZv79z
>>112そうとは言い切れないよ。

関数の仕様がシンプルで覚えやすければいい。
覚えるには何度も使うことが必須で
結果的に汎用性が高い(だから何度も使える)ものってことになる。
114 :
2014/03/28(金) 18:58:13.19 ID:Vf+Kze9a
>>111
> ほら中見てるじゃんw
見ないとロジック追えないだろ。

どんな関数でもメソッドでも同じ。
バグフィックスか仕様変更が必要なら、どんな場合でもそのコードを見る必要がある。

このことと、その関数の良し悪しは関係無い。
115 :
2014/03/28(金) 19:03:06.04 ID:QLpZv79z
>>114
> > ほら中見てるじゃんw
> 見ないとロジック追えないだろ。

君は少し勘違いしてるね。

上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないって話だよ。


> function process() {
>  initialize();
>  calc_price();
>  save_data()
> }

上位関数 = processのロジックを追う時に
下位関数 = initializeやcalc_priceやsave_data の
ロジックを追わないと上位関数が何をしているのかわからない。

function process(name) {
  printf("hello " + name);
}

でもこの場合は上位関数(process)のロジックを追っている時に
下位関数(printf)のロジックは追わない。
116 :
2014/03/28(金) 19:05:59.21 ID:QLpZv79z
上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないような
コードになってるから、

コードを解析するときに、関数があるたびに
下位関数の実装先にあっちこっちジャンプしていって大変なことになる。
117 :
2014/03/28(金) 19:20:17.16 ID:QLpZv79z
ここから発展して、
privateメソッドが、privateメソッドを読んでいて
そのprivateメソッドが、更にprivateメソッドを読んでいて
更にそのprivateメソッドが、privateメソッドを・・・みたいに
(再帰ではなく)文法上のコールスタックが深いものも
ダメな関数の一例だろうね。

なぜなら、privateメソッドは通常汎用的ではない。
汎用的なものに比べたら使われる回数が少ない。
こんなものは覚えられないし、覚える必要もない。

だから上位関数のロジックを追ってる時に
下位関数のロジックを追うことになる。
118 :
2014/03/28(金) 20:50:21.98 ID:VVPQgbpw
>>116からの>>117は誤解を生むだろう。
関数への切り分けが適切であれば、利用している関数内で何してようが関係ない。
そうでないから、切り分けがまずいから結果としてサブのサブまで降りていかないといけないというのはわかるが、
構造としてサブのサブを呼び出すことが悪というのは真ではない。
119 :
2014/03/29(土) 01:06:59.37 ID:YRxS2933
オブジェクト指向は1990年代の話題
当時は実装メモリも少なかったので、コンパイルサイズの上限に達しないように
コンパイル単位となるファイルや関数を小さくしなければならなかった。また
CPUの性能も低かったので、コンパイル単位を小さくすることで再makeにかかる
時間を節約していた。そうでなければとてもじゃないが、実務では使えなかった。
現代では分かりやすさを犠牲にしてまで、小さい関数を量産する必要はなくなっ
ている。
以上、教科書に載らないオブジェクト指向の歴史
120 :
2014/03/29(土) 01:21:57.46 ID:3OHlSsnI
>>29
名付けを手間と思ってる時点で…
そういうやつに限ってコメントはダラダラズラズラ書く

そのコメントへの労力をまるごとメソッド名なり変数名なりの名付けに当てれば問題ない
121 :
2014/03/29(土) 01:27:50.25 ID:3OHlSsnI
>>57
鳥肌立った
122 :
2014/03/29(土) 01:30:44.27 ID:3OHlSsnI
>>67
ずっと読んでて思ったけど、もしかしてこの人がstaticおじさん?
123 :
2014/03/29(土) 01:39:31.14 ID:3OHlSsnI
ようやくスレ全部読んだが、ポリモーフィズムとか委譲とかDIとかやってて、そういう話をしてるもんだと思って覗いたから
なんか逆に新鮮な気持ちになったぜ

俺が恵まれてるだけなんだろうが、50行を超える関数には出会ったことがない
自分でも書いたことがない
124 :
2014/03/29(土) 01:45:14.49 ID:2x5p0G/E
50行を超える関数ぐらい出会うだろ?
オープンソースのコード読んだことある?
125 :
2014/03/29(土) 08:53:28.56 ID:VG1PVttb
オブジェクト指向で作られたライブラリを手続きの中で利用するのがベスト。
自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。
オブジェクト指向は基盤レイヤーで収まっていればいい。
より上のレイヤーは構造化プログラミングとモジュール化で対応すべきだ。
126 :
2014/03/29(土) 10:41:15.74 ID:FZRsbrVI
>>125
>自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。

ならプログラマーなんかやめたほうがいい。適性なし。
127 :
2014/03/29(土) 13:47:53.85 ID:qOhcuGD/
言いたい事はわかる。きれいに階層化されたツリー構造の方が処理を追いやすい。
しかし、どうしてもオブジェクトグラフがネットワーク状になる場合があるし、
ユーザーがオブジェクトどうしを自由に接続できるアプリだってある。
128 :
2014/03/29(土) 14:12:25.86 ID:riFdWRlf
プログラマ適性なしは言い過ぎ
最近は非オブジェクト指向の言語も注目されてきてるよね
129 :
2014/03/29(土) 15:10:59.76 ID:T0jzXlJE
関数型の次はなんだ?
130 :
2014/03/29(土) 17:53:31.03 ID:nUN7khDD
OOだろうが非OOだろうが、
粒度の小さなデータ構造でネットワークを形成することを
「複雑にする」と思う時点でプログラミングに向いていない。
131 :
2014/03/29(土) 18:15:38.16 ID:VG1PVttb
メインルーチンでまとめて管理すればいいものを、
処理とデータをセットにすることに拘った挙句、
メディエータパターンなんてマヌケな再発明を強いられるOOPに哀愁を禁じえない。
132 :
2014/03/29(土) 18:26:03.80 ID:qOhcuGD/
巨大なメインルーチンねえ。描画とかどうすんのかな。
133 :
2014/03/29(土) 18:36:10.02 ID:VG1PVttb
描画はイベントドリブンか、メインループの中で描画オブジェクトの配列を作るわ。
134 :
2014/03/29(土) 19:00:43.30 ID:nUN7khDD
>>131
あんたも適性ないね
135 :
2014/03/29(土) 19:40:22.20 ID:VG1PVttb
しかたない。SEにでも転職するか。
136 :
2014/03/29(土) 20:02:51.62 ID:riFdWRlf
適性とかそういう話じゃないなコレ、教育不足に経験不足だ
137 :
2014/03/30(日) 02:19:44.18 ID:3Fl9YNZ5
数珠つなぎのメソッドチェーンを呼び出して何をするのかと思ったら、単に変数
に値を代入(または取得)して終わり、みたいのをよく見かけます。途中に現れる
メソッド名を見ても必然性を感じません。その階層で何をするでもないのです。
そういう場合はただの変数の代入に書き換えます。
(ついでなので)変数の名前はその目的が分かる名前に直します。

まるでオブジェクト指向の本質は多重のメソッド呼び出しだ、と言わんばかりな
のです。自分はそんなことより、単なる変数・関数であったとしても命名を重視
したいです。

規模の大きいソフトウェアの場合、名前をグルーピングして、階層を持たせて命
名することに異論はありません。でもそもそもそんなに大きいソフトウェアを
作っているわけではないんです。

世界にひとつだけの名前にして衝突を未然に防ぎたい、ということでしょうか?
138 :
2014/03/30(日) 02:26:07.76 ID:3Fl9YNZ5
同じことがメソッド呼び出しにも言えます。チェーンしているメソッドがそれぞ
れ何を意味しているのか分かりづらい上、記述の順序と実行の順序が異なるので
す。

例えば文章において、姓名は「姓」と「名」を近くに記述することで「姓名」と
なって、ひとりの人を表わすことができます。日付の「年」「月」「日」も電話
番号の「市外局番」「市内局番」「加入者番号」も同様です。これらをばらばら
に離して記述すると読み解くのに苦労することでしょう。

記述の順序が実行の順序と一致しないというのは、そういう状況に似ています。
ソースプログラムがまるでなぞなぞのようになってしまうのです。

実行順序が隣り合っているものは隣り合わせて記述すると分かりやすいプログラ
ムになります。修正も簡単です。テキストエディタやgrepが強力なプログラミン
グツールになります。
139 :
2014/03/30(日) 02:40:59.19 ID:xYPcFXGk
>>137,138
オブジェクト指向の必要性とは、規模とか複雑さとか再利用性の問題だから、
当てはまらなければ気にしなくてもいいんだよ。
140 :
2014/03/30(日) 02:59:11.38 ID:WoVbd8CL
>>137-138
あなた、オブジェクト指向の話をしてないですよ。
141 :
2014/03/30(日) 03:06:19.07 ID:f3QUPmmN
メソッドチェーンが何かを知らない人に説明しておくと、

value を foo関数で加工して、bar関数で加工して、baz関数で加工するという、
シェルスクリプトで言えば
cat var | foo | bar | baz というのを

baz(bar(foo(value))) という逆順で書くのではなく、
value.foo().bar().baz() という風に
処理の順番の通りにかけるようにした方法です。

ただそれだけのことです。
どちらがわかりやすいかは言うまでもありませんね。
142 :
2014/03/30(日) 03:10:55.68 ID:DA7dDHvX
メソッドチェーンだと書いている順番に
処理が実行されるからわかりやすいんだよな。
オブジェクト指向だと、メソッド名短くても
かぶらないからその点でもメリットがある。
143 :
2014/03/30(日) 03:11:55.59 ID:F8tYL6fO
なあんだ!どっちの目を使うかなんだね!
144 :
2014/03/30(日) 03:28:36.95 ID:DA7dDHvX
> baz(bar(foo(value))) という逆順で書くのではなく、
これって引数無いからまだわかりやすいけど、
引数あると見にくいんだよね。

baz(bar(foo(value, 1, 2), true), "test");

呼び出しが深くなるにつれて、bazと"test"みたいに距離がどんどん離れちゃう。


これがメソッドチェーンだと
value.foo(1,2).bar(true).baz("test");
このように関数と引数が近くに集まる。
145 :
2014/03/30(日) 03:30:32.83 ID:DA7dDHvX
これもオブジェクト指向の活用方法の一つだろうね。
146 :
2014/03/30(日) 03:34:47.32 ID:eSXxjJTc
だらだら連ねて1文に詰め込むのはデバッガで追いにくくなるからあまり好きじゃない。
147 :
2014/03/30(日) 11:13:41.29 ID:CUSBQvN9
>>139
>オブジェクト指向の必要性とは、規模とか複雑さとか再利用性の問題だから、

はずれ。
148 :
2014/03/30(日) 11:13:50.33 ID:Ep1/Keko
返り値をチェックして独自のエラーログを出したいw
149 :
2014/03/30(日) 11:14:24.92 ID:CUSBQvN9
>>146
どんなオンボロデバッガ使ってんだ?
150 :
2014/03/30(日) 11:52:19.72 ID:DA7dDHvX
>>146
つまり、

baz(bar(foo(value, 1, 2), true), "test");

こういうのを

v = foo(value, 1, 2);
v = bar(v, true);
v = baz(v, "test");

って書くってこと?

おっと、メソッドチェーンとは関係ない話だったから
関数の方でレスしちゃったw
151 :
2014/03/30(日) 11:57:24.64 ID:IecYjjCX
>>149
> value.foo().bar().baz()

bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ
152 :
2014/03/30(日) 12:01:26.08 ID:DA7dDHvX
訂正(笑)

> baz(bar(foo(value, 1, 2), true), "test");

bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ
153 :
2014/03/30(日) 12:07:13.82 ID:DA7dDHvX
メソッドチェーンならこれが使える。

メソッドチェーンの p デバッグ? それ tap でできるよAdd Starasakichy
http://d.hatena.ne.jp/mas-higa/20100805/1281018189

function p(obj) { print obj }
value.foo(1,2).bar(true).tap(p).("test");


まあ関数でも使えるよ。見難くなるけどねw
baz(p(bar(foo(value, 1, 2), true)), "test");
154 :
2014/03/30(日) 12:32:55.33 ID:rCEPh8in
難しいことをしようとすれば、何を使っても複雑になる。
言語やパラダイムが複雑なんじゃなくて、解決しようとしている問題が複雑なだけなんだ。
155 :
2014/03/30(日) 12:47:55.23 ID:DA7dDHvX
えと、ああ、うん、
言語の違いっていうのは、問題がどうとかじゃなくて
読みやすさと書きやすさの違いの話なんだけどね。
156 :
2014/03/30(日) 13:17:38.07 ID:CUSBQvN9
>>151
え?そんな簡単なこともできない開発環境でオブジェクト指向とか大笑いだな
157 :
2014/03/30(日) 13:27:57.55 ID:3Fl9YNZ5
>>141
>シェルスクリプトで言えば
>cat var | foo | bar | baz というのを
このとき、foo や bar が何もしないプログラムであっても baz の前に入れることに
意味はありますか?関数型で組む場合は、何もしない関数 foo(), bar() を挟み込む
発想になったことがありません。必要になったとき、何かをしたくなったとき、その
ときに追加しています。
158 :
2014/03/30(日) 13:31:27.59 ID:amVAfrHC
>>102
思うことは二つある。

1) 結局中身って見なくてもよくね?
どんな糞名前、糞用途でもAPIとして資料があって

 int aaaaaaaaabbbbbbbbbbb(int x, int y)
 x + yが素数のとき0を返し、それ以外のときyを返します。

となっていれば、中身は見なくてよくね?
実装なんてどーでもいいし想像したくもない。

2) 用途と名前が優れていればなおよし
シンプルな名前で表現されていれば、
APIリファレンスを紐解くことすら不要。
bool isprime(int x)ならこれだけで十分。
159 :
2014/03/30(日) 13:35:22.35 ID:qbWQb+53
継承とインターフェイスだけで十分便利
160 :
2014/03/30(日) 14:01:44.17 ID:qe+yThv9
>>157
たぶんお前の説明が下手くそだと思うんだが、いかなる場合も何もすることがない関数なんて言語問わず存在意義あるわけないじゃん
メソッドチェーン関係なく単に修正ミスとかだろ

もしくは、お前が知らないだけで何かの意味があるんだよ
よくみるなら具体例出してみろ
161 :
2014/03/30(日) 14:29:06.62 ID:rCEPh8in
With...End With ステートメント (Visual Basic)
http://msdn.microsoft.com/ja-jp/library/wc500chb.aspx

メソッドチェーンなんていらない。
言語側でwithステートメントを用意すれば済む話。
162 :
2014/03/30(日) 14:30:58.29 ID:DA7dDHvX
それでどうやって一行で書くの?
163 :
2014/03/30(日) 14:44:34.88 ID:rCEPh8in
かりにメソッドチェーンという糖衣構文があるからといって実際に使う時は
object.func1(arg1, arg2, arg3)
    .func2(arg1, arg2, arg3)
    .func3(arg1, arg2, arg3)
    ...
    .funcN(arg1, arg2, arg3);

って書くわけで、別にワンライナーしたいとかいう話ではないはず。
一つのオブジェクトに対して連続的にメソッドを呼び出す場合に、
それが手続きや意味ある関連として成立しないならまぎらわしいからやめろっていうのが
>>137-138の主張じゃないの。
164 :
2014/03/30(日) 14:58:29.04 ID:DA7dDHvX
メソッドチェーンまで糖衣構文かよw
これのどこが構文なんだ?
ライブラリの仕様だろ。
165 :
2014/03/30(日) 15:11:02.31 ID:qe+yThv9
Withは見にくいからやめろという主張をよく聞くが

メソッドチェーンの利点はメソッドで加工を行ってそれを別のメソッドに引き渡せるっていうこと
同じオブジェクトにたいして関連したメソッドをいくつも呼ぶ時も行を分けたりとかしなくて済むから見やすい
166 :
2014/03/30(日) 15:11:12.60 ID:yCsw+RdE
>>163
糖衣?…構文??
167 :
2014/03/30(日) 15:17:34.92 ID:rCEPh8in
>>165
withが見にくくてメソッドチェーンが見やすいってのも変な話だな。
記述に大差ないのに。
168 :
2014/03/30(日) 15:39:47.59 ID:J3oHNw57
みんな、見やすいかどうかは
文字列の長さや行数で変わるってことを
理解してないよ。

たとえばこの二つ。

var newValue = value.fooFooFooFooFooFoo().barBarBarBarBarBar().bazBazBazBazBaz();

var newValue = value.foo().bar().baz();

単に文字列の長さが違うだけでやってることは全く一緒。
だけど上の方は見難くて下の方は見難くはない。

つまりどういうコードが見やすいかどうかは、単に文字列の長さだけでも変わってくるということ
だから文字列が長くなる場合にメソッドチェーンで一行にすることは不適切。
逆に言えば、文字列が短い場合に有効なのがメソッドチェーンというわけ。

withが見やすいのは、文字列が長くなった場合の話で
短いならばメソッドチェーンの方が見やすい。

どちらが、どんな場合でも見やすいなんてことにはならないんだよ。
169 :
2014/03/30(日) 15:47:45.96 ID:rCEPh8in
短かろうと一行にするのはよくないと思うな。
オブジェクトが無い場合に

foo(); bar(); baz();

なんて書けるけど、実際はたとえ関連があっても横に連ねては書かないし。
メソッドチェーンにしたって
graphics.clearRect(0,0,640,480).drawRect(100,100,50,50).drawCircle(50,50,100)...
なんて横には書かなくね。
170 :
2014/03/30(日) 15:49:43.00 ID:J3oHNw57
> foo(); bar(); baz();
>
> なんて書けるけど

書けないよ。

baz(bar(foo()));

こうだろ
171 :
2014/03/30(日) 15:53:47.22 ID:rCEPh8in
>>170
今の話の流れにおけるメソッドチェーンでは
自身のインスタンスをreturnするから、
その例のような意味でつなげてるのでは無いよ。
172 :
2014/03/30(日) 15:58:50.57 ID:J3oHNw57
>>170
インスタンスに対して操作をするんだろう?

じゃあ、何らかの引数がなければ、
同じ意味にならないじゃないか。
173 :
2014/03/30(日) 16:33:15.45 ID:IecYjjCX
>>156
で、具体的なデバッガの名前とやり方は?
174 :
2014/03/30(日) 17:17:26.79 ID:CUSBQvN9
>>160
関数型言語ではid関数は重宝するぞ
175 :
2014/03/30(日) 17:34:15.13 ID:qe+yThv9
>>169
複数の文を一行で書くのはなんか嫌だけど、メソッドチェーンなら気にならないな
ifの後ろとかにつけていたい目を見そうだからかな

しかし、メソッドチェーンもやっぱりAndroidみたいに何十行にも渡るのは読みかにくいからせいぜい数行が限度だとは思う

逆に数文字の命令が何十行にも渡って書かれる光景はイライラする

>>174
関数型言語はわからんが、重宝するならなんか意味があるんだろ?
176 :
2014/03/30(日) 18:01:52.30 ID:3Fl9YNZ5
>>160 具体例は公開できないので申し訳ない
その1. メソッド名が訳の分かる名前ならば、その中身を心配して見にいく必要はない
   ⇒ これはレスや参考図書がよく使う 'foo' だの 'bar' だののレベルの名前を開発
    しているプログラムに使っていることが問題なのだと思う
その2. 場合によっては改名するつもりで中身を見にいくと、なんでこれを括りだしたの?
   という疑問が発生(もとから括り出す必要はなくて、名前も要らないんじゃないの?)
   ⇒ メソッドの中身をメインルーチンにコピペして解決!!
オブジェクト指向の話がいつの間にかコピペの話に...

オブジェクト指向って、どんな場合に役に立つのか、また活用方法を知りたい
のです
あるいはオブジェクト指向があるから常に使わなければならない、という考えは
間違いで、使うか使わないかは便利か便利じゃないか、解決しようとしている
問題や環境・状況に合わせて、判断すればいいものなのか?
そのとき、判断材料には本人や周りのひとのスキルを含めなくていいのか?
人のスキルに関係なく、いつでも・絶対にオブジェクト指向が有利なのか?
メソッド呼びさえしていればオブジェクト指向なので後ろ指さされることは
ないものなのか?
177 :
2014/03/30(日) 19:02:38.40 ID:qe+yThv9
>>176
なんだ、昨日の続きならそうかけよ

当然、 fooとbarとかの名前なら書いたやつが無能なだけ。
jQueryとかrubyみたいにわかりやすい名前がいい
中身はどこかでまたつかうとか、メソッドチェーンでシンプルに書けるなら有用かもしれない


オブジェクト指向は完璧ではないし、スキルがない人ならやらなくてもいいんじゃない?
ただし、C#とかJavaみたいにオブジェクト指向ありきで設計された言語はやっぱり知識は必要
標準ライブラリ自体オブジェクト指向専用だからね
C#でStreamではなくFileStreamしか受けないメソッドとかを作ってしまったら不便だし、不要なフィールドを公開したら危険だ
178 :
2014/03/30(日) 22:50:01.50 ID:rCEPh8in
>>176
オブジェクト指向を使うと、同じものを2つ以上同時に扱うのが簡単なんだよね。
2つのファイルを同時に編集するとか
ぷよぷよの画面を2つならべてみるとか
5人のボンバーマンが同時に動くとかさ。
179 :
2014/04/01(火) 20:30:56.47 ID:c88mFqYR
>>173
スモールトーク系のデバッガーはメソッドチェーンのそれぞれのメソッド呼び出しごとにステップ実行できるらしいよ
180 :
2014/04/01(火) 21:54:52.60 ID:WgoYILFU
>>179
具体的な名前書けっつーてるのに...
結局 ID:CUSBQvN9 は口先番長かよ (w
181 :
2014/04/02(水) 21:15:51.80 ID:R40jOAQ7
性能低下を防ぐためにメソッドの内容をメインルーチンに直に展開する作業は、
処理系にまかせることもできるだろうが、それによって多態性は失われる。
それよりもソフトウェアを細かく分割して構成する以上、バージョンの依存
関係が複雑に絡み合うほうが問題として大きい。
182 :
2014/04/02(水) 21:49:26.89 ID:YdJBhj/R
>>180
スモールトークっていったらスクイークとかじゃないの?
口先番長認定するまえに自分で調べてみたの?
口の中にご飯をスプーンで入れてもらうまで
馬鹿みたいに口開けて上を向いているタイプの人なの?
183 :
2014/04/02(水) 22:04:27.79 ID:UHLZ3L7X
>>182
で、そのスクイークとやらは、ブレークかけられんのか?
当然調べたんだよな (w
184 :
2014/04/03(木) 00:45:59.14 ID:OChVK7bs
>>4
ポリモーフィズムはリリースされたプログラムをユーザーが部分的に更新しな
がら使う(ライブラリやDLLを更新する)と、プログラマが当初考えていた以上
の使われ方をして、動作の保証ができなくなる、ってことにならないの?
昔でいうgoto文や、メモリーリークを起こしがちなC言語のポインタみたいに
やっかいなことにならないの?
185 :
2014/04/03(木) 00:59:50.75 ID:p51daBHj
動作の保証ができなくなるようなことを許すのは単なる欠陥でしょ
186 :
2014/04/03(木) 02:22:36.23 ID:Dr19mwRL
メソッドごとにコメントアウトすればいいよ
てかメソッドチェーンとしてのチェックってあるかね
187 :
2014/04/03(木) 04:56:35.67 ID:4OpITLe5
>>183
できないと思ってるの?
188 :
2014/04/03(木) 07:32:45.27 ID:7TERZTkc
>>187
できるんなら、その方法書いてくれ。
189 :
2014/04/03(木) 08:26:44.88 ID:oN99KWq6
いい加減に認めろよ……

そもそも仮に「メソッドチェーンはデバッグできない」としても、それは「オブジェクト指向」を否定するのに大事な要素でもないじゃん
何かこだわりでもあるの?
190 :
2014/04/03(木) 08:48:37.07 ID:syg3Ul2m
>>189
> いい加減に認めろよ……

何を認めるんだ?
ブレーク掛けられるなら >>151
が情弱と言うことだし、かけられないなら >>156 が口先番長と言うだけのことだろ。
どこから、オブジェクト指向の否定が出てきたんだよ (w
191 :
2014/04/03(木) 15:05:44.04 ID:v6ez+Y0x
>>188
ちゃんとしたSmalltalk処理系では(つまりGNU Smalltalkとかの変わり種を除けば)一般に
value foo halt bar baz で、bar のコール直前でデバッガを起動させて bar のステップ実行ができる
ってそういうことではなく? ちなみに halt は古典的なSmalltalkにおけるブレイクポイントみたいなもの。
192 :
2014/04/03(木) 15:25:06.01 ID:hov1QvrO
みんなSmalltalk使ってたのかよ
193 :
2014/04/03(木) 17:07:01.60 ID:4OpITLe5
スモールトークがオブジェクト指向の元祖だからな
スモールトークでできるならオブジェクト指向の欠点とは胃炎な
194 :
2014/04/03(木) 17:16:43.96 ID:hov1QvrO
ていうか、一つの式に詰め込んだら便利かどうかなんてオブジェクト指向と関係なくね?
195 :
2014/04/03(木) 19:17:35.74 ID:/A78gSRK
Smalltalkには、コードを英文のように読み下せるように書く慣習みたいなものがあって、
value foo bar baz みたいな式だとちょっとメリットをイメージしにくいですが、たとえば
「1 から 9 までの数を配列にして、それをシャッフルして最初の3つを得る」みたいな処理を、
(1 to: 9) asArray shuffled first: 3 というふうに一気にメソッドチェーンにして書くようなことはよくします。

そんなこともあって、メソッドチェーンだからデバッグしづらいというような制約はほとんどうけない仕組みになっています。
196 :
2014/04/03(木) 20:08:44.08 ID:JDC55uKf
>>194
そもそもオブジェクト指向についてあんまり語ってないからいいんじゃね
197 :
2014/04/03(木) 21:23:31.55 ID:y3U0PHNW
>>191
なるほど、ブレーク+ステップ実行なのね
まあ実用上は十分かな
C# とかでもできるようにしてほしい
198 :
2014/04/04(金) 00:28:50.72 ID:T327aBHM
C++じゃなくてObjective-Cが流行ってれば
オブジェクト指向絡みの論争は半分になったんじゃないかと
思えてしかたがない。
オブジェクト指向が、じゃなくてC++が採用した方法は、な議論大杉
199 :
2014/04/04(金) 01:37:59.49 ID:G1RCkua4
クラスベース vs プロトタイプベース
200 :
2014/04/04(金) 01:52:31.25 ID:h1F261Ig
Objective-C十分流行ってるじゃん
201 :
2014/04/04(金) 03:12:14.91 ID:T327aBHM
ここ5年ぐらいでiOS用で一気に拡まったけど90年代を通じて
一般の想定するオブジェクト指向と言ったらC++だったからな…
90年代後半からはそこにJavaが加わり…的な。
ある意味バカみたいに基本に忠実なObjective-Cの方が
オブジェクト指向とは〜って議論のたたき台としてはよかったよな的な。
202 :
2014/04/04(金) 07:15:48.10 ID:R/rpZwB2
>>197
と言うか、行単位でのブレークポイントなのはデバッガの都合でしかないんだよなあ
203 :
2014/04/04(金) 07:36:28.20 ID:KeYVoIFc
>>202
式の途中にブレークポイントを入れるのはデバッガだけでは無理っす。
204 :
2014/04/04(金) 08:06:13.57 ID:JslAeCyW
>>203
いや、だからそれって 今の デバッガだからだろ?
技術的にできない訳じゃなかろ
205 :
2014/04/04(金) 09:05:42.51 ID:KeYVoIFc
最低限、コンパイラにも手を入れる必要があると思うぞ。
206 :
2014/04/04(金) 10:52:39.43 ID:N5FO4XZ5
デバッガのブレークポイントの指定が
行単位ってだけで、関数単位でのステップは可能。

そして関数単位で止めたいなら
関数ごとに改行すればいいだけじゃない。
207 :
2014/04/04(金) 13:07:13.88 ID:JslAeCyW
>>206
> デバッガのブレークポイントの指定が行単位ってだけで、

たいていの IDE は行単位ではなくてステートメント単位じゃね?

> 関数ごとに改行すればいいだけじゃない。

そもそもそんなことしたくないか、発端だろ。
デバッグのためにソース弄るとかは最後の手段だろ。
208 :
2014/04/05(土) 08:19:53.84 ID:nKpGUjgO
>>206
だーかーらー、
コンパイラが出す行情報以外にどうやって
ブレークかけるアドレスを取り出すわけ?
関数ごとに改行したところで
普通のコンパイラはステートメント単位でしか行番号情報ださねーぞ。

もしかして、単にデバッガのUIの問題だと思ってた?
甘杉
209 :
2014/04/05(土) 08:39:06.87 ID:OXL1p1Q1
そういうスレたててやれ
210 :
2014/04/05(土) 10:05:58.71 ID:AlWzj+6w
いったいどのデバッガやコンパイラについて話してるのか知らんが、
VS2013とかにはメソッドチェーンのデバッグ機能あるぞ……
メソッドチェーン中の個々のメソッドについて戻り値とその型を表示してくれる
211 :
2014/04/05(土) 12:34:58.04 ID:zg062x0r
>>1
mvcで作ればなんとなくわかる
212 :
2014/04/05(土) 21:29:41.29 ID:LGGjyQ0u
オブジェクト指向を使うには、変数や関数がある程度以上の個数がないと無意味。
あとインスタンスが2個以上必要な場合じゃないと意味がない。
俺の分野ではどちらも当てはまらないので、オブジェクト指向が活用できない
という結論に至った。みんな、ありがとう。
213 :
2014/04/05(土) 21:49:36.29 ID:anSZmmIR
オブジェクト指向が活用できない分野ってどんな分野よ
214 :
2014/04/05(土) 22:16:36.14 ID:iKzYf4PO
書き換えて再利用とか機能の追加が少ない機械みたいな分野だったら
(構造化言語の)Cそのまんまで十分じゃないの、とは思う。
215 :
2014/04/06(日) 06:09:18.41 ID:IRmFVDmN
>>212の日本語訳
「俺がいつも書くコードはオブジェクト指向になっていない。
だから俺の分野ではオブジェクト指向は使えない。」

「オブジェクト指向」の部分にどんな技術を入れても成立する
魔法の言い訳だな。
216 :
2014/04/06(日) 06:50:21.75 ID:7fCDh1Rd
同じものが沢山作れる、ってのは確かにオブジェクト指向のミソだが、
インスタンスが一つだろうと、オブジェクト指向プログラミングによって得られるものは色々あるぞ
再利用性とか、単体テストのしやすさとか、拡張性とかな

あと、オブジェクト指向プログラミングの重要なデザインパターンに「シングルトン」というのがあって、こいつはインスタンスを一つに限定するものなんじゃな
インスタンス一つだから役に立たない、ってのは世の中のプログラマには通じないと思われる
217 :
2014/04/06(日) 09:28:19.55 ID:v5F7vKVc
記述側がより人間の思想に近くなったメリットと、実装側でからくり(C++ なら vtable)を生成コードに常に追加するコストとを天秤にかけたら、どっちに軍配があがるかは人それぞれだね
ライナスは OO をぼろくそにけなしているね
218 :
2014/04/06(日) 11:55:32.65 ID:X8q2hYwd
>>216
> 再利用性とか、単体テストのしやすさとか、拡張性とかな

単体テストはべつにして、再利用性とか拡張性とか広い意味では複数インスタンスじゃね?

あと、同じものをたくさんじゃなくって、ちょっと違うものを作れるって言うのがミソかと。
219 :
2014/04/06(日) 12:55:51.09 ID:hTzu53D+
>>217
> ライナスは OO をぼろくそにけなしているね
ライナスだけじゃね?w

しかも俺らはカーネル作ってるわけじゃないから、
用途によって言語は変えるべきという正しい考え方からすると、
ライナスが何言っても何使っても関係ないよねw
220 :
2014/04/06(日) 12:56:37.04 ID:hTzu53D+
どっちに軍配があがるかは人それぞれというより
用途によりけりってことだろう。

で、大概の用途にOOに軍配が上がると。
221 :
2014/04/06(日) 13:06:24.24 ID:N1Ox9kUH
ここまでの内容ならライブラリで十分。オブジェクト指向は不要。
222 :
2014/04/06(日) 13:16:36.50 ID:nZeav+Zp
ライブラリとオブジェクト指向を同列に語ってる馬鹿は黙ってろよ
223 :
2014/04/06(日) 13:29:28.28 ID:d9KztC3X
こういうのを見ると、やっぱりオブジェクト指向が一般的であることがよく分かるよ。

.NETにおけるSOLID設計原則とデザインパターン
http://www.infoq.com/jp/news/2013/09/solid-principles-revisited

SOLIDとは5つの設計原則の頭字語である。氏の簡潔な説明を借りれば:

単一責務の原則(Single Responsibility Principle)
  すべてのオブジェクトは唯一の責務を持たなければならない。すなわち,実行することはただひとつでなければならない。

開放/閉鎖の原則(Open-Closed Principle)
  クラスは拡張に対しては開いて(Open),修正に対しては閉じて(Close)いなければならない。

Liskovの置換原則(Liskov Substitution Principle)
  派生クラスは親クラスの置換として使用可能でなければならない。なおかつ,同じ振る舞いをしなければならない。

インターフェイス分離の原則(Interface Segregation Principle)
  使用しないインターフェースへの依存をクライアントに強制してはならない。

依存関係逆転の原則(Dependency Inversion Principle)
  具体的な実装よりも抽象に依存するべきである。これはコードの分離に有効だ。
224 :
2014/04/06(日) 17:51:43.94 ID:v5F7vKVc
>>223
vtableを生成コードに常に追加するコストに見合うものかどうか疑問だね
225 :
2014/04/06(日) 18:19:41.32 ID:7fCDh1Rd
vtableの生成コストとか言い出したら、スクリプト言語なんて論外じゃねーかw
226 :
2014/04/06(日) 18:34:59.08 ID:C74PoYgz
C++だとvtableは必要なとこにしか付かないよね
227 :
2014/04/06(日) 18:36:50.32 ID:XoDYwo6S
ぷらぷら。ぼくはvirtualなメソッドじゃないよ。
228 :
2014/04/06(日) 18:37:51.19 ID:ZbP0XCh9
なんでここだけC++初心者スレみたいになってんの?
229 :
2014/04/06(日) 18:39:42.35 ID:7fCDh1Rd
一番知名度のあるオブジェクト指向プログラミング言語はJavaの筈なのにね
230 :
2014/04/06(日) 18:44:04.82 ID:wJ4fkLfq
致命度?
231 :
2014/04/06(日) 20:38:36.74 ID:IDxsBa0K
いいや、Objective-Cが最後に勝つね
232 :
2014/04/06(日) 20:55:17.94 ID:C74PoYgz
Objective-C++が節操なくて素敵だよw
233 :
2014/04/09(水) 01:49:33.61 ID:eVIzB16V
オブジェクト指向に相対するパラダイムってなによ
関数型+代数的データ型?
234 :
2014/04/09(水) 03:10:51.74 ID:j9Z2BVsM
それは相対する、ってほどでも無いような
オブジェクト指向自体も考え方が複数あるからなあ…
関数型はともかく、手続き型でオブジェクト指向に真っ向から相対して組むとすれば

・データと処理がお互いに依存しないように組む、例えば特定のユーザ定義型に依存する処理などは控え、ひとつずつ引数で渡してもらうなどする
・モジュールは流れに沿って切り分ける、例えば全てのデータはデータモジュールに、全ての初期化は初期化モジュールに、本処理はメインモジュールに書く

とか、そんな感じになるのかな
235 :
2014/04/09(水) 08:48:53.28 ID:lgQL/971
向いてる方向が違うんだから、遠い近いはあるだろうけど相対って言うのはないんじゃね?
236 :
2014/04/09(水) 17:51:40.57 ID:iVtPfWG1
>>129
DDD?ってこれパラダイムじゃないか
237 :
2014/04/09(水) 18:41:01.22 ID:rvzGfgdi
昔DDDっていうデバッガ使ってたな...
238 :
2014/04/09(水) 21:00:52.84 ID:TCIMdxjw
DDT (CP/M-80) じゃなくて?
239 :
2014/04/09(水) 21:03:36.40 ID:rvzGfgdi
>>238
gdbのGUIフロントエンドだよ
240 :
2014/04/10(木) 22:59:06.71 ID:EbsHnFyb
最近ベクトル演算をする必要が出てきたので、オブジェクト指向のプロパティを
使って実現しようと考えている。

○か×か?
241 :
2014/04/10(木) 23:07:48.12 ID:c1sQcFAM
>>240
どう見ても「君には」×
242 :
2014/04/10(木) 23:36:09.35 ID:Uir6dqld
実際にベクトルクラスがあるからそれ参考にする
243 :
2014/04/11(金) 02:56:48.62 ID:HtRnBfLu
同じメソッド呼び出しを何度も行うと呼び出しのコードをコピペすることになっ
てしまいます。何もせず名前の意味も不明な多重のメソッド呼び出しはコピペを
防ぐためだったと判明しました。もちろん手打ちしたとのことです。

オブジェクト指向脳っていうんですか?本当に怖いです。
244 :
2014/04/11(金) 09:11:53.91 ID:nUaUWR93
>>243
それ違う。関数脳っていうの(笑)
同じ関数呼び出しを何度も実行すると
関数を何度もコピペすることになるからね(爆笑)
245 :
2014/04/11(金) 09:12:29.97 ID:nUaUWR93
>>243
それ違う。アセンブラ脳っていうの(笑)
同じニーモニック呼び出しを何度も実行すると
ニーモニックを何度もコピペすることになるからね(大爆笑)
246 :
2014/04/11(金) 09:13:54.98 ID:nUaUWR93
>>243
人生で同じ英単語・アルファベットを何度もコピペする略(ゲラゲラ)
247 :
2014/04/11(金) 13:07:20.58 ID:xNOhzDQj
なんか面白いんだろうな...
俺には理解できないけど
248 :
2014/04/12(土) 12:55:19.47 ID:5P9XNUOV
プログラマはソースのコピペを恐れないでください。誰でも最初は初心者で、
しかも誰もが成長するとは限らないのです。
成長を強いるオブジェクト指向が、万人の解決策になり得ないのは明らかです。
コピペこそが、初心者からベテランまで、万人の解決策となり得るのです。
第一、grepすらできないソースをメンテナンスできるはずありません。

コピペによるプログラミングは、複雑に絡まったバージョン依存問題を解決する
という、潜在的なポテンシャルがあります。

大体、オブジェクト指向を推進する人は、協調性がない人が多く、共同で作業す
るには向いていないのです。冗談のセンスすらありません。
249 :
2014/04/12(土) 17:13:54.61 ID:1eEiGLxS
全部反対のことを言っていると見抜けば
>>248が言っていることに納得できるはずw
250 :
2014/04/12(土) 17:19:09.23 ID:f/RHrroc
なんか面白いんだろうな...
俺には理解できないけど
251 :
2014/04/13(日) 10:45:23.58 ID:839g2ruV
ここで僕らは「良いソフト部品は、有名なのだけだ」という原則に立ち戻る必要があるだろうね。
誰も使ってない、メンテナンスもされない俺様オブジェクト部品を使うくらいなら、コピペの方がましな
んだよ。宣言型か関数型が使えるならその方がいいし、使えなければテストの自動化で乗り切る
しかないと、もう10年も前からいわれて続けているわけだ。
research.microsoft.com/en-us/um/people/blampson/70-SoftwareComponents/70-SoftwareComponents.htm
252 :
2014/04/13(日) 10:51:49.05 ID:oaa109sw
うん、まったくだ。
有名なソフトは良い。

有名じゃなくても良いソフトはまれにあるけど、
多くの、つまり何万、何十万とある無名なソフトはクソでしかない。
253 :
2014/04/13(日) 11:22:22.91 ID:2QOmxkhr
ストラウストラップが「オブジェクト指向というのは継承と再利用なんだよ!」ってやったせいで
えらい風評被害やな。

単にクラスというCでの関数に代わる単位の取り回し方法だから
Objective-C辺りじゃ継承…めんどいから使わない
NSObjectってクラスの基本的ふるまいを持った基底クラスから
テキトーなクラス作って、その中に使えるクラスぶち込んで
メッセージ(メソッド)オーバーライドでふるまい変えて使う。
クラスとは単にレゴブロックみたいなパーツ扱い。
254 :
2014/04/13(日) 11:38:57.62 ID:Vp4hM6j5
>NSObjectってクラスの基本的ふるまいを持った基底クラスからテキトーなクラス作って
継承してるじゃないの。

むしろC++の方が継承なしのパーツ扱いが多いんじゃないの。
255 :
2014/04/13(日) 11:54:36.21 ID:j71fNHt+
いわゆるObjectクラスが必要な理由って何かあるの?
256 :
2014/04/13(日) 12:17:57.96 ID:2QOmxkhr
Objective-Cはとにかくクラスの実体ありきで
言語的にひな型からインスタンスを作るんじゃなくて
起動時に存在するファクトリクラスにallocとinitを送って
クラスに"自分のインスタンスを作らせる"から
すべてのクラスはallocやinit、retainカウント、deallocを受け付け管理する
NSObjectを継承していないとクラスとして存在しえないので…
257 :
2014/04/13(日) 15:02:09.06 ID:Vp4hM6j5
動的な言語だとだいたいObjectクラスが必須だよね
258 :
2014/04/13(日) 15:38:34.94 ID:j71fNHt+
>>256
別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
259 :
2014/04/13(日) 15:55:24.32 ID:BqlLq9pK
動的な言語でも本来はObjectなんて要らない。
Smalltalk-80だってnilのサブクラスを作れたし。
260 :
2014/04/13(日) 16:04:45.61 ID:oaa109sw
値の型が動的なのと
変数の型が動的なのとを
区別つけろよ。アホ。

Objectが必要なのは変数に型があって
値の型が動的な場合なだけだ。
変数に型があるが、そこで記述された型だけではなく
互換性がある型を入れられる。
そういう言語でどんな型にも互換性があるのがObject型だ。

変数に型がない言語ではどんな値でも入れられるから
Objectは要らない。変数にはどんな型でも入れられる
とはいうものもコードは互換性がある型を入れてないと
結局正しく動かないんだけどなw
261 :
2014/04/13(日) 16:17:49.14 ID:Vp4hM6j5
値の型が動的ってどういう事?
さっきまでStringだったけど今みたらIntに変わってたわ!みたいな?
262 :
2014/04/13(日) 16:24:02.51 ID:oaa109sw
変数の型は固定なんだよ。
この変数は、Numeric型みたいに。

でもNumeric型って書いてあっても
その値は実はInt型だったりFloat型だったりと
Numeric型に互換性がある型に変わっていたりする。

変数の型は固定なのに値の型は違う。

それに対して、変数に型が決まってない言語があるの。
変数に型が書いてないなら変数aにどんな型でも入れられる。
263 :
2014/04/13(日) 16:26:13.02 ID:Vp4hM6j5
Objectって全部に共通の動作を定義するために使われてるよね普通は。
例えば、自分の型を返すとか。
264 :
2014/04/13(日) 17:45:48.17 ID:CtgsENNt
値が型情報持ってない言語は一応あるね、C言語とか
あれは変数側にしか型がない
265 :
2014/04/13(日) 18:03:36.88 ID:BqlLq9pK
>>261
SmalltalkではさっきまでByteStringだったオブジェクトが今みたらWideStringだったぜとか普通
266 :
デフォルトの名無しさん
2014/04/13(日) 18:07:49.11 ID:+sscY2hT
>>263
それがルート(基底)クラスだな。
Objective-Cで言えばNSObjectで、全てのクラスのルート。
267 :
2014/04/13(日) 18:54:15.96 ID:BqlLq9pK
全部に共通の動作なんてものが必要なうちはダメだな
268 :
2014/04/13(日) 19:10:20.98 ID:wSq/pgWA
>>267
ダメな理由書いてみ
269 :
2014/04/13(日) 19:31:38.05 ID:Vp4hM6j5
>>265
それは参照してるオブジェクトが変わったんじゃないの?
270 :
2014/04/13(日) 20:05:02.79 ID:+sscY2hT
共通の動作がなければ、てんでばらばらって事じゃんw
271 :
2014/04/13(日) 20:31:47.78 ID:yhlLeWxx
>>269
Smalltalkではbecome:というメソッドで
ポインタレベルでのオブジェクトの差し替えが可能なんで

| x y |
x := y := 'abc'
x become: 3.14.
y. "=> 3.14 "

これを応用してオブジェクトの型の変更も容易なんですよ
272 :
2014/04/13(日) 20:36:46.47 ID:1ZgLAbLW
>>259
よく知らないんですけどSmalltalkのnilとObjectって
お互い継承関係にあるんじゃないんですか?
273 :
2014/04/13(日) 20:46:56.28 ID:+sscY2hT
>>271
SmallTalk知らないんだけど、それってxというオブジェクトにbecome:という動作をさせてるの?
そうなら、become:という動作は全オブジェクトに共通だよね。
274 :
2014/04/13(日) 20:50:21.03 ID:Vp4hM6j5
>>271
Smalltalkよくしらないから適当言語だけど...
x = "x"; y = "y"; z = y;
の状態で
y become: x;
とやったら、
zの指してるオブジェクトは"x"になるって事?
275 :
2014/04/13(日) 20:59:39.25 ID:BqlLq9pK
>>268
つ proxyパターン

>>272
nilはクラスではないところがポイント。

>>273
全オブジェクトに共通ではない。

>>274
なる。xが"x"のままの流派と"y"になる流派とがある。
276 :
2014/04/13(日) 21:09:17.21 ID:1ZgLAbLW
よく知らない三連星ワロタ

>>275
なるほどそういう意図ですか
1. nillはUndefinedObjectのインスタンス
2. UndefinedObjectはObjectの継承している
3. Objectはnilを継承している
こうかな?
となると全てのクラスの共通となる祖先が存在してるんで
不要論として出すのはやっぱおかしくないですか?
277 :
2014/04/13(日) 21:15:34.64 ID:TiAwmeQu
知れば知る程Smalltalkのウンコさが身にしみる
278 :
2014/04/13(日) 21:40:50.80 ID:+sscY2hT
proxyパターンと共通の動作にどういう関係があるのかわからん。
279 :
2014/04/14(月) 01:52:57.81 ID:QEqaYkvm
>>258
>別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
いま、C++とかがそこに起因する泥沼に嵌ってるけど
オブジェクトクラスの側は言ってしまえば実装だしライブラリだから
将来に動作を変更されるうるし、実際に変更されるけど
言語仕様はもう一段上のルールだから変更が実に困難だという…
280 :
2014/04/14(月) 01:57:18.83 ID:QEqaYkvm
>>259
要らないつうか、それだと基本的なオブジェクトとしてのふるまいを持ってないから
Objective-Cで生のC関数書いたりObjective-C++でC++のクラス扱ってる状態なだけじゃ…
281 :
2014/04/14(月) 19:01:11.23 ID:9oXXilb1
>>276
nilはクラスではないから共通の祖先となるクラスではないよ。
というか基底クラスが複数あるのはそんなに珍しいことではないが、
一体何がわからないのかわからない。
282 :
2014/04/14(月) 20:50:15.58 ID:2o5NlHiv
>>281
nilを継承できる事と所謂Object型が不要になる事の繋がりが分からないんですよね
nillオブジェクトとObjectクラスは親子関係にあるのになんでだろう
って思って質問したんです
283 :
2014/04/14(月) 21:32:49.46 ID:1BzKypQe
> 3. Objectはnilを継承している
それが真であれば、Objectはnilの特徴を持っていないといけない。
Objectはnilではないので、これは間違い。
284 :
2014/04/14(月) 21:40:20.78 ID:KfO5hauH
>>280
要らないんじゃなくて、あった方がやり易いってことだよな。
別にObjective-CでもNSObject無視してクラス自作できるけど、まずそんな事しない。
285 :
2014/04/14(月) 21:41:56.76 ID:kBF05cIr
Rubyだと
・nil は Nilクラスの唯一のインスタンス
・NilクラスはObjectクラスから派生したサブクラス

$ irb2.0
irb(main):001:0> nil.class
=> NilClass
irb(main):002:0> NilClass.superclass
=> Object

Smalltalkは知らん
286 :
2014/04/14(月) 22:20:14.96 ID:2o5NlHiv
>>283
あ、そうなんですか
Wikipediaに
> 基本的な派生元となるObjectやProtoObjectは、それらから派生したUndefinedObjectのインスタンスオブジェクトであるnilを継承しており再帰関係を持つ。
と書いてあったんでそういうものだと思ってました
あと
Object isKindOf: nill
が true を返すのはなんででしょう?
287 :
2014/04/15(火) 04:06:44.72 ID:wLbFOpnz
>>285
つまりnilとNilは別々のオブジェクトであり、
NilがObjectのサブクラスであることとnilは何の関係もない、
ということだね。

>>286
つまりnilとUndefinedObjectは別々のオブジェクトであり、
UndefinedObjectがObjectのサブクラスであることとnilは何の関係もないし、
nilはクラスではないし
Squeak4.4ではObject isKindOf: nilはfalseだし、
Object new isKindOf: nilもfalseだし、
仮にtrueになる処理系があっても、nilはクラスではないからnilはObjectの基底クラスではない、
ということだね。
288 :
2014/04/15(火) 18:46:18.65 ID:4TC7MUH1
>>287
ありしゃす、Object isKindOf: nil の結果は実装依存なんですね
true になるのはGNU Smalltalkでした
289 :
2014/04/15(火) 20:46:27.61 ID:d1+oXg+5
>>287
>つまりnilとNilは別々のオブジェクトであり、

nil はインスタンスでありNil はクラスだから、別々のオブジェクトってこと


>NilがObjectのサブクラスであることとnilは何の関係もない、

Nil と Object とは「サブクラス-スーパークラス」という継承関係であり、
Nil と nil とは「クラス-インスタンス」というインスタンス化関係であり、
二種類の関係をごっちゃにしてはいけない、ってこと
290 :
2014/04/15(火) 21:07:45.24 ID:d1+oXg+5
>>286
>> 基本的な派生元となるObjectやProtoObjectは、
>>それらから派生したUndefinedObjectのインスタンスオブジェクトである
>>nilを継承しており再帰関係を持つ。

Rubyの場合
・ClassクラスのスーパークラスはModuleクラスである(継承関係)
・ModuleクラスのスーパークラスはObjectクラスである(継承関係)
・ObjectクラスはClassクラスをインスタンス化したオブジェクトである(インスタンス化関係)

$ irb2.0
irb(main):001:0> Class.superclass
=> Module
irb(main):002:0> Module.superclass
=> Object
irb(main):003:0> Object.kind_of?(Class)
=> true

結果として、各クラス間の関係は「循環的」に定義されることになる
ただしRubyコミュニティでは、それを(その循環関係)を「再帰的」と呼ぶ事はない

Smalltalkは知らんけど、おそらく、そのWikipediaの著者が
継承とインスタンス化をごっちゃに理解しているんじゃないかと思われ
291 :
2014/04/15(火) 21:25:46.27 ID:POAb9xNt
>>288
GNU Smalltalk は名前から受ける印象と違って
単なるファンお手製の勝手実装なうえに、
Smalltalk としてもかなりの変わり種なので
あれを元に Smalltalk がどういうものか学ぶのはちょっと問題が。
できれば VisualWorks 、悪くても Squeak/Pharo で
試すようにするのがよいと思います。
(これらの処理系はそれぞれ独自の進化を遂げてはいますが、
いちおう古典的 XEROX Smalltalk-80 からの直系の派生物で、
その名残を多く残しています)
292 :
2014/04/15(火) 22:39:29.15 ID:4TC7MUH1
>>290
https://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/S4-5-4_1.html
http://pharo.gforge.inria.fr/PBE1/PBE1ch14.html
を読んでみましたが

1. ObjectクラスはObject class(メタクラス)のインスタンス
2. Object class(メタクラス)はClassクラスを継承している
3. ClassクラスはClassDescriptionクラスを継承している
4. ClassDescriptionクラスはBehaviorクラスを継承している
5. BehaviorクラスはObjectクラスを継承している

って事で、Wikipediaの言う再帰関係は成り立ちますね
nilの存在は謎のままですが
間違ってたら教えて下さい

>>291
情報ありしゃす!
勉強はGNU以外でやります
293 :
2014/04/15(火) 22:48:36.35 ID:8/R6vbb5
大量のベクトル演算をオブジェクト指向で行うのはいい考えではありませんでした。
パフォーマンスが話になりません。

あらためてオブジェクト指向の活用方法が知りたいです。
294 :
2014/04/15(火) 22:56:10.29 ID:TDL51eos
あたりまえやないかw インラインでやれ。
295 :
2014/04/16(水) 05:01:31.46 ID:ZBBb0DXo
>>292
それはmeta cyclicというのであってrecursionとは全く別だよ
296 :
2014/04/16(水) 08:21:50.02 ID:A1GSn+hc
>>295
http://upload.wikimedia.org/wikipedia/commons/f/f9/Smalltalk_80_metaclasses.svg
を拝借するとrecursionはどの部分になりますか?(または当て嵌まらない、とか)
MetaclassとMetaclass classがrecursion?
と言うかmeta cyclicとrecursionは定義はどこを調べればいいんでしょうか
あー分かんなくなってきた
297 :
2014/04/16(水) 17:33:35.89 ID:ZBBb0DXo
>>296
まず、
全てのクラスの基底となるクラスが存在するかどうかという>>255の話は継承関係の話で、
クラス-インスタンス関係で構成されるメタタワーの話である>>296の話とは
全く別々の話だということはOK?
298 :
2014/04/16(水) 18:10:12.53 ID:A1GSn+hc
>>297
はいそれは分かってるつもりです
自分が疑問に思ったのは>>259なんで、
nilを継承できる事とObjectが不要である事の関連性を
説明して貰えるとありがたいんですが…
299 :
2014/04/17(木) 03:03:07.59 ID:g3SPX8xq
isKindOf:等のクラス階層へのアクセスを使わない限りにおいて、
全てのクラスは基底クラスから継承したインスタンス変数やメソッド等を取り込むことで
nilからの継承による実装に置き換えることが出来るのはOK?
300 :
2014/04/17(木) 06:51:39.99 ID:XZy5mn+7
>>299
はい、続けて下さい
301 :
2014/04/17(木) 07:01:46.34 ID:g3SPX8xq
>>297>>299を前提とすれば、
全てのクラスの基底クラスとしてのObjectは不必要であることは自明だというのはOK?
302 :
2014/04/17(木) 07:48:37.17 ID:XZy5mn+7
>>301
いいえ、その飛躍が判りません
nilにObjectクラスと同じ能力があるからObjectクラスは不要だという事ですか?
303 :
2014/04/17(木) 09:46:27.34 ID:g3SPX8xq
>>302
いいえ、nilにObjectと同じ能力があるなんて誰か言ってるのですか?
304 :
2014/04/17(木) 19:48:33.36 ID:XZy5mn+7
>>303
じゃあ>>299の解釈が間違ってますね
うーん、Objectの代わりにnilから派生できるよ、としか汲み取れません
でもそれだとクラス階層のルートの必要性とは無関係の話だから違うんだろうな

自明の部分を取り違えないように省略せず説明して頂けませんか?
305 :
2014/04/18(金) 02:02:31.47 ID:3m4Hm4jr
今更な反応だけど
メソッドチェーンのデバッグどうのこうのは
パワーアサートである程度解決できるんじゃね

テストとデバッグを同一視すんなとか言われそうだけど
そこはなんやかんやで
306 :
2014/04/19(土) 11:19:09.69 ID:fQ1JDqwN
みんなモデリングツール使ってる?
307 :
2014/04/19(土) 15:25:11.54 ID:7lbU/Cwq
UMLは手書きのノートに万年筆で描いてるけど?
308 :
2014/04/19(土) 15:25:52.03 ID:7lbU/Cwq
ああ、もうすぐ司法試験なんだよなぁ・・・
今年も申し込みしてねーや。
仕事辞めたいわ
309 :
2014/04/19(土) 15:28:51.08 ID:oGrzc7nx
ぜひ弁護士資格を取って人売り屋を訴えてやってください。
310 :
2014/04/19(土) 15:32:20.57 ID:7lbU/Cwq
弁護士より裁判官志望なんだけどな。
知財専門の裁判官やるわ。
311 :
2014/05/02(金) 02:53:15.17 ID:sB1UFa5X
裁判官になるのはある意味、終身刑になるようなもの
仕事にやりがいはないし、趣味、嗜好、信仰の類は一切行えない
どうしてもやりたいというなら止めないが、いいもんじゃないぞ
312 :
2014/07/11(金) 14:24:19.29 ID:u5XcYD/q
確かに日本語ネイティブじゃないと解り難い表現ではある
313 :
2014/10/15(水) 02:03:28.04 ID:fxqbNGWP
急にスレが死んだ
314 :
2014/10/16(木) 17:21:37.89 ID:MhzmuNOz
>>217
>ライナスは OO をぼろくそにけなしているね

Linusが批判したのはOOPじゃなくてC++だろ(Cとの比較で)。
315 :
2014/10/18(土) 12:18:53.66 ID:/oNwCDSd
似たようなものさ‥Linus が GC の存在を受け入れるわけがない
316 :
2014/10/18(土) 15:46:58.25 ID:7/IQKq91
そりゃ、カーネルやドライバレベルの開発でGC付きの言語環境は要らんわ。
OOPの話題でリーナス発言を引き合いに出すのは的外れすぎる。
317 :
2014/11/05(水) 13:15:41.31 ID:QbWIQhdw
OOPって結局、こういう考え方すれば分かりやすくなりますよって例でしかないからな
その考え方を前提に置けば、こういう表現ができますよって利点はいろいろな実装があるけど

完全性や効率性を犠牲に、可読性を上げて保守性や再利用性、試験性なんかを上げましょうってそういうものだと思うんだけど
318 :
2014/11/05(水) 20:29:01.97 ID:NM+61D3j
OOPって結局、…でしかないからな

という奴って、OOP以外にも関数型言語でもアジャイルプロセスでも受託ビジネスでも
みーんな「結局、…でしかないからな」とわかったような気になるだけで
実際には何も身についてないんだよなw
319 :
2014/11/05(水) 23:26:57.45 ID:UbfQ7xJO
オブジェクト指向は愚かな考え。排便メソッド2 [転載禁止]©2ch.net
http://peace.2ch.net/test/read.cgi/tech/1415122540/
320 :
2014/11/06(木) 08:17:55.90 ID:WCLQna6c
>>31
「結局、ただの方法論でしかないからな」

方法を知っているかとそれをビジネスで生かせるかは全く別のスキルだしなー
321 :
デフォルトの名無しさん
2014/12/15(月) 00:00:56.39 ID:Ovh10mZl
カプセル化 ポリモーフィズム 継承を理解して設計出来る人って実際、何人に一人ぐらいに感じる?
322 :
2014/12/15(月) 09:52:17.25 ID:z8CdksSX
ひとそれぞれ解釈違うからなんとも言えん
323 :
デフォルトの名無しさん
2014/12/15(月) 11:05:06.23 ID:cy4sFuPq
カプセル化&オブジェクト化の行き先は関数型プログラミングじゃないの?
324 :
2014/12/15(月) 12:54:30.82 ID:t6/tpY1X
絶対違う
325 :
2014/12/15(月) 15:09:37.42 ID:2aP18QTz
>>323
北極と南極の違いだろ。
OOPの落伍者のパラダイスが関数型なんだから。
326 :
2014/12/17(水) 11:09:29.57 ID:N1jNpsSg
ポリモーフィズムは分かりやすいんだけどカプセル化がいまいちわからない
ゲッターセッター書いて何になるの?ってレベルの理解しかないから優しく教えて
327 :
2014/12/17(水) 11:58:16.14 ID:qGVIuFRu
>>326
カプセル化はむしろ単純セッター書いたら負け
そのクラスの機能のみ提供して、内部実装を隠すのが要点
328 :
2014/12/17(水) 13:49:16.52 ID:dSysfVHr
カプセル内では、他のオブジェクトの定義を知らなくても済むように書く。
閉じたオブジェクトにすればいい。
329 :
2014/12/17(水) 17:36:45.21 ID:FGZvKMUK
>>326
基本的にそのクラスのメンバーはそのクラス内でいじられることを保障するため。
330 :
2014/12/17(水) 18:56:34.51 ID:qGVIuFRu
実装を隠す
→知らなくても使えるように設計する
→使い方さえ変えなければいい
→中は変え放題、新しい使い方も追加放題

>>329
よくあるサンプルみたいに全メンバアクセッサ実装してるようなクソクラスだと
その原則破るための効果の方が強くなってしまうからなぁ

クラスの中から≠クラスファイルの中から
クラスの中から=クラス機能の中から
331 :
2014/12/17(水) 19:24:20.07 ID:N1jNpsSg
327-330
いろいろありがとう
公開したいとこだけ公開すりゃいいのね
332 :
2014/12/17(水) 19:38:57.10 ID:y3DoL19d
極論を言えば「公開」したら負けなのがカプセル化
333 :
2014/12/17(水) 21:14:17.50 ID:lLmQTo2M
>>326
getter-setter をかましておけば、なにかのときに簡単に監視やフックを追加できる
334 :
2014/12/17(水) 22:00:02.25 ID:adMFmMY0
>>333
ちょっとした用途ならリフレクションから呼べば良いじゃん
機能として提供する必要が出来たならそんな直接参照するような裏ワザ使わないで継承するなり追加するなりしようよ

影響が外に広がらないようにカプセル化して直接参照する手段を封じるんだから
直接参照できるセッターやゲッターつけたら保証できなくなるじゃん
335 :
2014/12/17(水) 22:40:02.99 ID:lLmQTo2M
>>334
リフレクションは悪、コンパイル時に検出できるエラーがリフレクションにすると検出できなくなってしまう‥
まあ何でもかんでもsetter-getter で公開してしまうのはどうかと思うが(ましてやプロパティを公開してしまうのは最悪)
336 :
デフォルトの名無しさん
2014/12/18(木) 15:10:59.93 ID:ZOTu6c+H
おいおいインスタンスにアクセサなかったら、
そいつの状態を変えたりモニターしたりどうやるんだよ。
337 :
2014/12/18(木) 15:18:48.22 ID:hbsgKLA0
>>336
状態をモニタするのは「モニタする」メソッドでやるべきじゃね?
状態を変えるなら、状態を変えるメソッドを通すべきだと思うし

もちろん、カプセル化の観点から見たら、の話ね
何か目的があってカプセル化を崩すなら、それはそれだろうし
338 :
デフォルトの名無しさん
2014/12/18(木) 15:31:32.87 ID:ZOTu6c+H
いやそのためのメソッドがsetter/getterだろうと。
339 :
2014/12/18(木) 16:01:52.60 ID:a38PRbZq
>>335
> ましてやプロパティを公開してしまうのは最悪
.NETのクラスは山ほどプロパティを公開してるけど、これも最悪なの?
340 :
2014/12/18(木) 22:10:35.29 ID:nYq1QBRW
>>339
>>335 はプロパティをフィールドと混同している気がする。
フィールドを公開するのが最悪、なら納得できるもん。

>>338
setter/getterはあくまで、結果としてそうなるだけのものだよ。

あくまで例えばの話だけど setLeft(), setRight(), setWidth() という3つのsetterがあったとして、
内部データは「left,right」でもいいし「left,width」でも「center,width」でも
「center,half_width」でもいい、もっと言えば「width,right」でも構わない。
まあよほど処理上の都合がないかぎり最後のを選ぶ人は少数だと思うけど、
どれが単純なsetter/getterになるのか、どれが違うのかは外からは分からない。
そして、それは分からなくていいものだと思うよ。

状態が最初にあって、それを見たり弄ろうと思うとsetter/getterになっちゃうけど
まずそのオブジェクトで何をしたいのかを考えて、それを実現するための内部構造と考えると
自然とカプセル化されてくもんじゃないかな。
341 :
デフォルトの名無しさん
2014/12/18(木) 22:32:07.68 ID:ZOTu6c+H
>>340
いやだからアクセサでオブジェクトの状態を変える・モニターするのは別に普通だろと言ってるの。
342 :
デフォルトの名無しさん
2014/12/18(木) 22:55:00.66 ID:CbZTNJ5S
Entityにgetsetつけてるのって何も考えてないとしか思えない
343 :
2014/12/18(木) 23:22:15.68 ID:rHvMFTQj
状態変更やモニタするメソッドの名前をgetやsetにするのは自由だけど・・・命名規則的にそれってどうなの?
それに当然モニタリング機能を提供すべき責任を負ってるクラスだけだからな

状態を変更するメソッドならバリデーションや整合性チェック、状態変化に伴う動作まで含めて一つの完結した機能として定義すべきかな
状態変化監視するならオブザーバパターンで、JavaならpropeatyChangeListenerとか
実装して受け取るべきだと思う
もしくは監視用ステータスオブジェクトを返す感じとかか?
344 :
デフォルトの名無しさん
2014/12/18(木) 23:28:53.90 ID:ZOTu6c+H
ああ、俺が言ってるのは単純にプロパティの事だよ。
345 :
2014/12/19(金) 00:08:44.41 ID:Z5vGYKdT
こういう説明はどうだろう?
NG:状態変数を取得するために状態変数取得メソッドを作った
OK:状態取得メソッドを作ったので保管場所として状態変数を作った

少なくとも設計段階でデザインするべき物かな
そうやってデザインの結果として一部にクラスに、
結果的に単純プロパティのような形の実装になった物が出来るの悪いことではないと思う
346 :
デフォルトの名無しさん
2014/12/19(金) 00:25:25.61 ID:kXOboZoh
始めからプロパティとして定義するものもあれば、
プライベート変数を後からプロパティに変更する事もあれば、
プロパティだったものをプライベート変数に変更する事もあるよ。
347 :
2014/12/20(土) 09:38:36.96 ID:+GgZ8JtG
CTMCPでggr
348 :
2014/12/25(木) 01:56:12.77 ID:FXTtDPDb
C++とかjavaは元来の意味でのオブジェクト指向じゃないからね
あくまで、オブジェクト指向に便利な機能つけた手続き言語

オブジェクト指向をきちんと使いたいならsmalltalk参考にしてる言語のほうがいいと思われる


例として、整数を文字列に変換するときに
Java
String.valueOf(48)

Ruby
48.to_s

48さんに文字列になって欲しければ、48さんのメソッド呼ぶのが本来のオブジェクト指向ー
349 :
2014/12/25(木) 02:01:12.47 ID:FXTtDPDb
同じように、通信をするconnectionってインスタンスがあったとして

connection.status = Status::FINISHED

とかやっちゃうのはオブジェクト指向らしくなくて

connection.finish

で、終了処理から内部状態変更やらやってくれるのがオブジェクト指向
350 :
2014/12/25(木) 03:27:23.93 ID:plZQlrr3
>>348
Staticメソッドを引き合いに出してJavaをけなしてもねえ……
351 :
2014/12/25(木) 03:29:07.82 ID:EL6gBj3v
>>348
そりゃ OO 的には美しいが、レジスタ一個で収まるところをごてごてとデコレートするのもね‥
352 :
2014/12/25(木) 14:56:46.31 ID:UXO0kBFe
手続きとOOを排他扱いする時点でお察し
353 :
2014/12/25(木) 15:07:57.78 ID:ZM9QeVU6
まぁ、速度優先するならOOPだの関数型だの構造化だのオーバーヘッドの必要なルール止めて
シーケンシャルに処理手書きしていけよってなるしな

保守性とかほかの目的で冗長な記述をルール化してるんだし
354 :
デフォルトの名無しさん
2014/12/27(土) 21:08:42.89 ID:Dl8SRIg9
文字列とか数値とか考えないのがオブジェクト思考じゃないの?
355 :
2014/12/31(水) 03:38:42.55 ID:GtslL7/x
基底クラスが「人」で、3つの派生クラスを作ってそれぞれに「.work()」を記述した場合で
3つの派生クラスの全インスタンスの「.work()」を実行したいときどのように管理すれば良いのでしょうか
自分では派生クラス毎にループを回すことしか思いつきませんでした
356 :
2014/12/31(水) 07:56:11.57 ID:grXbYJWV
基底クラスにwork()を定義して、派生クラスでオーバーライドするとか
357 :
2014/12/31(水) 11:53:58.04 ID:HNmCF9/p
>>355
「職業」インターフェースを追加して、work()を定義するかな

work()を使う側は、人に対して命令しているのではなく、職業の役割に対してその通り働けと言ってるわけだから
358 :
2014/12/31(水) 17:22:24.60 ID:/ugoQQzd
>>355
そんなん、クラスが「基底か」「派生か」ということとは関係ないじゃん。

基底クラスのインスタンスを複数作成した場合でも、同じでしょ。

複数インスタンスに同時にメッセージを送るということなんだから。

ヒントはリスナー。
359 :
2014/12/31(水) 19:32:50.12 ID:NQSYJ4L5
>>355
> 3つの派生クラスの全インスタンスの「.work()」を
> 実行したいとき

例えば Smalltalk なら

人 allSubinstances do: #work

とかそういうこと?
360 :
2015/01/01(木) 10:15:28.02 ID:J+tSiQ0Q
Javaでクラスメソッド書いてると罪悪感あるんだけど、
副作用のない関数を書くんなら問題ないよね?

OOPっぽくないというのが罪悪感の原因だろうけど、
public staticで副作用のない関数だとむしろ書いていくべきだよね?
361 :
2015/01/01(木) 10:29:00.83 ID:unDf2EkN
>>360
気にするとすれば、そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの?ってところかな

クラスって、データと「そのデータに対する」操作の集まりだから。
影響を受けるデータの方に自身の操作として定義した方が良くない?

良くあるアンチパターンの機能クラスと、データクラスに分かれちゃってる手続き型設計
362 :
2015/01/01(木) 10:49:25.84 ID:ZjnnyCSc
> そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの?ってところかな

クラスを定義しないと関数を書けないからね。

> クラスって、データと「そのデータに対する」操作の集まりだから。

Math.sinなどのメソッドは、どのデータに対する操作かな?
やっぱ、関数、っていう使い方は生き残ると思うんよね。
363 :
2015/01/02(金) 03:24:38.38 ID:Urv5GfAa
オブジェクト指向的にはstrategyっぽくオブジェクトにしとくべきなんだろうとは思う

んで、普通はAngleオブジェクトがあってそれがsinやらcosやらのオブジェクト持ってる感じじゃない?
364 :
2015/01/02(金) 18:16:39.18 ID:u8eIFPVv
この話題でJava固有の話をするのは本意ではないんだけど、
やっぱプリミティブ型ありきの現状考えると、
式の中にAngle a = new Angle(PI/4)からのa.getSin().doubleValue()みたいなんが出てくるのも、
式の途中で new Angle(a + b) みたいな生成が混じるのもシンドイ気がする。

次に、プリミティブ以外に目を向けたとしても、
関数的に表現したほうが自然に見える操作もある。
たとえばファイルのコピーをするメソッドを考えたとき、
file.copyTo(other)というふうにするより、
FileUtils.copy(File src, File dst)となってるほうが自然に見える。
実際、Javaの標準ライブラリにおいてもjava.nio.file.Filesにおいて、
public static Path copy(Path source, Path target, CopyOption... options)
となってる。これも関数的アプローチの無くならない理由というか証拠のような気もする。
365 :
2015/01/02(金) 18:23:55.66 ID:IjnWDn9W
>>364
public static Angle fromDegree(double degree);
public static Angle fromRadian(double radian);
public double sin();
public double cos();
...
でいいじゃん。
Angle.fromDegree(45).sin()とか。
366 :
2015/01/02(金) 20:15:57.81 ID:86rXEaVV
三角関数自体は角度の持っている特性だからAngleから取り出せるものだけど、
数学としてそれを導き出す関数で概念化した法則≒数式はMathとして定義されていてもおかしくはないか

ただ、数式自体はオブジェクト(物)を扱わず、その法則のみを抜き出して机上で扱う関数の集合、
数学自体が物事をオブジェクトで表現せずに、関数で表現したもの(ただし、直接使え無いと超非効率になる)
って感じかな

>>364
ファイルのコピーはファイル自体の機能ではなく、その上のストレージに自身の保持してるファイルを複製せよって命令する感じのような
367 :
2015/01/02(金) 21:02:15.51 ID:gr/6otir
>>365
そのnewを書く書かないとかcreateメソッドを準備するとかは興味なくて、
パラメータ→結果 で済む世界の話に短命オブジェクトを挟むのが嬉しくないよね?
絶対嫌だとか、困るとか言うつもりもないけど、今んとこメリットも見えないような。

>>366
関数型言語に詳しくてウンチクのひとつも言えるなら、
この気持ちスッキリ表せるんだろうけど、今の俺が言えるのは、
関数ありだよね、特に、式には関数だよね、みたいなことだけ…。

ファイルのコピーの例はご指摘を受け、自分の中では少なくとも、
「メソッド方式よりも、関数方式でスッキリする例」で無くなってしまったw
関数方式でスッキリするのはやっぱ数式関係だけ、なのかも。
368 :
2015/01/02(金) 23:29:08.38 ID:Wdw9kQqY
基本的に読みやすいと言うか、その処理がどういう本質のものかをコード自体で示してるのが良いコードなワケで
数学関係の処理は、元が元だけに関数形式が一番本質に近いから、そりゃ関数形式が読みやすくもなるわな
369 :
2015/01/03(土) 07:48:27.17 ID:aZa/y2Ql
>>367
Angleがどうして短命なわけ?Pointとの本質的な違いは?
全てはあんたの一方的な思い込みだよw
370 :
2015/01/03(土) 07:51:27.38 ID:aZa/y2Ql
>>367は関数型に詳しくないだけじゃなくオブジェクト指向も初心者レベルだよw
371 :
2015/01/18(日) 03:08:14.87 ID:1HDk1G1l
>>370
その理由は?
372 :
デフォルトの名無しさん
2015/01/29(木) 11:14:38.08 ID:FsmC2LI9
beanというかバリューオブジェクト?とユーティリティクラスって

効率のためにあえてオブジェクト指向の設計を崩して、
構造化プログラミングで設計するときに利用するものって考えでいいんですかね?

構造体と機能モジュールの関係そのまんまだし
373 :
2015/02/02(月) 21:59:42.72 ID:Q01xzseR
ブログラマの質にできるだけ影響を受けないように
プログラムの質を維持するのが目的だろ。
プログラマの質の水準をどの程度と見るかで
求められる効果が変わってくる。
374 :
2015/04/12(日) 15:53:34.84 ID:Buy3OTWo
恥ずかしながらC#やった時に初めて理解できたわ

IEnumerableとかIDisposableを継承すると馬鹿でも分かると思う
375 :
東京女子医科大学病院プロポフォール大量投与
2015/06/08(月) 21:15:24.77 ID:Fqp3awmG
マスゴミ・売国奴・医療業界が隠そうとする真実---------------------安楽死---------------------奴隷に勝手に死なれては困る

安楽死旅行企画が大人気|竹田恒泰チャンネル

https://www.youtube.com/watch?v=XmP1TRsAe88


武田邦彦:安楽死と大麻、そして売春・・・オランダに学ぶ

https://www.youtube.com/watch?v=nWV8YOY39tw


安楽死党

https://www.youtube.com/watch?v=8nU2UaSlGx0

自殺は後遺症が怖い!だから-----------------------------------安楽死制度-------------------------------------安心して生きるために
376 :
2015/08/29(土) 13:11:34.86 ID:g7aWBHc9
全ての識別子をグローバルにして誰かと共同制作したいならどうぞ、って感じだな
377 :
2015/11/01(日) 11:36:44.47 ID:hTxt2JkX
データ(変数群)と関数を関連付けすることでデータがデータとして存在するだけで意味がわかるのがオブジェクト指向
たとえば貨幣として扱いたいデータに対して、貨幣として必要な機能だけに関数を限定させれば、それはもうデータが存在するだけで貨幣として意味がわかる(貨幣以外の動作が起こり得ないから)

関数型言語だとデータを出力するまで貨幣かどうかは信用できない
変数 kahei に対して全ての関数が利用できるから、kahei はどうとでもなり得る

コメントつけろとかそういう原始的な話じゃなくてね
378 :
2015/11/02(月) 05:08:00.98 ID:tRZ2mEuQ
その辺は言語の構造によって違うが
つーかオブジェクトの使われ方も言語によって全然違ったりするのでね
379 :
2015/11/02(月) 08:23:24.30 ID:+vmX+mwq
あ、オブジェクト指向言語の実装とはちょっとかけ離れた例え話な
関数型言語で生きてきた人間にオブジェクト指向を説明する時にこういう話し方をする

勿論、実際には外部にある関数を変数に関連付けするわけじゃなくてクラス内部にメソッド(≒関数)を実装するわけなんだが

カッチカチの関数型人間がオブジェクト指向の意味を理解できるように、多少強引に言葉を改編してる

つっても >>377で理解できるのはカプセル化のメリットだけだからまだ全然オブジェクト指向を説明しきれていないが
380 :
2015/11/22(日) 11:27:04.36 ID:yehd6qpM
ネットで調べていてもオブジェクト指向が分からない…。

仕事でVB(昔の)やってたんだけど、画面のプログラムは目次状態で動かす部分は全てモジュールに作って入れてた。
画面の目次(仮名)には
<モジュール名>//○○を行う
が続いてる状態で中身はモジュールへ、モジュール使い回ししながら作ってたんだけど(時折モジュール内にも目次できたりしてた)
これはオブジェクト指向とは違うの??
モジュールがクラスになっただけちゃうんかなって、うーん良く分からない。

違いを教えてください。
381 :
2015/12/17(木) 16:14:25.39 ID:f9fm3u2u
全てプリミティブかつアクセサ禁止って破綻してる
アクセスできないからプログラムも書けん
382 :
2015/12/18(金) 04:38:42.92 ID:TCff1iV0
>>380
vbのユーザー定義型とそれを扱うモジュール内の関数を一つのかたまりとして収めたのがクラスの考え方の原型。
vb なら本当のクラスも定義出来るんだが使ったこと無いのか?
383 :
2015/12/18(金) 07:38:43.70 ID:VKllly6g
>>382
ありがとう。
うーん、前職、書き方に制限ありまくりだったからクラスって本当に分からない。
情報系の大学だったけどプログラミングはほとんどやらなかったのに、基礎があるからって叩き上げられた形だったのよね。前職。
VB456にあるのかな。
.NET使う頃にはSEになってしまったから.NETもさわりしか分からない。
何かもう自分取り残されてるな…。
384 :
2015/12/18(金) 20:50:42.22 ID:rBQUliqS
一ヶ月も前のをまだ待ってたんかいな。
検索すればいきなり出てきそうなもんだけど。

オブジェクト指向ってのは、
データ構造と処理構造を動的にかつ個別に、そしてそれらを一体化して管理できるようにできる仕組み。

全部まとめたその一連の一体がクラス
動的に個別に扱ってるデータがインスタンス
インスタンスに対応した処理がメソッド
インスタンスを発生させるのがそのクラスのコンストラクタ
いらないインスタンスを消すのがデストラクタ

インスタンスってのは、動的に作られたクラスデータ(専用型)であり、さらにそのクラスが持つメソッドを呼び出すことが出来る。
したがってこう書ける。

//インスタンス = クラス名->コンストラクタ(引数);
//戻り値 = インスタンス->メソッド名(引数);

うさぎ = 動物->new(耳が長い、白い); //コンストラクタ起動。動的に新データを生成します。うさぎが産まれました。インスタンスは必要な情報を全て保持しているかのように振舞います。
きりん = 動物->new(首が長い, 黄色い); //きりんが産まれました。


跳ねた距離 = うさき->動け(跳ねろ); //動物クラスが持つ、動くメソッドをうさぎに適用しました。うさぎは跳ねたときのデータに書き変わります。疲労度が増えてるかもしれません。戻り値は跳ねた距離です。
食った葉っぱの枚数 = きりん->食え->(柳); //きりんに柳の葉っぱを食わせます。きりんの内部データは自動で腹が膨れます。戻り値として食った葉っぱが返されます。

きりん->死ね; //デストラクタ。キリンに関するデータを全部メモリから消去します。


メソッドは関数のようですが、当然インスタンスからしか呼ぶことができず、名前空間を汚しません。
きりんからメソッドを呼ぶと、メソッドはきりんの情報を受け取ります。(もしくはメソッドやクラス全体はきりんの情報をすでに持っていて、きりんから呼ばれたことをメソッド自身は知っており、きりんのデータを扱えます)。
385 :
2015/12/22(火) 12:13:39.68 ID:aBFh4Ipr
勘違いが多々見受けられるので、もう少し勉強したほうがいいね。
386 :
2015/12/31(木) 03:23:42.07 ID:riQaChnP
その言語のオブジェクト指向か、オブジェクト指向自体の定義か。
かなり違う。
387 :
2016/03/27(日) 21:38:57.58 ID:N7IGtcj3
結局、設計って何のためにするの?
って言ったら読む人間にわかりやすくするためだから
いくら哲学でガチガチに固めても読み手が
「何これさっぱりわからなーい」って言ったらそこで終わりな
設計書と内容が乖離してるソースもクソだし
どの仕様を実現しようとして書いたコードなのかわからないのもクソ
そもそも仕様の定義が明確でないのなんてソース書く前からクソが漏れてる

ブリブリブリブリ漏れてる!
388 :
2016/03/28(月) 21:59:57.56 ID:jI9F+kOe
家と同じ
無計画に建てたらあばら家になる
389 :
デフォルトの名無しさん
2016/03/29(火) 09:35:59.83 ID:/c8bAcK4
サッカーブッシュ日本代表日程ぷあたん(しゅっちょうまいくろ教育長交代)春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ24チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン(販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート
390 :
2016/03/29(火) 21:13:02.91 ID:WTA2j3Vp
オブジェクト指向に何故するかと言えば
変数、プロパティは全てpublicにすればいいじゃないかと言うところから始まる
391 :
2016/03/30(水) 09:31:45.09 ID:idf8Q5SU
それなんて構造体?
カプセル化なんて常識じゃんw
392 :
2016/03/30(水) 20:08:05.29 ID:H6rY7wzp
>>391
常識になってるが故に何故する必要があるのか説明が出来ない人が多いかと

例えばオブジェクトのプロパティを全てpublicにしてコンピューターからしてみたらそれで何の問題があるのかと
393 :
2016/04/01(金) 18:13:49.68 ID:ELyCfH/G
>>392
ばか?
394 :
2016/04/01(金) 18:22:47.72 ID:TewsBR2n
>>393
でも全publicのプログラムって何の問題もなく動きますよね?それが悪いんですかね?
395 :
2016/04/01(金) 18:28:15.95 ID:j6FPRdfu
CPUがpublicかprivateか判断するのか
396 :
2016/04/01(金) 19:43:57.88 ID:RonLnaIy
あ、アセンブラ的な話はちょっと、、
397 :
2016/04/02(土) 06:38:34.56 ID:vYH8mHjR
>>394
もうちょっと気合い入れて釣れよ
398 :
2016/04/02(土) 16:15:31.86 ID:P45UDLlW
>>397
えー結構いいキレ具合やろ
399 :
2016/04/03(日) 21:25:16.27 ID:AFllrpm9
キレ過ぎてストライクゾーンから外れてるんやで
もうちょい工夫して再チャレンジするように
400 :
2016/04/03(日) 23:25:16.70 ID:I1bXI3bS
じゃあここはオブジェクト指向の大敵publicおじさん登場という展開の方針で
401 :
2016/04/03(日) 23:37:46.54 ID:GlCd9dIf
Setter getter使えw
402 :
2016/04/04(月) 19:02:28.23 ID:Pgq0yCJI
大敵はstaticおじさんだろ?
403 :
デフォルトの名無しさん
2016/05/01(日) 15:58:07.83 ID:tKi6j9CT
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?

Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
404 :
2016/05/05(木) 17:44:51.45 ID:uHWe44q7
OOPに毒されすぎた人間はOCamlをやるべき
オブジェクト指向を活用できる部分は驚くほど少なく、殆どの問題はポリモーフィズムで静的に解決できることを知るだろう
OOの本質であるメッセージパッシングを活用できる場面を見極めることができるようになるだろう

オブジェクトの階層構造のデメリットが分からないなら、traitを知るべきだろう。

階層構造の設計、リファクタリング、デザインパターンの適用は仕事をした気になるが、
それらのほとんどが、何でもOOで問題に取り組もうとしたから発生する必要性だと気付くべきだ
405 :
2016/05/17(火) 16:15:23.13 ID:PHOPFQsz
OCamlってそんなに駄目な言語なの?
406 :
2016/05/18(水) 01:04:43.37 ID:ErRdtrnJ
みんなにとってオブジェクト指向ってどんなの?
言語がJavaやC#だったり、Hibernateとかの有名ライブラリ使ってればオブジェクト指向?
「受注Entityにはgetterでカプセル化された各変数と、決済・出荷・返品・破棄のメソッドがあって...」みたいにビジネスロジックまでがっつり?

後者の失敗した感じの奴を引き取るハメになったんだが、巨大で邪悪な状態地獄を前に吐きそう・・・
407 :
2016/05/23(月) 21:43:40.30 ID:VxHtpmL+
>>406
>決済・出荷・返品・破棄のメソッドがあって

クラスじゃないの?
そうだとしたら凄そうだな。
とりあえずリファクタリングが許されるなら、機能ごとにクラス化して責務をきちんと分けるとか。
でもきっとパッチ当てるような修正しか許されないんじゃないかな。

頑張ってくださいとしか言いようがないです。
408 :
2016/05/24(火) 14:37:31.12 ID:kSJa5DY/
>>407
ありがとう…
手持ちの知識と経験で最初から実装するなら「振る舞いを持たない受注Dto」と「状態を持たない受注各種操作サービス」で作ると思う。
それとも「受注Dtoを包んだ受注操作Executer」みたいなのがOOPっぽくて良いのかな。

どうしてこうなったんだろ
入門書の自動車クラスを忠実に参考にしたのかな
409 :
2017/03/25(土) 13:05:46.69 ID:Hepb4FxQ
ふるまいを持たないクラスと状態クラスを分離したいよね
その設計指針は全くもって正しいと思う
でもそれはオブジェクト指向を真っ向から否定してるんだよね

我々の言葉に言い換えるとこうだ
データとふるまいが合併しているクラスは、プログラムサイズが巨大化するにつれて問題であるとわかった

なぜかといえば状態がそこらじゅうのクラスにちりばめられていてプログラマやSEがコントロールが不可能な領域になっている
だからふるまいと状態を分離しよう

ふるまいを失ったクラス、それは構造体あるいは単なるコンテナだ

状態を失ったクラス、それは単なる関数だ
つまり君が直感的にやりたいとおもっていることは実は関数型なわけだ

もしベースがJavaならScalaまたはclojureで再実装することをおすすめする

もしJavaでやるなら君がいった通り、サービスクラスとコンテナクラスに分離するべき

これはトランザクションスクリプトとよばれ、OOP界隈ではディスられているやり方だけど、(なぜならクラスという概念を否定してるから)、こっちのほうが設計がシンプルかつ明瞭にたもたれると思う
個人的にはjavaでこれをやりたくないけどね
410 :
2017/03/28(火) 18:35:33.54 ID:wSpDlXLz
一年近く前のレスになにを書いてるんだって思ったがそれは置いておいて、
最初にオブジェクト指向を学んだ時、もっとも意味不明でかつ無意味な単語が「ふるまい」だった。
411 :
2017/03/29(水) 09:44:06.57 ID:PMA68UxV
>>410
> 「ふるまい」

Smalltalkなら言語レベルで組み込みの概念なんだけどね…

ProtoObject
 Object
  Behavior
   ClassDescription
    Class
    Metaclass
173KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: