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

1 ：デフォルトの名無しさん：2014/03/25(火) 21:44:07.66 ID:AtcH5MLU.net

お願いします。言語は問いません。
オブジェクト指向言語じゃなくても
オブジェクト指向の話であれば問題ありません。

2 ：デフォルトの名無しさん：2014/03/25(火) 21:52:21.12 ID:EiPXCdKp.net

アイ　オブジェクト　たべたい

3 ：デフォルトの名無しさん：2014/03/25(火) 21:53:45.99 ID:pgzxn/ED.net

オブジェクト指向の活用方法とあらためてきかれてもな。
仕事やってるなら、オブジェクト指向以外を使うことのほうが
まれだよ。まあ空気のようなものだ。

4 ：デフォルトの名無しさん：2014/03/25(火) 22:27:48.82 ID:NjDRIK2T.net

ポリモーフィズム

5 ：デフォルトの名無しさん：2014/03/26(水) 00:23:07.66 ID:u5ViS8To.net

もしオブジェクト指向がなかった場合に困るのであれば、あなたが一体どんな風に
困るのかを教えてください。自分は困ったことがないので。

6 ：デフォルトの名無しさん：2014/03/26(水) 00:32:00.76 ID:2aKYqEvM.net

>>5
俺はオブジェクト指向以外の方法論を知らない。
逆にどういうのがオブジェクト指向じゃないのだ？

7 ：デフォルトの名無しさん：2014/03/26(水) 00:43:25.50 ID:q9v11IGY.net

SQLは関数型言語ですが何か？業務プログラマじゃないのがバレバレな発言だね。

8 ：デフォルトの名無しさん：2014/03/26(水) 00:49:07.29 ID:czRoHAkF.net

困るのは関数の数が数百だとか数千だとか、ある程度規模が大きい場合だな。

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

そういう便利なモジュール化を最初から言語仕様に取り込んで
class{} とするだけで誰でも簡単にモジュールが作れるようにしたのが
オブジェクト指向言語。

9 ：デフォルトの名無しさん：2014/03/26(水) 00:52:05.00 ID:2aKYqEvM.net

へー、SQLは関数型なのか。
俺は業務プログラマじゃないよw

10 ：デフォルトの名無しさん：2014/03/26(水) 00:56:46.58 ID:UFBUrpIy.net

SQLが関数型であるという考え方は、
C言語は関数を定義するから関数型だよね、と同じ

11 ：デフォルトの名無しさん：2014/03/26(水) 00:59:32.24 ID:rbVA5aPF.net

SQLは宣言型言語だったかと。HTMLもそうだけど。

12 ：デフォルトの名無しさん：2014/03/26(水) 01:47:31.32 ID:u5ViS8To.net

>>8
それは関数名や変数名を区分して、ネームスペースを分けるというところまでで
十分目的を達成できるように思えるのだけれど、それで達成できないことは何？

13 ：デフォルトの名無しさん：2014/03/26(水) 01:54:10.43 ID:XRtgkR6L.net

それで出来ないのは属性の隠蔽と、継承による親子関係だな
まあ継承には最初はそんなにお世話にならんが、ある程度のクラス群を定義してくと
それらにグループ的な物が出来てくると思う

14 ：デフォルトの名無しさん：2014/03/26(水) 05:17:45.52 ID:q9v11IGY.net

実は、SQLは集合論を基にしているという点で、ある種の関数型言語とも考えられる（言語と
しては制限が多すぎるにしても）。
thinkbiganalytics.com/programming-trends-to-watch-logic-and-probabilistic-programming/

15 ：デフォルトの名無しさん：2014/03/26(水) 07:05:24.48 ID:q8kXJDbw.net

>>12
実運用

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

ちなみに俺も、１人で行うC言語の開発ではオブジェクト指向的に関数名や変数名を区分して作る。

16 ：デフォルトの名無しさん：2014/03/26(水) 07:48:30.63 ID:5lLsdkXL.net

>>14
集合論ベースなら論理型じゃないのか？

17 ：デフォルトの名無しさん：2014/03/26(水) 09:03:17.98 ID:isiCXEht.net

SQLはクエリーであって、つまり問い合わせであって
それだけでアプリケーションになるわけないしな。

実際にSQLだけでアプリを作ったことあるのかい？って話。

18 ：デフォルトの名無しさん：2014/03/26(水) 09:10:42.35 ID:isiCXEht.net

>>12
> それで達成できないことは何？

複雑さの低減かな。

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

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

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

読んで考えなきゃいけないことが、
単語一つで、あぁあれね。とすぐに知ることが出来る。
そういうコードになる。

19 ：デフォルトの名無しさん：2014/03/26(水) 12:27:56.78 ID:Vvdm35l0.net

>>17
オセロくらいなら作れそうだな
ちょっと面白そう

20 ：デフォルトの名無しさん：2014/03/26(水) 19:13:13.84 ID:C/yXeurz.net

SQLはチューリング完全じゃないんでしょ

21 ：デフォルトの名無しさん：2014/03/26(水) 20:05:10.15 ID:u5ViS8To.net

>>18 複雑さの低減のところ、詳しく。
オブジェクト指向について書かれた本だと例題がそもそも短いので、オブジェクト
指向の導入によって逆に長い記述になってしまうし、わざとらしい例ばかりなので
これで本当に分かりやすくなったの？生産性や保守性は本当に上がったの？という
点がいつまで経っても納得がいかない。
（いまどきの学校なら、先生がちゃんと教えてくれるんだろうか？）

22 ：デフォルトの名無しさん：2014/03/26(水) 20:36:30.54 ID:65VtCojr.net

18じゃないが。
電気回路で例えたら、抵抗とかダイオードとかトランジスタがびっしり基板を埋め尽くす
回路を作っていたのを、ICチップ数個を配線して繋げればいいだけにした
みたいなものかな。

ICチップ自体を作るところで確かに手間はかかるけど、
そのICチップという単位で手軽に扱える便利さが出てくるよね。

23 ：デフォルトの名無しさん：2014/03/26(水) 20:54:01.45 ID:lornT58y.net

オブジェクト指向によるループの簡略化ってなんだ？アイテレータか？
foreach構文使える言語ならOOPしなくても簡略化できるぜ。

24 ：デフォルトの名無しさん：2014/03/26(水) 21:17:17.67 ID:lornT58y.net

構造化プログラミングでは「機能」で全体を切り分けてた。
それがC++などのオブジェクト指向プログラミングになると「オブジェクト」で全体を切り分けるようになる。

電気回路に例えるなら、
それぞれの機能は基盤ごと、チップごとに整理されているが電源が一つしかない状態が構造化プログラミング。
それぞれの機能が自前の電源を持ってるのがオブジェクト指向。

25 ：デフォルトの名無しさん：2014/03/26(水) 21:43:06.83 ID:dEVLbQ7F.net

>>23
そういうレイヤーの話じゃないんだよね。

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

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

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

物の生成をどうするか？
物の構造をどうするか？
物の振る舞いをどうするか？

26 ：デフォルトの名無しさん：2014/03/26(水) 22:07:44.33 ID:dEVLbQ7F.net

>>21
たとえばゲームで考えるとね。キャラクターを横に1つ移動するはX座標をプラス1するだけ。
だけどこれだけじゃゲームとして成り立たない。キャラクターには座標以外にも色々な情報がある。

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

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

つまりこういうこと。

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

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

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

この時大抵の人ならデータと処理を分離せずに分けていくと思うから、それがオブジェクトになるんだよ。
オブジェクト指向でなかったら、最後にデータと処理に分けてそれを関連付ける処理まで考えなといけない。
分けるたびに数は増えるから最後は膨大になるよね。それは嫌だから一つ手前のオブジェクトにしておきましょう。

27 ：デフォルトの名無しさん：2014/03/26(水) 22:19:45.69 ID:2aKYqEvM.net

要は、プログラマが問題解決の為に注目するスコープを、小さくするって事だよな。

28 ：デフォルトの名無しさん：2014/03/26(水) 23:16:50.71 ID:dEVLbQ7F.net

オブジェクト指向使わないでも ”出来る” とかいうやつがいるけど、
出来るのは出来るんだよ。
重要なのはどれだけ複雑にしないで出来るかということ。
その複雑という観点が抜けてる意見は的外れで参考にならない。

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

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

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

例題程度の短い問題で、オブジェクト指向の利点を感じないのも
短い問題だからという理由で説明できるね。

29 ：デフォルトの名無しさん：2014/03/26(水) 23:42:37.18 ID:u5ViS8To.net

(A) オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
　→ 手間が増えるところ
(B) だけどクラス内のプロパティとメソッドの関連付けに対して名前を付ける必要がない
　→ 手間が減るところ

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

abs(B) ＞ abs(A)

ということになり、これが「複雑さの低減」という理解で合ってますか？

30 ：デフォルトの名無しさん：2014/03/26(水) 23:52:53.55 ID:u5ViS8To.net

もしそうだとすると、自分がオブジェクト指向のありがたみが分からないのは

abs(B) ＝ abs(A)

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

31 ：デフォルトの名無しさん：2014/03/26(水) 23:55:51.39 ID:lornT58y.net

>オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
javascriptみたく、プロトタイプベースのオブジェクト指向あるから、
これは必ずしもオブジェクト指向に当てはまる性質とは違う。
もちろん、名前付けてもいいけど。

32 ：デフォルトの名無しさん：2014/03/26(水) 23:56:29.04 ID:2aKYqEvM.net

>>30
ちょっと違うな。　そこは大した問題じゃ無いよ。
問題にしてる複雑さっていうのは、どう頑張っても理解できない複雑な構造の事。

33 ：デフォルトの名無しさん：2014/03/27(木) 00:03:01.47 ID:gcsG9K2Q.net

>>29
少し微妙なところはあるけれど、

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

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

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

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

多くのプログラミング技術っていうのは、大きくて複雑な問題を
解決するために考えだされているものだから、
簡単な問題を使わなくても出来る というのは意味がなくて
大きな問題で比較しないといけない。

34 ：デフォルトの名無しさん：2014/03/27(木) 00:04:50.94 ID:2gDV9B/K.net

ICチップの例でいうなら、その中に１個のダイオードしか入っていないものを作っている
ので、ICにする意味がない（なかった）、ということです

35 ：デフォルトの名無しさん：2014/03/27(木) 00:08:07.39 ID:1568NTop.net

>>29
実際にやって見るのがいいと思う

C#とかなら、書き込みや読み込みを行う抽象クラスであるStreamをとるメソッドに、ファイル、メモリ、ネット、データベースなんかを区別なく渡せたりする
自分でStreamを実装したクラスを作れば、それを利用する側は一切の修正なしに自作のStreamを使える、とか。

36 ：デフォルトの名無しさん：2014/03/27(木) 00:11:02.12 ID:ZCk9J0RA.net

>>34
そのダイオードがオブジェクトだよ。
ダイオードには入力と出力があってダイオードの仕事をするだろう。
入出力というinterfaceがわかれば、中はブラックボックスでいい。
外から見た時に、中がどんな仕組みなのかは知らなくてもいい。
それがオブジェクト指向だ。

37 ：デフォルトの名無しさん：2014/03/27(木) 00:11:39.64 ID:j3gvVEw0.net

クラスを作る目的の１つは、ある変数に対してアクセスする関数群を同じクラスにまとめて、
変数自身は極力非公開にして、どこからか勝手にいじられないように隠蔽することだよ。
カプセル化というんだけどね。

38 ：デフォルトの名無しさん：2014/03/27(木) 00:14:40.12 ID:j3gvVEw0.net

>>36
それは関数も同じでは？
入出力が分かれば、中はブラックボックスでいいよね？

むしろ単機能という点ではダイオードはむしろ関数に近いかと。

39 ：デフォルトの名無しさん：2014/03/27(木) 00:18:11.94 ID:gcsG9K2Q.net

俺もダイオードは関数だと思わ。

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

その製品を作るために各パーツどうやって組み合わせて効率よく作るか
という方法論としてソフトウェアではオブジェクト指向があると思うよ。

40 ：デフォルトの名無しさん：2014/03/27(木) 00:26:18.85 ID:2gDV9B/K.net

>>37 そうだとすると、１つのプロパティしかないような場合でもクラスにする価値が
あるということなんだろうけど、勝手にいじられるものが"変数"なのか"関数"なのか
というだけなので、結局同じに思えてしまうなあ
(暴走を引き起こすような)でたらめな値を設定できないようにするということかな？

41 ：デフォルトの名無しさん：2014/03/27(木) 00:28:46.02 ID:ZCk9J0RA.net

>>38,39
クラス内部もオブジェクト指向で書くんだよ。
だから関数・メソッドもオブジェクトとして捉える。
ICの中にもICが入ってるだろ？
注目するスケールが違うだけで、方法論は変わらない。

42 ：デフォルトの名無しさん：2014/03/27(木) 00:29:16.59 ID:2gDV9B/K.net

フリップ・フロップならオブジェクトかもしれないね

43 ：デフォルトの名無しさん：2014/03/27(木) 00:32:34.40 ID:gcsG9K2Q.net

一つのプロパティしかないクラスであっても
アプリ全体で、そのクラスだけしか使ってないってことはまず無い。

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

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

小さな視点ではなく、大きな視点を持つこと。
大きな視点を持てば、たまたまプロパティが一つしか
無いクラスがあったとしても、それがシステム全体として
必要なことであればなんら不思議ではない。

44 ：デフォルトの名無しさん：2014/03/27(木) 00:39:43.19 ID:E6f/eeJ0.net

javaなんかだと標準出力に文字を表示するのにSystem.out.println("Hello World!"); なんてことやってるわけで
ダイオードがstreamの一種ならオブジェクトで問題ない。
仕組みの複雑さが外から見えないという意味で、ダイオードは実に成功していると言えるだろう。

45 ：デフォルトの名無しさん：2014/03/27(木) 00:41:16.91 ID:gcsG9K2Q.net

オブジェクト指向の話で
クラスとインスタンスの話で
終わっちゃう人がいるけど、

オブジェクト指向の話には
インスタンスとインスタンスを組み合わせて動かすという
構造の話、組み合わせ方の話も含まれるよ。

46 ：デフォルトの名無しさん：2014/03/27(木) 00:42:23.36 ID:gcsG9K2Q.net

インスタンスとインスタンスを組み合わせだけじゃなくて
クラスとクラスの組み合わせも。
（クラスの代わりにインターフェースだったりもする）

ほんと関数の中身などという小さな部分じゃなくて
全体を見ないとね。

47 ：デフォルトの名無しさん：2014/03/27(木) 00:43:14.26 ID:E6f/eeJ0.net

ハローワールドでさえオブジェクト指向の真髄に触れてるわけで、
小さいプログラムだからOOPの恩恵が無いなどということはない。
Javaでは十分に抽象化され、簡便に使えるように用意されたライブラリ群を使っているではないか。

でも何でもかんでもオブジェクトにしてしまおうとするのは疑問だな。

48 ：デフォルトの名無しさん：2014/03/27(木) 00:43:29.31 ID:ht0q0Cmu.net

組み合わせが固定的な場合、一見オブジェクトに見えても単なる構造化にすぎないことが
多い。新しいオブジェクトをくっつけようとして、全部のオブジェクトを書き換えるはめになる。
依存性が多すぎるのだ。究極まで依存性をなくして何でも接続できるようにしたものを、
Inversion of Control (IoC), とか dependency injection (DI) と呼ぶ。テスト環境と本番環境と
で、まったく同じモジュールを動かしてテストできるようになる。が、何もかもIoCやDIにでき
るわけではないので、本当に使えるケースはあまりない。仕掛けが大掛かりすぎて、一行の
SQLやスクリプトに負けてしまうことも多い。

49 ：デフォルトの名無しさん：2014/03/27(木) 00:47:32.14 ID:gcsG9K2Q.net

IoCやDIを使うところは構造に関する所だと思う。
クラスがアプリの構造を表している所だと思う。

クラス（インスタンス）を値として使う場合
たとえばBigInt型みたいな、int値の巨大版みたいな
"値" にはDIを使わない方がいい。
こういう場合は値として普通にnewした方がいい。

50 ：デフォルトの名無しさん：2014/03/27(木) 00:50:57.11 ID:2gDV9B/K.net

規模の話が出てきたので、アンケートをとってもよいでしょうか？

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.net

>>50
えと、そのコードを客観的に評価してもらったことある？
たとえばコードメトリクスツールで計測するとか。
その評価がないと、それ見てもなんの参考にもならない。

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

コピペがだめな行為だってのは言うまでもないと思うけど、
コピペをすると簡単に行数稼げるよ。

52 ：デフォルトの名無しさん：2014/03/27(木) 01:17:32.04 ID:gcsG9K2Q.net

>>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.net

関数や変数は多めに数えたんですが、こういった規模でもオブジェクト指向を活用できるのか
どうかを知りたかったのです。関数はさておき、変数はがんばって捻出しても増やせないと思
います。関数は増やせるかもしれませんが、無理をしそうな気がします。つまり不自然なソー
スになりそうです。

54 ：デフォルトの名無しさん：2014/03/27(木) 01:21:39.80 ID:gcsG9K2Q.net

>>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.net

>>53
変数は増やす意味は無い。
それで良いコードになったりも悪いコードになったりもしない。
どちらかと言えば少ない方がいいが、
少なくするほどいいってことでもなく無駄を無くす程度でいい。

56 ：デフォルトの名無しさん：2014/03/27(木) 01:24:04.56 ID:ze0m1e8o.net

オブジェクト指向はプログラムの問題というより人間の問題に近い。
オブジェクト指向にすれば、人間らしい仕様変更に比較的強いというだけの話。

57 ：デフォルトの名無しさん：2014/03/27(木) 01:26:05.92 ID:2gDV9B/K.net

>>54 いや、違います。１関数あたり10行位です。残りがメインルーチンです。

58 ：デフォルトの名無しさん：2014/03/27(木) 01:30:04.40 ID:ZCk9J0RA.net

>>50
1ファイルで10000行は見通し悪くないかねw
俺のは簡単に言うとだが、シンセで80ファイル、各200から1000行程度。
電卓で50ファイル、各100から1500行ってところだな。
長い関数で120行ぐらいだよ。

59 ：デフォルトの名無しさん：2014/03/27(木) 01:31:59.53 ID:1568NTop.net

ものによるんじゃない？
テキストフィルターがどういうものかわからないけど、変更に強くするとか再利用できるようにするとか

ただ、無理に小分けにしても返って複雑になることもありうる

60 ：デフォルトの名無しさん：2014/03/27(木) 01:32:11.42 ID:gcsG9K2Q.net

アンチパターン（悪いコートパターン）本に
"メイン"ルーチン という名前がでてきたら
それはアンチパターンだって書いてあった気がするなｗ

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

一度コード品質計測してみるといいよ。
10点満点中1点未満とか言われるだろうから。

61 ：デフォルトの名無しさん：2014/03/27(木) 01:34:26.69 ID:2gDV9B/K.net

着目したい変数/関数があったとき、grep するとプログラムの実行順と同じ順序で
表示されて便利です。

62 ：デフォルトの名無しさん：2014/03/27(木) 01:37:53.70 ID:gcsG9K2Q.net

で、なんでコードの品質の話をしたかだけど、
技術力が低い人は、良いコードとダメなコードの違いがわからないから。

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

だからそのレベルでオブジェクト指向の利点がわからないのも無理はないし、
現時点でオブジェクト指向は意味が無いって結論づけたらダメだよ。
単に君がまだ未熟だから（それははっきりわかった）ってだけだから。

63 ：デフォルトの名無しさん：2014/03/27(木) 01:42:00.90 ID:E6f/eeJ0.net

>>62
なんでそんなに追い詰められてんの？

64 ：デフォルトの名無しさん：2014/03/27(木) 01:47:38.94 ID:gcsG9K2Q.net

>>61
プログラムの実行順が気になる？
それは抽象化ができてないから。

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

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

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

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

順番なんて気にしていたら、ユニットテストで関数をテストするときどうするのさ？
ユニットテストではある関数を狙い撃ちでテストするのよ？

65 ：デフォルトの名無しさん：2014/03/27(木) 01:48:13.52 ID:gcsG9K2Q.net

>>63
なんでそう思ったの？
俺は新人に教育している気分なんだけどｗ

66 ：デフォルトの名無しさん：2014/03/27(木) 01:48:36.67 ID:E6f/eeJ0.net

LoCは何かと馬鹿にされがちだけど、
逆にCOCOMO2でとか言われても誰が答えられるってんだっていう。
つか変数や関数の数って何だよ。どうしてそれが気になる。コボラーか？
俺はどれも気にしないし、計測ツールもいれてねえよチクショウ。

67 ：デフォルトの名無しさん：2014/03/27(木) 01:49:47.41 ID:2gDV9B/K.net

(オブジェクト指向から離れちゃうけど)関数を一画面に収まる規模にして、複数の関数から
構成するようにすると、関数呼び出しが発生することになってしまいます。それが必然性が
ないものだったら、ロジックを追いづらいし、メンテしずらくなってしまうような気がしま
す。大体、関数の名前を考えるのに苦労してしまって、変な名前をつけちゃいそうです。
個人の技術力の問題であれば、しばらくROMってます。

68 ：デフォルトの名無しさん：2014/03/27(木) 01:53:16.02 ID:gcsG9K2Q.net

LoCは「同じ仕様のアプリを作った時に短いほうが優れているだろう」という
判断には使えるがそれ以外の目的では使えないよ。

LoCが多くてもは生産性が高いことにはならない
（たとえばコピペをすれば簡単に水増しできるが、これは品質を下げる行為）

69 ：デフォルトの名無しさん：2014/03/27(木) 01:55:37.34 ID:zuVXk4tw.net

Javaは現代のCOBOL

70 ：デフォルトの名無しさん：2014/03/27(木) 02:05:57.47 ID:gcsG9K2Q.net

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

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

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

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

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

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

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

そうやって読むべき所を減らしていけばいいんだよ。関数の中を見なくて済むような
そんな関数にしていけば、関数呼び出しが発生してもロジックは追える。見なくて言い分早く追える。

71 ：デフォルトの名無しさん：2014/03/27(木) 07:13:03.30 ID:EL0PowgV.net

オブジェクト指向のこころは良い本だ

72 ：デフォルトの名無しさん：2014/03/27(木) 07:26:53.08 ID:6dxUJoHd.net

「オブジェクト」が参照なのって割と不便だよね。

73 ：デフォルトの名無しさん：2014/03/27(木) 10:03:27.48 ID:E6f/eeJ0.net

関数型プログラミング的に言うと、
副作用（内部情報を持つ、外部デバイスにアクセスする等）のある関数は
プログラムを複雑にする悪玉菌扱いなんだけどね。
かといって純粋関数だけでプログラムかけるかっていう現実問題はあるけど。
しかし問題の切り分け方として、データと処理がセットになることが必ずしも礼賛されるかというとそうでもない。

74 ：デフォルトの名無しさん：2014/03/27(木) 11:42:05.43 ID:pwhdAG7g.net

>>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.net

もっとも身近なオブジェクト指向の概念って、
ファイルやソケットのディスクリプタかな
説明もしやすいし理解も早い

76 ：デフォルトの名無しさん：2014/03/27(木) 12:52:47.48 ID:Q+RTv4Ce.net

ファイラー上で見るファイルオブジェクト
あれのポップアップメニューが変化するのを見せるのがよさそう

77 ：デフォルトの名無しさん：2014/03/27(木) 15:10:04.52 ID:qIhM9I6N.net

>>75
俺はStringクラスだと思うね。
この例を出すとどうも必ず叩かれるんだけどｗ

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

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

文字列データと、長さ、っていう非常に近い関係のものが、
内部に一緒に揃ってる。
一緒にあったほうがマシだから、一緒にある。
クラスの内側にそれを隠し持ってる。
そして、いろんなメソッドの内部でふんだんに参照してる。

78 ：デフォルトの名無しさん：2014/03/27(木) 15:29:20.56 ID:zuVXk4tw.net

strlenしないと長さが得られないのか、最初から長さを持ってるのか、
中身がどういう仕掛けになってるのか気にしなくていいのがオブジェクト指向なんじゃないの？

79 ：デフォルトの名無しさん：2014/03/27(木) 15:29:34.54 ID:Q+RTv4Ce.net

昔はそう思ったこともあるが実装とI/Fがあまりにも近すぎてよくない

80 ：デフォルトの名無しさん：2014/03/27(木) 16:23:36.30 ID:R9FKO6iJ.net

JavaのStringだと、lengthはフィールドじゃなくてメソッドでは？
内部で保持してるのかどうかは知らんが

81 ：デフォルトの名無しさん：2014/03/27(木) 19:09:37.68 ID:+xc3TnzN.net

>ファイルやソケットのディスクリプタかな
ハンドル持ち回りはCによる実装レベルでも十分確立されてるし
OO言語じゃないと実装がとても大変って例はないもんかね

82 ：デフォルトの名無しさん：2014/03/27(木) 20:16:21.85 ID:rDeXrVt7.net

>>77
オブジェクト指向の真髄はポリモーフィズムだと思ってるので
>>77の考え方に反逆するわ

83 ：デフォルトの名無しさん：2014/03/27(木) 20:31:07.44 ID:gcsG9K2Q.net

>>74
> 実際にはprintf()の中身は複雑なんですけどね。
いや、知ってるってｗ

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

これがいい関数の例。

中を見ないと、どんなことやってるかわからないよ〜。
となってるのが、悪い関数の例。

84 ：デフォルトの名無しさん：2014/03/27(木) 21:26:09.20 ID:ZhR8Azo0.net

C++のストリーム演算子らへんは何をやってるのかさっぱり判らない悪い例じゃないの

85 ：デフォルトの名無しさん：2014/03/27(木) 21:34:12.95 ID:gcsG9K2Q.net

>>84
何をやってるのかさっぱりわからないのは、
ストリーム演算子の中身の話であって、

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

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

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

86 ：デフォルトの名無しさん：2014/03/27(木) 21:55:08.72 ID:ZhR8Azo0.net

>>85
お話が通じないことが良く判ったよ
俺流オペレータが何をやってるのかは中を見なと判らないでしょ
だからストリーム演算子の例を出したのに「使う人は使える」

>（関数名は例ではない）
ちゃんとした関数名にすれば中身見る必要無いだろ

87 ：デフォルトの名無しさん：2014/03/27(木) 22:02:47.00 ID:ZhR8Azo0.net

printfも可変引数の仕組みと書式の関係が判ってようやく
初めて使えるレベルになるものだと思うけどな
それって結局中身見ないとまともに使えないでござるよ…って事にならないかね？
まさかこんなスレでprintfの中身を一度も見たことない奴なんていないだろうから
きっと錯覚してるだけだよ

88 ：デフォルトの名無しさん：2014/03/27(木) 22:06:56.92 ID:+xc3TnzN.net

そういう意味だと上のハンドル志向が一番解りやすい
中を見たいとも思わないし

89 ：デフォルトの名無しさん：2014/03/27(木) 22:09:08.87 ID:UpPNmNS/.net

誰かJava8のStreamの話をしてくれ。

90 ：デフォルトの名無しさん：2014/03/27(木) 22:12:33.90 ID:ZhR8Azo0.net

かなりprintf族もハンドル取るのあるだろ
いやそういうことではなくて、関数名だけでちゃんと表現できてれば中身見る必要なんてないんだよ
結局いくら関数化しても中身見ないといけないようなケースは必ず存在するんだよ

91 ：デフォルトの名無しさん：2014/03/27(木) 22:18:02.77 ID:GOaviY18.net

今言う中身は実装じゃね？
実装を知らなくても使い方が分かればいいと
例は良くわかんない

92 ：デフォルトの名無しさん：2014/03/27(木) 22:26:01.90 ID:ZhR8Azo0.net

実装を知らなくても使い方を想像できるってのは
裏返せば過去に自分が似たような物を作ったり設計書見たりとか
それなりの経験のある中の事じゃないの？
実装がさっぱり想像できないのをいくら眺めたところで
使い方が判るようになるとはとても思えないけど

93 ：デフォルトの名無しさん：2014/03/27(木) 22:27:02.26 ID:1568NTop.net

コメントとか仕様書とかに使い方が書いてあれば実装を見なくても済む
printfのすべての実装なんて見たことないけど、仕様書どうりの動作をするとわかっている

94 ：デフォルトの名無しさん：2014/03/27(木) 22:36:29.59 ID:GOaviY18.net

想像して使うってのはよく分からないけどsleep()とかsystem()はそれに近いかも？
使い方を知って、かつそれが曖昧になっても関数名や引数で思い出せるってところが分かり易さじゃない？
逆に見ても分からないってのは設計として複雑な気が
std::coutでいえば<<なら直感的だけど>>だと途端に恐怖を覚える

95 ：デフォルトの名無しさん：2014/03/27(木) 22:41:51.63 ID:zuVXk4tw.net

GoogleのC++スタイルガイドではストリームはやめろprintf使っとけって事になってるな。

96 ：デフォルトの名無しさん：2014/03/27(木) 23:09:47.29 ID:1568NTop.net

他の言語に全く採用されないところをみるに、たんに演算子いじれてすごいでしょアピールで実利はなかったんだったんだろう

97 ：デフォルトの名無しさん：2014/03/27(木) 23:29:08.64 ID:ZhR8Azo0.net

可変引数は呼び出し側自己申告以外にチェック機能が無いからバグの温床になりやすく
標準ライブラリからは除外したかったと昔どっかで読んだよ
正規表現みたいに書式と引数の型から判定するような仕組みは作れたはずだけど
それを言語仕様に含めてしまうと1関数でしかなかったprintfの書式文字列を
今更特別扱いするのは抵抗がとか紆余曲折あって全く別の方向に逃げた

98 ：デフォルトの名無しさん：2014/03/27(木) 23:34:55.71 ID:1568NTop.net

コンパイラが警告してくれるけどね

99 ：デフォルトの名無しさん：2014/03/27(木) 23:55:40.61 ID:gcsG9K2Q.net

>>86
> 俺流オペレータが何をやってるのかは中を見なと判らないでしょ
いつオペレータの話したの？

ストリーム演算子の話だったよね？

100 ：デフォルトの名無しさん：2014/03/27(木) 23:59:54.87 ID:zuVXk4tw.net

俺流オペレータの代表格だわな

101 ：デフォルトの名無しさん：2014/03/28(金) 00:09:53.54 ID:9wj0hHB8.net

代表格 ＝ 同じではないという意味。

102 ：デフォルトの名無しさん：2014/03/28(金) 00:14:00.53 ID:Ek64RinZ.net

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

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

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

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

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

話はこれと何も変わっとらん。反論にはなっていない。むしろ俺と同じことを言ってるだけ。

103 ：デフォルトの名無しさん：2014/03/28(金) 00:37:59.39 ID:MtUKbk72.net

例えばさ、AppleとかMicroSoftのAPIは実装非公開だし、実装知らなくても使ってますよみんな。

つか、中身はブラックボックスでいいって表現に語弊があるのかな。
全体の構造を見てるときは個々の中身は気にしなくてもいい、
個々の中身を検討してるときは他のオブジェクトは気にしなくてもいいって意味だよ。
スコープを小さくすればわかりやすいよねってこと。

104 ：デフォルトの名無しさん：2014/03/28(金) 00:40:38.80 ID:Ek64RinZ.net

そういうこと。全体の構造を見ている時に
個々の中身を気にしなくちゃいけないコードを書いているから

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

関数呼び出しでロジックが追いづらくなっちゃうわけ。
それは関数の作り方が悪いせいであって関数のせいじゃないんだよ。

105 ：デフォルトの名無しさん：2014/03/28(金) 00:53:28.66 ID:jDIkKEXq.net

本来シフト演算子なはずの << やら >> を入出力に使うっていうのが、
演算子オーバーロードの悪い使い方(=俺流オペレータ)の代表格だっていう話では。

106 ：デフォルトの名無しさん：2014/03/28(金) 01:15:21.16 ID:DmpYV1MJ.net

(構造化プログラミングのスレかな？)

107 ：デフォルトの名無しさん：2014/03/28(金) 01:52:09.43 ID:wFHfzfhB.net

（ここまでオブジェクト指向の活用方法の具体例なし）

108 ：デフォルトの名無しさん：2014/03/28(金) 01:54:17.33 ID:Ek64RinZ.net

>>105
話ずれてるなぁ。

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

ストリーム演算子は普通に記憶してるじゃんか。
中見ないでしょ？

109 ：デフォルトの名無しさん：2014/03/28(金) 02:34:08.23 ID:uMoDJ17A.net

具体例ならエロい人のソースを覗き見…
ぐへへ

110 ：デフォルトの名無しさん：2014/03/28(金) 11:21:32.67 ID:Vf+Kze9a.net

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

その三つの関数は、再利用もしないし、他からも呼ばれないんじゃないの？
だったら、中身を見る必要ないよね。
中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。

111 ：デフォルトの名無しさん：2014/03/28(金) 18:36:40.74 ID:Ek64RinZ.net

> 中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
ほら中見てるじゃんｗ

112 ：デフォルトの名無しさん：2014/03/28(金) 18:44:51.50 ID:VVPQgbpw.net

中身を見なくていい　＝　機能もバグ取りもドキュメントも完成してるってことだから
今自分または開発チームが手がけてる関数は全て悪い関数ということになる。

113 ：デフォルトの名無しさん：2014/03/28(金) 18:50:33.65 ID:QLpZv79z.net

>>112そうとは言い切れないよ。

関数の仕様がシンプルで覚えやすければいい。
覚えるには何度も使うことが必須で
結果的に汎用性が高い（だから何度も使える）ものってことになる。

114 ：デフォルトの名無しさん：2014/03/28(金) 18:58:13.19 ID:Vf+Kze9a.net

>>111
> ほら中見てるじゃんｗ
見ないとロジック追えないだろ。

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

このことと、その関数の良し悪しは関係無い。

115 ：デフォルトの名無しさん：2014/03/28(金) 19:03:06.04 ID:QLpZv79z.net

>>114
> > ほら中見てるじゃんｗ
> 見ないとロジック追えないだろ。

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

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


> 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.net

上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないような
コードになってるから、

コードを解析するときに、関数があるたびに
下位関数の実装先にあっちこっちジャンプしていって大変なことになる。

117 ：デフォルトの名無しさん：2014/03/28(金) 19:20:17.16 ID:QLpZv79z.net

ここから発展して、
privateメソッドが、privateメソッドを読んでいて
そのprivateメソッドが、更にprivateメソッドを読んでいて
更にそのprivateメソッドが、privateメソッドを・・・みたいに
（再帰ではなく）文法上のコールスタックが深いものも
ダメな関数の一例だろうね。

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

だから上位関数のロジックを追ってる時に
下位関数のロジックを追うことになる。

118 ：デフォルトの名無しさん：2014/03/28(金) 20:50:21.98 ID:VVPQgbpw.net

>>116からの>>117は誤解を生むだろう。
関数への切り分けが適切であれば、利用している関数内で何してようが関係ない。
そうでないから、切り分けがまずいから結果としてサブのサブまで降りていかないといけないというのはわかるが、
構造としてサブのサブを呼び出すことが悪というのは真ではない。

119 ：デフォルトの名無しさん：2014/03/29(土) 01:06:59.37 ID:YRxS2933.net

オブジェクト指向は1990年代の話題
当時は実装メモリも少なかったので、コンパイルサイズの上限に達しないように
コンパイル単位となるファイルや関数を小さくしなければならなかった。また
CPUの性能も低かったので、コンパイル単位を小さくすることで再makeにかかる
時間を節約していた。そうでなければとてもじゃないが、実務では使えなかった。
現代では分かりやすさを犠牲にしてまで、小さい関数を量産する必要はなくなっ
ている。
以上、教科書に載らないオブジェクト指向の歴史

120 ：デフォルトの名無しさん：2014/03/29(土) 01:21:57.46 ID:3OHlSsnI.net

>>29
名付けを手間と思ってる時点で…
そういうやつに限ってコメントはダラダラズラズラ書く

そのコメントへの労力をまるごとメソッド名なり変数名なりの名付けに当てれば問題ない

121 ：デフォルトの名無しさん：2014/03/29(土) 01:27:50.25 ID:3OHlSsnI.net

>>57
鳥肌立った

122 ：デフォルトの名無しさん：2014/03/29(土) 01:30:44.27 ID:3OHlSsnI.net

>>67
ずっと読んでて思ったけど、もしかしてこの人がstaticおじさん？

123 ：デフォルトの名無しさん：2014/03/29(土) 01:39:31.14 ID:3OHlSsnI.net

ようやくスレ全部読んだが、ポリモーフィズムとか委譲とかDIとかやってて、そういう話をしてるもんだと思って覗いたから
なんか逆に新鮮な気持ちになったぜ

俺が恵まれてるだけなんだろうが、50行を超える関数には出会ったことがない
自分でも書いたことがない

124 ：デフォルトの名無しさん：2014/03/29(土) 01:45:14.49 ID:2x5p0G/E.net

50行を超える関数ぐらい出会うだろ？
オープンソースのコード読んだことある？

125 ：デフォルトの名無しさん：2014/03/29(土) 08:53:28.56 ID:VG1PVttb.net

オブジェクト指向で作られたライブラリを手続きの中で利用するのがベスト。
自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。
オブジェクト指向は基盤レイヤーで収まっていればいい。
より上のレイヤーは構造化プログラミングとモジュール化で対応すべきだ。

126 ：デフォルトの名無しさん：2014/03/29(土) 10:41:15.74 ID:FZRsbrVI.net

>>125
>自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。

ならプログラマーなんかやめたほうがいい。適性なし。

127 ：デフォルトの名無しさん：2014/03/29(土) 13:47:53.85 ID:qOhcuGD/.net

言いたい事はわかる。きれいに階層化されたツリー構造の方が処理を追いやすい。
しかし、どうしてもオブジェクトグラフがネットワーク状になる場合があるし、
ユーザーがオブジェクトどうしを自由に接続できるアプリだってある。

128 ：デフォルトの名無しさん：2014/03/29(土) 14:12:25.86 ID:riFdWRlf.net

プログラマ適性なしは言い過ぎ
最近は非オブジェクト指向の言語も注目されてきてるよね

129 ：デフォルトの名無しさん：2014/03/29(土) 15:10:59.76 ID:T0jzXlJE.net

関数型の次はなんだ？

130 ：デフォルトの名無しさん：2014/03/29(土) 17:53:31.03 ID:nUN7khDD.net

OOだろうが非OOだろうが、
粒度の小さなデータ構造でネットワークを形成することを
「複雑にする」と思う時点でプログラミングに向いていない。

131 ：デフォルトの名無しさん：2014/03/29(土) 18:15:38.16 ID:VG1PVttb.net

メインルーチンでまとめて管理すればいいものを、
処理とデータをセットにすることに拘った挙句、
メディエータパターンなんてマヌケな再発明を強いられるOOPに哀愁を禁じえない。

132 ：デフォルトの名無しさん：2014/03/29(土) 18:26:03.80 ID:qOhcuGD/.net

巨大なメインルーチンねえ。描画とかどうすんのかな。

133 ：デフォルトの名無しさん：2014/03/29(土) 18:36:10.02 ID:VG1PVttb.net

描画はイベントドリブンか、メインループの中で描画オブジェクトの配列を作るわ。

134 ：デフォルトの名無しさん：2014/03/29(土) 19:00:43.30 ID:nUN7khDD.net

>>131
あんたも適性ないね

135 ：デフォルトの名無しさん：2014/03/29(土) 19:40:22.20 ID:VG1PVttb.net

しかたない。SEにでも転職するか。

136 ：デフォルトの名無しさん：2014/03/29(土) 20:02:51.62 ID:riFdWRlf.net

適性とかそういう話じゃないなコレ、教育不足に経験不足だ

137 ：デフォルトの名無しさん：2014/03/30(日) 02:19:44.18 ID:3Fl9YNZ5.net

数珠つなぎのメソッドチェーンを呼び出して何をするのかと思ったら、単に変数
に値を代入(または取得)して終わり、みたいのをよく見かけます。途中に現れる
メソッド名を見ても必然性を感じません。その階層で何をするでもないのです。
そういう場合はただの変数の代入に書き換えます。
(ついでなので)変数の名前はその目的が分かる名前に直します。

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

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

世界にひとつだけの名前にして衝突を未然に防ぎたい、ということでしょうか？

138 ：デフォルトの名無しさん：2014/03/30(日) 02:26:07.76 ID:3Fl9YNZ5.net

同じことがメソッド呼び出しにも言えます。チェーンしているメソッドがそれぞ
れ何を意味しているのか分かりづらい上、記述の順序と実行の順序が異なるので
す。

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

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

実行順序が隣り合っているものは隣り合わせて記述すると分かりやすいプログラ
ムになります。修正も簡単です。テキストエディタやgrepが強力なプログラミン
グツールになります。

139 ：デフォルトの名無しさん：2014/03/30(日) 02:40:59.19 ID:xYPcFXGk.net

>>137,138
オブジェクト指向の必要性とは、規模とか複雑さとか再利用性の問題だから、
当てはまらなければ気にしなくてもいいんだよ。

140 ：デフォルトの名無しさん：2014/03/30(日) 02:59:11.38 ID:WoVbd8CL.net

>>137-138
あなた、オブジェクト指向の話をしてないですよ。

141 ：デフォルトの名無しさん：2014/03/30(日) 03:06:19.07 ID:f3QUPmmN.net

メソッドチェーンが何かを知らない人に説明しておくと、

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.net

メソッドチェーンだと書いている順番に
処理が実行されるからわかりやすいんだよな。
オブジェクト指向だと、メソッド名短くても
かぶらないからその点でもメリットがある。

143 ：デフォルトの名無しさん：2014/03/30(日) 03:11:55.59 ID:F8tYL6fO.net

なあんだ！どっちの目を使うかなんだね！

144 ：デフォルトの名無しさん：2014/03/30(日) 03:28:36.95 ID:DA7dDHvX.net

> 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.net

これもオブジェクト指向の活用方法の一つだろうね。

146 ：デフォルトの名無しさん：2014/03/30(日) 03:34:47.32 ID:eSXxjJTc.net

だらだら連ねて1文に詰め込むのはデバッガで追いにくくなるからあまり好きじゃない。

147 ：デフォルトの名無しさん：2014/03/30(日) 11:13:41.29 ID:CUSBQvN9.net

>>139
>オブジェクト指向の必要性とは、規模とか複雑さとか再利用性の問題だから、

はずれ。

148 ：デフォルトの名無しさん：2014/03/30(日) 11:13:50.33 ID:Ep1/Keko.net

返り値をチェックして独自のエラーログを出したいｗ

149 ：デフォルトの名無しさん：2014/03/30(日) 11:14:24.92 ID:CUSBQvN9.net

>>146
どんなオンボロデバッガ使ってんだ？

150 ：デフォルトの名無しさん：2014/03/30(日) 11:52:19.72 ID:DA7dDHvX.net

>>146
つまり、

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

こういうのを

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

って書くってこと？

おっと、メソッドチェーンとは関係ない話だったから
関数の方でレスしちゃったｗ

151 ：デフォルトの名無しさん：2014/03/30(日) 11:57:24.64 ID:IecYjjCX.net

>>149
> value.foo().bar().baz()

bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ

152 ：デフォルトの名無しさん：2014/03/30(日) 12:01:26.08 ID:DA7dDHvX.net

訂正（笑）

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

bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ

153 ：デフォルトの名無しさん：2014/03/30(日) 12:07:13.82 ID:DA7dDHvX.net

メソッドチェーンならこれが使える。

メソッドチェーンの 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");


まあ関数でも使えるよ。見難くなるけどねｗ
baz(p(bar(foo(value, 1, 2), true)), "test");

154 ：デフォルトの名無しさん：2014/03/30(日) 12:32:55.33 ID:rCEPh8in.net

難しいことをしようとすれば、何を使っても複雑になる。
言語やパラダイムが複雑なんじゃなくて、解決しようとしている問題が複雑なだけなんだ。

155 ：デフォルトの名無しさん：2014/03/30(日) 12:47:55.23 ID:DA7dDHvX.net

えと、ああ、うん、
言語の違いっていうのは、問題がどうとかじゃなくて
読みやすさと書きやすさの違いの話なんだけどね。

156 ：デフォルトの名無しさん：2014/03/30(日) 13:17:38.07 ID:CUSBQvN9.net

>>151
え？そんな簡単なこともできない開発環境でオブジェクト指向とか大笑いだな

157 ：デフォルトの名無しさん：2014/03/30(日) 13:27:57.55 ID:3Fl9YNZ5.net

>>141
>シェルスクリプトで言えば
>cat var | foo | bar | baz というのを
このとき、foo や bar が何もしないプログラムであっても baz の前に入れることに
意味はありますか？関数型で組む場合は、何もしない関数 foo(), bar() を挟み込む
発想になったことがありません。必要になったとき、何かをしたくなったとき、その
ときに追加しています。

158 ：デフォルトの名無しさん：2014/03/30(日) 13:31:27.59 ID:amVAfrHC.net

>>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.net

継承とインターフェイスだけで十分便利

160 ：デフォルトの名無しさん：2014/03/30(日) 14:01:44.17 ID:qe+yThv9.net

>>157
たぶんお前の説明が下手くそだと思うんだが、いかなる場合も何もすることがない関数なんて言語問わず存在意義あるわけないじゃん
メソッドチェーン関係なく単に修正ミスとかだろ

もしくは、お前が知らないだけで何かの意味があるんだよ
よくみるなら具体例出してみろ

161 ：デフォルトの名無しさん：2014/03/30(日) 14:29:06.62 ID:rCEPh8in.net

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.net

それでどうやって一行で書くの？

163 ：デフォルトの名無しさん：2014/03/30(日) 14:44:34.88 ID:rCEPh8in.net

かりにメソッドチェーンという糖衣構文があるからといって実際に使う時は
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.net

メソッドチェーンまで糖衣構文かよｗ
これのどこが構文なんだ？
ライブラリの仕様だろ。

165 ：デフォルトの名無しさん：2014/03/30(日) 15:11:02.31 ID:qe+yThv9.net

Withは見にくいからやめろという主張をよく聞くが

メソッドチェーンの利点はメソッドで加工を行ってそれを別のメソッドに引き渡せるっていうこと
同じオブジェクトにたいして関連したメソッドをいくつも呼ぶ時も行を分けたりとかしなくて済むから見やすい

166 ：デフォルトの名無しさん：2014/03/30(日) 15:11:12.60 ID:yCsw+RdE.net

>>163
糖衣？…構文？？

167 ：デフォルトの名無しさん：2014/03/30(日) 15:17:34.92 ID:rCEPh8in.net

>>165
withが見にくくてメソッドチェーンが見やすいってのも変な話だな。
記述に大差ないのに。

168 ：デフォルトの名無しさん：2014/03/30(日) 15:39:47.59 ID:J3oHNw57.net

みんな、見やすいかどうかは
文字列の長さや行数で変わるってことを
理解してないよ。

たとえばこの二つ。

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

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

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

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

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

どちらが、どんな場合でも見やすいなんてことにはならないんだよ。

169 ：デフォルトの名無しさん：2014/03/30(日) 15:47:45.96 ID:rCEPh8in.net

短かろうと一行にするのはよくないと思うな。
オブジェクトが無い場合に

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.net

> foo(); bar(); baz();
>
> なんて書けるけど

書けないよ。

baz(bar(foo()));

こうだろ

171 ：デフォルトの名無しさん：2014/03/30(日) 15:53:47.22 ID:rCEPh8in.net

>>170
今の話の流れにおけるメソッドチェーンでは
自身のインスタンスをreturnするから、
その例のような意味でつなげてるのでは無いよ。

172 ：デフォルトの名無しさん：2014/03/30(日) 15:58:50.57 ID:J3oHNw57.net

>>170
インスタンスに対して操作をするんだろう？

じゃあ、何らかの引数がなければ、
同じ意味にならないじゃないか。

173 ：デフォルトの名無しさん：2014/03/30(日) 16:33:15.45 ID:IecYjjCX.net

>>156
で、具体的なデバッガの名前とやり方は？

174 ：デフォルトの名無しさん：2014/03/30(日) 17:17:26.79 ID:CUSBQvN9.net

>>160
関数型言語ではid関数は重宝するぞ

175 ：デフォルトの名無しさん：2014/03/30(日) 17:34:15.13 ID:qe+yThv9.net

>>169
複数の文を一行で書くのはなんか嫌だけど、メソッドチェーンなら気にならないな
ifの後ろとかにつけていたい目を見そうだからかな

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

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

>>174
関数型言語はわからんが、重宝するならなんか意味があるんだろ？

176 ：デフォルトの名無しさん：2014/03/30(日) 18:01:52.30 ID:3Fl9YNZ5.net

>>160 具体例は公開できないので申し訳ない
その1. メソッド名が訳の分かる名前ならば、その中身を心配して見にいく必要はない
　　　⇒ これはレスや参考図書がよく使う 'foo' だの 'bar' だののレベルの名前を開発
　　　　しているプログラムに使っていることが問題なのだと思う
その2. 場合によっては改名するつもりで中身を見にいくと、なんでこれを括りだしたの？
　　　という疑問が発生(もとから括り出す必要はなくて、名前も要らないんじゃないの？)
　　　⇒ メソッドの中身をメインルーチンにコピペして解決!!
オブジェクト指向の話がいつの間にかコピペの話に...

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

177 ：デフォルトの名無しさん：2014/03/30(日) 19:02:38.40 ID:qe+yThv9.net

>>176
なんだ、昨日の続きならそうかけよ

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


オブジェクト指向は完璧ではないし、スキルがない人ならやらなくてもいいんじゃない？
ただし、C＃とかJavaみたいにオブジェクト指向ありきで設計された言語はやっぱり知識は必要
標準ライブラリ自体オブジェクト指向専用だからね
C#でStreamではなくFileStreamしか受けないメソッドとかを作ってしまったら不便だし、不要なフィールドを公開したら危険だ

178 ：デフォルトの名無しさん：2014/03/30(日) 22:50:01.50 ID:rCEPh8in.net

>>176
オブジェクト指向を使うと、同じものを2つ以上同時に扱うのが簡単なんだよね。
2つのファイルを同時に編集するとか
ぷよぷよの画面を2つならべてみるとか
5人のボンバーマンが同時に動くとかさ。

179 ：デフォルトの名無しさん：2014/04/01(火) 20:30:56.47 ID:c88mFqYR.net

>>173
スモールトーク系のデバッガーはメソッドチェーンのそれぞれのメソッド呼び出しごとにステップ実行できるらしいよ

180 ：デフォルトの名無しさん：2014/04/01(火) 21:54:52.60 ID:WgoYILFU.net

>>179
具体的な名前書けっつーてるのに...
結局 ID:CUSBQvN9 は口先番長かよ (w

181 ：デフォルトの名無しさん：2014/04/02(水) 21:15:51.80 ID:R40jOAQ7.net

性能低下を防ぐためにメソッドの内容をメインルーチンに直に展開する作業は、
処理系にまかせることもできるだろうが、それによって多態性は失われる。
それよりもソフトウェアを細かく分割して構成する以上、バージョンの依存
関係が複雑に絡み合うほうが問題として大きい。

182 ：デフォルトの名無しさん：2014/04/02(水) 21:49:26.89 ID:YdJBhj/R.net

>>180
スモールトークっていったらスクイークとかじゃないの？
口先番長認定するまえに自分で調べてみたの？
口の中にご飯をスプーンで入れてもらうまで
馬鹿みたいに口開けて上を向いているタイプの人なの？

183 ：デフォルトの名無しさん：2014/04/02(水) 22:04:27.79 ID:UHLZ3L7X.net

>>182
で、そのスクイークとやらは、ブレークかけられんのか？
当然調べたんだよな (w

184 ：デフォルトの名無しさん：2014/04/03(木) 00:45:59.14 ID:OChVK7bs.net

>>4
ポリモーフィズムはリリースされたプログラムをユーザーが部分的に更新しな
がら使う(ライブラリやDLLを更新する)と、プログラマが当初考えていた以上
の使われ方をして、動作の保証ができなくなる、ってことにならないの？
昔でいうgoto文や、メモリーリークを起こしがちなC言語のポインタみたいに
やっかいなことにならないの？

185 ：デフォルトの名無しさん：2014/04/03(木) 00:59:50.75 ID:p51daBHj.net

動作の保証ができなくなるようなことを許すのは単なる欠陥でしょ

186 ：デフォルトの名無しさん：2014/04/03(木) 02:22:36.23 ID:Dr19mwRL.net

メソッドごとにコメントアウトすればいいよ
てかメソッドチェーンとしてのチェックってあるかね

187 ：デフォルトの名無しさん：2014/04/03(木) 04:56:35.67 ID:4OpITLe5.net

>>183
できないと思ってるの？

188 ：デフォルトの名無しさん：2014/04/03(木) 07:32:45.27 ID:7TERZTkc.net

>>187
できるんなら、その方法書いてくれ。

189 ：デフォルトの名無しさん：2014/04/03(木) 08:26:44.88 ID:oN99KWq6.net

いい加減に認めろよ……

そもそも仮に「メソッドチェーンはデバッグできない」としても、それは「オブジェクト指向」を否定するのに大事な要素でもないじゃん
何かこだわりでもあるの？

190 ：デフォルトの名無しさん：2014/04/03(木) 08:48:37.07 ID:syg3Ul2m.net

>>189
> いい加減に認めろよ……

何を認めるんだ？
ブレーク掛けられるなら >>151
が情弱と言うことだし、かけられないなら >>156 が口先番長と言うだけのことだろ。
どこから、オブジェクト指向の否定が出てきたんだよ (w

191 ：デフォルトの名無しさん：2014/04/03(木) 15:05:44.04 ID:v6ez+Y0x.net

>>188
ちゃんとしたSmalltalk処理系では（つまりGNU Smalltalkとかの変わり種を除けば）一般に
value foo halt bar baz で、bar のコール直前でデバッガを起動させて bar のステップ実行ができる
ってそういうことではなく？　ちなみに halt は古典的なSmalltalkにおけるブレイクポイントみたいなもの。

192 ：デフォルトの名無しさん：2014/04/03(木) 15:25:06.01 ID:hov1QvrO.net

みんなSmalltalk使ってたのかよ

193 ：デフォルトの名無しさん：2014/04/03(木) 17:07:01.60 ID:4OpITLe5.net

スモールトークがオブジェクト指向の元祖だからな
スモールトークでできるならオブジェクト指向の欠点とは胃炎な

194 ：デフォルトの名無しさん：2014/04/03(木) 17:16:43.96 ID:hov1QvrO.net

ていうか、一つの式に詰め込んだら便利かどうかなんてオブジェクト指向と関係なくね？

195 ：デフォルトの名無しさん：2014/04/03(木) 19:17:35.74 ID:/A78gSRK.net

Smalltalkには、コードを英文のように読み下せるように書く慣習みたいなものがあって、
value foo bar baz みたいな式だとちょっとメリットをイメージしにくいですが、たとえば
「1 から 9 までの数を配列にして、それをシャッフルして最初の３つを得る」みたいな処理を、
(1 to: 9) asArray shuffled first: 3 というふうに一気にメソッドチェーンにして書くようなことはよくします。

そんなこともあって、メソッドチェーンだからデバッグしづらいというような制約はほとんどうけない仕組みになっています。

196 ：デフォルトの名無しさん：2014/04/03(木) 20:08:44.08 ID:JDC55uKf.net

>>194
そもそもオブジェクト指向についてあんまり語ってないからいいんじゃね

197 ：デフォルトの名無しさん：2014/04/03(木) 21:23:31.55 ID:y3U0PHNW.net

>>191
なるほど、ブレーク+ステップ実行なのね
まあ実用上は十分かな
C# とかでもできるようにしてほしい

198 ：デフォルトの名無しさん：2014/04/04(金) 00:28:50.72 ID:T327aBHM.net

C++じゃなくてObjective-Cが流行ってれば
オブジェクト指向絡みの論争は半分になったんじゃないかと
思えてしかたがない。
オブジェクト指向が、じゃなくてC++が採用した方法は、な議論大杉

199 ：デフォルトの名無しさん：2014/04/04(金) 01:37:59.49 ID:G1RCkua4.net

クラスベース vs プロトタイプベース

200 ：デフォルトの名無しさん：2014/04/04(金) 01:52:31.25 ID:h1F261Ig.net

Objective-C十分流行ってるじゃん

201 ：デフォルトの名無しさん：2014/04/04(金) 03:12:14.91 ID:T327aBHM.net

ここ5年ぐらいでiOS用で一気に拡まったけど90年代を通じて
一般の想定するオブジェクト指向と言ったらC++だったからな…
90年代後半からはそこにJavaが加わり…的な。
ある意味バカみたいに基本に忠実なObjective-Cの方が
オブジェクト指向とは〜って議論のたたき台としてはよかったよな的な。

202 ：デフォルトの名無しさん：2014/04/04(金) 07:15:48.10 ID:R/rpZwB2.net

>>197
と言うか、行単位でのブレークポイントなのはデバッガの都合でしかないんだよなあ

203 ：デフォルトの名無しさん：2014/04/04(金) 07:36:28.20 ID:KeYVoIFc.net

>>202
式の途中にブレークポイントを入れるのはデバッガだけでは無理っす。

204 ：デフォルトの名無しさん：2014/04/04(金) 08:06:13.57 ID:JslAeCyW.net

>>203
いや、だからそれって 今の デバッガだからだろ？
技術的にできない訳じゃなかろ

205 ：デフォルトの名無しさん：2014/04/04(金) 09:05:42.51 ID:KeYVoIFc.net

最低限、コンパイラにも手を入れる必要があると思うぞ。

206 ：デフォルトの名無しさん：2014/04/04(金) 10:52:39.43 ID:N5FO4XZ5.net

デバッガのブレークポイントの指定が
行単位ってだけで、関数単位でのステップは可能。

そして関数単位で止めたいなら
関数ごとに改行すればいいだけじゃない。

207 ：デフォルトの名無しさん：2014/04/04(金) 13:07:13.88 ID:JslAeCyW.net

>>206
> デバッガのブレークポイントの指定が行単位ってだけで、

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

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

そもそもそんなことしたくないか、発端だろ。
デバッグのためにソース弄るとかは最後の手段だろ。

208 ：デフォルトの名無しさん：2014/04/05(土) 08:19:53.84 ID:nKpGUjgO.net

>>206
だーかーらー、
コンパイラが出す行情報以外にどうやって
ブレークかけるアドレスを取り出すわけ？
関数ごとに改行したところで
普通のコンパイラはステートメント単位でしか行番号情報ださねーぞ。

もしかして、単にデバッガのUIの問題だと思ってた？
甘杉

209 ：デフォルトの名無しさん：2014/04/05(土) 08:39:06.87 ID:OXL1p1Q1.net

そういうスレたててやれ

210 ：デフォルトの名無しさん：2014/04/05(土) 10:05:58.71 ID:AlWzj+6w.net

いったいどのデバッガやコンパイラについて話してるのか知らんが、
VS2013とかにはメソッドチェーンのデバッグ機能あるぞ……
メソッドチェーン中の個々のメソッドについて戻り値とその型を表示してくれる

211 ：デフォルトの名無しさん：2014/04/05(土) 12:34:58.04 ID:zg062x0r.net

>>1
mvcで作ればなんとなくわかる

212 ：デフォルトの名無しさん：2014/04/05(土) 21:29:41.29 ID:LGGjyQ0u.net

オブジェクト指向を使うには、変数や関数がある程度以上の個数がないと無意味。
あとインスタンスが２個以上必要な場合じゃないと意味がない。
俺の分野ではどちらも当てはまらないので、オブジェクト指向が活用できない
という結論に至った。みんな、ありがとう。

213 ：デフォルトの名無しさん：2014/04/05(土) 21:49:36.29 ID:anSZmmIR.net

オブジェクト指向が活用できない分野ってどんな分野よ

214 ：デフォルトの名無しさん：2014/04/05(土) 22:16:36.14 ID:iKzYf4PO.net

書き換えて再利用とか機能の追加が少ない機械みたいな分野だったら
(構造化言語の)Cそのまんまで十分じゃないの、とは思う。

215 ：デフォルトの名無しさん：2014/04/06(日) 06:09:18.41 ID:IRmFVDmN.net

>>212の日本語訳
「俺がいつも書くコードはオブジェクト指向になっていない。
だから俺の分野ではオブジェクト指向は使えない。」

「オブジェクト指向」の部分にどんな技術を入れても成立する
魔法の言い訳だな。

216 ：デフォルトの名無しさん：2014/04/06(日) 06:50:21.75 ID:7fCDh1Rd.net

同じものが沢山作れる、ってのは確かにオブジェクト指向のミソだが、
インスタンスが一つだろうと、オブジェクト指向プログラミングによって得られるものは色々あるぞ
再利用性とか、単体テストのしやすさとか、拡張性とかな

あと、オブジェクト指向プログラミングの重要なデザインパターンに「シングルトン」というのがあって、こいつはインスタンスを一つに限定するものなんじゃな
インスタンス一つだから役に立たない、ってのは世の中のプログラマには通じないと思われる

217 ：デフォルトの名無しさん：2014/04/06(日) 09:28:19.55 ID:v5F7vKVc.net

記述側がより人間の思想に近くなったメリットと、実装側でからくり（C++ なら vtable）を生成コードに常に追加するコストとを天秤にかけたら、どっちに軍配があがるかは人それぞれだね
ライナスは OO をぼろくそにけなしているね

218 ：デフォルトの名無しさん：2014/04/06(日) 11:55:32.65 ID:X8q2hYwd.net

>>216
> 再利用性とか、単体テストのしやすさとか、拡張性とかな

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

あと、同じものをたくさんじゃなくって、ちょっと違うものを作れるって言うのがミソかと。

219 ：デフォルトの名無しさん：2014/04/06(日) 12:55:51.09 ID:hTzu53D+.net

>>217
> ライナスは OO をぼろくそにけなしているね
ライナスだけじゃね？ｗ

しかも俺らはカーネル作ってるわけじゃないから、
用途によって言語は変えるべきという正しい考え方からすると、
ライナスが何言っても何使っても関係ないよねｗ

220 ：デフォルトの名無しさん：2014/04/06(日) 12:56:37.04 ID:hTzu53D+.net

どっちに軍配があがるかは人それぞれというより
用途によりけりってことだろう。

で、大概の用途にOOに軍配が上がると。

221 ：デフォルトの名無しさん：2014/04/06(日) 13:06:24.24 ID:N1Ox9kUH.net

ここまでの内容ならライブラリで十分。オブジェクト指向は不要。

222 ：デフォルトの名無しさん：2014/04/06(日) 13:16:36.50 ID:nZeav+Zp.net

ライブラリとオブジェクト指向を同列に語ってる馬鹿は黙ってろよ

223 ：デフォルトの名無しさん：2014/04/06(日) 13:29:28.28 ID:d9KztC3X.net

こういうのを見ると、やっぱりオブジェクト指向が一般的であることがよく分かるよ。

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

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

単一責務の原則(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.net

>>223
vtableを生成コードに常に追加するコストに見合うものかどうか疑問だね

225 ：デフォルトの名無しさん：2014/04/06(日) 18:19:41.32 ID:7fCDh1Rd.net

vtableの生成コストとか言い出したら、スクリプト言語なんて論外じゃねーかw

226 ：デフォルトの名無しさん：2014/04/06(日) 18:34:59.08 ID:C74PoYgz.net

C++だとvtableは必要なとこにしか付かないよね

227 ：デフォルトの名無しさん：2014/04/06(日) 18:36:50.32 ID:XoDYwo6S.net

ぷらぷら。ぼくはvirtualなメソッドじゃないよ。

228 ：デフォルトの名無しさん：2014/04/06(日) 18:37:51.19 ID:ZbP0XCh9.net

なんでここだけC++初心者スレみたいになってんの？

229 ：デフォルトの名無しさん：2014/04/06(日) 18:39:42.35 ID:7fCDh1Rd.net

一番知名度のあるオブジェクト指向プログラミング言語はJavaの筈なのにね

230 ：デフォルトの名無しさん：2014/04/06(日) 18:44:04.82 ID:wJ4fkLfq.net

致命度？

231 ：デフォルトの名無しさん：2014/04/06(日) 20:38:36.74 ID:IDxsBa0K.net

いいや、Objective-Cが最後に勝つね

232 ：デフォルトの名無しさん：2014/04/06(日) 20:55:17.94 ID:C74PoYgz.net

Objective-C++が節操なくて素敵だよw

233 ：デフォルトの名無しさん：2014/04/09(水) 01:49:33.61 ID:eVIzB16V.net

オブジェクト指向に相対するパラダイムってなによ
関数型＋代数的データ型？

234 ：デフォルトの名無しさん：2014/04/09(水) 03:10:51.74 ID:j9Z2BVsM.net

それは相対する、ってほどでも無いような
オブジェクト指向自体も考え方が複数あるからなあ…
関数型はともかく、手続き型でオブジェクト指向に真っ向から相対して組むとすれば

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

とか、そんな感じになるのかな

235 ：デフォルトの名無しさん：2014/04/09(水) 08:48:53.28 ID:lgQL/971.net

向いてる方向が違うんだから、遠い近いはあるだろうけど相対って言うのはないんじゃね？

236 ：デフォルトの名無しさん：2014/04/09(水) 17:51:40.57 ID:iVtPfWG1.net

>>129
DDD？ってこれパラダイムじゃないか

237 ：デフォルトの名無しさん：2014/04/09(水) 18:41:01.22 ID:rvzGfgdi.net

昔DDDっていうデバッガ使ってたな...

238 ：デフォルトの名無しさん：2014/04/09(水) 21:00:52.84 ID:TCIMdxjw.net

DDT (CP/M-80) じゃなくて？

239 ：デフォルトの名無しさん：2014/04/09(水) 21:03:36.40 ID:rvzGfgdi.net

>>238
gdbのGUIフロントエンドだよ

240 ：デフォルトの名無しさん：2014/04/10(木) 22:59:06.71 ID:EbsHnFyb.net

最近ベクトル演算をする必要が出てきたので、オブジェクト指向のプロパティを
使って実現しようと考えている。

○か×か？

241 ：デフォルトの名無しさん：2014/04/10(木) 23:07:48.12 ID:c1sQcFAM.net

>>240
どう見ても「君には」×

242 ：デフォルトの名無しさん：2014/04/10(木) 23:36:09.35 ID:Uir6dqld.net

実際にベクトルクラスがあるからそれ参考にする

243 ：デフォルトの名無しさん：2014/04/11(金) 02:56:48.62 ID:HtRnBfLu.net

同じメソッド呼び出しを何度も行うと呼び出しのコードをコピペすることになっ
てしまいます。何もせず名前の意味も不明な多重のメソッド呼び出しはコピペを
防ぐためだったと判明しました。もちろん手打ちしたとのことです。

オブジェクト指向脳っていうんですか？本当に怖いです。

244 ：デフォルトの名無しさん：2014/04/11(金) 09:11:53.91 ID:nUaUWR93.net

>>243
それ違う。関数脳っていうの（笑）
同じ関数呼び出しを何度も実行すると
関数を何度もコピペすることになるからね（爆笑）

245 ：デフォルトの名無しさん：2014/04/11(金) 09:12:29.97 ID:nUaUWR93.net

>>243
それ違う。アセンブラ脳っていうの（笑）
同じニーモニック呼び出しを何度も実行すると
ニーモニックを何度もコピペすることになるからね（大爆笑）

246 ：デフォルトの名無しさん：2014/04/11(金) 09:13:54.98 ID:nUaUWR93.net

>>243
人生で同じ英単語・アルファベットを何度もコピペする略（ゲラゲラ）

247 ：デフォルトの名無しさん：2014/04/11(金) 13:07:20.58 ID:xNOhzDQj.net

なんか面白いんだろうな...
俺には理解できないけど

248 ：デフォルトの名無しさん：2014/04/12(土) 12:55:19.47 ID:5P9XNUOV.net

プログラマはソースのコピペを恐れないでください。誰でも最初は初心者で、
しかも誰もが成長するとは限らないのです。
成長を強いるオブジェクト指向が、万人の解決策になり得ないのは明らかです。
コピペこそが、初心者からベテランまで、万人の解決策となり得るのです。
第一、grepすらできないソースをメンテナンスできるはずありません。

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

大体、オブジェクト指向を推進する人は、協調性がない人が多く、共同で作業す
るには向いていないのです。冗談のセンスすらありません。

249 ：デフォルトの名無しさん：2014/04/12(土) 17:13:54.61 ID:1eEiGLxS.net

全部反対のことを言っていると見抜けば
>>248が言っていることに納得できるはずｗ

250 ：デフォルトの名無しさん：2014/04/12(土) 17:19:09.23 ID:f/RHrroc.net

なんか面白いんだろうな...
俺には理解できないけど

251 ：デフォルトの名無しさん：2014/04/13(日) 10:45:23.58 ID:839g2ruV.net

ここで僕らは「良いソフト部品は、有名なのだけだ」という原則に立ち戻る必要があるだろうね。
誰も使ってない、メンテナンスもされない俺様オブジェクト部品を使うくらいなら、コピペの方がましな
んだよ。宣言型か関数型が使えるならその方がいいし、使えなければテストの自動化で乗り切る
しかないと、もう１０年も前からいわれて続けているわけだ。
research.microsoft.com/en-us/um/people/blampson/70-SoftwareComponents/70-SoftwareComponents.htm

252 ：デフォルトの名無しさん：2014/04/13(日) 10:51:49.05 ID:oaa109sw.net

うん、まったくだ。
有名なソフトは良い。

有名じゃなくても良いソフトはまれにあるけど、
多くの、つまり何万、何十万とある無名なソフトはクソでしかない。

253 ：デフォルトの名無しさん：2014/04/13(日) 11:22:22.91 ID:2QOmxkhr.net

ストラウストラップが「オブジェクト指向というのは継承と再利用なんだよ！」ってやったせいで
えらい風評被害やな。

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

254 ：デフォルトの名無しさん：2014/04/13(日) 11:38:57.62 ID:Vp4hM6j5.net

＞NSObjectってクラスの基本的ふるまいを持った基底クラスからテキトーなクラス作って
継承してるじゃないの。

むしろC++の方が継承なしのパーツ扱いが多いんじゃないの。

255 ：デフォルトの名無しさん：2014/04/13(日) 11:54:36.21 ID:j71fNHt+.net

いわゆるObjectクラスが必要な理由って何かあるの？

256 ：デフォルトの名無しさん：2014/04/13(日) 12:17:57.96 ID:2QOmxkhr.net

Objective-Cはとにかくクラスの実体ありきで
言語的にひな型からインスタンスを作るんじゃなくて
起動時に存在するファクトリクラスにallocとinitを送って
クラスに"自分のインスタンスを作らせる"から
すべてのクラスはallocやinit、retainカウント、deallocを受け付け管理する
NSObjectを継承していないとクラスとして存在しえないので…

257 ：デフォルトの名無しさん：2014/04/13(日) 15:02:09.06 ID:Vp4hM6j5.net

動的な言語だとだいたいObjectクラスが必須だよね

258 ：デフォルトの名無しさん：2014/04/13(日) 15:38:34.94 ID:j71fNHt+.net

>>256
別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな

259 ：デフォルトの名無しさん：2014/04/13(日) 15:55:24.32 ID:BqlLq9pK.net

動的な言語でも本来はObjectなんて要らない。
Smalltalk-80だってnilのサブクラスを作れたし。

260 ：デフォルトの名無しさん：2014/04/13(日) 16:04:45.61 ID:oaa109sw.net

値の型が動的なのと
変数の型が動的なのとを
区別つけろよ。アホ。

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

変数に型がない言語ではどんな値でも入れられるから
Objectは要らない。変数にはどんな型でも入れられる
とはいうものもコードは互換性がある型を入れてないと
結局正しく動かないんだけどなｗ

261 ：デフォルトの名無しさん：2014/04/13(日) 16:17:49.14 ID:Vp4hM6j5.net

値の型が動的ってどういう事？
さっきまでStringだったけど今みたらIntに変わってたわ！みたいな？

262 ：デフォルトの名無しさん：2014/04/13(日) 16:24:02.51 ID:oaa109sw.net

変数の型は固定なんだよ。
この変数は、Numeric型みたいに。

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

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

それに対して、変数に型が決まってない言語があるの。
変数に型が書いてないなら変数aにどんな型でも入れられる。

263 ：デフォルトの名無しさん：2014/04/13(日) 16:26:13.02 ID:Vp4hM6j5.net

Objectって全部に共通の動作を定義するために使われてるよね普通は。
例えば、自分の型を返すとか。

264 ：デフォルトの名無しさん：2014/04/13(日) 17:45:48.17 ID:CtgsENNt.net

値が型情報持ってない言語は一応あるね、C言語とか
あれは変数側にしか型がない

265 ：デフォルトの名無しさん：2014/04/13(日) 18:03:36.88 ID:BqlLq9pK.net

>>261
SmalltalkではさっきまでByteStringだったオブジェクトが今みたらWideStringだったぜとか普通

266 ：デフォルトの名無しさん：2014/04/13(日) 18:07:49.11 ID:+sscY2hT.net

>>263
それがルート(基底)クラスだな。
Objective-Cで言えばNSObjectで、全てのクラスのルート。

267 ：デフォルトの名無しさん：2014/04/13(日) 18:54:15.96 ID:BqlLq9pK.net

全部に共通の動作なんてものが必要なうちはダメだな

268 ：デフォルトの名無しさん：2014/04/13(日) 19:10:20.98 ID:wSq/pgWA.net

>>267
ダメな理由書いてみ

269 ：デフォルトの名無しさん：2014/04/13(日) 19:31:38.05 ID:Vp4hM6j5.net

>>265
それは参照してるオブジェクトが変わったんじゃないの？

270 ：デフォルトの名無しさん：2014/04/13(日) 20:05:02.79 ID:+sscY2hT.net

共通の動作がなければ、てんでばらばらって事じゃんw

271 ：デフォルトの名無しさん：2014/04/13(日) 20:31:47.78 ID:yhlLeWxx.net

>>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.net

>>259
よく知らないんですけどSmalltalkのnilとObjectって
お互い継承関係にあるんじゃないんですか？

273 ：デフォルトの名無しさん：2014/04/13(日) 20:46:56.28 ID:+sscY2hT.net

>>271
SmallTalk知らないんだけど、それってxというオブジェクトにbecome:という動作をさせてるの?
そうなら、become:という動作は全オブジェクトに共通だよね。

274 ：デフォルトの名無しさん：2014/04/13(日) 20:50:21.03 ID:Vp4hM6j5.net

>>271
Smalltalkよくしらないから適当言語だけど...
x = "x"; y = "y"; z = y;
の状態で
y become: x;
とやったら、
zの指してるオブジェクトは"x"になるって事？

275 ：デフォルトの名無しさん：2014/04/13(日) 20:59:39.25 ID:BqlLq9pK.net

>>268
つ proxyパターン

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

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

>>274
なる。xが"x"のままの流派と"y"になる流派とがある。

276 ：デフォルトの名無しさん：2014/04/13(日) 21:09:17.21 ID:1ZgLAbLW.net

よく知らない三連星ワロタ

>>275
なるほどそういう意図ですか
1. nillはUndefinedObjectのインスタンス
2. UndefinedObjectはObjectの継承している
3. Objectはnilを継承している
こうかな？
となると全てのクラスの共通となる祖先が存在してるんで
不要論として出すのはやっぱおかしくないですか？

277 ：デフォルトの名無しさん：2014/04/13(日) 21:15:34.64 ID:TiAwmeQu.net

知れば知る程Smalltalkのウンコさが身にしみる

278 ：デフォルトの名無しさん：2014/04/13(日) 21:40:50.80 ID:+sscY2hT.net

proxyパターンと共通の動作にどういう関係があるのかわからん。

279 ：デフォルトの名無しさん：2014/04/14(月) 03:36:50.26 ID:9JfqG4RHk

てｓｔ

280 ：デフォルトの名無しさん：2014/04/14(月) 01:57:18.83 ID:QEqaYkvm.net

>>259
要らないつうか、それだと基本的なオブジェクトとしてのふるまいを持ってないから
Objective-Cで生のC関数書いたりObjective-C++でC++のクラス扱ってる状態なだけじゃ…

281 ：デフォルトの名無しさん：2014/04/14(月) 19:01:11.23 ID:9oXXilb1.net

>>276
nilはクラスではないから共通の祖先となるクラスではないよ。
というか基底クラスが複数あるのはそんなに珍しいことではないが、
一体何がわからないのかわからない。

282 ：デフォルトの名無しさん：2014/04/14(月) 20:50:15.58 ID:2o5NlHiv.net

>>281
nilを継承できる事と所謂Object型が不要になる事の繋がりが分からないんですよね
nillオブジェクトとObjectクラスは親子関係にあるのになんでだろう
って思って質問したんです

283 ：デフォルトの名無しさん：2014/04/14(月) 21:32:49.46 ID:1BzKypQe.net

> 3. Objectはnilを継承している
それが真であれば、Objectはnilの特徴を持っていないといけない。
Objectはnilではないので、これは間違い。

284 ：デフォルトの名無しさん：2014/04/14(月) 21:40:20.78 ID:KfO5hauH.net

>>280
要らないんじゃなくて、あった方がやり易いってことだよな。
別にObjective-CでもNSObject無視してクラス自作できるけど、まずそんな事しない。

285 ：デフォルトの名無しさん：2014/04/14(月) 21:41:56.76 ID:kBF05cIr.net

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.net

>>283
あ、そうなんですか
Wikipediaに
> 基本的な派生元となるObjectやProtoObjectは、それらから派生したUndefinedObjectのインスタンスオブジェクトであるnilを継承しており再帰関係を持つ。
と書いてあったんでそういうものだと思ってました
あと
Object isKindOf: nill
が true を返すのはなんででしょう？

287 ：デフォルトの名無しさん：2014/04/15(火) 04:06:44.72 ID:wLbFOpnz.net

>>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.net

>>287
ありしゃす、Object isKindOf: nil の結果は実装依存なんですね
true になるのはGNU Smalltalkでした

289 ：デフォルトの名無しさん：2014/04/15(火) 20:46:27.61 ID:d1+oXg+5.net

>>287
>つまりnilとNilは別々のオブジェクトであり、

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


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

Nil と Object とは「サブクラス-スーパークラス」という継承関係であり、
Nil と nil とは「クラス-インスタンス」というインスタンス化関係であり、
二種類の関係をごっちゃにしてはいけない、ってこと

290 ：デフォルトの名無しさん：2014/04/15(火) 21:07:45.24 ID:d1+oXg+5.net

>>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.net

>>288
GNU Smalltalk は名前から受ける印象と違って
単なるファンお手製の勝手実装なうえに、
Smalltalk としてもかなりの変わり種なので
あれを元に Smalltalk がどういうものか学ぶのはちょっと問題が。
できれば VisualWorks 、悪くても Squeak/Pharo で
試すようにするのがよいと思います。
（これらの処理系はそれぞれ独自の進化を遂げてはいますが、
いちおう古典的 XEROX Smalltalk-80 からの直系の派生物で、
その名残を多く残しています）

292 ：デフォルトの名無しさん：2014/04/15(火) 22:39:29.15 ID:4TC7MUH1.net

>>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.net

大量のベクトル演算をオブジェクト指向で行うのはいい考えではありませんでした。
パフォーマンスが話になりません。

あらためてオブジェクト指向の活用方法が知りたいです。

294 ：デフォルトの名無しさん：2014/04/15(火) 22:56:10.29 ID:TDL51eos.net

あたりまえやないかw　インラインでやれ。

295 ：デフォルトの名無しさん：2014/04/16(水) 05:01:31.46 ID:ZBBb0DXo.net

>>292
それはmeta cyclicというのであってrecursionとは全く別だよ

296 ：デフォルトの名無しさん：2014/04/16(水) 08:21:50.02 ID:A1GSn+hc.net

>>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.net

>>296
まず、
全てのクラスの基底となるクラスが存在するかどうかという>>255の話は継承関係の話で、
クラス-インスタンス関係で構成されるメタタワーの話である>>296の話とは
全く別々の話だということはOK？

298 ：デフォルトの名無しさん：2014/04/16(水) 18:10:12.53 ID:A1GSn+hc.net

>>297
はいそれは分かってるつもりです
自分が疑問に思ったのは>>259なんで、
nilを継承できる事とObjectが不要である事の関連性を
説明して貰えるとありがたいんですが…

299 ：デフォルトの名無しさん：2014/04/17(木) 03:03:07.59 ID:g3SPX8xq.net

isKindOf:等のクラス階層へのアクセスを使わない限りにおいて、
全てのクラスは基底クラスから継承したインスタンス変数やメソッド等を取り込むことで
nilからの継承による実装に置き換えることが出来るのはOK？

300 ：デフォルトの名無しさん：2014/04/17(木) 06:51:39.99 ID:XZy5mn+7.net

>>299
はい、続けて下さい

301 ：デフォルトの名無しさん：2014/04/17(木) 07:01:46.34 ID:g3SPX8xq.net

>>297と>>299を前提とすれば、
全てのクラスの基底クラスとしてのObjectは不必要であることは自明だというのはOK？

302 ：デフォルトの名無しさん：2014/04/17(木) 07:48:37.17 ID:XZy5mn+7.net

>>301
いいえ、その飛躍が判りません
nilにObjectクラスと同じ能力があるからObjectクラスは不要だという事ですか？

303 ：デフォルトの名無しさん：2014/04/17(木) 09:46:27.34 ID:g3SPX8xq.net

>>302
いいえ、nilにObjectと同じ能力があるなんて誰か言ってるのですか？

304 ：デフォルトの名無しさん：2014/04/17(木) 19:48:33.36 ID:XZy5mn+7.net

>>303
じゃあ>>299の解釈が間違ってますね
うーん、Objectの代わりにnilから派生できるよ、としか汲み取れません
でもそれだとクラス階層のルートの必要性とは無関係の話だから違うんだろうな

自明の部分を取り違えないように省略せず説明して頂けませんか？

305 ：デフォルトの名無しさん：2014/04/18(金) 02:02:31.47 ID:3m4Hm4jr.net

今更な反応だけど
メソッドチェーンのデバッグどうのこうのは
パワーアサートである程度解決できるんじゃね

テストとデバッグを同一視すんなとか言われそうだけど
そこはなんやかんやで

306 ：デフォルトの名無しさん：2014/04/19(土) 11:19:09.69 ID:fQ1JDqwN.net

みんなモデリングツール使ってる？

307 ：デフォルトの名無しさん：2014/04/19(土) 15:25:11.54 ID:7lbU/Cwq.net

UMLは手書きのノートに万年筆で描いてるけど？

308 ：デフォルトの名無しさん：2014/04/19(土) 15:25:52.03 ID:7lbU/Cwq.net

ああ、もうすぐ司法試験なんだよなぁ・・・
今年も申し込みしてねーや。
仕事辞めたいわ

309 ：デフォルトの名無しさん：2014/04/19(土) 15:28:51.08 ID:oGrzc7nx.net

ぜひ弁護士資格を取って人売り屋を訴えてやってください。

310 ：デフォルトの名無しさん：2014/04/19(土) 15:32:20.57 ID:7lbU/Cwq.net

弁護士より裁判官志望なんだけどな。
知財専門の裁判官やるわ。

311 ：デフォルトの名無しさん：2014/05/02(金) 02:53:15.17 ID:sB1UFa5X.net

裁判官になるのはある意味、終身刑になるようなもの
仕事にやりがいはないし、趣味、嗜好、信仰の類は一切行えない
どうしてもやりたいというなら止めないが、いいもんじゃないぞ

312 ：デフォルトの名無しさん：2014/07/11(金) 14:24:19.29 ID:u5XcYD/q.net

確かに日本語ネイティブじゃないと解り難い表現ではある

313 ：デフォルトの名無しさん：2014/10/15(水) 02:03:28.04 ID:fxqbNGWP.net

急にスレが死んだ

314 ：デフォルトの名無しさん：2014/10/16(木) 17:21:37.89 ID:MhzmuNOz.net

>>217
>ライナスは OO をぼろくそにけなしているね

Linusが批判したのはOOPじゃなくてC++だろ（Cとの比較で）。

315 ：デフォルトの名無しさん：2014/10/18(土) 12:18:53.66 ID:/oNwCDSd.net

似たようなものさ‥Linus が GC の存在を受け入れるわけがない

316 ：デフォルトの名無しさん：2014/10/18(土) 15:46:58.25 ID:7/IQKq91.net

そりゃ、カーネルやドライバレベルの開発でGC付きの言語環境は要らんわ。
OOPの話題でリーナス発言を引き合いに出すのは的外れすぎる。

317 ：デフォルトの名無しさん：2014/11/05(水) 13:15:41.31 ID:QbWIQhdw.net

OOPって結局、こういう考え方すれば分かりやすくなりますよって例でしかないからな
その考え方を前提に置けば、こういう表現ができますよって利点はいろいろな実装があるけど

完全性や効率性を犠牲に、可読性を上げて保守性や再利用性、試験性なんかを上げましょうってそういうものだと思うんだけど

318 ：デフォルトの名無しさん：2014/11/05(水) 20:29:01.97 ID:NM+61D3j.net

OOPって結局、…でしかないからな

という奴って、OOP以外にも関数型言語でもアジャイルプロセスでも受託ビジネスでも
みーんな「結局、…でしかないからな」とわかったような気になるだけで
実際には何も身についてないんだよなw

319 ：デフォルトの名無しさん：2014/11/05(水) 23:26:57.45 ID:UbfQ7xJO.net

オブジェクト指向は愚かな考え。排便メソッド2 [転載禁止]©2ch.net
http://peace.2ch.net/test/read.cgi/tech/1415122540/

320 ：デフォルトの名無しさん：2014/11/06(木) 08:17:55.90 ID:WCLQna6c.net

>>31
「結局、ただの方法論でしかないからな」

方法を知っているかとそれをビジネスで生かせるかは全く別のスキルだしなー

321 ：デフォルトの名無しさん：2014/12/15(月) 00:00:56.39 ID:Ovh10mZl.net

カプセル化 ポリモーフィズム 継承を理解して設計出来る人って実際、何人に一人ぐらいに感じる？

322 ：デフォルトの名無しさん：2014/12/15(月) 09:52:17.25 ID:z8CdksSX.net

ひとそれぞれ解釈違うからなんとも言えん

323 ：デフォルトの名無しさん：2014/12/15(月) 11:05:06.23 ID:cy4sFuPq.net

ｶﾌﾟｾﾙ化＆オブジェクト化の行き先は関数型プログラミングじゃないの？

324 ：デフォルトの名無しさん：2014/12/15(月) 12:54:30.82 ID:t6/tpY1X.net

絶対違う

325 ：デフォルトの名無しさん：2014/12/15(月) 15:09:37.42 ID:2aP18QTz.net

>>323
北極と南極の違いだろ。
OOPの落伍者のパラダイスが関数型なんだから。

326 ：デフォルトの名無しさん：2014/12/17(水) 11:09:29.57 ID:N1jNpsSg.net

ポリモーフィズムは分かりやすいんだけどカプセル化がいまいちわからない
ゲッターセッター書いて何になるの？ってレベルの理解しかないから優しく教えて

327 ：デフォルトの名無しさん：2014/12/17(水) 11:58:16.14 ID:qGVIuFRu.net

>>326
カプセル化はむしろ単純セッター書いたら負け
そのクラスの機能のみ提供して、内部実装を隠すのが要点

328 ：デフォルトの名無しさん：2014/12/17(水) 13:49:16.52 ID:dSysfVHr.net

カプセル内では、他のオブジェクトの定義を知らなくても済むように書く。
閉じたオブジェクトにすればいい。

329 ：デフォルトの名無しさん：2014/12/17(水) 17:36:45.21 ID:FGZvKMUK.net

>>326
基本的にそのクラスのメンバーはそのクラス内でいじられることを保障するため。

330 ：デフォルトの名無しさん：2014/12/17(水) 18:56:34.51 ID:qGVIuFRu.net

実装を隠す
→知らなくても使えるように設計する
→使い方さえ変えなければいい
→中は変え放題、新しい使い方も追加放題

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

クラスの中から≠クラスファイルの中から
クラスの中から＝クラス機能の中から

331 ：デフォルトの名無しさん：2014/12/17(水) 19:24:20.07 ID:N1jNpsSg.net

327-330
いろいろありがとう
公開したいとこだけ公開すりゃいいのね

332 ：デフォルトの名無しさん：2014/12/17(水) 19:38:57.10 ID:y3DoL19d.net

極論を言えば「公開」したら負けなのがカプセル化

333 ：デフォルトの名無しさん：2014/12/17(水) 21:14:17.50 ID:lLmQTo2M.net

>>326
getter-setter をかましておけば、なにかのときに簡単に監視やフックを追加できる

334 ：デフォルトの名無しさん：2014/12/17(水) 22:00:02.25 ID:adMFmMY0.net

>>333
ちょっとした用途ならリフレクションから呼べば良いじゃん
機能として提供する必要が出来たならそんな直接参照するような裏ワザ使わないで継承するなり追加するなりしようよ

影響が外に広がらないようにカプセル化して直接参照する手段を封じるんだから
直接参照できるセッターやゲッターつけたら保証できなくなるじゃん

335 ：デフォルトの名無しさん：2014/12/17(水) 22:40:02.99 ID:lLmQTo2M.net

>>334
リフレクションは悪、コンパイル時に検出できるエラーがリフレクションにすると検出できなくなってしまう‥
まあ何でもかんでもsetter-getter で公開してしまうのはどうかと思うが（ましてやプロパティを公開してしまうのは最悪）

336 ：デフォルトの名無しさん：2014/12/18(木) 15:10:59.93 ID:ZOTu6c+H.net

おいおいインスタンスにアクセサなかったら、
そいつの状態を変えたりモニターしたりどうやるんだよ。

337 ：デフォルトの名無しさん：2014/12/18(木) 15:18:48.22 ID:hbsgKLA0.net

>>336
状態をモニタするのは「モニタする」メソッドでやるべきじゃね？
状態を変えるなら、状態を変えるメソッドを通すべきだと思うし

もちろん、カプセル化の観点から見たら、の話ね
何か目的があってカプセル化を崩すなら、それはそれだろうし

338 ：デフォルトの名無しさん：2014/12/18(木) 15:31:32.87 ID:ZOTu6c+H.net

いやそのためのメソッドがsetter/getterだろうと。

339 ：デフォルトの名無しさん：2014/12/18(木) 16:01:52.60 ID:a38PRbZq.net

>>335
> ましてやプロパティを公開してしまうのは最悪
.NETのクラスは山ほどプロパティを公開してるけど、これも最悪なの？

340 ：デフォルトの名無しさん：2014/12/18(木) 22:10:35.29 ID:nYq1QBRW.net

>>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.net

>>340
いやだからアクセサでオブジェクトの状態を変える・モニターするのは別に普通だろと言ってるの。

342 ：デフォルトの名無しさん：2014/12/18(木) 22:55:00.66 ID:CbZTNJ5S.net

Entityにgetsetつけてるのって何も考えてないとしか思えない

343 ：デフォルトの名無しさん：2014/12/18(木) 23:22:15.68 ID:rHvMFTQj.net

状態変更やモニタするメソッドの名前をgetやsetにするのは自由だけど・・・命名規則的にそれってどうなの？
それに当然モニタリング機能を提供すべき責任を負ってるクラスだけだからな

状態を変更するメソッドならバリデーションや整合性チェック、状態変化に伴う動作まで含めて一つの完結した機能として定義すべきかな
状態変化監視するならオブザーバパターンで、JavaならpropeatyChangeListenerとか
実装して受け取るべきだと思う
もしくは監視用ステータスオブジェクトを返す感じとかか？

344 ：デフォルトの名無しさん：2014/12/18(木) 23:28:53.90 ID:ZOTu6c+H.net

ああ、俺が言ってるのは単純にプロパティの事だよ。

345 ：デフォルトの名無しさん：2014/12/19(金) 00:08:44.41 ID:Z5vGYKdT.net

こういう説明はどうだろう？
NG:状態変数を取得するために状態変数取得メソッドを作った
OK:状態取得メソッドを作ったので保管場所として状態変数を作った

少なくとも設計段階でデザインするべき物かな
そうやってデザインの結果として一部にクラスに、
結果的に単純プロパティのような形の実装になった物が出来るの悪いことではないと思う

346 ：デフォルトの名無しさん：2014/12/19(金) 00:25:25.61 ID:kXOboZoh.net

始めからプロパティとして定義するものもあれば、
プライベート変数を後からプロパティに変更する事もあれば、
プロパティだったものをプライベート変数に変更する事もあるよ。

347 ：デフォルトの名無しさん：2014/12/20(土) 09:38:36.96 ID:+GgZ8JtG.net

CTMCPでggr

348 ：デフォルトの名無しさん：2014/12/25(木) 01:56:12.77 ID:FXTtDPDb.net

C++とかjavaは元来の意味でのオブジェクト指向じゃないからね
あくまで、オブジェクト指向に便利な機能つけた手続き言語

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


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

Ruby
48.to_s

48さんに文字列になって欲しければ、48さんのメソッド呼ぶのが本来のオブジェクト指向ー

349 ：デフォルトの名無しさん：2014/12/25(木) 02:01:12.47 ID:FXTtDPDb.net

同じように、通信をするconnectionってインスタンスがあったとして

connection.status = Status::FINISHED

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

connection.finish

で、終了処理から内部状態変更やらやってくれるのがオブジェクト指向

350 ：デフォルトの名無しさん：2014/12/25(木) 03:27:23.93 ID:plZQlrr3.net

>>348
Staticメソッドを引き合いに出してJavaをけなしてもねえ……

351 ：デフォルトの名無しさん：2014/12/25(木) 03:29:07.82 ID:EL6gBj3v.net

>>348
そりゃ OO 的には美しいが、レジスタ一個で収まるところをごてごてとデコレートするのもね‥

352 ：デフォルトの名無しさん：2014/12/25(木) 14:56:46.31 ID:UXO0kBFe.net

手続きとOOを排他扱いする時点でお察し

353 ：デフォルトの名無しさん：2014/12/25(木) 15:07:57.78 ID:ZM9QeVU6.net

まぁ、速度優先するならOOPだの関数型だの構造化だのオーバーヘッドの必要なルール止めて
シーケンシャルに処理手書きしていけよってなるしな

保守性とかほかの目的で冗長な記述をルール化してるんだし

354 ：デフォルトの名無しさん：2014/12/27(土) 21:08:42.89 ID:Dl8SRIg9.net

文字列とか数値とか考えないのがオブジェクト思考じゃないの？

355 ：デフォルトの名無しさん：2014/12/31(水) 03:38:42.55 ID:GtslL7/x.net

基底クラスが「人」で、3つの派生クラスを作ってそれぞれに「.work()」を記述した場合で
3つの派生クラスの全インスタンスの「.work()」を実行したいときどのように管理すれば良いのでしょうか
自分では派生クラス毎にループを回すことしか思いつきませんでした

356 ：デフォルトの名無しさん：2014/12/31(水) 07:56:11.57 ID:grXbYJWV.net

基底クラスにwork()を定義して、派生クラスでオーバーライドするとか

357 ：デフォルトの名無しさん：2014/12/31(水) 11:53:58.04 ID:HNmCF9/p.net

>>355
「職業」インターフェースを追加して、work()を定義するかな

work()を使う側は、人に対して命令しているのではなく、職業の役割に対してその通り働けと言ってるわけだから

358 ：デフォルトの名無しさん：2014/12/31(水) 17:22:24.60 ID:/ugoQQzd.net

>>355
そんなん、クラスが「基底か」「派生か」ということとは関係ないじゃん。

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

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

ヒントはリスナー。

359 ：デフォルトの名無しさん：2014/12/31(水) 19:32:50.12 ID:NQSYJ4L5.net

>>355
> 3つの派生クラスの全インスタンスの「.work()」を
> 実行したいとき

例えば Smalltalk なら

人 allSubinstances do: #work

とかそういうこと？

360 ：デフォルトの名無しさん：2015/01/01(木) 10:15:28.02 ID:J+tSiQ0Q.net

Javaでクラスメソッド書いてると罪悪感あるんだけど、
副作用のない関数を書くんなら問題ないよね？

OOPっぽくないというのが罪悪感の原因だろうけど、
public staticで副作用のない関数だとむしろ書いていくべきだよね？

361 ：デフォルトの名無しさん：2015/01/01(木) 10:29:00.83 ID:unDf2EkN.net

>>360
気にするとすれば、そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの？ってところかな

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

良くあるアンチパターンの機能クラスと、データクラスに分かれちゃってる手続き型設計

362 ：デフォルトの名無しさん：2015/01/01(木) 10:49:25.84 ID:ZjnnyCSc.net

> そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの？ってところかな

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

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

Math.sinなどのメソッドは、どのデータに対する操作かな？
やっぱ、関数、っていう使い方は生き残ると思うんよね。

363 ：デフォルトの名無しさん：2015/01/02(金) 03:24:38.38 ID:Urv5GfAa.net

オブジェクト指向的にはstrategyっぽくオブジェクトにしとくべきなんだろうとは思う

んで、普通はAngleオブジェクトがあってそれがsinやらcosやらのオブジェクト持ってる感じじゃない？

364 ：デフォルトの名無しさん：2015/01/02(金) 18:16:39.18 ID:u8eIFPVv.net

この話題で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.net

>>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.net

三角関数自体は角度の持っている特性だからAngleから取り出せるものだけど、
数学としてそれを導き出す関数で概念化した法則≒数式はMathとして定義されていてもおかしくはないか

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

>>364
ファイルのコピーはファイル自体の機能ではなく、その上のストレージに自身の保持してるファイルを複製せよって命令する感じのような

367 ：デフォルトの名無しさん：2015/01/02(金) 21:02:15.51 ID:gr/6otir.net

>>365
そのnewを書く書かないとかcreateメソッドを準備するとかは興味なくて、
パラメータ→結果　で済む世界の話に短命オブジェクトを挟むのが嬉しくないよね？
絶対嫌だとか、困るとか言うつもりもないけど、今んとこメリットも見えないような。

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

ファイルのコピーの例はご指摘を受け、自分の中では少なくとも、
「メソッド方式よりも、関数方式でスッキリする例」で無くなってしまったｗ
関数方式でスッキリするのはやっぱ数式関係だけ、なのかも。

368 ：デフォルトの名無しさん：2015/01/02(金) 23:29:08.38 ID:Wdw9kQqY.net

基本的に読みやすいと言うか、その処理がどういう本質のものかをコード自体で示してるのが良いコードなワケで
数学関係の処理は、元が元だけに関数形式が一番本質に近いから、そりゃ関数形式が読みやすくもなるわな

369 ：デフォルトの名無しさん：2015/01/03(土) 07:48:27.17 ID:aZa/y2Ql.net

>>367
Angleがどうして短命なわけ？Pointとの本質的な違いは？
全てはあんたの一方的な思い込みだよw

370 ：デフォルトの名無しさん：2015/01/03(土) 07:51:27.38 ID:aZa/y2Ql.net

>>367は関数型に詳しくないだけじゃなくオブジェクト指向も初心者レベルだよw

371 ：デフォルトの名無しさん：2015/01/18(日) 03:08:14.87 ID:1HDk1G1l.net

>>370
その理由は？

372 ：デフォルトの名無しさん：2015/01/29(木) 11:14:38.08 ID:FsmC2LI9.net

beanというかバリューオブジェクト？とユーティリティクラスって

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

構造体と機能モジュールの関係そのまんまだし

373 ：デフォルトの名無しさん：2015/02/02(月) 21:59:42.72 ID:Q01xzseR.net

ブログラマの質にできるだけ影響を受けないように
プログラムの質を維持するのが目的だろ。
プログラマの質の水準をどの程度と見るかで
求められる効果が変わってくる。

374 ：デフォルトの名無しさん：2015/04/12(日) 15:53:34.84 ID:Buy3OTWo.net

恥ずかしながらC#やった時に初めて理解できたわ

IEnumerableとかIDisposableを継承すると馬鹿でも分かると思う

375 ：東京女子医科大学病院プロポフォール大量投与：2015/06/08(月) 21:15:24.77 ID:Fqp3awmG.net

マスゴミ・売国奴・医療業界が隠そうとする真実---------------------安楽死---------------------奴隷に勝手に死なれては困る

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

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.net

全ての識別子をグローバルにして誰かと共同制作したいならどうぞ、って感じだな

377 ：デフォルトの名無しさん：2015/11/01(日) 11:36:44.47 ID:hTxt2JkX.net

データ(変数群)と関数を関連付けすることでデータがデータとして存在するだけで意味がわかるのがオブジェクト指向
たとえば貨幣として扱いたいデータに対して、貨幣として必要な機能だけに関数を限定させれば、それはもうデータが存在するだけで貨幣として意味がわかる(貨幣以外の動作が起こり得ないから)

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

コメントつけろとかそういう原始的な話じゃなくてね

378 ：デフォルトの名無しさん：2015/11/02(月) 05:08:00.98 ID:tRZ2mEuQ.net

その辺は言語の構造によって違うが
つーかオブジェクトの使われ方も言語によって全然違ったりするのでね

379 ：デフォルトの名無しさん：2015/11/02(月) 08:23:24.30 ID:+vmX+mwq.net

あ、オブジェクト指向言語の実装とはちょっとかけ離れた例え話な
関数型言語で生きてきた人間にオブジェクト指向を説明する時にこういう話し方をする

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

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

つっても >>377で理解できるのはカプセル化のメリットだけだからまだ全然オブジェクト指向を説明しきれていないが

380 ：デフォルトの名無しさん：2015/11/22(日) 11:27:04.36 ID:yehd6qpM.net

ネットで調べていてもオブジェクト指向が分からない…。

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

違いを教えてください。

381 ：デフォルトの名無しさん：2015/12/17(木) 16:14:25.39 ID:f9fm3u2u.net

全てプリミティブかつアクセサ禁止って破綻してる
アクセスできないからプログラムも書けん

382 ：デフォルトの名無しさん：2015/12/18(金) 04:38:42.92 ID:TCff1iV0.net

>>380
vbのユーザー定義型とそれを扱うモジュール内の関数を一つのかたまりとして収めたのがクラスの考え方の原型。
vb なら本当のクラスも定義出来るんだが使ったこと無いのか?

383 ：デフォルトの名無しさん：2015/12/18(金) 07:38:43.70 ID:VKllly6g.net

>>382
ありがとう。
うーん、前職、書き方に制限ありまくりだったからクラスって本当に分からない。
情報系の大学だったけどプログラミングはほとんどやらなかったのに、基礎があるからって叩き上げられた形だったのよね。前職。
VB456にあるのかな。
.NET使う頃にはSEになってしまったから.NETもさわりしか分からない。
何かもう自分取り残されてるな…。

384 ：デフォルトの名無しさん：2015/12/18(金) 20:50:42.22 ID:rBQUliqS.net

一ヶ月も前のをまだ待ってたんかいな。
検索すればいきなり出てきそうなもんだけど。

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

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

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

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

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


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

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


メソッドは関数のようですが、当然インスタンスからしか呼ぶことができず、名前空間を汚しません。
きりんからメソッドを呼ぶと、メソッドはきりんの情報を受け取ります。(もしくはメソッドやクラス全体はきりんの情報をすでに持っていて、きりんから呼ばれたことをメソッド自身は知っており、きりんのデータを扱えます)。

385 ：デフォルトの名無しさん：2015/12/22(火) 12:13:39.68 ID:aBFh4Ipr.net

勘違いが多々見受けられるので、もう少し勉強したほうがいいね。

386 ：デフォルトの名無しさん：2015/12/31(木) 03:23:42.07 ID:riQaChnP.net

その言語のオブジェクト指向か、オブジェクト指向自体の定義か。
かなり違う。

387 ：デフォルトの名無しさん：2016/03/27(日) 21:38:57.58 ID:N7IGtcj3.net

結局、設計って何のためにするの?
って言ったら読む人間にわかりやすくするためだから
いくら哲学でガチガチに固めても読み手が
「何これさっぱりわからなーい」って言ったらそこで終わりな
設計書と内容が乖離してるソースもクソだし
どの仕様を実現しようとして書いたコードなのかわからないのもクソ
そもそも仕様の定義が明確でないのなんてソース書く前からクソが漏れてる

ブリブリブリブリ漏れてる!

388 ：デフォルトの名無しさん：2016/03/28(月) 21:59:57.56 ID:jI9F+kOe.net

家と同じ
無計画に建てたらあばら家になる

389 ：デフォルトの名無しさん：2016/03/29(火) 09:35:59.83 ID:/c8bAcK4.net

サッカーブッシュ日本代表日程ぷあたん（しゅっちょうまいくろ教育長交代）春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ２４チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン（販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート

390 ：デフォルトの名無しさん：2016/03/29(火) 21:13:02.91 ID:WTA2j3Vp.net

オブジェクト指向に何故するかと言えば
変数、プロパティは全てpublicにすればいいじゃないかと言うところから始まる

391 ：デフォルトの名無しさん：2016/03/30(水) 09:31:45.09 ID:idf8Q5SU.net

それなんて構造体？
カプセル化なんて常識じゃんw

392 ：デフォルトの名無しさん：2016/03/30(水) 20:08:05.29 ID:H6rY7wzp.net

>>391
常識になってるが故に何故する必要があるのか説明が出来ない人が多いかと

例えばオブジェクトのプロパティを全てpublicにしてコンピューターからしてみたらそれで何の問題があるのかと

393 ：デフォルトの名無しさん：2016/04/01(金) 18:13:49.68 ID:ELyCfH/G.net

>>392
ばか？

394 ：デフォルトの名無しさん：2016/04/01(金) 18:22:47.72 ID:TewsBR2n.net

>>393
でも全publicのプログラムって何の問題もなく動きますよね？それが悪いんですかね？

395 ：デフォルトの名無しさん：2016/04/01(金) 18:28:15.95 ID:j6FPRdfu.net

CPUがpublicかprivateか判断するのか

396 ：デフォルトの名無しさん：2016/04/01(金) 19:43:57.88 ID:RonLnaIy.net

あ、アセンブラ的な話はちょっと、、

397 ：デフォルトの名無しさん：2016/04/02(土) 06:38:34.56 ID:vYH8mHjR.net

>>394
もうちょっと気合い入れて釣れよ

398 ：デフォルトの名無しさん：2016/04/02(土) 16:15:31.86 ID:P45UDLlW.net

>>397
えー結構いいキレ具合やろ

399 ：デフォルトの名無しさん：2016/04/03(日) 21:25:16.27 ID:AFllrpm9.net

キレ過ぎてストライクゾーンから外れてるんやで
もうちょい工夫して再チャレンジするように

400 ：デフォルトの名無しさん：2016/04/03(日) 23:25:16.70 ID:I1bXI3bS.net

じゃあここはオブジェクト指向の大敵publicおじさん登場という展開の方針で

401 ：デフォルトの名無しさん：2016/04/03(日) 23:37:46.54 ID:GlCd9dIf.net

Setter getter使えw

402 ：デフォルトの名無しさん：2016/04/04(月) 19:02:28.23 ID:Pgq0yCJI.net

大敵はstaticおじさんだろ？

403 ：デフォルトの名無しさん：2016/05/01(日) 15:58:07.83 ID:tKi6j9CT.net

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

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

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

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


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.net

OOPに毒されすぎた人間はOCamlをやるべき
オブジェクト指向を活用できる部分は驚くほど少なく、殆どの問題はポリモーフィズムで静的に解決できることを知るだろう
OOの本質であるメッセージパッシングを活用できる場面を見極めることができるようになるだろう

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

階層構造の設計、リファクタリング、デザインパターンの適用は仕事をした気になるが、
それらのほとんどが、何でもOOで問題に取り組もうとしたから発生する必要性だと気付くべきだ

405 ：デフォルトの名無しさん：2016/05/17(火) 16:15:23.13 ID:PHOPFQsz.net

OCamlってそんなに駄目な言語なの？

406 ：デフォルトの名無しさん：2016/05/18(水) 01:04:43.37 ID:ErRdtrnJ.net

みんなにとってオブジェクト指向ってどんなの？
言語がJavaやC#だったり、Hibernateとかの有名ライブラリ使ってればオブジェクト指向？
「受注Entityにはgetterでカプセル化された各変数と、決済・出荷・返品・破棄のメソッドがあって...」みたいにビジネスロジックまでがっつり？

後者の失敗した感じの奴を引き取るハメになったんだが、巨大で邪悪な状態地獄を前に吐きそう･･･

407 ：デフォルトの名無しさん：2016/05/23(月) 21:43:40.30 ID:VxHtpmL+.net

>>406
＞決済・出荷・返品・破棄のメソッドがあって

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

頑張ってくださいとしか言いようがないです。

408 ：デフォルトの名無しさん：2016/05/24(火) 14:37:31.12 ID:kSJa5DY/.net

>>407
ありがとう…
手持ちの知識と経験で最初から実装するなら「振る舞いを持たない受注Dto」と「状態を持たない受注各種操作サービス」で作ると思う。
それとも「受注Dtoを包んだ受注操作Executer」みたいなのがOOPっぽくて良いのかな。

どうしてこうなったんだろ
入門書の自動車クラスを忠実に参考にしたのかな

409 ：デフォルトの名無しさん：2017/03/25(土) 13:05:46.69 ID:Hepb4FxQ.net

ふるまいを持たないクラスと状態クラスを分離したいよね
その設計指針は全くもって正しいと思う
でもそれはオブジェクト指向を真っ向から否定してるんだよね

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

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

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

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

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

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

これはトランザクションスクリプトとよばれ、OOP界隈ではディスられているやり方だけど、(なぜならクラスという概念を否定してるから)、こっちのほうが設計がシンプルかつ明瞭にたもたれると思う
個人的にはjavaでこれをやりたくないけどね

410 ：デフォルトの名無しさん：2017/03/28(火) 18:35:33.54 ID:wSpDlXLz.net

一年近く前のレスになにを書いてるんだって思ったがそれは置いておいて、
最初にオブジェクト指向を学んだ時、もっとも意味不明でかつ無意味な単語が「ふるまい」だった。

411 ：デフォルトの名無しさん：2017/03/29(水) 09:44:06.57 ID:PMA68UxV.net

>>410
> 「ふるまい」

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

ProtoObject
　Object
　　Behavior
　　　ClassDescription
　　　　Class
　　　　Metaclass

412 ：デフォルトの名無しさん：2017/07/23(日) 00:47:28.95 ID:4pTb5xvQ.net

　　　　　　　┌─マシン語
│
言語のレベル─┼─低級言語
　　　　　　　│　　　　　　┌─コンパイラ型
　　　　　　　└─高級言語─┤　
　　　　　　　　　　　　　　└─インタプリタ型
　　　　┌─手続き型
│
　　　　│　 　　　　　┌─宣言型
│ │
文法──┤ 　　　　　　├─関数型
│ │
　　 └ 非手続き型─┼─論理型
│
　　 　　　　　　├─グラフィック型
│
　　 　　　　　　└─問い合わせ

パラダイム──オブジェクト指向


ttp://webrylabo.blogspot.jp/2009/11/blog-post_28.html
2009年11月28日土曜日

413 ：デフォルトの名無しさん：2017/07/23(日) 00:54:24.08 ID:4pTb5xvQ.net

　　　　　　　　 　 ┌─マシン語
　　　　　　　　 　 │
言語のレベル─┼─低級言語
　　　　　　　　 　 │　 　 　 　 　 　 ┌─コンパイラ型
　　　　　　　　 　 └─高級言語─┤　
　　　　　　　　 　 　 　 　 　 　 　 　 └─インタプリタ型
　 　 　 　 ┌─手続き型
　 　 　 　 │
　 　 　 　 │　　　　　　　　　┌─宣言型
　 　 　 　 │　　　　　　　　　│
文法──┤　　　　　　　　　├─関数型
　 　 　 　 │　　　　　　　　　│
　 　 　 　 └ 非手続き型─┼─論理型
　　　　　　　　　　 　 　 　 　 │
　　　　　　　　　　 　 　 　 　 ├─グラフィック型
　　　　　　　　　　 　 　 　 　 │
　　　　　　　　　　 　 　 　 　 └─問い合わせ
　　　　　　　　　　　　　　　　　　　　　　　　　　　
パラダイム──オブジェクト指向
　　　　　　　　　　　　　　　　　　　　　　　　　　　
ttp://webrylabo.blogspot.jp/2009/11/blog-post_28.html
2009年11月28日土曜日

414 ：デフォルトの名無しさん：2017/09/16(土) 17:26:47.77 ID:3R6WSf4d.net

関数型はパラダイムの方にもっていきたいね

415 ：デフォルトの名無しさん：2017/11/06(月) 03:33:00.01 ID:2Q/sT7xS.net

ヤフーブログの　https://blogs.yahoo.co.jp/kamyu_2010　にデザパタ解説を発見した。

416 ：デフォルトの名無しさん：2018/05/23(水) 21:20:33.63 ID:Au5e7VGg.net

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

5648K

417 ：デフォルトの名無しさん：2018/07/05(木) 00:37:19.93 ID:RfoszcD2.net

QS9

418 ：デフォルトの名無しさん：2018/07/08(日) 16:25:00.06 ID:vDaTJ8Du.net

ヤフーのブログのサイトで初心者にはわかりやすいブログを発見したよ。
https://blogs.yahoo.co.jp/kamyu_2010/35417803.html

419 ：デフォルトの名無しさん：2020/06/18(木) 19:59:44.28 ID:n5xiCy8O.net

こちらで同意を得られなかったからニュース速報スレで騒いでるｗ

オブジェクト指向は愚かな考え 　　
https://hayabusa9.5ch.net/test/read.cgi/news/1592474015/
　　

420 ：デフォルトの名無しさん：2020/06/18(木) 22:56:36.42 ID:g18Fqbw/.net

未経験から半年でフリーエンジニアになれる人の特徴
https://www.youtube.com/watch?v=YCxu0jn52Qw
フリーランスか会社員かどっちが簡単かについての最終回答
https://www.youtube.com/watch?v=JA4JNSmIdxI
【エンジニア】正社員/派遣社員/フリーランスのメリット・デメリットについて
https://www.youtube.com/watch?v=fTG-eMpwhCg
月収1000万円オンラインサロンオーナーの日常【飲み過ぎ】
https://www.youtube.com/watch?v=lPfWZLatYus&t=107s
借金400万円から人生逆転するまでの軌跡
https://www.youtube.com/watch?v=fXdHlFFUjGY
エンジニアはお金を追求してはいけないという年寄りを論破してみた
https://www.youtube.com/watch?v=qJHCmxFv718
プログラミングスクールを否定する老害どもについて
https://www.youtube.com/watch?v=K2SN-Rr0PgY&t=506s
新人叩きしてる古参勢がすぐ儲からなくなる理由
https://www.youtube.com/watch?v=Ch9Ir8O-iqU&t=332s

421 ：デフォルトの名無しさん：2020/08/23(日) 20:35:12.94 ID:qp6BB2Af.net

ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？

チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

422 ：デフォルトの名無しさん：2020/08/23(日) 20:54:14.43 ID:QkS8Y3mc.net

まだ言ってる

423 ：デフォルトの名無しさん：2020/08/24(月) 03:51:28.76 ID:kS+LJTrm.net

>>1
必要なものと思い込ませて教材商法で荒稼ぎ

424 ：デフォルトの名無しさん：2020/08/24(月) 12:34:56 ID:jN2NYQ9A.net

複雑なあるいは煩雑なデータ構造を管理するとき。
類似したデータを系統立てて扱いたい時。
データが多くのインスタンスで構成される時。

425 ：デフォルトの名無しさん：2020/08/25(火) 01:58:34.46 ID:kR3OjXLq.net

enemyオブジェクトとか？
bulletインスタンスとか？

426 ：デフォルトの名無しさん：2020/08/25(火) 04:40:46.72 ID:yD81MP45.net

>>17
T-SQLは問合せ文と制御文が同時に書けるので、かなり複雑なことが手軽にできる（熟練者には）
なのでSQL　Server技術者の方がORACLE技術者よりも腕がいいことが多いらしい
工夫する幅が広いので、経験も広くなる

ウィンドウ操作ができないだけ
データ操作とウィンドウ操作を完全に分けると、要件的にはSQLの方が大部分を占めることもある
特に業務系の場合、ウィンドウ操作は定型的で、業務要件にそれほど関わらない
そっちの方がオマケ
データ処理の一部がクライアント側でしかできないと思ってるのは、腕がないだけ

427 ：デフォルトの名無しさん：2020/08/25(火) 04:55:25.53 ID:yD81MP45.net

MS-DOSの頃はMacを「オブジェクト指向」と言ったもんだが、今の意味とは違う
「オブジェクト思想」と言った方がいいのかな

Windowsはフォルダ構成以外に、スタートメニューがある
フォルダがごちゃごちゃしてるからだ
フォルダ構成とスタートメニューが二重にあるので、「インストール」を経ないと同期しない
実際にはレジストリで三重
なので「インストール」や「アンインストール」に抜けがあるとゴミが残ったり

それは机に物を置くという「オブジェクト思想」のデスクトップじゃない
そのかわり、動作が速く落ちにくい

今のMacは知らんが当時のMacは、「物」をどう置こうが自由なので、
パスも起動してから動的に確定したり、「機能拡張」のファイル数が少ない換わりに大きいので、遅く落ちやすかった

428 ：デフォルトの名無しさん：2020/08/25(火) 05:00:39.88 ID:yD81MP45.net

APPDATAで四重かｗ
Macは設定ファイルもアプリケーションの隣に置かれた

429 ：デフォルトの名無しさん：2020/08/25(火) 05:02:41.90 ID:yD81MP45.net

ところがそのスタートメニューもごちゃごちゃしてるので、もう長年見てないｗ
使う物をタスクバーにピン留めしてる