お願いします。言語は問いません。
オブジェクト指向言語じゃなくても
オブジェクト指向の話であれば問題ありません。
オブジェクト指向の活用方法を教えて下さい
■ このスレッドは過去ログ倉庫に格納されています
2014/03/25(火) 21:44:07.66ID:AtcH5MLU
2014/03/25(火) 21:52:21.12ID:EiPXCdKp
アイ オブジェクト たべたい
2014/03/25(火) 21:53:45.99ID:pgzxn/ED
オブジェクト指向の活用方法とあらためてきかれてもな。
仕事やってるなら、オブジェクト指向以外を使うことのほうが
まれだよ。まあ空気のようなものだ。
仕事やってるなら、オブジェクト指向以外を使うことのほうが
まれだよ。まあ空気のようなものだ。
4デフォルトの名無しさん
2014/03/25(火) 22:27:48.82ID:NjDRIK2T ポリモーフィズム
2014/03/26(水) 00:23:07.66ID:u5ViS8To
もしオブジェクト指向がなかった場合に困るのであれば、あなたが一体どんな風に
困るのかを教えてください。自分は困ったことがないので。
困るのかを教えてください。自分は困ったことがないので。
2014/03/26(水) 00:32:00.76ID:2aKYqEvM
2014/03/26(水) 00:43:25.50ID:q9v11IGY
SQLは関数型言語ですが何か?業務プログラマじゃないのがバレバレな発言だね。
2014/03/26(水) 00:49:07.29ID:czRoHAkF
困るのは関数の数が数百だとか数千だとか、ある程度規模が大きい場合だな。
オブジェクト指向なんて呼び方しているけど、本質的には構造化言語でもやっていた
モジュール化だからな。大量の関数を個別に扱うなんて大変な事をするよりも、
分類してまとめたモジュールを単位として組み合わせた方がシンプルになるからね。
そういう便利なモジュール化を最初から言語仕様に取り込んで
class{} とするだけで誰でも簡単にモジュールが作れるようにしたのが
オブジェクト指向言語。
オブジェクト指向なんて呼び方しているけど、本質的には構造化言語でもやっていた
モジュール化だからな。大量の関数を個別に扱うなんて大変な事をするよりも、
分類してまとめたモジュールを単位として組み合わせた方がシンプルになるからね。
そういう便利なモジュール化を最初から言語仕様に取り込んで
class{} とするだけで誰でも簡単にモジュールが作れるようにしたのが
オブジェクト指向言語。
2014/03/26(水) 00:52:05.00ID:2aKYqEvM
へー、SQLは関数型なのか。
俺は業務プログラマじゃないよw
俺は業務プログラマじゃないよw
2014/03/26(水) 00:56:46.58ID:UFBUrpIy
SQLが関数型であるという考え方は、
C言語は関数を定義するから関数型だよね、と同じ
C言語は関数を定義するから関数型だよね、と同じ
2014/03/26(水) 00:59:32.24ID:rbVA5aPF
SQLは宣言型言語だったかと。HTMLもそうだけど。
2014/03/26(水) 01:47:31.32ID:u5ViS8To
2014/03/26(水) 01:54:10.43ID:XRtgkR6L
それで出来ないのは属性の隠蔽と、継承による親子関係だな
まあ継承には最初はそんなにお世話にならんが、ある程度のクラス群を定義してくと
それらにグループ的な物が出来てくると思う
まあ継承には最初はそんなにお世話にならんが、ある程度のクラス群を定義してくと
それらにグループ的な物が出来てくると思う
2014/03/26(水) 05:17:45.52ID:q9v11IGY
実は、SQLは集合論を基にしているという点で、ある種の関数型言語とも考えられる(言語と
しては制限が多すぎるにしても)。
thinkbiganalytics.com/programming-trends-to-watch-logic-and-probabilistic-programming/
しては制限が多すぎるにしても)。
thinkbiganalytics.com/programming-trends-to-watch-logic-and-probabilistic-programming/
2014/03/26(水) 07:05:24.48ID:q8kXJDbw
>>12
実運用
自分1人で自分だけしか触らないプログラムだったら別にそのやり方でもある程度まで出来るだろうけど、
複数人数だとか、他の人が触るだとかするようになると、決めてたことが守られなくなってスパゲティに
なるのが常。
それをしっかりと見張って、ルールを破ったソースは絶対に許さないと監視してくれるのが、
その言語のコンパイラさん。
ちなみに俺も、1人で行うC言語の開発ではオブジェクト指向的に関数名や変数名を区分して作る。
実運用
自分1人で自分だけしか触らないプログラムだったら別にそのやり方でもある程度まで出来るだろうけど、
複数人数だとか、他の人が触るだとかするようになると、決めてたことが守られなくなってスパゲティに
なるのが常。
それをしっかりと見張って、ルールを破ったソースは絶対に許さないと監視してくれるのが、
その言語のコンパイラさん。
ちなみに俺も、1人で行うC言語の開発ではオブジェクト指向的に関数名や変数名を区分して作る。
2014/03/26(水) 07:48:30.63ID:5lLsdkXL
>>14
集合論ベースなら論理型じゃないのか?
集合論ベースなら論理型じゃないのか?
2014/03/26(水) 09:03:17.98ID:isiCXEht
SQLはクエリーであって、つまり問い合わせであって
それだけでアプリケーションになるわけないしな。
実際にSQLだけでアプリを作ったことあるのかい?って話。
それだけでアプリケーションになるわけないしな。
実際にSQLだけでアプリを作ったことあるのかい?って話。
2014/03/26(水) 09:10:42.35ID:isiCXEht
>>12
> それで達成できないことは何?
複雑さの低減かな。
たとえば、アセンブラ使って比較とジャンプで
ループは作れる。でも言語としてループがあれば簡単に書ける
つまりは複雑さが減ってるわけ。
オブジェクト指向も同じで、使えば複雑さが減る。
読んで考えなきゃいけないことが、
単語一つで、あぁあれね。とすぐに知ることが出来る。
そういうコードになる。
> それで達成できないことは何?
複雑さの低減かな。
たとえば、アセンブラ使って比較とジャンプで
ループは作れる。でも言語としてループがあれば簡単に書ける
つまりは複雑さが減ってるわけ。
オブジェクト指向も同じで、使えば複雑さが減る。
読んで考えなきゃいけないことが、
単語一つで、あぁあれね。とすぐに知ることが出来る。
そういうコードになる。
2014/03/26(水) 12:27:56.78ID:Vvdm35l0
2014/03/26(水) 19:13:13.84ID:C/yXeurz
SQLはチューリング完全じゃないんでしょ
2014/03/26(水) 20:05:10.15ID:u5ViS8To
>>18 複雑さの低減のところ、詳しく。
オブジェクト指向について書かれた本だと例題がそもそも短いので、オブジェクト
指向の導入によって逆に長い記述になってしまうし、わざとらしい例ばかりなので
これで本当に分かりやすくなったの?生産性や保守性は本当に上がったの?という
点がいつまで経っても納得がいかない。
(いまどきの学校なら、先生がちゃんと教えてくれるんだろうか?)
オブジェクト指向について書かれた本だと例題がそもそも短いので、オブジェクト
指向の導入によって逆に長い記述になってしまうし、わざとらしい例ばかりなので
これで本当に分かりやすくなったの?生産性や保守性は本当に上がったの?という
点がいつまで経っても納得がいかない。
(いまどきの学校なら、先生がちゃんと教えてくれるんだろうか?)
2014/03/26(水) 20:36:30.54ID:65VtCojr
18じゃないが。
電気回路で例えたら、抵抗とかダイオードとかトランジスタがびっしり基板を埋め尽くす
回路を作っていたのを、ICチップ数個を配線して繋げればいいだけにした
みたいなものかな。
ICチップ自体を作るところで確かに手間はかかるけど、
そのICチップという単位で手軽に扱える便利さが出てくるよね。
電気回路で例えたら、抵抗とかダイオードとかトランジスタがびっしり基板を埋め尽くす
回路を作っていたのを、ICチップ数個を配線して繋げればいいだけにした
みたいなものかな。
ICチップ自体を作るところで確かに手間はかかるけど、
そのICチップという単位で手軽に扱える便利さが出てくるよね。
2014/03/26(水) 20:54:01.45ID:lornT58y
オブジェクト指向によるループの簡略化ってなんだ?アイテレータか?
foreach構文使える言語ならOOPしなくても簡略化できるぜ。
foreach構文使える言語ならOOPしなくても簡略化できるぜ。
2014/03/26(水) 21:17:17.67ID:lornT58y
構造化プログラミングでは「機能」で全体を切り分けてた。
それがC++などのオブジェクト指向プログラミングになると「オブジェクト」で全体を切り分けるようになる。
電気回路に例えるなら、
それぞれの機能は基盤ごと、チップごとに整理されているが電源が一つしかない状態が構造化プログラミング。
それぞれの機能が自前の電源を持ってるのがオブジェクト指向。
それがC++などのオブジェクト指向プログラミングになると「オブジェクト」で全体を切り分けるようになる。
電気回路に例えるなら、
それぞれの機能は基盤ごと、チップごとに整理されているが電源が一つしかない状態が構造化プログラミング。
それぞれの機能が自前の電源を持ってるのがオブジェクト指向。
2014/03/26(水) 21:43:06.83ID:dEVLbQ7F
>>23
そういうレイヤーの話じゃないんだよね。
あなた関数の中の話をしてるじゃない?関数の中の書き方の話じゃない。
関数ではないものにデータがある。データは関数ではない。
オブジェクト指向はデータにそのデータを扱う関数をまとめたもの。
関連があるものを別々に管理するよりも、まとめたほうがわかりやすい。
データと処理が一体で管理できるから、このデータを扱えることが出来る処理はどれだろう?
などと考えなくて良くなる。管理がものすごく楽になる。
このまとめた物がオブジェクト。
そしてオブジェクト指向は、そのまとめた、物 と 物。
物自体と物同士を組み合わせて使うときの考え方。
物の生成をどうするか?
物の構造をどうするか?
物の振る舞いをどうするか?
そういうレイヤーの話じゃないんだよね。
あなた関数の中の話をしてるじゃない?関数の中の書き方の話じゃない。
関数ではないものにデータがある。データは関数ではない。
オブジェクト指向はデータにそのデータを扱う関数をまとめたもの。
関連があるものを別々に管理するよりも、まとめたほうがわかりやすい。
データと処理が一体で管理できるから、このデータを扱えることが出来る処理はどれだろう?
などと考えなくて良くなる。管理がものすごく楽になる。
このまとめた物がオブジェクト。
そしてオブジェクト指向は、そのまとめた、物 と 物。
物自体と物同士を組み合わせて使うときの考え方。
物の生成をどうするか?
物の構造をどうするか?
物の振る舞いをどうするか?
2014/03/26(水) 22:07:44.33ID:dEVLbQ7F
>>21
たとえばゲームで考えるとね。キャラクターを横に1つ移動するはX座標をプラス1するだけ。
だけどこれだけじゃゲームとして成り立たない。キャラクターには座標以外にも色々な情報がある。
キャラクターが持ってるであろう情報にはどんなものがある?
と聞いたら、いくつも答えが出てくるでしょう?
ならそれをまとめて種類(クラス)として管理したほうが楽じゃない?
敵キャラとかキャラクター自体は一緒だけどデータ(座標など)が違うものってあるじゃない?
敵キャラという物がいてある場面になったら、この物を生成する必要があるじゃない?(敵出現)
敵と自分が戦うとしたら、それは物と物と関連があってそこである作用が発生するということ。
つまりこういうこと。
小さな処理ではなくて、巨大なアプリを作ることを考えてみよう。
座標を1動かすという小さな処理だけを見ていたら分からないが、
なにかアプリを作ろうと思ったら、その処理を沢山組み合わせて作ることになる。
その処理をバラバラに管理していたら複雑になりすぎる。複雑だと時間がかかるしバグも増える。
出来るか出来ないかではなく、複雑にならないように作るというのが実際の開発で必ず求められる要件。
じゃあ、複雑にならないようにある単位でまとめようと思うだろう?
その後はまとめた物同士をどう組み合わせるのがいいか考えるようになるだろう?
そこでオブジェクト指向を使うと自然な形でまとめやすくなるんだよ。
わからなければ実際に頭の中で考えてみたらいい。たとえばブラウザを作るってのはどう?
aタグなら〜、ulタグなら〜などと、いきなり詳細なものを考える前に、まずブラウザを構成している要素。
UI部分、HTMLレンダリング部分、JavaScript部分、CSS部分と分けて考えるでしょう?
そこから更に各部分を小さく分けて、それをまた小さく分けてって考えていくでしょう?
この時大抵の人ならデータと処理を分離せずに分けていくと思うから、それがオブジェクトになるんだよ。
オブジェクト指向でなかったら、最後にデータと処理に分けてそれを関連付ける処理まで考えなといけない。
分けるたびに数は増えるから最後は膨大になるよね。それは嫌だから一つ手前のオブジェクトにしておきましょう。
たとえばゲームで考えるとね。キャラクターを横に1つ移動するはX座標をプラス1するだけ。
だけどこれだけじゃゲームとして成り立たない。キャラクターには座標以外にも色々な情報がある。
キャラクターが持ってるであろう情報にはどんなものがある?
と聞いたら、いくつも答えが出てくるでしょう?
ならそれをまとめて種類(クラス)として管理したほうが楽じゃない?
敵キャラとかキャラクター自体は一緒だけどデータ(座標など)が違うものってあるじゃない?
敵キャラという物がいてある場面になったら、この物を生成する必要があるじゃない?(敵出現)
敵と自分が戦うとしたら、それは物と物と関連があってそこである作用が発生するということ。
つまりこういうこと。
小さな処理ではなくて、巨大なアプリを作ることを考えてみよう。
座標を1動かすという小さな処理だけを見ていたら分からないが、
なにかアプリを作ろうと思ったら、その処理を沢山組み合わせて作ることになる。
その処理をバラバラに管理していたら複雑になりすぎる。複雑だと時間がかかるしバグも増える。
出来るか出来ないかではなく、複雑にならないように作るというのが実際の開発で必ず求められる要件。
じゃあ、複雑にならないようにある単位でまとめようと思うだろう?
その後はまとめた物同士をどう組み合わせるのがいいか考えるようになるだろう?
そこでオブジェクト指向を使うと自然な形でまとめやすくなるんだよ。
わからなければ実際に頭の中で考えてみたらいい。たとえばブラウザを作るってのはどう?
aタグなら〜、ulタグなら〜などと、いきなり詳細なものを考える前に、まずブラウザを構成している要素。
UI部分、HTMLレンダリング部分、JavaScript部分、CSS部分と分けて考えるでしょう?
そこから更に各部分を小さく分けて、それをまた小さく分けてって考えていくでしょう?
この時大抵の人ならデータと処理を分離せずに分けていくと思うから、それがオブジェクトになるんだよ。
オブジェクト指向でなかったら、最後にデータと処理に分けてそれを関連付ける処理まで考えなといけない。
分けるたびに数は増えるから最後は膨大になるよね。それは嫌だから一つ手前のオブジェクトにしておきましょう。
2014/03/26(水) 22:19:45.69ID:2aKYqEvM
要は、プログラマが問題解決の為に注目するスコープを、小さくするって事だよな。
2014/03/26(水) 23:16:50.71ID:dEVLbQ7F
オブジェクト指向使わないでも ”出来る” とかいうやつがいるけど、
出来るのは出来るんだよ。
重要なのはどれだけ複雑にしないで出来るかということ。
その複雑という観点が抜けてる意見は的外れで参考にならない。
たまに本当にオブジェクト指向じゃなくても複雑にしないで
できることもある。オブジェクト指向よりもシンプルに作れることもある。
それは問題領域が異なるから。上でSQLの話がでていたが
それはRDBMSからのデータ取得という問題だから。
SQLはその問題に特化した言語なのだから得意なのは当然。
でもアプリを作るという問題の場合は、オブジェクト指向が適していることが多い。
例題程度の短い問題で、オブジェクト指向の利点を感じないのも
短い問題だからという理由で説明できるね。
出来るのは出来るんだよ。
重要なのはどれだけ複雑にしないで出来るかということ。
その複雑という観点が抜けてる意見は的外れで参考にならない。
たまに本当にオブジェクト指向じゃなくても複雑にしないで
できることもある。オブジェクト指向よりもシンプルに作れることもある。
それは問題領域が異なるから。上でSQLの話がでていたが
それはRDBMSからのデータ取得という問題だから。
SQLはその問題に特化した言語なのだから得意なのは当然。
でもアプリを作るという問題の場合は、オブジェクト指向が適していることが多い。
例題程度の短い問題で、オブジェクト指向の利点を感じないのも
短い問題だからという理由で説明できるね。
2014/03/26(水) 23:42:37.18ID:u5ViS8To
(A) オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
→ 手間が増えるところ
(B) だけどクラス内のプロパティとメソッドの関連付けに対して名前を付ける必要がない
→ 手間が減るところ
普通、ひとつのクラスには複数(多数)のプロパティ、メソッドがあるので、
abs(B) > abs(A)
ということになり、これが「複雑さの低減」という理解で合ってますか?
→ 手間が増えるところ
(B) だけどクラス内のプロパティとメソッドの関連付けに対して名前を付ける必要がない
→ 手間が減るところ
普通、ひとつのクラスには複数(多数)のプロパティ、メソッドがあるので、
abs(B) > abs(A)
ということになり、これが「複雑さの低減」という理解で合ってますか?
2014/03/26(水) 23:52:53.55ID:u5ViS8To
もしそうだとすると、自分がオブジェクト指向のありがたみが分からないのは
abs(B) = abs(A)
のような、1つのクラスに1つのプロパティと1つのメソッドしかないような
ものばかり作っているのが原因ではないかと思えてきました
abs(B) = abs(A)
のような、1つのクラスに1つのプロパティと1つのメソッドしかないような
ものばかり作っているのが原因ではないかと思えてきました
2014/03/26(水) 23:55:51.39ID:lornT58y
>オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
javascriptみたく、プロトタイプベースのオブジェクト指向あるから、
これは必ずしもオブジェクト指向に当てはまる性質とは違う。
もちろん、名前付けてもいいけど。
javascriptみたく、プロトタイプベースのオブジェクト指向あるから、
これは必ずしもオブジェクト指向に当てはまる性質とは違う。
もちろん、名前付けてもいいけど。
2014/03/26(水) 23:56:29.04ID:2aKYqEvM
2014/03/27(木) 00:03:01.47ID:gcsG9K2Q
>>29
少し微妙なところはあるけれど、
>>30の
> のような、1つのクラスに1つのプロパティと1つのメソッドしかないような
> ものばかり作っているのが原因ではないかと思えてきました
ということであれば、その程度じゃ理解し難いと思うよw
処理と定義文の行が同じぐらいだろうからね。
普通は一つのクラスに、複数のプロパティとメソッドある。
関数やクラスの定義のための行よりも、処理の行数のほうが圧倒的に多い。
小さな問題なら関数さえ使わなくていい。
数行で終わる単純なスクリプトなら実際にそうする。
多くのプログラミング技術っていうのは、大きくて複雑な問題を
解決するために考えだされているものだから、
簡単な問題を使わなくても出来る というのは意味がなくて
大きな問題で比較しないといけない。
少し微妙なところはあるけれど、
>>30の
> のような、1つのクラスに1つのプロパティと1つのメソッドしかないような
> ものばかり作っているのが原因ではないかと思えてきました
ということであれば、その程度じゃ理解し難いと思うよw
処理と定義文の行が同じぐらいだろうからね。
普通は一つのクラスに、複数のプロパティとメソッドある。
関数やクラスの定義のための行よりも、処理の行数のほうが圧倒的に多い。
小さな問題なら関数さえ使わなくていい。
数行で終わる単純なスクリプトなら実際にそうする。
多くのプログラミング技術っていうのは、大きくて複雑な問題を
解決するために考えだされているものだから、
簡単な問題を使わなくても出来る というのは意味がなくて
大きな問題で比較しないといけない。
2014/03/27(木) 00:04:50.94ID:2gDV9B/K
ICチップの例でいうなら、その中に1個のダイオードしか入っていないものを作っている
ので、ICにする意味がない(なかった)、ということです
ので、ICにする意味がない(なかった)、ということです
2014/03/27(木) 00:08:07.39ID:1568NTop
>>29
実際にやって見るのがいいと思う
C#とかなら、書き込みや読み込みを行う抽象クラスであるStreamをとるメソッドに、ファイル、メモリ、ネット、データベースなんかを区別なく渡せたりする
自分でStreamを実装したクラスを作れば、それを利用する側は一切の修正なしに自作のStreamを使える、とか。
実際にやって見るのがいいと思う
C#とかなら、書き込みや読み込みを行う抽象クラスであるStreamをとるメソッドに、ファイル、メモリ、ネット、データベースなんかを区別なく渡せたりする
自分でStreamを実装したクラスを作れば、それを利用する側は一切の修正なしに自作のStreamを使える、とか。
2014/03/27(木) 00:11:02.12ID:ZCk9J0RA
>>34
そのダイオードがオブジェクトだよ。
ダイオードには入力と出力があってダイオードの仕事をするだろう。
入出力というinterfaceがわかれば、中はブラックボックスでいい。
外から見た時に、中がどんな仕組みなのかは知らなくてもいい。
それがオブジェクト指向だ。
そのダイオードがオブジェクトだよ。
ダイオードには入力と出力があってダイオードの仕事をするだろう。
入出力というinterfaceがわかれば、中はブラックボックスでいい。
外から見た時に、中がどんな仕組みなのかは知らなくてもいい。
それがオブジェクト指向だ。
2014/03/27(木) 00:11:39.64ID:j3gvVEw0
クラスを作る目的の1つは、ある変数に対してアクセスする関数群を同じクラスにまとめて、
変数自身は極力非公開にして、どこからか勝手にいじられないように隠蔽することだよ。
カプセル化というんだけどね。
変数自身は極力非公開にして、どこからか勝手にいじられないように隠蔽することだよ。
カプセル化というんだけどね。
2014/03/27(木) 00:14:40.12ID:j3gvVEw0
2014/03/27(木) 00:18:11.94ID:gcsG9K2Q
俺もダイオードは関数だと思わ。
そんな単機能のものではなく、
ダイオードなどを使って作られる製品。
ダイオードなどのパーツを組み合わせて作る製品
その製品を作るために各パーツどうやって組み合わせて効率よく作るか
という方法論としてソフトウェアではオブジェクト指向があると思うよ。
そんな単機能のものではなく、
ダイオードなどを使って作られる製品。
ダイオードなどのパーツを組み合わせて作る製品
その製品を作るために各パーツどうやって組み合わせて効率よく作るか
という方法論としてソフトウェアではオブジェクト指向があると思うよ。
2014/03/27(木) 00:26:18.85ID:2gDV9B/K
>>37 そうだとすると、1つのプロパティしかないような場合でもクラスにする価値が
あるということなんだろうけど、勝手にいじられるものが"変数"なのか"関数"なのか
というだけなので、結局同じに思えてしまうなあ
(暴走を引き起こすような)でたらめな値を設定できないようにするということかな?
あるということなんだろうけど、勝手にいじられるものが"変数"なのか"関数"なのか
というだけなので、結局同じに思えてしまうなあ
(暴走を引き起こすような)でたらめな値を設定できないようにするということかな?
2014/03/27(木) 00:28:46.02ID:ZCk9J0RA
2014/03/27(木) 00:29:16.59ID:2gDV9B/K
フリップ・フロップならオブジェクトかもしれないね
2014/03/27(木) 00:32:34.40ID:gcsG9K2Q
一つのプロパティしかないクラスであっても
アプリ全体で、そのクラスだけしか使ってないってことはまず無い。
小さなクラスしか見てないからわからないのであって
アプリ全体という大きなもので考えよう。
小さなクラスが数個あろうが、このクラスは他のクラスと
協調して動くでしょう? そういうところまで含めて考えないとダメだよ。
小さな視点ではなく、大きな視点を持つこと。
大きな視点を持てば、たまたまプロパティが一つしか
無いクラスがあったとしても、それがシステム全体として
必要なことであればなんら不思議ではない。
アプリ全体で、そのクラスだけしか使ってないってことはまず無い。
小さなクラスしか見てないからわからないのであって
アプリ全体という大きなもので考えよう。
小さなクラスが数個あろうが、このクラスは他のクラスと
協調して動くでしょう? そういうところまで含めて考えないとダメだよ。
小さな視点ではなく、大きな視点を持つこと。
大きな視点を持てば、たまたまプロパティが一つしか
無いクラスがあったとしても、それがシステム全体として
必要なことであればなんら不思議ではない。
2014/03/27(木) 00:39:43.19ID:E6f/eeJ0
javaなんかだと標準出力に文字を表示するのにSystem.out.println("Hello World!"); なんてことやってるわけで
ダイオードがstreamの一種ならオブジェクトで問題ない。
仕組みの複雑さが外から見えないという意味で、ダイオードは実に成功していると言えるだろう。
ダイオードがstreamの一種ならオブジェクトで問題ない。
仕組みの複雑さが外から見えないという意味で、ダイオードは実に成功していると言えるだろう。
2014/03/27(木) 00:41:16.91ID:gcsG9K2Q
オブジェクト指向の話で
クラスとインスタンスの話で
終わっちゃう人がいるけど、
オブジェクト指向の話には
インスタンスとインスタンスを組み合わせて動かすという
構造の話、組み合わせ方の話も含まれるよ。
クラスとインスタンスの話で
終わっちゃう人がいるけど、
オブジェクト指向の話には
インスタンスとインスタンスを組み合わせて動かすという
構造の話、組み合わせ方の話も含まれるよ。
2014/03/27(木) 00:42:23.36ID:gcsG9K2Q
インスタンスとインスタンスを組み合わせだけじゃなくて
クラスとクラスの組み合わせも。
(クラスの代わりにインターフェースだったりもする)
ほんと関数の中身などという小さな部分じゃなくて
全体を見ないとね。
クラスとクラスの組み合わせも。
(クラスの代わりにインターフェースだったりもする)
ほんと関数の中身などという小さな部分じゃなくて
全体を見ないとね。
2014/03/27(木) 00:43:14.26ID:E6f/eeJ0
ハローワールドでさえオブジェクト指向の真髄に触れてるわけで、
小さいプログラムだからOOPの恩恵が無いなどということはない。
Javaでは十分に抽象化され、簡便に使えるように用意されたライブラリ群を使っているではないか。
でも何でもかんでもオブジェクトにしてしまおうとするのは疑問だな。
小さいプログラムだからOOPの恩恵が無いなどということはない。
Javaでは十分に抽象化され、簡便に使えるように用意されたライブラリ群を使っているではないか。
でも何でもかんでもオブジェクトにしてしまおうとするのは疑問だな。
2014/03/27(木) 00:43:29.31ID:ht0q0Cmu
組み合わせが固定的な場合、一見オブジェクトに見えても単なる構造化にすぎないことが
多い。新しいオブジェクトをくっつけようとして、全部のオブジェクトを書き換えるはめになる。
依存性が多すぎるのだ。究極まで依存性をなくして何でも接続できるようにしたものを、
Inversion of Control (IoC), とか dependency injection (DI) と呼ぶ。テスト環境と本番環境と
で、まったく同じモジュールを動かしてテストできるようになる。が、何もかもIoCやDIにでき
るわけではないので、本当に使えるケースはあまりない。仕掛けが大掛かりすぎて、一行の
SQLやスクリプトに負けてしまうことも多い。
多い。新しいオブジェクトをくっつけようとして、全部のオブジェクトを書き換えるはめになる。
依存性が多すぎるのだ。究極まで依存性をなくして何でも接続できるようにしたものを、
Inversion of Control (IoC), とか dependency injection (DI) と呼ぶ。テスト環境と本番環境と
で、まったく同じモジュールを動かしてテストできるようになる。が、何もかもIoCやDIにでき
るわけではないので、本当に使えるケースはあまりない。仕掛けが大掛かりすぎて、一行の
SQLやスクリプトに負けてしまうことも多い。
2014/03/27(木) 00:47:32.14ID:gcsG9K2Q
IoCやDIを使うところは構造に関する所だと思う。
クラスがアプリの構造を表している所だと思う。
クラス(インスタンス)を値として使う場合
たとえばBigInt型みたいな、int値の巨大版みたいな
"値" にはDIを使わない方がいい。
こういう場合は値として普通にnewした方がいい。
クラスがアプリの構造を表している所だと思う。
クラス(インスタンス)を値として使う場合
たとえばBigInt型みたいな、int値の巨大版みたいな
"値" にはDIを使わない方がいい。
こういう場合は値として普通にnewした方がいい。
2014/03/27(木) 00:50:57.11ID: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ファイル
です
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ファイル
です
2014/03/27(木) 01:07:11.24ID:gcsG9K2Q
>>50
えと、そのコードを客観的に評価してもらったことある?
たとえばコードメトリクスツールで計測するとか。
その評価がないと、それ見てもなんの参考にもならない。
体育会系的に無駄で非効率な努力すれば
行数なんて稼げるしね。
コピペがだめな行為だってのは言うまでもないと思うけど、
コピペをすると簡単に行数稼げるよ。
えと、そのコードを客観的に評価してもらったことある?
たとえばコードメトリクスツールで計測するとか。
その評価がないと、それ見てもなんの参考にもならない。
体育会系的に無駄で非効率な努力すれば
行数なんて稼げるしね。
コピペがだめな行為だってのは言うまでもないと思うけど、
コピペをすると簡単に行数稼げるよ。
2014/03/27(木) 01:17:32.04ID: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個)評価が低くなってる。
ちょうど手元に今作っているソフトのカバレッジ結果を
開いていたから書くわ。オープンソースなので詳細は伏せるけど
1. 秘密
2.1 行数 約750行
2.2 関数の数 98個
2.3 変数の数 不明 (計測する意味が無い)
2.4 ファイル数 20個
2.5 クラス 25個
3. コードメトリクス 10点満点中 9.5
4. カバレッジ 90%
ちなみに一番、評価が低い関数だけど行数32行
行数は問題ではなくて、一つの関数にifとループが
多いから(と言っても8個)評価が低くなってる。
2014/03/27(木) 01:18:19.58ID:2gDV9B/K
関数や変数は多めに数えたんですが、こういった規模でもオブジェクト指向を活用できるのか
どうかを知りたかったのです。関数はさておき、変数はがんばって捻出しても増やせないと思
います。関数は増やせるかもしれませんが、無理をしそうな気がします。つまり不自然なソー
スになりそうです。
どうかを知りたかったのです。関数はさておき、変数はがんばって捻出しても増やせないと思
います。関数は増やせるかもしれませんが、無理をしそうな気がします。つまり不自然なソー
スになりそうです。
2014/03/27(木) 01:21:39.80ID:gcsG9K2Q
>>50
> 2.1 1,000行〜10,000行
> 2.2 5個〜20個
1関数あたり、200行〜500行ってことでいい?
これは多い。コードを把握するために一目で
スクロールしないで見渡せることが重要なので一画面が目安。
だいたい50行〜長くても100行
> 2.1 1,000行〜10,000行
> 2.2 5個〜20個
1関数あたり、200行〜500行ってことでいい?
これは多い。コードを把握するために一目で
スクロールしないで見渡せることが重要なので一画面が目安。
だいたい50行〜長くても100行
2014/03/27(木) 01:23:40.03ID:gcsG9K2Q
2014/03/27(木) 01:24:04.56ID:ze0m1e8o
オブジェクト指向はプログラムの問題というより人間の問題に近い。
オブジェクト指向にすれば、人間らしい仕様変更に比較的強いというだけの話。
オブジェクト指向にすれば、人間らしい仕様変更に比較的強いというだけの話。
2014/03/27(木) 01:26:05.92ID:2gDV9B/K
>>54 いや、違います。1関数あたり10行位です。残りがメインルーチンです。
2014/03/27(木) 01:30:04.40ID:ZCk9J0RA
>>50
1ファイルで10000行は見通し悪くないかねw
俺のは簡単に言うとだが、シンセで80ファイル、各200から1000行程度。
電卓で50ファイル、各100から1500行ってところだな。
長い関数で120行ぐらいだよ。
1ファイルで10000行は見通し悪くないかねw
俺のは簡単に言うとだが、シンセで80ファイル、各200から1000行程度。
電卓で50ファイル、各100から1500行ってところだな。
長い関数で120行ぐらいだよ。
2014/03/27(木) 01:31:59.53ID:1568NTop
ものによるんじゃない?
テキストフィルターがどういうものかわからないけど、変更に強くするとか再利用できるようにするとか
ただ、無理に小分けにしても返って複雑になることもありうる
テキストフィルターがどういうものかわからないけど、変更に強くするとか再利用できるようにするとか
ただ、無理に小分けにしても返って複雑になることもありうる
2014/03/27(木) 01:32:11.42ID:gcsG9K2Q
アンチパターン(悪いコートパターン)本に
"メイン"ルーチン という名前がでてきたら
それはアンチパターンだって書いてあった気がするなw
1関数10行?それが5個で
1000行 - 10*5 = メインルーチンが950行?
関数20個でもメインルーチン800行だよね?
一度コード品質計測してみるといいよ。
10点満点中1点未満とか言われるだろうから。
"メイン"ルーチン という名前がでてきたら
それはアンチパターンだって書いてあった気がするなw
1関数10行?それが5個で
1000行 - 10*5 = メインルーチンが950行?
関数20個でもメインルーチン800行だよね?
一度コード品質計測してみるといいよ。
10点満点中1点未満とか言われるだろうから。
2014/03/27(木) 01:34:26.69ID:2gDV9B/K
着目したい変数/関数があったとき、grep するとプログラムの実行順と同じ順序で
表示されて便利です。
表示されて便利です。
2014/03/27(木) 01:37:53.70ID:gcsG9K2Q
で、なんでコードの品質の話をしたかだけど、
技術力が低い人は、良いコードとダメなコードの違いがわからないから。
>>50の内容から、君がまだ良いコードがどんなものか
わからないレベルだろうってことがわかるわけ。
だからそのレベルでオブジェクト指向の利点がわからないのも無理はないし、
現時点でオブジェクト指向は意味が無いって結論づけたらダメだよ。
単に君がまだ未熟だから(それははっきりわかった)ってだけだから。
技術力が低い人は、良いコードとダメなコードの違いがわからないから。
>>50の内容から、君がまだ良いコードがどんなものか
わからないレベルだろうってことがわかるわけ。
だからそのレベルでオブジェクト指向の利点がわからないのも無理はないし、
現時点でオブジェクト指向は意味が無いって結論づけたらダメだよ。
単に君がまだ未熟だから(それははっきりわかった)ってだけだから。
2014/03/27(木) 01:42:00.90ID:E6f/eeJ0
>>62
なんでそんなに追い詰められてんの?
なんでそんなに追い詰められてんの?
2014/03/27(木) 01:47:38.94ID:gcsG9K2Q
>>61
プログラムの実行順が気になる?
それは抽象化ができてないから。
長いコードがあって、その順番まで意識しないといけなくなってる。
つまりそのコードは細かい断片で考えることができないということだよ。
変数もスコープが広くなってるね。着目したい変数でgrepしてわかるということは
変数名は長くなっているはず。でないと他の変数名とかぶるはずだからね。で、関数は使われてないと。
(関数が適切に使われていれば同じ"ローカル"変数名が何度も出てくる。同じでいいから名前考える手間省けるよ?)
関数は引数と戻り値があるだけ。それはいつどのタイミングでも使っても良い。
このようになっていれば、全体のことは考えずにその関数という小さな部分で考えることが出来る。
大きなものを大きなまま作るのではなく小さな物にしていく。
そうすれば順番なんて気にすることはないよ。
順番なんて気にしていたら、ユニットテストで関数をテストするときどうするのさ?
ユニットテストではある関数を狙い撃ちでテストするのよ?
プログラムの実行順が気になる?
それは抽象化ができてないから。
長いコードがあって、その順番まで意識しないといけなくなってる。
つまりそのコードは細かい断片で考えることができないということだよ。
変数もスコープが広くなってるね。着目したい変数でgrepしてわかるということは
変数名は長くなっているはず。でないと他の変数名とかぶるはずだからね。で、関数は使われてないと。
(関数が適切に使われていれば同じ"ローカル"変数名が何度も出てくる。同じでいいから名前考える手間省けるよ?)
関数は引数と戻り値があるだけ。それはいつどのタイミングでも使っても良い。
このようになっていれば、全体のことは考えずにその関数という小さな部分で考えることが出来る。
大きなものを大きなまま作るのではなく小さな物にしていく。
そうすれば順番なんて気にすることはないよ。
順番なんて気にしていたら、ユニットテストで関数をテストするときどうするのさ?
ユニットテストではある関数を狙い撃ちでテストするのよ?
2014/03/27(木) 01:48:13.52ID:gcsG9K2Q
2014/03/27(木) 01:48:36.67ID:E6f/eeJ0
LoCは何かと馬鹿にされがちだけど、
逆にCOCOMO2でとか言われても誰が答えられるってんだっていう。
つか変数や関数の数って何だよ。どうしてそれが気になる。コボラーか?
俺はどれも気にしないし、計測ツールもいれてねえよチクショウ。
逆にCOCOMO2でとか言われても誰が答えられるってんだっていう。
つか変数や関数の数って何だよ。どうしてそれが気になる。コボラーか?
俺はどれも気にしないし、計測ツールもいれてねえよチクショウ。
2014/03/27(木) 01:49:47.41ID:2gDV9B/K
(オブジェクト指向から離れちゃうけど)関数を一画面に収まる規模にして、複数の関数から
構成するようにすると、関数呼び出しが発生することになってしまいます。それが必然性が
ないものだったら、ロジックを追いづらいし、メンテしずらくなってしまうような気がしま
す。大体、関数の名前を考えるのに苦労してしまって、変な名前をつけちゃいそうです。
個人の技術力の問題であれば、しばらくROMってます。
構成するようにすると、関数呼び出しが発生することになってしまいます。それが必然性が
ないものだったら、ロジックを追いづらいし、メンテしずらくなってしまうような気がしま
す。大体、関数の名前を考えるのに苦労してしまって、変な名前をつけちゃいそうです。
個人の技術力の問題であれば、しばらくROMってます。
2014/03/27(木) 01:53:16.02ID:gcsG9K2Q
LoCは「同じ仕様のアプリを作った時に短いほうが優れているだろう」という
判断には使えるがそれ以外の目的では使えないよ。
LoCが多くてもは生産性が高いことにはならない
(たとえばコピペをすれば簡単に水増しできるが、これは品質を下げる行為)
判断には使えるがそれ以外の目的では使えないよ。
LoCが多くてもは生産性が高いことにはならない
(たとえばコピペをすれば簡単に水増しできるが、これは品質を下げる行為)
2014/03/27(木) 01:55:37.34ID:zuVXk4tw
Javaは現代のCOBOL
2014/03/27(木) 02:05:57.47ID:gcsG9K2Q
>>67
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし
それも俺の中では答えが出てる。
それは関数呼び出しをした時、関数の中まで見ないとロジックが
わからないようなコード(関数)になっているから。
たとえば、printf()という関数、その関数の中まで追ってみないでしょう?
それは関数名さえ見れば、中を追わなくてわかるから。
追わなくてもわかるというのは、脳に記憶できているということ。
関数の仕様がわかりやすいものは記憶できるが
中で何やっているかさっぱりな関数は記憶できない。
そういう関数は複雑ということ。記憶できないような関数を作らない。
大きなアプリを作るとき、コードをいちいち読んでいたらいくら時間があっても足りない。
だから読む時間を記憶することで圧縮する。とはいっても複雑なものは記憶できないし、
数が多くても記憶できない。俺は記憶術の天才じゃないのでね。
だから、関数はできるだけ単純な機能にする。複雑で高機能なものをたくさん作るよりも
(たくさん作ると名前をつけるのに困るし)
単純なものを少数作って、それを組み合わせるほうが覚えることが少ない。
中を見ないとわからないような関数は作らない。そういうのはだめな関数。
(オブジェクト指向にする理由としてオブジェクトという単位でグループ分けしておけば、覚えやすいというのもある)
そうやって読むべき所を減らしていけばいいんだよ。関数の中を見なくて済むような
そんな関数にしていけば、関数呼び出しが発生してもロジックは追える。見なくて言い分早く追える。
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし
それも俺の中では答えが出てる。
それは関数呼び出しをした時、関数の中まで見ないとロジックが
わからないようなコード(関数)になっているから。
たとえば、printf()という関数、その関数の中まで追ってみないでしょう?
それは関数名さえ見れば、中を追わなくてわかるから。
追わなくてもわかるというのは、脳に記憶できているということ。
関数の仕様がわかりやすいものは記憶できるが
中で何やっているかさっぱりな関数は記憶できない。
そういう関数は複雑ということ。記憶できないような関数を作らない。
大きなアプリを作るとき、コードをいちいち読んでいたらいくら時間があっても足りない。
だから読む時間を記憶することで圧縮する。とはいっても複雑なものは記憶できないし、
数が多くても記憶できない。俺は記憶術の天才じゃないのでね。
だから、関数はできるだけ単純な機能にする。複雑で高機能なものをたくさん作るよりも
(たくさん作ると名前をつけるのに困るし)
単純なものを少数作って、それを組み合わせるほうが覚えることが少ない。
中を見ないとわからないような関数は作らない。そういうのはだめな関数。
(オブジェクト指向にする理由としてオブジェクトという単位でグループ分けしておけば、覚えやすいというのもある)
そうやって読むべき所を減らしていけばいいんだよ。関数の中を見なくて済むような
そんな関数にしていけば、関数呼び出しが発生してもロジックは追える。見なくて言い分早く追える。
2014/03/27(木) 07:13:03.30ID:EL0PowgV
オブジェクト指向のこころは良い本だ
72デフォルトの名無しさん
2014/03/27(木) 07:26:53.08ID:6dxUJoHd 「オブジェクト」が参照なのって割と不便だよね。
2014/03/27(木) 10:03:27.48ID:E6f/eeJ0
関数型プログラミング的に言うと、
副作用(内部情報を持つ、外部デバイスにアクセスする等)のある関数は
プログラムを複雑にする悪玉菌扱いなんだけどね。
かといって純粋関数だけでプログラムかけるかっていう現実問題はあるけど。
しかし問題の切り分け方として、データと処理がセットになることが必ずしも礼賛されるかというとそうでもない。
副作用(内部情報を持つ、外部デバイスにアクセスする等)のある関数は
プログラムを複雑にする悪玉菌扱いなんだけどね。
かといって純粋関数だけでプログラムかけるかっていう現実問題はあるけど。
しかし問題の切り分け方として、データと処理がセットになることが必ずしも礼賛されるかというとそうでもない。
2014/03/27(木) 11:42:05.43ID: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
実際には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
2014/03/27(木) 12:26:13.49ID:rDeXrVt7
もっとも身近なオブジェクト指向の概念って、
ファイルやソケットのディスクリプタかな
説明もしやすいし理解も早い
ファイルやソケットのディスクリプタかな
説明もしやすいし理解も早い
2014/03/27(木) 12:52:47.48ID:Q+RTv4Ce
ファイラー上で見るファイルオブジェクト
あれのポップアップメニューが変化するのを見せるのがよさそう
あれのポップアップメニューが変化するのを見せるのがよさそう
2014/03/27(木) 15:10:04.52ID:qIhM9I6N
>>75
俺はStringクラスだと思うね。
この例を出すとどうも必ず叩かれるんだけどw
前提として長さをprivateで持ってる実装を考える(例えばjava.lang.Stringね)。
それを、連続したchar領域などと比較する。
strlenしないと長さが得られないのが後者で、
内部に既に長さを持ってるのが前者。
文字列データと、長さ、っていう非常に近い関係のものが、
内部に一緒に揃ってる。
一緒にあったほうがマシだから、一緒にある。
クラスの内側にそれを隠し持ってる。
そして、いろんなメソッドの内部でふんだんに参照してる。
俺はStringクラスだと思うね。
この例を出すとどうも必ず叩かれるんだけどw
前提として長さをprivateで持ってる実装を考える(例えばjava.lang.Stringね)。
それを、連続したchar領域などと比較する。
strlenしないと長さが得られないのが後者で、
内部に既に長さを持ってるのが前者。
文字列データと、長さ、っていう非常に近い関係のものが、
内部に一緒に揃ってる。
一緒にあったほうがマシだから、一緒にある。
クラスの内側にそれを隠し持ってる。
そして、いろんなメソッドの内部でふんだんに参照してる。
2014/03/27(木) 15:29:20.56ID:zuVXk4tw
strlenしないと長さが得られないのか、最初から長さを持ってるのか、
中身がどういう仕掛けになってるのか気にしなくていいのがオブジェクト指向なんじゃないの?
中身がどういう仕掛けになってるのか気にしなくていいのがオブジェクト指向なんじゃないの?
2014/03/27(木) 15:29:34.54ID:Q+RTv4Ce
昔はそう思ったこともあるが実装とI/Fがあまりにも近すぎてよくない
80デフォルトの名無しさん
2014/03/27(木) 16:23:36.30ID:R9FKO6iJ JavaのStringだと、lengthはフィールドじゃなくてメソッドでは?
内部で保持してるのかどうかは知らんが
内部で保持してるのかどうかは知らんが
2014/03/27(木) 19:09:37.68ID:+xc3TnzN
>ファイルやソケットのディスクリプタかな
ハンドル持ち回りはCによる実装レベルでも十分確立されてるし
OO言語じゃないと実装がとても大変って例はないもんかね
ハンドル持ち回りはCによる実装レベルでも十分確立されてるし
OO言語じゃないと実装がとても大変って例はないもんかね
2014/03/27(木) 20:16:21.85ID:rDeXrVt7
2014/03/27(木) 20:31:07.44ID:gcsG9K2Q
>>74
> 実際にはprintf()の中身は複雑なんですけどね。
いや、知ってるってw
複雑だけど、関数にすることで、
”中を見なくて良くなっている"
これがいい関数の例。
中を見ないと、どんなことやってるかわからないよ〜。
となってるのが、悪い関数の例。
> 実際にはprintf()の中身は複雑なんですけどね。
いや、知ってるってw
複雑だけど、関数にすることで、
”中を見なくて良くなっている"
これがいい関数の例。
中を見ないと、どんなことやってるかわからないよ〜。
となってるのが、悪い関数の例。
2014/03/27(木) 21:26:09.20ID:ZhR8Azo0
C++のストリーム演算子らへんは何をやってるのかさっぱり判らない悪い例じゃないの
2014/03/27(木) 21:34:12.95ID:gcsG9K2Q
>>84
何をやってるのかさっぱりわからないのは、
ストリーム演算子の中身の話であって、
そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう?
関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。(関数名は例ではない)
function process() {
initialize();
calc_price();
save_data()
}
何をやってるのかさっぱりわからないのは、
ストリーム演算子の中身の話であって、
そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう?
関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。(関数名は例ではない)
function process() {
initialize();
calc_price();
save_data()
}
2014/03/27(木) 21:55:08.72ID:ZhR8Azo0
>>85
お話が通じないことが良く判ったよ
俺流オペレータが何をやってるのかは中を見なと判らないでしょ
だからストリーム演算子の例を出したのに「使う人は使える」
>(関数名は例ではない)
ちゃんとした関数名にすれば中身見る必要無いだろ
お話が通じないことが良く判ったよ
俺流オペレータが何をやってるのかは中を見なと判らないでしょ
だからストリーム演算子の例を出したのに「使う人は使える」
>(関数名は例ではない)
ちゃんとした関数名にすれば中身見る必要無いだろ
2014/03/27(木) 22:02:47.00ID:ZhR8Azo0
printfも可変引数の仕組みと書式の関係が判ってようやく
初めて使えるレベルになるものだと思うけどな
それって結局中身見ないとまともに使えないでござるよ…って事にならないかね?
まさかこんなスレでprintfの中身を一度も見たことない奴なんていないだろうから
きっと錯覚してるだけだよ
初めて使えるレベルになるものだと思うけどな
それって結局中身見ないとまともに使えないでござるよ…って事にならないかね?
まさかこんなスレでprintfの中身を一度も見たことない奴なんていないだろうから
きっと錯覚してるだけだよ
2014/03/27(木) 22:06:56.92ID:+xc3TnzN
そういう意味だと上のハンドル志向が一番解りやすい
中を見たいとも思わないし
中を見たいとも思わないし
2014/03/27(木) 22:09:08.87ID:UpPNmNS/
誰かJava8のStreamの話をしてくれ。
2014/03/27(木) 22:12:33.90ID:ZhR8Azo0
かなりprintf族もハンドル取るのあるだろ
いやそういうことではなくて、関数名だけでちゃんと表現できてれば中身見る必要なんてないんだよ
結局いくら関数化しても中身見ないといけないようなケースは必ず存在するんだよ
いやそういうことではなくて、関数名だけでちゃんと表現できてれば中身見る必要なんてないんだよ
結局いくら関数化しても中身見ないといけないようなケースは必ず存在するんだよ
2014/03/27(木) 22:18:02.77ID:GOaviY18
今言う中身は実装じゃね?
実装を知らなくても使い方が分かればいいと
例は良くわかんない
実装を知らなくても使い方が分かればいいと
例は良くわかんない
2014/03/27(木) 22:26:01.90ID:ZhR8Azo0
実装を知らなくても使い方を想像できるってのは
裏返せば過去に自分が似たような物を作ったり設計書見たりとか
それなりの経験のある中の事じゃないの?
実装がさっぱり想像できないのをいくら眺めたところで
使い方が判るようになるとはとても思えないけど
裏返せば過去に自分が似たような物を作ったり設計書見たりとか
それなりの経験のある中の事じゃないの?
実装がさっぱり想像できないのをいくら眺めたところで
使い方が判るようになるとはとても思えないけど
2014/03/27(木) 22:27:02.26ID:1568NTop
コメントとか仕様書とかに使い方が書いてあれば実装を見なくても済む
printfのすべての実装なんて見たことないけど、仕様書どうりの動作をするとわかっている
printfのすべての実装なんて見たことないけど、仕様書どうりの動作をするとわかっている
2014/03/27(木) 22:36:29.59ID:GOaviY18
想像して使うってのはよく分からないけどsleep()とかsystem()はそれに近いかも?
使い方を知って、かつそれが曖昧になっても関数名や引数で思い出せるってところが分かり易さじゃない?
逆に見ても分からないってのは設計として複雑な気が
std::coutでいえば<<なら直感的だけど>>だと途端に恐怖を覚える
使い方を知って、かつそれが曖昧になっても関数名や引数で思い出せるってところが分かり易さじゃない?
逆に見ても分からないってのは設計として複雑な気が
std::coutでいえば<<なら直感的だけど>>だと途端に恐怖を覚える
2014/03/27(木) 22:41:51.63ID:zuVXk4tw
GoogleのC++スタイルガイドではストリームはやめろprintf使っとけって事になってるな。
2014/03/27(木) 23:09:47.29ID:1568NTop
他の言語に全く採用されないところをみるに、たんに演算子いじれてすごいでしょアピールで実利はなかったんだったんだろう
2014/03/27(木) 23:29:08.64ID:ZhR8Azo0
可変引数は呼び出し側自己申告以外にチェック機能が無いからバグの温床になりやすく
標準ライブラリからは除外したかったと昔どっかで読んだよ
正規表現みたいに書式と引数の型から判定するような仕組みは作れたはずだけど
それを言語仕様に含めてしまうと1関数でしかなかったprintfの書式文字列を
今更特別扱いするのは抵抗がとか紆余曲折あって全く別の方向に逃げた
標準ライブラリからは除外したかったと昔どっかで読んだよ
正規表現みたいに書式と引数の型から判定するような仕組みは作れたはずだけど
それを言語仕様に含めてしまうと1関数でしかなかったprintfの書式文字列を
今更特別扱いするのは抵抗がとか紆余曲折あって全く別の方向に逃げた
2014/03/27(木) 23:34:55.71ID:1568NTop
コンパイラが警告してくれるけどね
2014/03/27(木) 23:55:40.61ID:gcsG9K2Q
100デフォルトの名無しさん
2014/03/27(木) 23:59:54.87ID:zuVXk4tw 俺流オペレータの代表格だわな
101デフォルトの名無しさん
2014/03/28(金) 00:09:53.54ID:9wj0hHB8 代表格 = 同じではないという意味。
102デフォルトの名無しさん
2014/03/28(金) 00:14:00.53ID:Ek64RinZ そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう?
関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。(関数名は例ではない)
function process() {
initialize();
calc_price();
save_data()
}
定義済みのストリーム演算子は覚えればいいから、中を見ないでわかる。
俺俺オペレータで中を見ないとロジックを追えないようなものは
上に書いてあるのと同じ問題がある。
関数がダメなんじゃなくて使い方の問題。
オペレータもそれ自体がダメなんじゃなくて、使い方の問題。
中を見ないとロジック追えないような関数(オペレータも)はダメな関数。
話はこれと何も変わっとらん。反論にはなっていない。むしろ俺と同じことを言ってるだけ。
中身を見なくても、使えるでしょう?
関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。(関数名は例ではない)
function process() {
initialize();
calc_price();
save_data()
}
定義済みのストリーム演算子は覚えればいいから、中を見ないでわかる。
俺俺オペレータで中を見ないとロジックを追えないようなものは
上に書いてあるのと同じ問題がある。
関数がダメなんじゃなくて使い方の問題。
オペレータもそれ自体がダメなんじゃなくて、使い方の問題。
中を見ないとロジック追えないような関数(オペレータも)はダメな関数。
話はこれと何も変わっとらん。反論にはなっていない。むしろ俺と同じことを言ってるだけ。
103デフォルトの名無しさん
2014/03/28(金) 00:37:59.39ID:MtUKbk72 例えばさ、AppleとかMicroSoftのAPIは実装非公開だし、実装知らなくても使ってますよみんな。
つか、中身はブラックボックスでいいって表現に語弊があるのかな。
全体の構造を見てるときは個々の中身は気にしなくてもいい、
個々の中身を検討してるときは他のオブジェクトは気にしなくてもいいって意味だよ。
スコープを小さくすればわかりやすいよねってこと。
つか、中身はブラックボックスでいいって表現に語弊があるのかな。
全体の構造を見てるときは個々の中身は気にしなくてもいい、
個々の中身を検討してるときは他のオブジェクトは気にしなくてもいいって意味だよ。
スコープを小さくすればわかりやすいよねってこと。
104デフォルトの名無しさん
2014/03/28(金) 00:40:38.80ID:Ek64RinZ そういうこと。全体の構造を見ている時に
個々の中身を気にしなくちゃいけないコードを書いているから
>>67 みたいに
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし
関数呼び出しでロジックが追いづらくなっちゃうわけ。
それは関数の作り方が悪いせいであって関数のせいじゃないんだよ。
個々の中身を気にしなくちゃいけないコードを書いているから
>>67 みたいに
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし
関数呼び出しでロジックが追いづらくなっちゃうわけ。
それは関数の作り方が悪いせいであって関数のせいじゃないんだよ。
105デフォルトの名無しさん
2014/03/28(金) 00:53:28.66ID:jDIkKEXq 本来シフト演算子なはずの << やら >> を入出力に使うっていうのが、
演算子オーバーロードの悪い使い方(=俺流オペレータ)の代表格だっていう話では。
演算子オーバーロードの悪い使い方(=俺流オペレータ)の代表格だっていう話では。
106デフォルトの名無しさん
2014/03/28(金) 01:15:21.16ID:DmpYV1MJ (構造化プログラミングのスレかな?)
107デフォルトの名無しさん
2014/03/28(金) 01:52:09.43ID:wFHfzfhB (ここまでオブジェクト指向の活用方法の具体例なし)
108デフォルトの名無しさん
2014/03/28(金) 01:54:17.33ID:Ek64RinZ >>105
話ずれてるなぁ。
良い関数と悪い関数の違いの話だよ?
自分で勝手に作った関数でその中を見ないと
呼び出し元が何やってるかわからないのがダメって話。
ストリーム演算子は普通に記憶してるじゃんか。
中見ないでしょ?
話ずれてるなぁ。
良い関数と悪い関数の違いの話だよ?
自分で勝手に作った関数でその中を見ないと
呼び出し元が何やってるかわからないのがダメって話。
ストリーム演算子は普通に記憶してるじゃんか。
中見ないでしょ?
109デフォルトの名無しさん
2014/03/28(金) 02:34:08.23ID:uMoDJ17A 具体例ならエロい人のソースを覗き見…
ぐへへ
ぐへへ
110デフォルトの名無しさん
2014/03/28(金) 11:21:32.67ID:Vf+Kze9a >>102
> function process() {
> initialize();
> calc_price();
> save_data()
> }
その三つの関数は、再利用もしないし、他からも呼ばれないんじゃないの?
だったら、中身を見る必要ないよね。
中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
> function process() {
> initialize();
> calc_price();
> save_data()
> }
その三つの関数は、再利用もしないし、他からも呼ばれないんじゃないの?
だったら、中身を見る必要ないよね。
中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
111デフォルトの名無しさん
2014/03/28(金) 18:36:40.74ID:Ek64RinZ > 中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
ほら中見てるじゃんw
ほら中見てるじゃんw
112デフォルトの名無しさん
2014/03/28(金) 18:44:51.50ID:VVPQgbpw 中身を見なくていい = 機能もバグ取りもドキュメントも完成してるってことだから
今自分または開発チームが手がけてる関数は全て悪い関数ということになる。
今自分または開発チームが手がけてる関数は全て悪い関数ということになる。
113デフォルトの名無しさん
2014/03/28(金) 18:50:33.65ID:QLpZv79z114デフォルトの名無しさん
2014/03/28(金) 18:58:13.19ID:Vf+Kze9a >>111
> ほら中見てるじゃんw
見ないとロジック追えないだろ。
どんな関数でもメソッドでも同じ。
バグフィックスか仕様変更が必要なら、どんな場合でもそのコードを見る必要がある。
このことと、その関数の良し悪しは関係無い。
> ほら中見てるじゃんw
見ないとロジック追えないだろ。
どんな関数でもメソッドでも同じ。
バグフィックスか仕様変更が必要なら、どんな場合でもそのコードを見る必要がある。
このことと、その関数の良し悪しは関係無い。
115デフォルトの名無しさん
2014/03/28(金) 19:03:06.04ID:QLpZv79z >>114
> > ほら中見てるじゃんw
> 見ないとロジック追えないだろ。
君は少し勘違いしてるね。
上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないって話だよ。
> function process() {
> initialize();
> calc_price();
> save_data()
> }
上位関数 = processのロジックを追う時に
下位関数 = initializeやcalc_priceやsave_data の
ロジックを追わないと上位関数が何をしているのかわからない。
function process(name) {
printf("hello " + name);
}
でもこの場合は上位関数(process)のロジックを追っている時に
下位関数(printf)のロジックは追わない。
> > ほら中見てるじゃん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.21ID:QLpZv79z 上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないような
コードになってるから、
コードを解析するときに、関数があるたびに
下位関数の実装先にあっちこっちジャンプしていって大変なことになる。
下位関数のロジックを追わないとわからないような
コードになってるから、
コードを解析するときに、関数があるたびに
下位関数の実装先にあっちこっちジャンプしていって大変なことになる。
117デフォルトの名無しさん
2014/03/28(金) 19:20:17.16ID:QLpZv79z ここから発展して、
privateメソッドが、privateメソッドを読んでいて
そのprivateメソッドが、更にprivateメソッドを読んでいて
更にそのprivateメソッドが、privateメソッドを・・・みたいに
(再帰ではなく)文法上のコールスタックが深いものも
ダメな関数の一例だろうね。
なぜなら、privateメソッドは通常汎用的ではない。
汎用的なものに比べたら使われる回数が少ない。
こんなものは覚えられないし、覚える必要もない。
だから上位関数のロジックを追ってる時に
下位関数のロジックを追うことになる。
privateメソッドが、privateメソッドを読んでいて
そのprivateメソッドが、更にprivateメソッドを読んでいて
更にそのprivateメソッドが、privateメソッドを・・・みたいに
(再帰ではなく)文法上のコールスタックが深いものも
ダメな関数の一例だろうね。
なぜなら、privateメソッドは通常汎用的ではない。
汎用的なものに比べたら使われる回数が少ない。
こんなものは覚えられないし、覚える必要もない。
だから上位関数のロジックを追ってる時に
下位関数のロジックを追うことになる。
118デフォルトの名無しさん
2014/03/28(金) 20:50:21.98ID:VVPQgbpw119デフォルトの名無しさん
2014/03/29(土) 01:06:59.37ID:YRxS2933 オブジェクト指向は1990年代の話題
当時は実装メモリも少なかったので、コンパイルサイズの上限に達しないように
コンパイル単位となるファイルや関数を小さくしなければならなかった。また
CPUの性能も低かったので、コンパイル単位を小さくすることで再makeにかかる
時間を節約していた。そうでなければとてもじゃないが、実務では使えなかった。
現代では分かりやすさを犠牲にしてまで、小さい関数を量産する必要はなくなっ
ている。
以上、教科書に載らないオブジェクト指向の歴史
当時は実装メモリも少なかったので、コンパイルサイズの上限に達しないように
コンパイル単位となるファイルや関数を小さくしなければならなかった。また
CPUの性能も低かったので、コンパイル単位を小さくすることで再makeにかかる
時間を節約していた。そうでなければとてもじゃないが、実務では使えなかった。
現代では分かりやすさを犠牲にしてまで、小さい関数を量産する必要はなくなっ
ている。
以上、教科書に載らないオブジェクト指向の歴史
120デフォルトの名無しさん
2014/03/29(土) 01:21:57.46ID:3OHlSsnI121デフォルトの名無しさん
2014/03/29(土) 01:27:50.25ID:3OHlSsnI >>57
鳥肌立った
鳥肌立った
122デフォルトの名無しさん
2014/03/29(土) 01:30:44.27ID:3OHlSsnI >>67
ずっと読んでて思ったけど、もしかしてこの人がstaticおじさん?
ずっと読んでて思ったけど、もしかしてこの人がstaticおじさん?
123デフォルトの名無しさん
2014/03/29(土) 01:39:31.14ID:3OHlSsnI ようやくスレ全部読んだが、ポリモーフィズムとか委譲とかDIとかやってて、そういう話をしてるもんだと思って覗いたから
なんか逆に新鮮な気持ちになったぜ
俺が恵まれてるだけなんだろうが、50行を超える関数には出会ったことがない
自分でも書いたことがない
なんか逆に新鮮な気持ちになったぜ
俺が恵まれてるだけなんだろうが、50行を超える関数には出会ったことがない
自分でも書いたことがない
124デフォルトの名無しさん
2014/03/29(土) 01:45:14.49ID:2x5p0G/E 50行を超える関数ぐらい出会うだろ?
オープンソースのコード読んだことある?
オープンソースのコード読んだことある?
125デフォルトの名無しさん
2014/03/29(土) 08:53:28.56ID:VG1PVttb オブジェクト指向で作られたライブラリを手続きの中で利用するのがベスト。
自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。
オブジェクト指向は基盤レイヤーで収まっていればいい。
より上のレイヤーは構造化プログラミングとモジュール化で対応すべきだ。
自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。
オブジェクト指向は基盤レイヤーで収まっていればいい。
より上のレイヤーは構造化プログラミングとモジュール化で対応すべきだ。
126デフォルトの名無しさん
2014/03/29(土) 10:41:15.74ID:FZRsbrVI127デフォルトの名無しさん
2014/03/29(土) 13:47:53.85ID:qOhcuGD/ 言いたい事はわかる。きれいに階層化されたツリー構造の方が処理を追いやすい。
しかし、どうしてもオブジェクトグラフがネットワーク状になる場合があるし、
ユーザーがオブジェクトどうしを自由に接続できるアプリだってある。
しかし、どうしてもオブジェクトグラフがネットワーク状になる場合があるし、
ユーザーがオブジェクトどうしを自由に接続できるアプリだってある。
128デフォルトの名無しさん
2014/03/29(土) 14:12:25.86ID:riFdWRlf プログラマ適性なしは言い過ぎ
最近は非オブジェクト指向の言語も注目されてきてるよね
最近は非オブジェクト指向の言語も注目されてきてるよね
129デフォルトの名無しさん
2014/03/29(土) 15:10:59.76ID:T0jzXlJE 関数型の次はなんだ?
130デフォルトの名無しさん
2014/03/29(土) 17:53:31.03ID:nUN7khDD OOだろうが非OOだろうが、
粒度の小さなデータ構造でネットワークを形成することを
「複雑にする」と思う時点でプログラミングに向いていない。
粒度の小さなデータ構造でネットワークを形成することを
「複雑にする」と思う時点でプログラミングに向いていない。
131デフォルトの名無しさん
2014/03/29(土) 18:15:38.16ID:VG1PVttb メインルーチンでまとめて管理すればいいものを、
処理とデータをセットにすることに拘った挙句、
メディエータパターンなんてマヌケな再発明を強いられるOOPに哀愁を禁じえない。
処理とデータをセットにすることに拘った挙句、
メディエータパターンなんてマヌケな再発明を強いられるOOPに哀愁を禁じえない。
132デフォルトの名無しさん
2014/03/29(土) 18:26:03.80ID:qOhcuGD/ 巨大なメインルーチンねえ。描画とかどうすんのかな。
133デフォルトの名無しさん
2014/03/29(土) 18:36:10.02ID:VG1PVttb 描画はイベントドリブンか、メインループの中で描画オブジェクトの配列を作るわ。
134デフォルトの名無しさん
2014/03/29(土) 19:00:43.30ID:nUN7khDD >>131
あんたも適性ないね
あんたも適性ないね
135デフォルトの名無しさん
2014/03/29(土) 19:40:22.20ID:VG1PVttb しかたない。SEにでも転職するか。
136デフォルトの名無しさん
2014/03/29(土) 20:02:51.62ID:riFdWRlf 適性とかそういう話じゃないなコレ、教育不足に経験不足だ
137デフォルトの名無しさん
2014/03/30(日) 02:19:44.18ID:3Fl9YNZ5 数珠つなぎのメソッドチェーンを呼び出して何をするのかと思ったら、単に変数
に値を代入(または取得)して終わり、みたいのをよく見かけます。途中に現れる
メソッド名を見ても必然性を感じません。その階層で何をするでもないのです。
そういう場合はただの変数の代入に書き換えます。
(ついでなので)変数の名前はその目的が分かる名前に直します。
まるでオブジェクト指向の本質は多重のメソッド呼び出しだ、と言わんばかりな
のです。自分はそんなことより、単なる変数・関数であったとしても命名を重視
したいです。
規模の大きいソフトウェアの場合、名前をグルーピングして、階層を持たせて命
名することに異論はありません。でもそもそもそんなに大きいソフトウェアを
作っているわけではないんです。
世界にひとつだけの名前にして衝突を未然に防ぎたい、ということでしょうか?
に値を代入(または取得)して終わり、みたいのをよく見かけます。途中に現れる
メソッド名を見ても必然性を感じません。その階層で何をするでもないのです。
そういう場合はただの変数の代入に書き換えます。
(ついでなので)変数の名前はその目的が分かる名前に直します。
まるでオブジェクト指向の本質は多重のメソッド呼び出しだ、と言わんばかりな
のです。自分はそんなことより、単なる変数・関数であったとしても命名を重視
したいです。
規模の大きいソフトウェアの場合、名前をグルーピングして、階層を持たせて命
名することに異論はありません。でもそもそもそんなに大きいソフトウェアを
作っているわけではないんです。
世界にひとつだけの名前にして衝突を未然に防ぎたい、ということでしょうか?
138デフォルトの名無しさん
2014/03/30(日) 02:26:07.76ID:3Fl9YNZ5 同じことがメソッド呼び出しにも言えます。チェーンしているメソッドがそれぞ
れ何を意味しているのか分かりづらい上、記述の順序と実行の順序が異なるので
す。
例えば文章において、姓名は「姓」と「名」を近くに記述することで「姓名」と
なって、ひとりの人を表わすことができます。日付の「年」「月」「日」も電話
番号の「市外局番」「市内局番」「加入者番号」も同様です。これらをばらばら
に離して記述すると読み解くのに苦労することでしょう。
記述の順序が実行の順序と一致しないというのは、そういう状況に似ています。
ソースプログラムがまるでなぞなぞのようになってしまうのです。
実行順序が隣り合っているものは隣り合わせて記述すると分かりやすいプログラ
ムになります。修正も簡単です。テキストエディタやgrepが強力なプログラミン
グツールになります。
れ何を意味しているのか分かりづらい上、記述の順序と実行の順序が異なるので
す。
例えば文章において、姓名は「姓」と「名」を近くに記述することで「姓名」と
なって、ひとりの人を表わすことができます。日付の「年」「月」「日」も電話
番号の「市外局番」「市内局番」「加入者番号」も同様です。これらをばらばら
に離して記述すると読み解くのに苦労することでしょう。
記述の順序が実行の順序と一致しないというのは、そういう状況に似ています。
ソースプログラムがまるでなぞなぞのようになってしまうのです。
実行順序が隣り合っているものは隣り合わせて記述すると分かりやすいプログラ
ムになります。修正も簡単です。テキストエディタやgrepが強力なプログラミン
グツールになります。
139デフォルトの名無しさん
2014/03/30(日) 02:40:59.19ID:xYPcFXGk140デフォルトの名無しさん
2014/03/30(日) 02:59:11.38ID:WoVbd8CL >>137-138
あなた、オブジェクト指向の話をしてないですよ。
あなた、オブジェクト指向の話をしてないですよ。
141デフォルトの名無しさん
2014/03/30(日) 03:06:19.07ID:f3QUPmmN メソッドチェーンが何かを知らない人に説明しておくと、
value を foo関数で加工して、bar関数で加工して、baz関数で加工するという、
シェルスクリプトで言えば
cat var | foo | bar | baz というのを
baz(bar(foo(value))) という逆順で書くのではなく、
value.foo().bar().baz() という風に
処理の順番の通りにかけるようにした方法です。
ただそれだけのことです。
どちらがわかりやすいかは言うまでもありませんね。
value を foo関数で加工して、bar関数で加工して、baz関数で加工するという、
シェルスクリプトで言えば
cat var | foo | bar | baz というのを
baz(bar(foo(value))) という逆順で書くのではなく、
value.foo().bar().baz() という風に
処理の順番の通りにかけるようにした方法です。
ただそれだけのことです。
どちらがわかりやすいかは言うまでもありませんね。
142デフォルトの名無しさん
2014/03/30(日) 03:10:55.68ID:DA7dDHvX メソッドチェーンだと書いている順番に
処理が実行されるからわかりやすいんだよな。
オブジェクト指向だと、メソッド名短くても
かぶらないからその点でもメリットがある。
処理が実行されるからわかりやすいんだよな。
オブジェクト指向だと、メソッド名短くても
かぶらないからその点でもメリットがある。
143デフォルトの名無しさん
2014/03/30(日) 03:11:55.59ID:F8tYL6fO なあんだ!どっちの目を使うかなんだね!
144デフォルトの名無しさん
2014/03/30(日) 03:28:36.95ID:DA7dDHvX > baz(bar(foo(value))) という逆順で書くのではなく、
これって引数無いからまだわかりやすいけど、
引数あると見にくいんだよね。
baz(bar(foo(value, 1, 2), true), "test");
呼び出しが深くなるにつれて、bazと"test"みたいに距離がどんどん離れちゃう。
これがメソッドチェーンだと
value.foo(1,2).bar(true).baz("test");
このように関数と引数が近くに集まる。
これって引数無いからまだわかりやすいけど、
引数あると見にくいんだよね。
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.83ID:DA7dDHvX これもオブジェクト指向の活用方法の一つだろうね。
146デフォルトの名無しさん
2014/03/30(日) 03:34:47.32ID:eSXxjJTc だらだら連ねて1文に詰め込むのはデバッガで追いにくくなるからあまり好きじゃない。
147デフォルトの名無しさん
2014/03/30(日) 11:13:41.29ID:CUSBQvN9148デフォルトの名無しさん
2014/03/30(日) 11:13:50.33ID:Ep1/Keko 返り値をチェックして独自のエラーログを出したいw
149デフォルトの名無しさん
2014/03/30(日) 11:14:24.92ID:CUSBQvN9 >>146
どんなオンボロデバッガ使ってんだ?
どんなオンボロデバッガ使ってんだ?
150デフォルトの名無しさん
2014/03/30(日) 11:52:19.72ID:DA7dDHvX >>146
つまり、
baz(bar(foo(value, 1, 2), true), "test");
こういうのを
v = foo(value, 1, 2);
v = bar(v, true);
v = baz(v, "test");
って書くってこと?
おっと、メソッドチェーンとは関係ない話だったから
関数の方でレスしちゃったw
つまり、
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.64ID:IecYjjCX152デフォルトの名無しさん
2014/03/30(日) 12:01:26.08ID:DA7dDHvX 訂正(笑)
> baz(bar(foo(value, 1, 2), true), "test");
bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ
> baz(bar(foo(value, 1, 2), true), "test");
bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ
153デフォルトの名無しさん
2014/03/30(日) 12:07:13.82ID: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");
メソッドチェーンの 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.33ID:rCEPh8in 難しいことをしようとすれば、何を使っても複雑になる。
言語やパラダイムが複雑なんじゃなくて、解決しようとしている問題が複雑なだけなんだ。
言語やパラダイムが複雑なんじゃなくて、解決しようとしている問題が複雑なだけなんだ。
155デフォルトの名無しさん
2014/03/30(日) 12:47:55.23ID:DA7dDHvX えと、ああ、うん、
言語の違いっていうのは、問題がどうとかじゃなくて
読みやすさと書きやすさの違いの話なんだけどね。
言語の違いっていうのは、問題がどうとかじゃなくて
読みやすさと書きやすさの違いの話なんだけどね。
156デフォルトの名無しさん
2014/03/30(日) 13:17:38.07ID:CUSBQvN9 >>151
え?そんな簡単なこともできない開発環境でオブジェクト指向とか大笑いだな
え?そんな簡単なこともできない開発環境でオブジェクト指向とか大笑いだな
157デフォルトの名無しさん
2014/03/30(日) 13:27:57.55ID:3Fl9YNZ5 >>141
>シェルスクリプトで言えば
>cat var | foo | bar | baz というのを
このとき、foo や bar が何もしないプログラムであっても baz の前に入れることに
意味はありますか?関数型で組む場合は、何もしない関数 foo(), bar() を挟み込む
発想になったことがありません。必要になったとき、何かをしたくなったとき、その
ときに追加しています。
>シェルスクリプトで言えば
>cat var | foo | bar | baz というのを
このとき、foo や bar が何もしないプログラムであっても baz の前に入れることに
意味はありますか?関数型で組む場合は、何もしない関数 foo(), bar() を挟み込む
発想になったことがありません。必要になったとき、何かをしたくなったとき、その
ときに追加しています。
158デフォルトの名無しさん
2014/03/30(日) 13:31:27.59ID:amVAfrHC >>102
思うことは二つある。
1) 結局中身って見なくてもよくね?
どんな糞名前、糞用途でもAPIとして資料があって
int aaaaaaaaabbbbbbbbbbb(int x, int y)
x + yが素数のとき0を返し、それ以外のときyを返します。
となっていれば、中身は見なくてよくね?
実装なんてどーでもいいし想像したくもない。
2) 用途と名前が優れていればなおよし
シンプルな名前で表現されていれば、
APIリファレンスを紐解くことすら不要。
bool isprime(int x)ならこれだけで十分。
思うことは二つある。
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.35ID:qbWQb+53 継承とインターフェイスだけで十分便利
160デフォルトの名無しさん
2014/03/30(日) 14:01:44.17ID:qe+yThv9 >>157
たぶんお前の説明が下手くそだと思うんだが、いかなる場合も何もすることがない関数なんて言語問わず存在意義あるわけないじゃん
メソッドチェーン関係なく単に修正ミスとかだろ
もしくは、お前が知らないだけで何かの意味があるんだよ
よくみるなら具体例出してみろ
たぶんお前の説明が下手くそだと思うんだが、いかなる場合も何もすることがない関数なんて言語問わず存在意義あるわけないじゃん
メソッドチェーン関係なく単に修正ミスとかだろ
もしくは、お前が知らないだけで何かの意味があるんだよ
よくみるなら具体例出してみろ
161デフォルトの名無しさん
2014/03/30(日) 14:29:06.62ID:rCEPh8in With...End With ステートメント (Visual Basic)
http://msdn.microsoft.com/ja-jp/library/wc500chb.aspx
メソッドチェーンなんていらない。
言語側でwithステートメントを用意すれば済む話。
http://msdn.microsoft.com/ja-jp/library/wc500chb.aspx
メソッドチェーンなんていらない。
言語側でwithステートメントを用意すれば済む話。
162デフォルトの名無しさん
2014/03/30(日) 14:30:58.29ID:DA7dDHvX それでどうやって一行で書くの?
163デフォルトの名無しさん
2014/03/30(日) 14:44:34.88ID:rCEPh8in かりにメソッドチェーンという糖衣構文があるからといって実際に使う時は
object.func1(arg1, arg2, arg3)
.func2(arg1, arg2, arg3)
.func3(arg1, arg2, arg3)
...
.funcN(arg1, arg2, arg3);
って書くわけで、別にワンライナーしたいとかいう話ではないはず。
一つのオブジェクトに対して連続的にメソッドを呼び出す場合に、
それが手続きや意味ある関連として成立しないならまぎらわしいからやめろっていうのが
>>137-138の主張じゃないの。
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.04ID:DA7dDHvX メソッドチェーンまで糖衣構文かよw
これのどこが構文なんだ?
ライブラリの仕様だろ。
これのどこが構文なんだ?
ライブラリの仕様だろ。
165デフォルトの名無しさん
2014/03/30(日) 15:11:02.31ID:qe+yThv9 Withは見にくいからやめろという主張をよく聞くが
メソッドチェーンの利点はメソッドで加工を行ってそれを別のメソッドに引き渡せるっていうこと
同じオブジェクトにたいして関連したメソッドをいくつも呼ぶ時も行を分けたりとかしなくて済むから見やすい
メソッドチェーンの利点はメソッドで加工を行ってそれを別のメソッドに引き渡せるっていうこと
同じオブジェクトにたいして関連したメソッドをいくつも呼ぶ時も行を分けたりとかしなくて済むから見やすい
166デフォルトの名無しさん
2014/03/30(日) 15:11:12.60ID:yCsw+RdE >>163
糖衣?…構文??
糖衣?…構文??
167デフォルトの名無しさん
2014/03/30(日) 15:17:34.92ID:rCEPh8in168デフォルトの名無しさん
2014/03/30(日) 15:39:47.59ID:J3oHNw57 みんな、見やすいかどうかは
文字列の長さや行数で変わるってことを
理解してないよ。
たとえばこの二つ。
var newValue = value.fooFooFooFooFooFoo().barBarBarBarBarBar().bazBazBazBazBaz();
var newValue = value.foo().bar().baz();
単に文字列の長さが違うだけでやってることは全く一緒。
だけど上の方は見難くて下の方は見難くはない。
つまりどういうコードが見やすいかどうかは、単に文字列の長さだけでも変わってくるということ
だから文字列が長くなる場合にメソッドチェーンで一行にすることは不適切。
逆に言えば、文字列が短い場合に有効なのがメソッドチェーンというわけ。
withが見やすいのは、文字列が長くなった場合の話で
短いならばメソッドチェーンの方が見やすい。
どちらが、どんな場合でも見やすいなんてことにはならないんだよ。
文字列の長さや行数で変わるってことを
理解してないよ。
たとえばこの二つ。
var newValue = value.fooFooFooFooFooFoo().barBarBarBarBarBar().bazBazBazBazBaz();
var newValue = value.foo().bar().baz();
単に文字列の長さが違うだけでやってることは全く一緒。
だけど上の方は見難くて下の方は見難くはない。
つまりどういうコードが見やすいかどうかは、単に文字列の長さだけでも変わってくるということ
だから文字列が長くなる場合にメソッドチェーンで一行にすることは不適切。
逆に言えば、文字列が短い場合に有効なのがメソッドチェーンというわけ。
withが見やすいのは、文字列が長くなった場合の話で
短いならばメソッドチェーンの方が見やすい。
どちらが、どんな場合でも見やすいなんてことにはならないんだよ。
169デフォルトの名無しさん
2014/03/30(日) 15:47:45.96ID:rCEPh8in 短かろうと一行にするのはよくないと思うな。
オブジェクトが無い場合に
foo(); bar(); baz();
なんて書けるけど、実際はたとえ関連があっても横に連ねては書かないし。
メソッドチェーンにしたって
graphics.clearRect(0,0,640,480).drawRect(100,100,50,50).drawCircle(50,50,100)...
なんて横には書かなくね。
オブジェクトが無い場合に
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.00ID:J3oHNw57 > foo(); bar(); baz();
>
> なんて書けるけど
書けないよ。
baz(bar(foo()));
こうだろ
>
> なんて書けるけど
書けないよ。
baz(bar(foo()));
こうだろ
171デフォルトの名無しさん
2014/03/30(日) 15:53:47.22ID:rCEPh8in172デフォルトの名無しさん
2014/03/30(日) 15:58:50.57ID:J3oHNw57173デフォルトの名無しさん
2014/03/30(日) 16:33:15.45ID:IecYjjCX >>156
で、具体的なデバッガの名前とやり方は?
で、具体的なデバッガの名前とやり方は?
174デフォルトの名無しさん
2014/03/30(日) 17:17:26.79ID:CUSBQvN9 >>160
関数型言語ではid関数は重宝するぞ
関数型言語ではid関数は重宝するぞ
175デフォルトの名無しさん
2014/03/30(日) 17:34:15.13ID:qe+yThv9176デフォルトの名無しさん
2014/03/30(日) 18:01:52.30ID:3Fl9YNZ5 >>160 具体例は公開できないので申し訳ない
その1. メソッド名が訳の分かる名前ならば、その中身を心配して見にいく必要はない
⇒ これはレスや参考図書がよく使う 'foo' だの 'bar' だののレベルの名前を開発
しているプログラムに使っていることが問題なのだと思う
その2. 場合によっては改名するつもりで中身を見にいくと、なんでこれを括りだしたの?
という疑問が発生(もとから括り出す必要はなくて、名前も要らないんじゃないの?)
⇒ メソッドの中身をメインルーチンにコピペして解決!!
オブジェクト指向の話がいつの間にかコピペの話に...
オブジェクト指向って、どんな場合に役に立つのか、また活用方法を知りたい
のです
あるいはオブジェクト指向があるから常に使わなければならない、という考えは
間違いで、使うか使わないかは便利か便利じゃないか、解決しようとしている
問題や環境・状況に合わせて、判断すればいいものなのか?
そのとき、判断材料には本人や周りのひとのスキルを含めなくていいのか?
人のスキルに関係なく、いつでも・絶対にオブジェクト指向が有利なのか?
メソッド呼びさえしていればオブジェクト指向なので後ろ指さされることは
ないものなのか?
その1. メソッド名が訳の分かる名前ならば、その中身を心配して見にいく必要はない
⇒ これはレスや参考図書がよく使う 'foo' だの 'bar' だののレベルの名前を開発
しているプログラムに使っていることが問題なのだと思う
その2. 場合によっては改名するつもりで中身を見にいくと、なんでこれを括りだしたの?
という疑問が発生(もとから括り出す必要はなくて、名前も要らないんじゃないの?)
⇒ メソッドの中身をメインルーチンにコピペして解決!!
オブジェクト指向の話がいつの間にかコピペの話に...
オブジェクト指向って、どんな場合に役に立つのか、また活用方法を知りたい
のです
あるいはオブジェクト指向があるから常に使わなければならない、という考えは
間違いで、使うか使わないかは便利か便利じゃないか、解決しようとしている
問題や環境・状況に合わせて、判断すればいいものなのか?
そのとき、判断材料には本人や周りのひとのスキルを含めなくていいのか?
人のスキルに関係なく、いつでも・絶対にオブジェクト指向が有利なのか?
メソッド呼びさえしていればオブジェクト指向なので後ろ指さされることは
ないものなのか?
177デフォルトの名無しさん
2014/03/30(日) 19:02:38.40ID:qe+yThv9 >>176
なんだ、昨日の続きならそうかけよ
当然、 fooとbarとかの名前なら書いたやつが無能なだけ。
jQueryとかrubyみたいにわかりやすい名前がいい
中身はどこかでまたつかうとか、メソッドチェーンでシンプルに書けるなら有用かもしれない
オブジェクト指向は完璧ではないし、スキルがない人ならやらなくてもいいんじゃない?
ただし、C#とかJavaみたいにオブジェクト指向ありきで設計された言語はやっぱり知識は必要
標準ライブラリ自体オブジェクト指向専用だからね
C#でStreamではなくFileStreamしか受けないメソッドとかを作ってしまったら不便だし、不要なフィールドを公開したら危険だ
なんだ、昨日の続きならそうかけよ
当然、 fooとbarとかの名前なら書いたやつが無能なだけ。
jQueryとかrubyみたいにわかりやすい名前がいい
中身はどこかでまたつかうとか、メソッドチェーンでシンプルに書けるなら有用かもしれない
オブジェクト指向は完璧ではないし、スキルがない人ならやらなくてもいいんじゃない?
ただし、C#とかJavaみたいにオブジェクト指向ありきで設計された言語はやっぱり知識は必要
標準ライブラリ自体オブジェクト指向専用だからね
C#でStreamではなくFileStreamしか受けないメソッドとかを作ってしまったら不便だし、不要なフィールドを公開したら危険だ
178デフォルトの名無しさん
2014/03/30(日) 22:50:01.50ID:rCEPh8in >>176
オブジェクト指向を使うと、同じものを2つ以上同時に扱うのが簡単なんだよね。
2つのファイルを同時に編集するとか
ぷよぷよの画面を2つならべてみるとか
5人のボンバーマンが同時に動くとかさ。
オブジェクト指向を使うと、同じものを2つ以上同時に扱うのが簡単なんだよね。
2つのファイルを同時に編集するとか
ぷよぷよの画面を2つならべてみるとか
5人のボンバーマンが同時に動くとかさ。
179デフォルトの名無しさん
2014/04/01(火) 20:30:56.47ID:c88mFqYR >>173
スモールトーク系のデバッガーはメソッドチェーンのそれぞれのメソッド呼び出しごとにステップ実行できるらしいよ
スモールトーク系のデバッガーはメソッドチェーンのそれぞれのメソッド呼び出しごとにステップ実行できるらしいよ
180デフォルトの名無しさん
2014/04/01(火) 21:54:52.60ID:WgoYILFU181デフォルトの名無しさん
2014/04/02(水) 21:15:51.80ID:R40jOAQ7 性能低下を防ぐためにメソッドの内容をメインルーチンに直に展開する作業は、
処理系にまかせることもできるだろうが、それによって多態性は失われる。
それよりもソフトウェアを細かく分割して構成する以上、バージョンの依存
関係が複雑に絡み合うほうが問題として大きい。
処理系にまかせることもできるだろうが、それによって多態性は失われる。
それよりもソフトウェアを細かく分割して構成する以上、バージョンの依存
関係が複雑に絡み合うほうが問題として大きい。
182デフォルトの名無しさん
2014/04/02(水) 21:49:26.89ID:YdJBhj/R >>180
スモールトークっていったらスクイークとかじゃないの?
口先番長認定するまえに自分で調べてみたの?
口の中にご飯をスプーンで入れてもらうまで
馬鹿みたいに口開けて上を向いているタイプの人なの?
スモールトークっていったらスクイークとかじゃないの?
口先番長認定するまえに自分で調べてみたの?
口の中にご飯をスプーンで入れてもらうまで
馬鹿みたいに口開けて上を向いているタイプの人なの?
183デフォルトの名無しさん
2014/04/02(水) 22:04:27.79ID:UHLZ3L7X184デフォルトの名無しさん
2014/04/03(木) 00:45:59.14ID:OChVK7bs >>4
ポリモーフィズムはリリースされたプログラムをユーザーが部分的に更新しな
がら使う(ライブラリやDLLを更新する)と、プログラマが当初考えていた以上
の使われ方をして、動作の保証ができなくなる、ってことにならないの?
昔でいうgoto文や、メモリーリークを起こしがちなC言語のポインタみたいに
やっかいなことにならないの?
ポリモーフィズムはリリースされたプログラムをユーザーが部分的に更新しな
がら使う(ライブラリやDLLを更新する)と、プログラマが当初考えていた以上
の使われ方をして、動作の保証ができなくなる、ってことにならないの?
昔でいうgoto文や、メモリーリークを起こしがちなC言語のポインタみたいに
やっかいなことにならないの?
185デフォルトの名無しさん
2014/04/03(木) 00:59:50.75ID:p51daBHj 動作の保証ができなくなるようなことを許すのは単なる欠陥でしょ
186デフォルトの名無しさん
2014/04/03(木) 02:22:36.23ID:Dr19mwRL メソッドごとにコメントアウトすればいいよ
てかメソッドチェーンとしてのチェックってあるかね
てかメソッドチェーンとしてのチェックってあるかね
187デフォルトの名無しさん
2014/04/03(木) 04:56:35.67ID:4OpITLe5 >>183
できないと思ってるの?
できないと思ってるの?
188デフォルトの名無しさん
2014/04/03(木) 07:32:45.27ID:7TERZTkc >>187
できるんなら、その方法書いてくれ。
できるんなら、その方法書いてくれ。
189デフォルトの名無しさん
2014/04/03(木) 08:26:44.88ID:oN99KWq6 いい加減に認めろよ……
そもそも仮に「メソッドチェーンはデバッグできない」としても、それは「オブジェクト指向」を否定するのに大事な要素でもないじゃん
何かこだわりでもあるの?
そもそも仮に「メソッドチェーンはデバッグできない」としても、それは「オブジェクト指向」を否定するのに大事な要素でもないじゃん
何かこだわりでもあるの?
190デフォルトの名無しさん
2014/04/03(木) 08:48:37.07ID:syg3Ul2m191デフォルトの名無しさん
2014/04/03(木) 15:05:44.04ID:v6ez+Y0x >>188
ちゃんとしたSmalltalk処理系では(つまりGNU Smalltalkとかの変わり種を除けば)一般に
value foo halt bar baz で、bar のコール直前でデバッガを起動させて bar のステップ実行ができる
ってそういうことではなく? ちなみに halt は古典的なSmalltalkにおけるブレイクポイントみたいなもの。
ちゃんとしたSmalltalk処理系では(つまりGNU Smalltalkとかの変わり種を除けば)一般に
value foo halt bar baz で、bar のコール直前でデバッガを起動させて bar のステップ実行ができる
ってそういうことではなく? ちなみに halt は古典的なSmalltalkにおけるブレイクポイントみたいなもの。
192デフォルトの名無しさん
2014/04/03(木) 15:25:06.01ID:hov1QvrO みんなSmalltalk使ってたのかよ
193デフォルトの名無しさん
2014/04/03(木) 17:07:01.60ID:4OpITLe5 スモールトークがオブジェクト指向の元祖だからな
スモールトークでできるならオブジェクト指向の欠点とは胃炎な
スモールトークでできるならオブジェクト指向の欠点とは胃炎な
194デフォルトの名無しさん
2014/04/03(木) 17:16:43.96ID:hov1QvrO ていうか、一つの式に詰め込んだら便利かどうかなんてオブジェクト指向と関係なくね?
195デフォルトの名無しさん
2014/04/03(木) 19:17:35.74ID:/A78gSRK Smalltalkには、コードを英文のように読み下せるように書く慣習みたいなものがあって、
value foo bar baz みたいな式だとちょっとメリットをイメージしにくいですが、たとえば
「1 から 9 までの数を配列にして、それをシャッフルして最初の3つを得る」みたいな処理を、
(1 to: 9) asArray shuffled first: 3 というふうに一気にメソッドチェーンにして書くようなことはよくします。
そんなこともあって、メソッドチェーンだからデバッグしづらいというような制約はほとんどうけない仕組みになっています。
value foo bar baz みたいな式だとちょっとメリットをイメージしにくいですが、たとえば
「1 から 9 までの数を配列にして、それをシャッフルして最初の3つを得る」みたいな処理を、
(1 to: 9) asArray shuffled first: 3 というふうに一気にメソッドチェーンにして書くようなことはよくします。
そんなこともあって、メソッドチェーンだからデバッグしづらいというような制約はほとんどうけない仕組みになっています。
196デフォルトの名無しさん
2014/04/03(木) 20:08:44.08ID:JDC55uKf >>194
そもそもオブジェクト指向についてあんまり語ってないからいいんじゃね
そもそもオブジェクト指向についてあんまり語ってないからいいんじゃね
197デフォルトの名無しさん
2014/04/03(木) 21:23:31.55ID:y3U0PHNW198デフォルトの名無しさん
2014/04/04(金) 00:28:50.72ID:T327aBHM C++じゃなくてObjective-Cが流行ってれば
オブジェクト指向絡みの論争は半分になったんじゃないかと
思えてしかたがない。
オブジェクト指向が、じゃなくてC++が採用した方法は、な議論大杉
オブジェクト指向絡みの論争は半分になったんじゃないかと
思えてしかたがない。
オブジェクト指向が、じゃなくてC++が採用した方法は、な議論大杉
199デフォルトの名無しさん
2014/04/04(金) 01:37:59.49ID:G1RCkua4 クラスベース vs プロトタイプベース
200デフォルトの名無しさん
2014/04/04(金) 01:52:31.25ID:h1F261Ig Objective-C十分流行ってるじゃん
201デフォルトの名無しさん
2014/04/04(金) 03:12:14.91ID:T327aBHM ここ5年ぐらいでiOS用で一気に拡まったけど90年代を通じて
一般の想定するオブジェクト指向と言ったらC++だったからな…
90年代後半からはそこにJavaが加わり…的な。
ある意味バカみたいに基本に忠実なObjective-Cの方が
オブジェクト指向とは〜って議論のたたき台としてはよかったよな的な。
一般の想定するオブジェクト指向と言ったらC++だったからな…
90年代後半からはそこにJavaが加わり…的な。
ある意味バカみたいに基本に忠実なObjective-Cの方が
オブジェクト指向とは〜って議論のたたき台としてはよかったよな的な。
202デフォルトの名無しさん
2014/04/04(金) 07:15:48.10ID:R/rpZwB2 >>197
と言うか、行単位でのブレークポイントなのはデバッガの都合でしかないんだよなあ
と言うか、行単位でのブレークポイントなのはデバッガの都合でしかないんだよなあ
203デフォルトの名無しさん
2014/04/04(金) 07:36:28.20ID:KeYVoIFc >>202
式の途中にブレークポイントを入れるのはデバッガだけでは無理っす。
式の途中にブレークポイントを入れるのはデバッガだけでは無理っす。
204デフォルトの名無しさん
2014/04/04(金) 08:06:13.57ID:JslAeCyW205デフォルトの名無しさん
2014/04/04(金) 09:05:42.51ID:KeYVoIFc 最低限、コンパイラにも手を入れる必要があると思うぞ。
206デフォルトの名無しさん
2014/04/04(金) 10:52:39.43ID:N5FO4XZ5 デバッガのブレークポイントの指定が
行単位ってだけで、関数単位でのステップは可能。
そして関数単位で止めたいなら
関数ごとに改行すればいいだけじゃない。
行単位ってだけで、関数単位でのステップは可能。
そして関数単位で止めたいなら
関数ごとに改行すればいいだけじゃない。
207デフォルトの名無しさん
2014/04/04(金) 13:07:13.88ID:JslAeCyW >>206
> デバッガのブレークポイントの指定が行単位ってだけで、
たいていの IDE は行単位ではなくてステートメント単位じゃね?
> 関数ごとに改行すればいいだけじゃない。
そもそもそんなことしたくないか、発端だろ。
デバッグのためにソース弄るとかは最後の手段だろ。
> デバッガのブレークポイントの指定が行単位ってだけで、
たいていの IDE は行単位ではなくてステートメント単位じゃね?
> 関数ごとに改行すればいいだけじゃない。
そもそもそんなことしたくないか、発端だろ。
デバッグのためにソース弄るとかは最後の手段だろ。
208デフォルトの名無しさん
2014/04/05(土) 08:19:53.84ID:nKpGUjgO >>206
だーかーらー、
コンパイラが出す行情報以外にどうやって
ブレークかけるアドレスを取り出すわけ?
関数ごとに改行したところで
普通のコンパイラはステートメント単位でしか行番号情報ださねーぞ。
もしかして、単にデバッガのUIの問題だと思ってた?
甘杉
だーかーらー、
コンパイラが出す行情報以外にどうやって
ブレークかけるアドレスを取り出すわけ?
関数ごとに改行したところで
普通のコンパイラはステートメント単位でしか行番号情報ださねーぞ。
もしかして、単にデバッガのUIの問題だと思ってた?
甘杉
209デフォルトの名無しさん
2014/04/05(土) 08:39:06.87ID:OXL1p1Q1 そういうスレたててやれ
210デフォルトの名無しさん
2014/04/05(土) 10:05:58.71ID:AlWzj+6w いったいどのデバッガやコンパイラについて話してるのか知らんが、
VS2013とかにはメソッドチェーンのデバッグ機能あるぞ……
メソッドチェーン中の個々のメソッドについて戻り値とその型を表示してくれる
VS2013とかにはメソッドチェーンのデバッグ機能あるぞ……
メソッドチェーン中の個々のメソッドについて戻り値とその型を表示してくれる
211デフォルトの名無しさん
2014/04/05(土) 12:34:58.04ID:zg062x0r >>1
mvcで作ればなんとなくわかる
mvcで作ればなんとなくわかる
212デフォルトの名無しさん
2014/04/05(土) 21:29:41.29ID:LGGjyQ0u オブジェクト指向を使うには、変数や関数がある程度以上の個数がないと無意味。
あとインスタンスが2個以上必要な場合じゃないと意味がない。
俺の分野ではどちらも当てはまらないので、オブジェクト指向が活用できない
という結論に至った。みんな、ありがとう。
あとインスタンスが2個以上必要な場合じゃないと意味がない。
俺の分野ではどちらも当てはまらないので、オブジェクト指向が活用できない
という結論に至った。みんな、ありがとう。
213デフォルトの名無しさん
2014/04/05(土) 21:49:36.29ID:anSZmmIR オブジェクト指向が活用できない分野ってどんな分野よ
214デフォルトの名無しさん
2014/04/05(土) 22:16:36.14ID:iKzYf4PO 書き換えて再利用とか機能の追加が少ない機械みたいな分野だったら
(構造化言語の)Cそのまんまで十分じゃないの、とは思う。
(構造化言語の)Cそのまんまで十分じゃないの、とは思う。
215デフォルトの名無しさん
2014/04/06(日) 06:09:18.41ID:IRmFVDmN >>212の日本語訳
「俺がいつも書くコードはオブジェクト指向になっていない。
だから俺の分野ではオブジェクト指向は使えない。」
「オブジェクト指向」の部分にどんな技術を入れても成立する
魔法の言い訳だな。
「俺がいつも書くコードはオブジェクト指向になっていない。
だから俺の分野ではオブジェクト指向は使えない。」
「オブジェクト指向」の部分にどんな技術を入れても成立する
魔法の言い訳だな。
216デフォルトの名無しさん
2014/04/06(日) 06:50:21.75ID:7fCDh1Rd 同じものが沢山作れる、ってのは確かにオブジェクト指向のミソだが、
インスタンスが一つだろうと、オブジェクト指向プログラミングによって得られるものは色々あるぞ
再利用性とか、単体テストのしやすさとか、拡張性とかな
あと、オブジェクト指向プログラミングの重要なデザインパターンに「シングルトン」というのがあって、こいつはインスタンスを一つに限定するものなんじゃな
インスタンス一つだから役に立たない、ってのは世の中のプログラマには通じないと思われる
インスタンスが一つだろうと、オブジェクト指向プログラミングによって得られるものは色々あるぞ
再利用性とか、単体テストのしやすさとか、拡張性とかな
あと、オブジェクト指向プログラミングの重要なデザインパターンに「シングルトン」というのがあって、こいつはインスタンスを一つに限定するものなんじゃな
インスタンス一つだから役に立たない、ってのは世の中のプログラマには通じないと思われる
217デフォルトの名無しさん
2014/04/06(日) 09:28:19.55ID:v5F7vKVc 記述側がより人間の思想に近くなったメリットと、実装側でからくり(C++ なら vtable)を生成コードに常に追加するコストとを天秤にかけたら、どっちに軍配があがるかは人それぞれだね
ライナスは OO をぼろくそにけなしているね
ライナスは OO をぼろくそにけなしているね
218デフォルトの名無しさん
2014/04/06(日) 11:55:32.65ID:X8q2hYwd >>216
> 再利用性とか、単体テストのしやすさとか、拡張性とかな
単体テストはべつにして、再利用性とか拡張性とか広い意味では複数インスタンスじゃね?
あと、同じものをたくさんじゃなくって、ちょっと違うものを作れるって言うのがミソかと。
> 再利用性とか、単体テストのしやすさとか、拡張性とかな
単体テストはべつにして、再利用性とか拡張性とか広い意味では複数インスタンスじゃね?
あと、同じものをたくさんじゃなくって、ちょっと違うものを作れるって言うのがミソかと。
219デフォルトの名無しさん
2014/04/06(日) 12:55:51.09ID:hTzu53D+ >>217
> ライナスは OO をぼろくそにけなしているね
ライナスだけじゃね?w
しかも俺らはカーネル作ってるわけじゃないから、
用途によって言語は変えるべきという正しい考え方からすると、
ライナスが何言っても何使っても関係ないよねw
> ライナスは OO をぼろくそにけなしているね
ライナスだけじゃね?w
しかも俺らはカーネル作ってるわけじゃないから、
用途によって言語は変えるべきという正しい考え方からすると、
ライナスが何言っても何使っても関係ないよねw
220デフォルトの名無しさん
2014/04/06(日) 12:56:37.04ID:hTzu53D+ どっちに軍配があがるかは人それぞれというより
用途によりけりってことだろう。
で、大概の用途にOOに軍配が上がると。
用途によりけりってことだろう。
で、大概の用途にOOに軍配が上がると。
221デフォルトの名無しさん
2014/04/06(日) 13:06:24.24ID:N1Ox9kUH ここまでの内容ならライブラリで十分。オブジェクト指向は不要。
222デフォルトの名無しさん
2014/04/06(日) 13:16:36.50ID:nZeav+Zp ライブラリとオブジェクト指向を同列に語ってる馬鹿は黙ってろよ
223デフォルトの名無しさん
2014/04/06(日) 13:29:28.28ID: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)
具体的な実装よりも抽象に依存するべきである。これはコードの分離に有効だ。
.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.94ID:v5F7vKVc >>223
vtableを生成コードに常に追加するコストに見合うものかどうか疑問だね
vtableを生成コードに常に追加するコストに見合うものかどうか疑問だね
225デフォルトの名無しさん
2014/04/06(日) 18:19:41.32ID:7fCDh1Rd vtableの生成コストとか言い出したら、スクリプト言語なんて論外じゃねーかw
226デフォルトの名無しさん
2014/04/06(日) 18:34:59.08ID:C74PoYgz C++だとvtableは必要なとこにしか付かないよね
227デフォルトの名無しさん
2014/04/06(日) 18:36:50.32ID:XoDYwo6S ぷらぷら。ぼくはvirtualなメソッドじゃないよ。
228デフォルトの名無しさん
2014/04/06(日) 18:37:51.19ID:ZbP0XCh9 なんでここだけC++初心者スレみたいになってんの?
229デフォルトの名無しさん
2014/04/06(日) 18:39:42.35ID:7fCDh1Rd 一番知名度のあるオブジェクト指向プログラミング言語はJavaの筈なのにね
230デフォルトの名無しさん
2014/04/06(日) 18:44:04.82ID:wJ4fkLfq 致命度?
231デフォルトの名無しさん
2014/04/06(日) 20:38:36.74ID:IDxsBa0K いいや、Objective-Cが最後に勝つね
232デフォルトの名無しさん
2014/04/06(日) 20:55:17.94ID:C74PoYgz Objective-C++が節操なくて素敵だよw
233デフォルトの名無しさん
2014/04/09(水) 01:49:33.61ID:eVIzB16V オブジェクト指向に相対するパラダイムってなによ
関数型+代数的データ型?
関数型+代数的データ型?
234デフォルトの名無しさん
2014/04/09(水) 03:10:51.74ID:j9Z2BVsM それは相対する、ってほどでも無いような
オブジェクト指向自体も考え方が複数あるからなあ…
関数型はともかく、手続き型でオブジェクト指向に真っ向から相対して組むとすれば
・データと処理がお互いに依存しないように組む、例えば特定のユーザ定義型に依存する処理などは控え、ひとつずつ引数で渡してもらうなどする
・モジュールは流れに沿って切り分ける、例えば全てのデータはデータモジュールに、全ての初期化は初期化モジュールに、本処理はメインモジュールに書く
とか、そんな感じになるのかな
オブジェクト指向自体も考え方が複数あるからなあ…
関数型はともかく、手続き型でオブジェクト指向に真っ向から相対して組むとすれば
・データと処理がお互いに依存しないように組む、例えば特定のユーザ定義型に依存する処理などは控え、ひとつずつ引数で渡してもらうなどする
・モジュールは流れに沿って切り分ける、例えば全てのデータはデータモジュールに、全ての初期化は初期化モジュールに、本処理はメインモジュールに書く
とか、そんな感じになるのかな
235デフォルトの名無しさん
2014/04/09(水) 08:48:53.28ID:lgQL/971 向いてる方向が違うんだから、遠い近いはあるだろうけど相対って言うのはないんじゃね?
236デフォルトの名無しさん
2014/04/09(水) 17:51:40.57ID:iVtPfWG1 >>129
DDD?ってこれパラダイムじゃないか
DDD?ってこれパラダイムじゃないか
237デフォルトの名無しさん
2014/04/09(水) 18:41:01.22ID:rvzGfgdi 昔DDDっていうデバッガ使ってたな...
238デフォルトの名無しさん
2014/04/09(水) 21:00:52.84ID:TCIMdxjw DDT (CP/M-80) じゃなくて?
239デフォルトの名無しさん
2014/04/09(水) 21:03:36.40ID:rvzGfgdi >>238
gdbのGUIフロントエンドだよ
gdbのGUIフロントエンドだよ
240デフォルトの名無しさん
2014/04/10(木) 22:59:06.71ID:EbsHnFyb 最近ベクトル演算をする必要が出てきたので、オブジェクト指向のプロパティを
使って実現しようと考えている。
○か×か?
使って実現しようと考えている。
○か×か?
241デフォルトの名無しさん
2014/04/10(木) 23:07:48.12ID:c1sQcFAM >>240
どう見ても「君には」×
どう見ても「君には」×
242デフォルトの名無しさん
2014/04/10(木) 23:36:09.35ID:Uir6dqld 実際にベクトルクラスがあるからそれ参考にする
243デフォルトの名無しさん
2014/04/11(金) 02:56:48.62ID:HtRnBfLu 同じメソッド呼び出しを何度も行うと呼び出しのコードをコピペすることになっ
てしまいます。何もせず名前の意味も不明な多重のメソッド呼び出しはコピペを
防ぐためだったと判明しました。もちろん手打ちしたとのことです。
オブジェクト指向脳っていうんですか?本当に怖いです。
てしまいます。何もせず名前の意味も不明な多重のメソッド呼び出しはコピペを
防ぐためだったと判明しました。もちろん手打ちしたとのことです。
オブジェクト指向脳っていうんですか?本当に怖いです。
244デフォルトの名無しさん
2014/04/11(金) 09:11:53.91ID:nUaUWR93245デフォルトの名無しさん
2014/04/11(金) 09:12:29.97ID:nUaUWR93246デフォルトの名無しさん
2014/04/11(金) 09:13:54.98ID:nUaUWR93 >>243
人生で同じ英単語・アルファベットを何度もコピペする略(ゲラゲラ)
人生で同じ英単語・アルファベットを何度もコピペする略(ゲラゲラ)
247デフォルトの名無しさん
2014/04/11(金) 13:07:20.58ID:xNOhzDQj なんか面白いんだろうな...
俺には理解できないけど
俺には理解できないけど
248デフォルトの名無しさん
2014/04/12(土) 12:55:19.47ID:5P9XNUOV プログラマはソースのコピペを恐れないでください。誰でも最初は初心者で、
しかも誰もが成長するとは限らないのです。
成長を強いるオブジェクト指向が、万人の解決策になり得ないのは明らかです。
コピペこそが、初心者からベテランまで、万人の解決策となり得るのです。
第一、grepすらできないソースをメンテナンスできるはずありません。
コピペによるプログラミングは、複雑に絡まったバージョン依存問題を解決する
という、潜在的なポテンシャルがあります。
大体、オブジェクト指向を推進する人は、協調性がない人が多く、共同で作業す
るには向いていないのです。冗談のセンスすらありません。
しかも誰もが成長するとは限らないのです。
成長を強いるオブジェクト指向が、万人の解決策になり得ないのは明らかです。
コピペこそが、初心者からベテランまで、万人の解決策となり得るのです。
第一、grepすらできないソースをメンテナンスできるはずありません。
コピペによるプログラミングは、複雑に絡まったバージョン依存問題を解決する
という、潜在的なポテンシャルがあります。
大体、オブジェクト指向を推進する人は、協調性がない人が多く、共同で作業す
るには向いていないのです。冗談のセンスすらありません。
249デフォルトの名無しさん
2014/04/12(土) 17:13:54.61ID:1eEiGLxS 全部反対のことを言っていると見抜けば
>>248が言っていることに納得できるはずw
>>248が言っていることに納得できるはずw
250デフォルトの名無しさん
2014/04/12(土) 17:19:09.23ID:f/RHrroc なんか面白いんだろうな...
俺には理解できないけど
俺には理解できないけど
251デフォルトの名無しさん
2014/04/13(日) 10:45:23.58ID:839g2ruV ここで僕らは「良いソフト部品は、有名なのだけだ」という原則に立ち戻る必要があるだろうね。
誰も使ってない、メンテナンスもされない俺様オブジェクト部品を使うくらいなら、コピペの方がましな
んだよ。宣言型か関数型が使えるならその方がいいし、使えなければテストの自動化で乗り切る
しかないと、もう10年も前からいわれて続けているわけだ。
research.microsoft.com/en-us/um/people/blampson/70-SoftwareComponents/70-SoftwareComponents.htm
誰も使ってない、メンテナンスもされない俺様オブジェクト部品を使うくらいなら、コピペの方がましな
んだよ。宣言型か関数型が使えるならその方がいいし、使えなければテストの自動化で乗り切る
しかないと、もう10年も前からいわれて続けているわけだ。
research.microsoft.com/en-us/um/people/blampson/70-SoftwareComponents/70-SoftwareComponents.htm
252デフォルトの名無しさん
2014/04/13(日) 10:51:49.05ID:oaa109sw うん、まったくだ。
有名なソフトは良い。
有名じゃなくても良いソフトはまれにあるけど、
多くの、つまり何万、何十万とある無名なソフトはクソでしかない。
有名なソフトは良い。
有名じゃなくても良いソフトはまれにあるけど、
多くの、つまり何万、何十万とある無名なソフトはクソでしかない。
253デフォルトの名無しさん
2014/04/13(日) 11:22:22.91ID:2QOmxkhr ストラウストラップが「オブジェクト指向というのは継承と再利用なんだよ!」ってやったせいで
えらい風評被害やな。
単にクラスというCでの関数に代わる単位の取り回し方法だから
Objective-C辺りじゃ継承…めんどいから使わない
NSObjectってクラスの基本的ふるまいを持った基底クラスから
テキトーなクラス作って、その中に使えるクラスぶち込んで
メッセージ(メソッド)オーバーライドでふるまい変えて使う。
クラスとは単にレゴブロックみたいなパーツ扱い。
えらい風評被害やな。
単にクラスというCでの関数に代わる単位の取り回し方法だから
Objective-C辺りじゃ継承…めんどいから使わない
NSObjectってクラスの基本的ふるまいを持った基底クラスから
テキトーなクラス作って、その中に使えるクラスぶち込んで
メッセージ(メソッド)オーバーライドでふるまい変えて使う。
クラスとは単にレゴブロックみたいなパーツ扱い。
254デフォルトの名無しさん
2014/04/13(日) 11:38:57.62ID:Vp4hM6j5 >NSObjectってクラスの基本的ふるまいを持った基底クラスからテキトーなクラス作って
継承してるじゃないの。
むしろC++の方が継承なしのパーツ扱いが多いんじゃないの。
継承してるじゃないの。
むしろC++の方が継承なしのパーツ扱いが多いんじゃないの。
255デフォルトの名無しさん
2014/04/13(日) 11:54:36.21ID:j71fNHt+ いわゆるObjectクラスが必要な理由って何かあるの?
256デフォルトの名無しさん
2014/04/13(日) 12:17:57.96ID:2QOmxkhr Objective-Cはとにかくクラスの実体ありきで
言語的にひな型からインスタンスを作るんじゃなくて
起動時に存在するファクトリクラスにallocとinitを送って
クラスに"自分のインスタンスを作らせる"から
すべてのクラスはallocやinit、retainカウント、deallocを受け付け管理する
NSObjectを継承していないとクラスとして存在しえないので…
言語的にひな型からインスタンスを作るんじゃなくて
起動時に存在するファクトリクラスにallocとinitを送って
クラスに"自分のインスタンスを作らせる"から
すべてのクラスはallocやinit、retainカウント、deallocを受け付け管理する
NSObjectを継承していないとクラスとして存在しえないので…
257デフォルトの名無しさん
2014/04/13(日) 15:02:09.06ID:Vp4hM6j5 動的な言語だとだいたいObjectクラスが必須だよね
258デフォルトの名無しさん
2014/04/13(日) 15:38:34.94ID:j71fNHt+ >>256
別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
259デフォルトの名無しさん
2014/04/13(日) 15:55:24.32ID:BqlLq9pK 動的な言語でも本来はObjectなんて要らない。
Smalltalk-80だってnilのサブクラスを作れたし。
Smalltalk-80だってnilのサブクラスを作れたし。
260デフォルトの名無しさん
2014/04/13(日) 16:04:45.61ID:oaa109sw 値の型が動的なのと
変数の型が動的なのとを
区別つけろよ。アホ。
Objectが必要なのは変数に型があって
値の型が動的な場合なだけだ。
変数に型があるが、そこで記述された型だけではなく
互換性がある型を入れられる。
そういう言語でどんな型にも互換性があるのがObject型だ。
変数に型がない言語ではどんな値でも入れられるから
Objectは要らない。変数にはどんな型でも入れられる
とはいうものもコードは互換性がある型を入れてないと
結局正しく動かないんだけどなw
変数の型が動的なのとを
区別つけろよ。アホ。
Objectが必要なのは変数に型があって
値の型が動的な場合なだけだ。
変数に型があるが、そこで記述された型だけではなく
互換性がある型を入れられる。
そういう言語でどんな型にも互換性があるのがObject型だ。
変数に型がない言語ではどんな値でも入れられるから
Objectは要らない。変数にはどんな型でも入れられる
とはいうものもコードは互換性がある型を入れてないと
結局正しく動かないんだけどなw
261デフォルトの名無しさん
2014/04/13(日) 16:17:49.14ID:Vp4hM6j5 値の型が動的ってどういう事?
さっきまでStringだったけど今みたらIntに変わってたわ!みたいな?
さっきまでStringだったけど今みたらIntに変わってたわ!みたいな?
262デフォルトの名無しさん
2014/04/13(日) 16:24:02.51ID:oaa109sw 変数の型は固定なんだよ。
この変数は、Numeric型みたいに。
でもNumeric型って書いてあっても
その値は実はInt型だったりFloat型だったりと
Numeric型に互換性がある型に変わっていたりする。
変数の型は固定なのに値の型は違う。
それに対して、変数に型が決まってない言語があるの。
変数に型が書いてないなら変数aにどんな型でも入れられる。
この変数は、Numeric型みたいに。
でもNumeric型って書いてあっても
その値は実はInt型だったりFloat型だったりと
Numeric型に互換性がある型に変わっていたりする。
変数の型は固定なのに値の型は違う。
それに対して、変数に型が決まってない言語があるの。
変数に型が書いてないなら変数aにどんな型でも入れられる。
263デフォルトの名無しさん
2014/04/13(日) 16:26:13.02ID:Vp4hM6j5 Objectって全部に共通の動作を定義するために使われてるよね普通は。
例えば、自分の型を返すとか。
例えば、自分の型を返すとか。
264デフォルトの名無しさん
2014/04/13(日) 17:45:48.17ID:CtgsENNt 値が型情報持ってない言語は一応あるね、C言語とか
あれは変数側にしか型がない
あれは変数側にしか型がない
265デフォルトの名無しさん
2014/04/13(日) 18:03:36.88ID:BqlLq9pK >>261
SmalltalkではさっきまでByteStringだったオブジェクトが今みたらWideStringだったぜとか普通
SmalltalkではさっきまでByteStringだったオブジェクトが今みたらWideStringだったぜとか普通
266デフォルトの名無しさん
2014/04/13(日) 18:07:49.11ID:+sscY2hT267デフォルトの名無しさん
2014/04/13(日) 18:54:15.96ID:BqlLq9pK 全部に共通の動作なんてものが必要なうちはダメだな
268デフォルトの名無しさん
2014/04/13(日) 19:10:20.98ID:wSq/pgWA >>267
ダメな理由書いてみ
ダメな理由書いてみ
269デフォルトの名無しさん
2014/04/13(日) 19:31:38.05ID:Vp4hM6j5 >>265
それは参照してるオブジェクトが変わったんじゃないの?
それは参照してるオブジェクトが変わったんじゃないの?
270デフォルトの名無しさん
2014/04/13(日) 20:05:02.79ID:+sscY2hT 共通の動作がなければ、てんでばらばらって事じゃんw
271デフォルトの名無しさん
2014/04/13(日) 20:31:47.78ID:yhlLeWxx >>269
Smalltalkではbecome:というメソッドで
ポインタレベルでのオブジェクトの差し替えが可能なんで
| x y |
x := y := 'abc'
x become: 3.14.
y. "=> 3.14 "
これを応用してオブジェクトの型の変更も容易なんですよ
Smalltalkではbecome:というメソッドで
ポインタレベルでのオブジェクトの差し替えが可能なんで
| x y |
x := y := 'abc'
x become: 3.14.
y. "=> 3.14 "
これを応用してオブジェクトの型の変更も容易なんですよ
272デフォルトの名無しさん
2014/04/13(日) 20:36:46.47ID:1ZgLAbLW273デフォルトの名無しさん
2014/04/13(日) 20:46:56.28ID:+sscY2hT274デフォルトの名無しさん
2014/04/13(日) 20:50:21.03ID:Vp4hM6j5 >>271
Smalltalkよくしらないから適当言語だけど...
x = "x"; y = "y"; z = y;
の状態で
y become: x;
とやったら、
zの指してるオブジェクトは"x"になるって事?
Smalltalkよくしらないから適当言語だけど...
x = "x"; y = "y"; z = y;
の状態で
y become: x;
とやったら、
zの指してるオブジェクトは"x"になるって事?
275デフォルトの名無しさん
2014/04/13(日) 20:59:39.25ID:BqlLq9pK276デフォルトの名無しさん
2014/04/13(日) 21:09:17.21ID:1ZgLAbLW よく知らない三連星ワロタ
>>275
なるほどそういう意図ですか
1. nillはUndefinedObjectのインスタンス
2. UndefinedObjectはObjectの継承している
3. Objectはnilを継承している
こうかな?
となると全てのクラスの共通となる祖先が存在してるんで
不要論として出すのはやっぱおかしくないですか?
>>275
なるほどそういう意図ですか
1. nillはUndefinedObjectのインスタンス
2. UndefinedObjectはObjectの継承している
3. Objectはnilを継承している
こうかな?
となると全てのクラスの共通となる祖先が存在してるんで
不要論として出すのはやっぱおかしくないですか?
277デフォルトの名無しさん
2014/04/13(日) 21:15:34.64ID:TiAwmeQu 知れば知る程Smalltalkのウンコさが身にしみる
278デフォルトの名無しさん
2014/04/13(日) 21:40:50.80ID:+sscY2hT proxyパターンと共通の動作にどういう関係があるのかわからん。
279デフォルトの名無しさん
2014/04/14(月) 01:52:57.81ID:QEqaYkvm >>258
>別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
いま、C++とかがそこに起因する泥沼に嵌ってるけど
オブジェクトクラスの側は言ってしまえば実装だしライブラリだから
将来に動作を変更されるうるし、実際に変更されるけど
言語仕様はもう一段上のルールだから変更が実に困難だという…
>別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
いま、C++とかがそこに起因する泥沼に嵌ってるけど
オブジェクトクラスの側は言ってしまえば実装だしライブラリだから
将来に動作を変更されるうるし、実際に変更されるけど
言語仕様はもう一段上のルールだから変更が実に困難だという…
280デフォルトの名無しさん
2014/04/14(月) 01:57:18.83ID:QEqaYkvm281デフォルトの名無しさん
2014/04/14(月) 19:01:11.23ID:9oXXilb1282デフォルトの名無しさん
2014/04/14(月) 20:50:15.58ID:2o5NlHiv283デフォルトの名無しさん
2014/04/14(月) 21:32:49.46ID:1BzKypQe > 3. Objectはnilを継承している
それが真であれば、Objectはnilの特徴を持っていないといけない。
Objectはnilではないので、これは間違い。
それが真であれば、Objectはnilの特徴を持っていないといけない。
Objectはnilではないので、これは間違い。
284デフォルトの名無しさん
2014/04/14(月) 21:40:20.78ID:KfO5hauH285デフォルトの名無しさん
2014/04/14(月) 21:41:56.76ID:kBF05cIr Rubyだと
・nil は Nilクラスの唯一のインスタンス
・NilクラスはObjectクラスから派生したサブクラス
$ irb2.0
irb(main):001:0> nil.class
=> NilClass
irb(main):002:0> NilClass.superclass
=> Object
Smalltalkは知らん
・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.96ID:2o5NlHiv >>283
あ、そうなんですか
Wikipediaに
> 基本的な派生元となるObjectやProtoObjectは、それらから派生したUndefinedObjectのインスタンスオブジェクトであるnilを継承しており再帰関係を持つ。
と書いてあったんでそういうものだと思ってました
あと
Object isKindOf: nill
が true を返すのはなんででしょう?
あ、そうなんですか
Wikipediaに
> 基本的な派生元となるObjectやProtoObjectは、それらから派生したUndefinedObjectのインスタンスオブジェクトであるnilを継承しており再帰関係を持つ。
と書いてあったんでそういうものだと思ってました
あと
Object isKindOf: nill
が true を返すのはなんででしょう?
287デフォルトの名無しさん
2014/04/15(火) 04:06:44.72ID: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の基底クラスではない、
ということだね。
つまり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.65ID:4TC7MUH1289デフォルトの名無しさん
2014/04/15(火) 20:46:27.61ID:d1+oXg+5 >>287
>つまりnilとNilは別々のオブジェクトであり、
nil はインスタンスでありNil はクラスだから、別々のオブジェクトってこと
>NilがObjectのサブクラスであることとnilは何の関係もない、
Nil と Object とは「サブクラス-スーパークラス」という継承関係であり、
Nil と nil とは「クラス-インスタンス」というインスタンス化関係であり、
二種類の関係をごっちゃにしてはいけない、ってこと
>つまりnilとNilは別々のオブジェクトであり、
nil はインスタンスでありNil はクラスだから、別々のオブジェクトってこと
>NilがObjectのサブクラスであることとnilは何の関係もない、
Nil と Object とは「サブクラス-スーパークラス」という継承関係であり、
Nil と nil とは「クラス-インスタンス」というインスタンス化関係であり、
二種類の関係をごっちゃにしてはいけない、ってこと
290デフォルトの名無しさん
2014/04/15(火) 21:07:45.24ID: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の著者が
継承とインスタンス化をごっちゃに理解しているんじゃないかと思われ
>> 基本的な派生元となる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.27ID:POAb9xNt >>288
GNU Smalltalk は名前から受ける印象と違って
単なるファンお手製の勝手実装なうえに、
Smalltalk としてもかなりの変わり種なので
あれを元に Smalltalk がどういうものか学ぶのはちょっと問題が。
できれば VisualWorks 、悪くても Squeak/Pharo で
試すようにするのがよいと思います。
(これらの処理系はそれぞれ独自の進化を遂げてはいますが、
いちおう古典的 XEROX Smalltalk-80 からの直系の派生物で、
その名残を多く残しています)
GNU Smalltalk は名前から受ける印象と違って
単なるファンお手製の勝手実装なうえに、
Smalltalk としてもかなりの変わり種なので
あれを元に Smalltalk がどういうものか学ぶのはちょっと問題が。
できれば VisualWorks 、悪くても Squeak/Pharo で
試すようにするのがよいと思います。
(これらの処理系はそれぞれ独自の進化を遂げてはいますが、
いちおう古典的 XEROX Smalltalk-80 からの直系の派生物で、
その名残を多く残しています)
292デフォルトの名無しさん
2014/04/15(火) 22:39:29.15ID: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以外でやります
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.35ID:8/R6vbb5 大量のベクトル演算をオブジェクト指向で行うのはいい考えではありませんでした。
パフォーマンスが話になりません。
あらためてオブジェクト指向の活用方法が知りたいです。
パフォーマンスが話になりません。
あらためてオブジェクト指向の活用方法が知りたいです。
294デフォルトの名無しさん
2014/04/15(火) 22:56:10.29ID:TDL51eos あたりまえやないかw インラインでやれ。
295デフォルトの名無しさん
2014/04/16(水) 05:01:31.46ID:ZBBb0DXo >>292
それはmeta cyclicというのであってrecursionとは全く別だよ
それはmeta cyclicというのであってrecursionとは全く別だよ
296デフォルトの名無しさん
2014/04/16(水) 08:21:50.02ID:A1GSn+hc >>295
http://upload.wikimedia.org/wikipedia/commons/f/f9/Smalltalk_80_metaclasses.svg
を拝借するとrecursionはどの部分になりますか?(または当て嵌まらない、とか)
MetaclassとMetaclass classがrecursion?
と言うかmeta cyclicとrecursionは定義はどこを調べればいいんでしょうか
あー分かんなくなってきた
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.89ID:ZBBb0DXo298デフォルトの名無しさん
2014/04/16(水) 18:10:12.53ID:A1GSn+hc299デフォルトの名無しさん
2014/04/17(木) 03:03:07.59ID:g3SPX8xq isKindOf:等のクラス階層へのアクセスを使わない限りにおいて、
全てのクラスは基底クラスから継承したインスタンス変数やメソッド等を取り込むことで
nilからの継承による実装に置き換えることが出来るのはOK?
全てのクラスは基底クラスから継承したインスタンス変数やメソッド等を取り込むことで
nilからの継承による実装に置き換えることが出来るのはOK?
300デフォルトの名無しさん
2014/04/17(木) 06:51:39.99ID:XZy5mn+7 >>299
はい、続けて下さい
はい、続けて下さい
301デフォルトの名無しさん
2014/04/17(木) 07:01:46.34ID:g3SPX8xq302デフォルトの名無しさん
2014/04/17(木) 07:48:37.17ID:XZy5mn+7303デフォルトの名無しさん
2014/04/17(木) 09:46:27.34ID:g3SPX8xq >>302
いいえ、nilにObjectと同じ能力があるなんて誰か言ってるのですか?
いいえ、nilにObjectと同じ能力があるなんて誰か言ってるのですか?
304デフォルトの名無しさん
2014/04/17(木) 19:48:33.36ID:XZy5mn+7305デフォルトの名無しさん
2014/04/18(金) 02:02:31.47ID:3m4Hm4jr 今更な反応だけど
メソッドチェーンのデバッグどうのこうのは
パワーアサートである程度解決できるんじゃね
テストとデバッグを同一視すんなとか言われそうだけど
そこはなんやかんやで
メソッドチェーンのデバッグどうのこうのは
パワーアサートである程度解決できるんじゃね
テストとデバッグを同一視すんなとか言われそうだけど
そこはなんやかんやで
306デフォルトの名無しさん
2014/04/19(土) 11:19:09.69ID:fQ1JDqwN みんなモデリングツール使ってる?
307デフォルトの名無しさん
2014/04/19(土) 15:25:11.54ID:7lbU/Cwq UMLは手書きのノートに万年筆で描いてるけど?
308デフォルトの名無しさん
2014/04/19(土) 15:25:52.03ID:7lbU/Cwq ああ、もうすぐ司法試験なんだよなぁ・・・
今年も申し込みしてねーや。
仕事辞めたいわ
今年も申し込みしてねーや。
仕事辞めたいわ
309デフォルトの名無しさん
2014/04/19(土) 15:28:51.08ID:oGrzc7nx ぜひ弁護士資格を取って人売り屋を訴えてやってください。
310デフォルトの名無しさん
2014/04/19(土) 15:32:20.57ID:7lbU/Cwq 弁護士より裁判官志望なんだけどな。
知財専門の裁判官やるわ。
知財専門の裁判官やるわ。
311デフォルトの名無しさん
2014/05/02(金) 02:53:15.17ID:sB1UFa5X 裁判官になるのはある意味、終身刑になるようなもの
仕事にやりがいはないし、趣味、嗜好、信仰の類は一切行えない
どうしてもやりたいというなら止めないが、いいもんじゃないぞ
仕事にやりがいはないし、趣味、嗜好、信仰の類は一切行えない
どうしてもやりたいというなら止めないが、いいもんじゃないぞ
312デフォルトの名無しさん
2014/07/11(金) 14:24:19.29ID:u5XcYD/q 確かに日本語ネイティブじゃないと解り難い表現ではある
313デフォルトの名無しさん
2014/10/15(水) 02:03:28.04ID:fxqbNGWP 急にスレが死んだ
314デフォルトの名無しさん
2014/10/16(木) 17:21:37.89ID:MhzmuNOz315デフォルトの名無しさん
2014/10/18(土) 12:18:53.66ID:/oNwCDSd 似たようなものさ‥Linus が GC の存在を受け入れるわけがない
316デフォルトの名無しさん
2014/10/18(土) 15:46:58.25ID:7/IQKq91 そりゃ、カーネルやドライバレベルの開発でGC付きの言語環境は要らんわ。
OOPの話題でリーナス発言を引き合いに出すのは的外れすぎる。
OOPの話題でリーナス発言を引き合いに出すのは的外れすぎる。
317デフォルトの名無しさん
2014/11/05(水) 13:15:41.31ID:QbWIQhdw OOPって結局、こういう考え方すれば分かりやすくなりますよって例でしかないからな
その考え方を前提に置けば、こういう表現ができますよって利点はいろいろな実装があるけど
完全性や効率性を犠牲に、可読性を上げて保守性や再利用性、試験性なんかを上げましょうってそういうものだと思うんだけど
その考え方を前提に置けば、こういう表現ができますよって利点はいろいろな実装があるけど
完全性や効率性を犠牲に、可読性を上げて保守性や再利用性、試験性なんかを上げましょうってそういうものだと思うんだけど
318デフォルトの名無しさん
2014/11/05(水) 20:29:01.97ID:NM+61D3j OOPって結局、…でしかないからな
という奴って、OOP以外にも関数型言語でもアジャイルプロセスでも受託ビジネスでも
みーんな「結局、…でしかないからな」とわかったような気になるだけで
実際には何も身についてないんだよなw
という奴って、OOP以外にも関数型言語でもアジャイルプロセスでも受託ビジネスでも
みーんな「結局、…でしかないからな」とわかったような気になるだけで
実際には何も身についてないんだよなw
319デフォルトの名無しさん
2014/11/05(水) 23:26:57.45ID:UbfQ7xJO オブジェクト指向は愚かな考え。排便メソッド2 [転載禁止]©2ch.net
http://peace.2ch.net/test/read.cgi/tech/1415122540/
http://peace.2ch.net/test/read.cgi/tech/1415122540/
320デフォルトの名無しさん
2014/11/06(木) 08:17:55.90ID:WCLQna6c321デフォルトの名無しさん
2014/12/15(月) 00:00:56.39ID:Ovh10mZl カプセル化 ポリモーフィズム 継承を理解して設計出来る人って実際、何人に一人ぐらいに感じる?
322デフォルトの名無しさん
2014/12/15(月) 09:52:17.25ID:z8CdksSX ひとそれぞれ解釈違うからなんとも言えん
323デフォルトの名無しさん
2014/12/15(月) 11:05:06.23ID:cy4sFuPq カプセル化&オブジェクト化の行き先は関数型プログラミングじゃないの?
324デフォルトの名無しさん
2014/12/15(月) 12:54:30.82ID:t6/tpY1X 絶対違う
325デフォルトの名無しさん
2014/12/15(月) 15:09:37.42ID:2aP18QTz326デフォルトの名無しさん
2014/12/17(水) 11:09:29.57ID:N1jNpsSg ポリモーフィズムは分かりやすいんだけどカプセル化がいまいちわからない
ゲッターセッター書いて何になるの?ってレベルの理解しかないから優しく教えて
ゲッターセッター書いて何になるの?ってレベルの理解しかないから優しく教えて
327デフォルトの名無しさん
2014/12/17(水) 11:58:16.14ID:qGVIuFRu328デフォルトの名無しさん
2014/12/17(水) 13:49:16.52ID:dSysfVHr カプセル内では、他のオブジェクトの定義を知らなくても済むように書く。
閉じたオブジェクトにすればいい。
閉じたオブジェクトにすればいい。
329デフォルトの名無しさん
2014/12/17(水) 17:36:45.21ID:FGZvKMUK >>326
基本的にそのクラスのメンバーはそのクラス内でいじられることを保障するため。
基本的にそのクラスのメンバーはそのクラス内でいじられることを保障するため。
330デフォルトの名無しさん
2014/12/17(水) 18:56:34.51ID:qGVIuFRu 実装を隠す
→知らなくても使えるように設計する
→使い方さえ変えなければいい
→中は変え放題、新しい使い方も追加放題
>>329
よくあるサンプルみたいに全メンバアクセッサ実装してるようなクソクラスだと
その原則破るための効果の方が強くなってしまうからなぁ
クラスの中から≠クラスファイルの中から
クラスの中から=クラス機能の中から
→知らなくても使えるように設計する
→使い方さえ変えなければいい
→中は変え放題、新しい使い方も追加放題
>>329
よくあるサンプルみたいに全メンバアクセッサ実装してるようなクソクラスだと
その原則破るための効果の方が強くなってしまうからなぁ
クラスの中から≠クラスファイルの中から
クラスの中から=クラス機能の中から
331デフォルトの名無しさん
2014/12/17(水) 19:24:20.07ID:N1jNpsSg 327-330
いろいろありがとう
公開したいとこだけ公開すりゃいいのね
いろいろありがとう
公開したいとこだけ公開すりゃいいのね
332デフォルトの名無しさん
2014/12/17(水) 19:38:57.10ID:y3DoL19d 極論を言えば「公開」したら負けなのがカプセル化
333デフォルトの名無しさん
2014/12/17(水) 21:14:17.50ID:lLmQTo2M >>326
getter-setter をかましておけば、なにかのときに簡単に監視やフックを追加できる
getter-setter をかましておけば、なにかのときに簡単に監視やフックを追加できる
334デフォルトの名無しさん
2014/12/17(水) 22:00:02.25ID:adMFmMY0 >>333
ちょっとした用途ならリフレクションから呼べば良いじゃん
機能として提供する必要が出来たならそんな直接参照するような裏ワザ使わないで継承するなり追加するなりしようよ
影響が外に広がらないようにカプセル化して直接参照する手段を封じるんだから
直接参照できるセッターやゲッターつけたら保証できなくなるじゃん
ちょっとした用途ならリフレクションから呼べば良いじゃん
機能として提供する必要が出来たならそんな直接参照するような裏ワザ使わないで継承するなり追加するなりしようよ
影響が外に広がらないようにカプセル化して直接参照する手段を封じるんだから
直接参照できるセッターやゲッターつけたら保証できなくなるじゃん
335デフォルトの名無しさん
2014/12/17(水) 22:40:02.99ID:lLmQTo2M >>334
リフレクションは悪、コンパイル時に検出できるエラーがリフレクションにすると検出できなくなってしまう‥
まあ何でもかんでもsetter-getter で公開してしまうのはどうかと思うが(ましてやプロパティを公開してしまうのは最悪)
リフレクションは悪、コンパイル時に検出できるエラーがリフレクションにすると検出できなくなってしまう‥
まあ何でもかんでもsetter-getter で公開してしまうのはどうかと思うが(ましてやプロパティを公開してしまうのは最悪)
336デフォルトの名無しさん
2014/12/18(木) 15:10:59.93ID:ZOTu6c+H おいおいインスタンスにアクセサなかったら、
そいつの状態を変えたりモニターしたりどうやるんだよ。
そいつの状態を変えたりモニターしたりどうやるんだよ。
337デフォルトの名無しさん
2014/12/18(木) 15:18:48.22ID:hbsgKLA0 >>336
状態をモニタするのは「モニタする」メソッドでやるべきじゃね?
状態を変えるなら、状態を変えるメソッドを通すべきだと思うし
もちろん、カプセル化の観点から見たら、の話ね
何か目的があってカプセル化を崩すなら、それはそれだろうし
状態をモニタするのは「モニタする」メソッドでやるべきじゃね?
状態を変えるなら、状態を変えるメソッドを通すべきだと思うし
もちろん、カプセル化の観点から見たら、の話ね
何か目的があってカプセル化を崩すなら、それはそれだろうし
338デフォルトの名無しさん
2014/12/18(木) 15:31:32.87ID:ZOTu6c+H いやそのためのメソッドがsetter/getterだろうと。
339デフォルトの名無しさん
2014/12/18(木) 16:01:52.60ID:a38PRbZq340デフォルトの名無しさん
2014/12/18(木) 22:10:35.29ID: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になっちゃうけど
まずそのオブジェクトで何をしたいのかを考えて、それを実現するための内部構造と考えると
自然とカプセル化されてくもんじゃないかな。
>>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.68ID:ZOTu6c+H >>340
いやだからアクセサでオブジェクトの状態を変える・モニターするのは別に普通だろと言ってるの。
いやだからアクセサでオブジェクトの状態を変える・モニターするのは別に普通だろと言ってるの。
342デフォルトの名無しさん
2014/12/18(木) 22:55:00.66ID:CbZTNJ5S Entityにgetsetつけてるのって何も考えてないとしか思えない
343デフォルトの名無しさん
2014/12/18(木) 23:22:15.68ID:rHvMFTQj 状態変更やモニタするメソッドの名前をgetやsetにするのは自由だけど・・・命名規則的にそれってどうなの?
それに当然モニタリング機能を提供すべき責任を負ってるクラスだけだからな
状態を変更するメソッドならバリデーションや整合性チェック、状態変化に伴う動作まで含めて一つの完結した機能として定義すべきかな
状態変化監視するならオブザーバパターンで、JavaならpropeatyChangeListenerとか
実装して受け取るべきだと思う
もしくは監視用ステータスオブジェクトを返す感じとかか?
それに当然モニタリング機能を提供すべき責任を負ってるクラスだけだからな
状態を変更するメソッドならバリデーションや整合性チェック、状態変化に伴う動作まで含めて一つの完結した機能として定義すべきかな
状態変化監視するならオブザーバパターンで、JavaならpropeatyChangeListenerとか
実装して受け取るべきだと思う
もしくは監視用ステータスオブジェクトを返す感じとかか?
344デフォルトの名無しさん
2014/12/18(木) 23:28:53.90ID:ZOTu6c+H ああ、俺が言ってるのは単純にプロパティの事だよ。
345デフォルトの名無しさん
2014/12/19(金) 00:08:44.41ID:Z5vGYKdT こういう説明はどうだろう?
NG:状態変数を取得するために状態変数取得メソッドを作った
OK:状態取得メソッドを作ったので保管場所として状態変数を作った
少なくとも設計段階でデザインするべき物かな
そうやってデザインの結果として一部にクラスに、
結果的に単純プロパティのような形の実装になった物が出来るの悪いことではないと思う
NG:状態変数を取得するために状態変数取得メソッドを作った
OK:状態取得メソッドを作ったので保管場所として状態変数を作った
少なくとも設計段階でデザインするべき物かな
そうやってデザインの結果として一部にクラスに、
結果的に単純プロパティのような形の実装になった物が出来るの悪いことではないと思う
346デフォルトの名無しさん
2014/12/19(金) 00:25:25.61ID:kXOboZoh 始めからプロパティとして定義するものもあれば、
プライベート変数を後からプロパティに変更する事もあれば、
プロパティだったものをプライベート変数に変更する事もあるよ。
プライベート変数を後からプロパティに変更する事もあれば、
プロパティだったものをプライベート変数に変更する事もあるよ。
347デフォルトの名無しさん
2014/12/20(土) 09:38:36.96ID:+GgZ8JtG CTMCPでggr
348デフォルトの名無しさん
2014/12/25(木) 01:56:12.77ID:FXTtDPDb C++とかjavaは元来の意味でのオブジェクト指向じゃないからね
あくまで、オブジェクト指向に便利な機能つけた手続き言語
オブジェクト指向をきちんと使いたいならsmalltalk参考にしてる言語のほうがいいと思われる
例として、整数を文字列に変換するときに
Java
String.valueOf(48)
Ruby
48.to_s
48さんに文字列になって欲しければ、48さんのメソッド呼ぶのが本来のオブジェクト指向ー
あくまで、オブジェクト指向に便利な機能つけた手続き言語
オブジェクト指向をきちんと使いたいならsmalltalk参考にしてる言語のほうがいいと思われる
例として、整数を文字列に変換するときに
Java
String.valueOf(48)
Ruby
48.to_s
48さんに文字列になって欲しければ、48さんのメソッド呼ぶのが本来のオブジェクト指向ー
349デフォルトの名無しさん
2014/12/25(木) 02:01:12.47ID:FXTtDPDb 同じように、通信をするconnectionってインスタンスがあったとして
connection.status = Status::FINISHED
とかやっちゃうのはオブジェクト指向らしくなくて
connection.finish
で、終了処理から内部状態変更やらやってくれるのがオブジェクト指向
connection.status = Status::FINISHED
とかやっちゃうのはオブジェクト指向らしくなくて
connection.finish
で、終了処理から内部状態変更やらやってくれるのがオブジェクト指向
350デフォルトの名無しさん
2014/12/25(木) 03:27:23.93ID:plZQlrr3 >>348
Staticメソッドを引き合いに出してJavaをけなしてもねえ……
Staticメソッドを引き合いに出してJavaをけなしてもねえ……
351デフォルトの名無しさん
2014/12/25(木) 03:29:07.82ID:EL6gBj3v >>348
そりゃ OO 的には美しいが、レジスタ一個で収まるところをごてごてとデコレートするのもね‥
そりゃ OO 的には美しいが、レジスタ一個で収まるところをごてごてとデコレートするのもね‥
352デフォルトの名無しさん
2014/12/25(木) 14:56:46.31ID:UXO0kBFe 手続きとOOを排他扱いする時点でお察し
353デフォルトの名無しさん
2014/12/25(木) 15:07:57.78ID:ZM9QeVU6 まぁ、速度優先するならOOPだの関数型だの構造化だのオーバーヘッドの必要なルール止めて
シーケンシャルに処理手書きしていけよってなるしな
保守性とかほかの目的で冗長な記述をルール化してるんだし
シーケンシャルに処理手書きしていけよってなるしな
保守性とかほかの目的で冗長な記述をルール化してるんだし
354デフォルトの名無しさん
2014/12/27(土) 21:08:42.89ID:Dl8SRIg9 文字列とか数値とか考えないのがオブジェクト思考じゃないの?
355デフォルトの名無しさん
2014/12/31(水) 03:38:42.55ID:GtslL7/x 基底クラスが「人」で、3つの派生クラスを作ってそれぞれに「.work()」を記述した場合で
3つの派生クラスの全インスタンスの「.work()」を実行したいときどのように管理すれば良いのでしょうか
自分では派生クラス毎にループを回すことしか思いつきませんでした
3つの派生クラスの全インスタンスの「.work()」を実行したいときどのように管理すれば良いのでしょうか
自分では派生クラス毎にループを回すことしか思いつきませんでした
356デフォルトの名無しさん
2014/12/31(水) 07:56:11.57ID:grXbYJWV 基底クラスにwork()を定義して、派生クラスでオーバーライドするとか
357デフォルトの名無しさん
2014/12/31(水) 11:53:58.04ID:HNmCF9/p358デフォルトの名無しさん
2014/12/31(水) 17:22:24.60ID:/ugoQQzd >>355
そんなん、クラスが「基底か」「派生か」ということとは関係ないじゃん。
基底クラスのインスタンスを複数作成した場合でも、同じでしょ。
複数インスタンスに同時にメッセージを送るということなんだから。
ヒントはリスナー。
そんなん、クラスが「基底か」「派生か」ということとは関係ないじゃん。
基底クラスのインスタンスを複数作成した場合でも、同じでしょ。
複数インスタンスに同時にメッセージを送るということなんだから。
ヒントはリスナー。
359デフォルトの名無しさん
2014/12/31(水) 19:32:50.12ID:NQSYJ4L5 >>355
> 3つの派生クラスの全インスタンスの「.work()」を
> 実行したいとき
例えば Smalltalk なら
人 allSubinstances do: #work
とかそういうこと?
> 3つの派生クラスの全インスタンスの「.work()」を
> 実行したいとき
例えば Smalltalk なら
人 allSubinstances do: #work
とかそういうこと?
360デフォルトの名無しさん
2015/01/01(木) 10:15:28.02ID:J+tSiQ0Q Javaでクラスメソッド書いてると罪悪感あるんだけど、
副作用のない関数を書くんなら問題ないよね?
OOPっぽくないというのが罪悪感の原因だろうけど、
public staticで副作用のない関数だとむしろ書いていくべきだよね?
副作用のない関数を書くんなら問題ないよね?
OOPっぽくないというのが罪悪感の原因だろうけど、
public staticで副作用のない関数だとむしろ書いていくべきだよね?
361デフォルトの名無しさん
2015/01/01(木) 10:29:00.83ID:unDf2EkN >>360
気にするとすれば、そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの?ってところかな
クラスって、データと「そのデータに対する」操作の集まりだから。
影響を受けるデータの方に自身の操作として定義した方が良くない?
良くあるアンチパターンの機能クラスと、データクラスに分かれちゃってる手続き型設計
気にするとすれば、そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの?ってところかな
クラスって、データと「そのデータに対する」操作の集まりだから。
影響を受けるデータの方に自身の操作として定義した方が良くない?
良くあるアンチパターンの機能クラスと、データクラスに分かれちゃってる手続き型設計
362デフォルトの名無しさん
2015/01/01(木) 10:49:25.84ID:ZjnnyCSc > そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの?ってところかな
クラスを定義しないと関数を書けないからね。
> クラスって、データと「そのデータに対する」操作の集まりだから。
Math.sinなどのメソッドは、どのデータに対する操作かな?
やっぱ、関数、っていう使い方は生き残ると思うんよね。
クラスを定義しないと関数を書けないからね。
> クラスって、データと「そのデータに対する」操作の集まりだから。
Math.sinなどのメソッドは、どのデータに対する操作かな?
やっぱ、関数、っていう使い方は生き残ると思うんよね。
363デフォルトの名無しさん
2015/01/02(金) 03:24:38.38ID:Urv5GfAa オブジェクト指向的にはstrategyっぽくオブジェクトにしとくべきなんだろうとは思う
んで、普通はAngleオブジェクトがあってそれがsinやらcosやらのオブジェクト持ってる感じじゃない?
んで、普通はAngleオブジェクトがあってそれがsinやらcosやらのオブジェクト持ってる感じじゃない?
364デフォルトの名無しさん
2015/01/02(金) 18:16:39.18ID: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)
となってる。これも関数的アプローチの無くならない理由というか証拠のような気もする。
やっぱプリミティブ型ありきの現状考えると、
式の中に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.66ID:IjnWDn9W >>364
public static Angle fromDegree(double degree);
public static Angle fromRadian(double radian);
public double sin();
public double cos();
...
でいいじゃん。
Angle.fromDegree(45).sin()とか。
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.81ID:86rXEaVV 三角関数自体は角度の持っている特性だからAngleから取り出せるものだけど、
数学としてそれを導き出す関数で概念化した法則≒数式はMathとして定義されていてもおかしくはないか
ただ、数式自体はオブジェクト(物)を扱わず、その法則のみを抜き出して机上で扱う関数の集合、
数学自体が物事をオブジェクトで表現せずに、関数で表現したもの(ただし、直接使え無いと超非効率になる)
って感じかな
>>364
ファイルのコピーはファイル自体の機能ではなく、その上のストレージに自身の保持してるファイルを複製せよって命令する感じのような
数学としてそれを導き出す関数で概念化した法則≒数式はMathとして定義されていてもおかしくはないか
ただ、数式自体はオブジェクト(物)を扱わず、その法則のみを抜き出して机上で扱う関数の集合、
数学自体が物事をオブジェクトで表現せずに、関数で表現したもの(ただし、直接使え無いと超非効率になる)
って感じかな
>>364
ファイルのコピーはファイル自体の機能ではなく、その上のストレージに自身の保持してるファイルを複製せよって命令する感じのような
367デフォルトの名無しさん
2015/01/02(金) 21:02:15.51ID:gr/6otir >>365
そのnewを書く書かないとかcreateメソッドを準備するとかは興味なくて、
パラメータ→結果 で済む世界の話に短命オブジェクトを挟むのが嬉しくないよね?
絶対嫌だとか、困るとか言うつもりもないけど、今んとこメリットも見えないような。
>>366
関数型言語に詳しくてウンチクのひとつも言えるなら、
この気持ちスッキリ表せるんだろうけど、今の俺が言えるのは、
関数ありだよね、特に、式には関数だよね、みたいなことだけ…。
ファイルのコピーの例はご指摘を受け、自分の中では少なくとも、
「メソッド方式よりも、関数方式でスッキリする例」で無くなってしまったw
関数方式でスッキリするのはやっぱ数式関係だけ、なのかも。
そのnewを書く書かないとかcreateメソッドを準備するとかは興味なくて、
パラメータ→結果 で済む世界の話に短命オブジェクトを挟むのが嬉しくないよね?
絶対嫌だとか、困るとか言うつもりもないけど、今んとこメリットも見えないような。
>>366
関数型言語に詳しくてウンチクのひとつも言えるなら、
この気持ちスッキリ表せるんだろうけど、今の俺が言えるのは、
関数ありだよね、特に、式には関数だよね、みたいなことだけ…。
ファイルのコピーの例はご指摘を受け、自分の中では少なくとも、
「メソッド方式よりも、関数方式でスッキリする例」で無くなってしまったw
関数方式でスッキリするのはやっぱ数式関係だけ、なのかも。
368デフォルトの名無しさん
2015/01/02(金) 23:29:08.38ID:Wdw9kQqY 基本的に読みやすいと言うか、その処理がどういう本質のものかをコード自体で示してるのが良いコードなワケで
数学関係の処理は、元が元だけに関数形式が一番本質に近いから、そりゃ関数形式が読みやすくもなるわな
数学関係の処理は、元が元だけに関数形式が一番本質に近いから、そりゃ関数形式が読みやすくもなるわな
369デフォルトの名無しさん
2015/01/03(土) 07:48:27.17ID:aZa/y2Ql370デフォルトの名無しさん
2015/01/03(土) 07:51:27.38ID:aZa/y2Ql >>367は関数型に詳しくないだけじゃなくオブジェクト指向も初心者レベルだよw
371デフォルトの名無しさん
2015/01/18(日) 03:08:14.87ID:1HDk1G1l >>370
その理由は?
その理由は?
372デフォルトの名無しさん
2015/01/29(木) 11:14:38.08ID:FsmC2LI9 beanというかバリューオブジェクト?とユーティリティクラスって
効率のためにあえてオブジェクト指向の設計を崩して、
構造化プログラミングで設計するときに利用するものって考えでいいんですかね?
構造体と機能モジュールの関係そのまんまだし
効率のためにあえてオブジェクト指向の設計を崩して、
構造化プログラミングで設計するときに利用するものって考えでいいんですかね?
構造体と機能モジュールの関係そのまんまだし
373デフォルトの名無しさん
2015/02/02(月) 21:59:42.72ID:Q01xzseR ブログラマの質にできるだけ影響を受けないように
プログラムの質を維持するのが目的だろ。
プログラマの質の水準をどの程度と見るかで
求められる効果が変わってくる。
プログラムの質を維持するのが目的だろ。
プログラマの質の水準をどの程度と見るかで
求められる効果が変わってくる。
374デフォルトの名無しさん
2015/04/12(日) 15:53:34.84ID:Buy3OTWo 恥ずかしながらC#やった時に初めて理解できたわ
IEnumerableとかIDisposableを継承すると馬鹿でも分かると思う
IEnumerableとかIDisposableを継承すると馬鹿でも分かると思う
375東京女子医科大学病院プロポフォール大量投与
2015/06/08(月) 21:15:24.77ID:Fqp3awmG マスゴミ・売国奴・医療業界が隠そうとする真実---------------------安楽死---------------------奴隷に勝手に死なれては困る
安楽死旅行企画が大人気|竹田恒泰チャンネル
https://www.youtube.com/watch?v=XmP1TRsAe88
武田邦彦:安楽死と大麻、そして売春・・・オランダに学ぶ
https://www.youtube.com/watch?v=nWV8YOY39tw
安楽死党
https://www.youtube.com/watch?v=8nU2UaSlGx0
自殺は後遺症が怖い!だから-----------------------------------安楽死制度-------------------------------------安心して生きるために
安楽死旅行企画が大人気|竹田恒泰チャンネル
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.86ID:g7aWBHc9 全ての識別子をグローバルにして誰かと共同制作したいならどうぞ、って感じだな
377デフォルトの名無しさん
2015/11/01(日) 11:36:44.47ID:hTxt2JkX データ(変数群)と関数を関連付けすることでデータがデータとして存在するだけで意味がわかるのがオブジェクト指向
たとえば貨幣として扱いたいデータに対して、貨幣として必要な機能だけに関数を限定させれば、それはもうデータが存在するだけで貨幣として意味がわかる(貨幣以外の動作が起こり得ないから)
関数型言語だとデータを出力するまで貨幣かどうかは信用できない
変数 kahei に対して全ての関数が利用できるから、kahei はどうとでもなり得る
コメントつけろとかそういう原始的な話じゃなくてね
たとえば貨幣として扱いたいデータに対して、貨幣として必要な機能だけに関数を限定させれば、それはもうデータが存在するだけで貨幣として意味がわかる(貨幣以外の動作が起こり得ないから)
関数型言語だとデータを出力するまで貨幣かどうかは信用できない
変数 kahei に対して全ての関数が利用できるから、kahei はどうとでもなり得る
コメントつけろとかそういう原始的な話じゃなくてね
378デフォルトの名無しさん
2015/11/02(月) 05:08:00.98ID:tRZ2mEuQ その辺は言語の構造によって違うが
つーかオブジェクトの使われ方も言語によって全然違ったりするのでね
つーかオブジェクトの使われ方も言語によって全然違ったりするのでね
379デフォルトの名無しさん
2015/11/02(月) 08:23:24.30ID:+vmX+mwq あ、オブジェクト指向言語の実装とはちょっとかけ離れた例え話な
関数型言語で生きてきた人間にオブジェクト指向を説明する時にこういう話し方をする
勿論、実際には外部にある関数を変数に関連付けするわけじゃなくてクラス内部にメソッド(≒関数)を実装するわけなんだが
カッチカチの関数型人間がオブジェクト指向の意味を理解できるように、多少強引に言葉を改編してる
つっても >>377で理解できるのはカプセル化のメリットだけだからまだ全然オブジェクト指向を説明しきれていないが
関数型言語で生きてきた人間にオブジェクト指向を説明する時にこういう話し方をする
勿論、実際には外部にある関数を変数に関連付けするわけじゃなくてクラス内部にメソッド(≒関数)を実装するわけなんだが
カッチカチの関数型人間がオブジェクト指向の意味を理解できるように、多少強引に言葉を改編してる
つっても >>377で理解できるのはカプセル化のメリットだけだからまだ全然オブジェクト指向を説明しきれていないが
380デフォルトの名無しさん
2015/11/22(日) 11:27:04.36ID:yehd6qpM ネットで調べていてもオブジェクト指向が分からない…。
仕事でVB(昔の)やってたんだけど、画面のプログラムは目次状態で動かす部分は全てモジュールに作って入れてた。
画面の目次(仮名)には
<モジュール名>//○○を行う
が続いてる状態で中身はモジュールへ、モジュール使い回ししながら作ってたんだけど(時折モジュール内にも目次できたりしてた)
これはオブジェクト指向とは違うの??
モジュールがクラスになっただけちゃうんかなって、うーん良く分からない。
違いを教えてください。
仕事でVB(昔の)やってたんだけど、画面のプログラムは目次状態で動かす部分は全てモジュールに作って入れてた。
画面の目次(仮名)には
<モジュール名>//○○を行う
が続いてる状態で中身はモジュールへ、モジュール使い回ししながら作ってたんだけど(時折モジュール内にも目次できたりしてた)
これはオブジェクト指向とは違うの??
モジュールがクラスになっただけちゃうんかなって、うーん良く分からない。
違いを教えてください。
381デフォルトの名無しさん
2015/12/17(木) 16:14:25.39ID:f9fm3u2u 全てプリミティブかつアクセサ禁止って破綻してる
アクセスできないからプログラムも書けん
アクセスできないからプログラムも書けん
382デフォルトの名無しさん
2015/12/18(金) 04:38:42.92ID:TCff1iV0383デフォルトの名無しさん
2015/12/18(金) 07:38:43.70ID:VKllly6g >>382
ありがとう。
うーん、前職、書き方に制限ありまくりだったからクラスって本当に分からない。
情報系の大学だったけどプログラミングはほとんどやらなかったのに、基礎があるからって叩き上げられた形だったのよね。前職。
VB456にあるのかな。
.NET使う頃にはSEになってしまったから.NETもさわりしか分からない。
何かもう自分取り残されてるな…。
ありがとう。
うーん、前職、書き方に制限ありまくりだったからクラスって本当に分からない。
情報系の大学だったけどプログラミングはほとんどやらなかったのに、基礎があるからって叩き上げられた形だったのよね。前職。
VB456にあるのかな。
.NET使う頃にはSEになってしまったから.NETもさわりしか分からない。
何かもう自分取り残されてるな…。
384デフォルトの名無しさん
2015/12/18(金) 20:50:42.22ID:rBQUliqS 一ヶ月も前のをまだ待ってたんかいな。
検索すればいきなり出てきそうなもんだけど。
オブジェクト指向ってのは、
データ構造と処理構造を動的にかつ個別に、そしてそれらを一体化して管理できるようにできる仕組み。
全部まとめたその一連の一体がクラス
動的に個別に扱ってるデータがインスタンス
インスタンスに対応した処理がメソッド
インスタンスを発生させるのがそのクラスのコンストラクタ
いらないインスタンスを消すのがデストラクタ
インスタンスってのは、動的に作られたクラスデータ(専用型)であり、さらにそのクラスが持つメソッドを呼び出すことが出来る。
したがってこう書ける。
//インスタンス = クラス名->コンストラクタ(引数);
//戻り値 = インスタンス->メソッド名(引数);
うさぎ = 動物->new(耳が長い、白い); //コンストラクタ起動。動的に新データを生成します。うさぎが産まれました。インスタンスは必要な情報を全て保持しているかのように振舞います。
きりん = 動物->new(首が長い, 黄色い); //きりんが産まれました。
跳ねた距離 = うさき->動け(跳ねろ); //動物クラスが持つ、動くメソッドをうさぎに適用しました。うさぎは跳ねたときのデータに書き変わります。疲労度が増えてるかもしれません。戻り値は跳ねた距離です。
食った葉っぱの枚数 = きりん->食え->(柳); //きりんに柳の葉っぱを食わせます。きりんの内部データは自動で腹が膨れます。戻り値として食った葉っぱが返されます。
きりん->死ね; //デストラクタ。キリンに関するデータを全部メモリから消去します。
メソッドは関数のようですが、当然インスタンスからしか呼ぶことができず、名前空間を汚しません。
きりんからメソッドを呼ぶと、メソッドはきりんの情報を受け取ります。(もしくはメソッドやクラス全体はきりんの情報をすでに持っていて、きりんから呼ばれたことをメソッド自身は知っており、きりんのデータを扱えます)。
検索すればいきなり出てきそうなもんだけど。
オブジェクト指向ってのは、
データ構造と処理構造を動的にかつ個別に、そしてそれらを一体化して管理できるようにできる仕組み。
全部まとめたその一連の一体がクラス
動的に個別に扱ってるデータがインスタンス
インスタンスに対応した処理がメソッド
インスタンスを発生させるのがそのクラスのコンストラクタ
いらないインスタンスを消すのがデストラクタ
インスタンスってのは、動的に作られたクラスデータ(専用型)であり、さらにそのクラスが持つメソッドを呼び出すことが出来る。
したがってこう書ける。
//インスタンス = クラス名->コンストラクタ(引数);
//戻り値 = インスタンス->メソッド名(引数);
うさぎ = 動物->new(耳が長い、白い); //コンストラクタ起動。動的に新データを生成します。うさぎが産まれました。インスタンスは必要な情報を全て保持しているかのように振舞います。
きりん = 動物->new(首が長い, 黄色い); //きりんが産まれました。
跳ねた距離 = うさき->動け(跳ねろ); //動物クラスが持つ、動くメソッドをうさぎに適用しました。うさぎは跳ねたときのデータに書き変わります。疲労度が増えてるかもしれません。戻り値は跳ねた距離です。
食った葉っぱの枚数 = きりん->食え->(柳); //きりんに柳の葉っぱを食わせます。きりんの内部データは自動で腹が膨れます。戻り値として食った葉っぱが返されます。
きりん->死ね; //デストラクタ。キリンに関するデータを全部メモリから消去します。
メソッドは関数のようですが、当然インスタンスからしか呼ぶことができず、名前空間を汚しません。
きりんからメソッドを呼ぶと、メソッドはきりんの情報を受け取ります。(もしくはメソッドやクラス全体はきりんの情報をすでに持っていて、きりんから呼ばれたことをメソッド自身は知っており、きりんのデータを扱えます)。
385デフォルトの名無しさん
2015/12/22(火) 12:13:39.68ID:aBFh4Ipr 勘違いが多々見受けられるので、もう少し勉強したほうがいいね。
386デフォルトの名無しさん
2015/12/31(木) 03:23:42.07ID:riQaChnP その言語のオブジェクト指向か、オブジェクト指向自体の定義か。
かなり違う。
かなり違う。
387デフォルトの名無しさん
2016/03/27(日) 21:38:57.58ID:N7IGtcj3 結局、設計って何のためにするの?
って言ったら読む人間にわかりやすくするためだから
いくら哲学でガチガチに固めても読み手が
「何これさっぱりわからなーい」って言ったらそこで終わりな
設計書と内容が乖離してるソースもクソだし
どの仕様を実現しようとして書いたコードなのかわからないのもクソ
そもそも仕様の定義が明確でないのなんてソース書く前からクソが漏れてる
ブリブリブリブリ漏れてる!
って言ったら読む人間にわかりやすくするためだから
いくら哲学でガチガチに固めても読み手が
「何これさっぱりわからなーい」って言ったらそこで終わりな
設計書と内容が乖離してるソースもクソだし
どの仕様を実現しようとして書いたコードなのかわからないのもクソ
そもそも仕様の定義が明確でないのなんてソース書く前からクソが漏れてる
ブリブリブリブリ漏れてる!
388デフォルトの名無しさん
2016/03/28(月) 21:59:57.56ID:jI9F+kOe 家と同じ
無計画に建てたらあばら家になる
無計画に建てたらあばら家になる
389デフォルトの名無しさん
2016/03/29(火) 09:35:59.83ID:/c8bAcK4 サッカーブッシュ日本代表日程ぷあたん(しゅっちょうまいくろ教育長交代)春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ24チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン(販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ24チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン(販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート
390デフォルトの名無しさん
2016/03/29(火) 21:13:02.91ID:WTA2j3Vp オブジェクト指向に何故するかと言えば
変数、プロパティは全てpublicにすればいいじゃないかと言うところから始まる
変数、プロパティは全てpublicにすればいいじゃないかと言うところから始まる
391デフォルトの名無しさん
2016/03/30(水) 09:31:45.09ID:idf8Q5SU それなんて構造体?
カプセル化なんて常識じゃんw
カプセル化なんて常識じゃんw
392デフォルトの名無しさん
2016/03/30(水) 20:08:05.29ID:H6rY7wzp393デフォルトの名無しさん
2016/04/01(金) 18:13:49.68ID:ELyCfH/G >>392
ばか?
ばか?
394デフォルトの名無しさん
2016/04/01(金) 18:22:47.72ID:TewsBR2n >>393
でも全publicのプログラムって何の問題もなく動きますよね?それが悪いんですかね?
でも全publicのプログラムって何の問題もなく動きますよね?それが悪いんですかね?
395デフォルトの名無しさん
2016/04/01(金) 18:28:15.95ID:j6FPRdfu CPUがpublicかprivateか判断するのか
396デフォルトの名無しさん
2016/04/01(金) 19:43:57.88ID:RonLnaIy あ、アセンブラ的な話はちょっと、、
397デフォルトの名無しさん
2016/04/02(土) 06:38:34.56ID:vYH8mHjR >>394
もうちょっと気合い入れて釣れよ
もうちょっと気合い入れて釣れよ
398デフォルトの名無しさん
2016/04/02(土) 16:15:31.86ID:P45UDLlW >>397
えー結構いいキレ具合やろ
えー結構いいキレ具合やろ
399デフォルトの名無しさん
2016/04/03(日) 21:25:16.27ID:AFllrpm9 キレ過ぎてストライクゾーンから外れてるんやで
もうちょい工夫して再チャレンジするように
もうちょい工夫して再チャレンジするように
400デフォルトの名無しさん
2016/04/03(日) 23:25:16.70ID:I1bXI3bS じゃあここはオブジェクト指向の大敵publicおじさん登場という展開の方針で
401デフォルトの名無しさん
2016/04/03(日) 23:37:46.54ID:GlCd9dIf Setter getter使えw
402デフォルトの名無しさん
2016/04/04(月) 19:02:28.23ID:Pgq0yCJI 大敵はstaticおじさんだろ?
403デフォルトの名無しさん
2016/05/01(日) 15:58:07.83ID: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的に分散され、特定のサーバーに依存しません
¥
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.45ID:uHWe44q7 OOPに毒されすぎた人間はOCamlをやるべき
オブジェクト指向を活用できる部分は驚くほど少なく、殆どの問題はポリモーフィズムで静的に解決できることを知るだろう
OOの本質であるメッセージパッシングを活用できる場面を見極めることができるようになるだろう
オブジェクトの階層構造のデメリットが分からないなら、traitを知るべきだろう。
階層構造の設計、リファクタリング、デザインパターンの適用は仕事をした気になるが、
それらのほとんどが、何でもOOで問題に取り組もうとしたから発生する必要性だと気付くべきだ
オブジェクト指向を活用できる部分は驚くほど少なく、殆どの問題はポリモーフィズムで静的に解決できることを知るだろう
OOの本質であるメッセージパッシングを活用できる場面を見極めることができるようになるだろう
オブジェクトの階層構造のデメリットが分からないなら、traitを知るべきだろう。
階層構造の設計、リファクタリング、デザインパターンの適用は仕事をした気になるが、
それらのほとんどが、何でもOOで問題に取り組もうとしたから発生する必要性だと気付くべきだ
405デフォルトの名無しさん
2016/05/17(火) 16:15:23.13ID:PHOPFQsz OCamlってそんなに駄目な言語なの?
406デフォルトの名無しさん
2016/05/18(水) 01:04:43.37ID:ErRdtrnJ みんなにとってオブジェクト指向ってどんなの?
言語がJavaやC#だったり、Hibernateとかの有名ライブラリ使ってればオブジェクト指向?
「受注Entityにはgetterでカプセル化された各変数と、決済・出荷・返品・破棄のメソッドがあって...」みたいにビジネスロジックまでがっつり?
後者の失敗した感じの奴を引き取るハメになったんだが、巨大で邪悪な状態地獄を前に吐きそう・・・
言語がJavaやC#だったり、Hibernateとかの有名ライブラリ使ってればオブジェクト指向?
「受注Entityにはgetterでカプセル化された各変数と、決済・出荷・返品・破棄のメソッドがあって...」みたいにビジネスロジックまでがっつり?
後者の失敗した感じの奴を引き取るハメになったんだが、巨大で邪悪な状態地獄を前に吐きそう・・・
407デフォルトの名無しさん
2016/05/23(月) 21:43:40.30ID:VxHtpmL+ >>406
>決済・出荷・返品・破棄のメソッドがあって
クラスじゃないの?
そうだとしたら凄そうだな。
とりあえずリファクタリングが許されるなら、機能ごとにクラス化して責務をきちんと分けるとか。
でもきっとパッチ当てるような修正しか許されないんじゃないかな。
頑張ってくださいとしか言いようがないです。
>決済・出荷・返品・破棄のメソッドがあって
クラスじゃないの?
そうだとしたら凄そうだな。
とりあえずリファクタリングが許されるなら、機能ごとにクラス化して責務をきちんと分けるとか。
でもきっとパッチ当てるような修正しか許されないんじゃないかな。
頑張ってくださいとしか言いようがないです。
408デフォルトの名無しさん
2016/05/24(火) 14:37:31.12ID:kSJa5DY/ >>407
ありがとう…
手持ちの知識と経験で最初から実装するなら「振る舞いを持たない受注Dto」と「状態を持たない受注各種操作サービス」で作ると思う。
それとも「受注Dtoを包んだ受注操作Executer」みたいなのがOOPっぽくて良いのかな。
どうしてこうなったんだろ
入門書の自動車クラスを忠実に参考にしたのかな
ありがとう…
手持ちの知識と経験で最初から実装するなら「振る舞いを持たない受注Dto」と「状態を持たない受注各種操作サービス」で作ると思う。
それとも「受注Dtoを包んだ受注操作Executer」みたいなのがOOPっぽくて良いのかな。
どうしてこうなったんだろ
入門書の自動車クラスを忠実に参考にしたのかな
409デフォルトの名無しさん
2017/03/25(土) 13:05:46.69ID:Hepb4FxQ ふるまいを持たないクラスと状態クラスを分離したいよね
その設計指針は全くもって正しいと思う
でもそれはオブジェクト指向を真っ向から否定してるんだよね
我々の言葉に言い換えるとこうだ
データとふるまいが合併しているクラスは、プログラムサイズが巨大化するにつれて問題であるとわかった
なぜかといえば状態がそこらじゅうのクラスにちりばめられていてプログラマやSEがコントロールが不可能な領域になっている
だからふるまいと状態を分離しよう
ふるまいを失ったクラス、それは構造体あるいは単なるコンテナだ
状態を失ったクラス、それは単なる関数だ
つまり君が直感的にやりたいとおもっていることは実は関数型なわけだ
もしベースがJavaならScalaまたはclojureで再実装することをおすすめする
もしJavaでやるなら君がいった通り、サービスクラスとコンテナクラスに分離するべき
これはトランザクションスクリプトとよばれ、OOP界隈ではディスられているやり方だけど、(なぜならクラスという概念を否定してるから)、こっちのほうが設計がシンプルかつ明瞭にたもたれると思う
個人的にはjavaでこれをやりたくないけどね
その設計指針は全くもって正しいと思う
でもそれはオブジェクト指向を真っ向から否定してるんだよね
我々の言葉に言い換えるとこうだ
データとふるまいが合併しているクラスは、プログラムサイズが巨大化するにつれて問題であるとわかった
なぜかといえば状態がそこらじゅうのクラスにちりばめられていてプログラマやSEがコントロールが不可能な領域になっている
だからふるまいと状態を分離しよう
ふるまいを失ったクラス、それは構造体あるいは単なるコンテナだ
状態を失ったクラス、それは単なる関数だ
つまり君が直感的にやりたいとおもっていることは実は関数型なわけだ
もしベースがJavaならScalaまたはclojureで再実装することをおすすめする
もしJavaでやるなら君がいった通り、サービスクラスとコンテナクラスに分離するべき
これはトランザクションスクリプトとよばれ、OOP界隈ではディスられているやり方だけど、(なぜならクラスという概念を否定してるから)、こっちのほうが設計がシンプルかつ明瞭にたもたれると思う
個人的にはjavaでこれをやりたくないけどね
410デフォルトの名無しさん
2017/03/28(火) 18:35:33.54ID:wSpDlXLz 一年近く前のレスになにを書いてるんだって思ったがそれは置いておいて、
最初にオブジェクト指向を学んだ時、もっとも意味不明でかつ無意味な単語が「ふるまい」だった。
最初にオブジェクト指向を学んだ時、もっとも意味不明でかつ無意味な単語が「ふるまい」だった。
411デフォルトの名無しさん
2017/03/29(水) 09:44:06.57ID:PMA68UxV >>410
> 「ふるまい」
Smalltalkなら言語レベルで組み込みの概念なんだけどね…
ProtoObject
Object
Behavior
ClassDescription
Class
Metaclass
> 「ふるまい」
Smalltalkなら言語レベルで組み込みの概念なんだけどね…
ProtoObject
Object
Behavior
ClassDescription
Class
Metaclass
412デフォルトの名無しさん
2017/07/23(日) 00:47:28.95ID:4pTb5xvQ ┌─マシン語
│
言語のレベル─┼─低級言語
│ ┌─コンパイラ型
└─高級言語─┤
└─インタプリタ型
┌─手続き型
│
│ ┌─宣言型
│ │
文法──┤ ├─関数型
│ │
└ 非手続き型─┼─論理型
│
├─グラフィック型
│
└─問い合わせ
パラダイム──オブジェクト指向
ttp://webrylabo.blogspot.jp/2009/11/blog-post_28.html
2009年11月28日土曜日
│
言語のレベル─┼─低級言語
│ ┌─コンパイラ型
└─高級言語─┤
└─インタプリタ型
┌─手続き型
│
│ ┌─宣言型
│ │
文法──┤ ├─関数型
│ │
└ 非手続き型─┼─論理型
│
├─グラフィック型
│
└─問い合わせ
パラダイム──オブジェクト指向
ttp://webrylabo.blogspot.jp/2009/11/blog-post_28.html
2009年11月28日土曜日
413デフォルトの名無しさん
2017/07/23(日) 00:54:24.08ID:4pTb5xvQ ┌─マシン語
│
言語のレベル─┼─低級言語
│ ┌─コンパイラ型
└─高級言語─┤
└─インタプリタ型
┌─手続き型
│
│ ┌─宣言型
│ │
文法──┤ ├─関数型
│ │
└ 非手続き型─┼─論理型
│
├─グラフィック型
│
└─問い合わせ
パラダイム──オブジェクト指向
ttp://webrylabo.blogspot.jp/2009/11/blog-post_28.html
2009年11月28日土曜日
│
言語のレベル─┼─低級言語
│ ┌─コンパイラ型
└─高級言語─┤
└─インタプリタ型
┌─手続き型
│
│ ┌─宣言型
│ │
文法──┤ ├─関数型
│ │
└ 非手続き型─┼─論理型
│
├─グラフィック型
│
└─問い合わせ
パラダイム──オブジェクト指向
ttp://webrylabo.blogspot.jp/2009/11/blog-post_28.html
2009年11月28日土曜日
414デフォルトの名無しさん
2017/09/16(土) 17:26:47.77ID:3R6WSf4d 関数型はパラダイムの方にもっていきたいね
415デフォルトの名無しさん
2017/11/06(月) 03:33:00.01ID:2Q/sT7xS ヤフーブログの https://blogs.yahoo.co.jp/kamyu_2010 にデザパタ解説を発見した。
416デフォルトの名無しさん
2018/05/23(水) 21:20:33.63ID:Au5e7VGg 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
5648K
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
5648K
417デフォルトの名無しさん
2018/07/05(木) 00:37:19.93ID:RfoszcD2 QS9
418デフォルトの名無しさん
2018/07/08(日) 16:25:00.06ID:vDaTJ8Du ヤフーのブログのサイトで初心者にはわかりやすいブログを発見したよ。
https://blogs.yahoo.co.jp/kamyu_2010/35417803.html
https://blogs.yahoo.co.jp/kamyu_2010/35417803.html
419デフォルトの名無しさん
2020/06/18(木) 19:59:44.28ID:n5xiCy8O こちらで同意を得られなかったからニュース速報スレで騒いでるw
オブジェクト指向は愚かな考え
https://hayabusa9.5ch.net/test/read.cgi/news/1592474015/
オブジェクト指向は愚かな考え
https://hayabusa9.5ch.net/test/read.cgi/news/1592474015/
420デフォルトの名無しさん
2020/06/18(木) 22:56:36.42ID:g18Fqbw/ 未経験から半年でフリーエンジニアになれる人の特徴
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
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.94ID:qp6BB2Af ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか?
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は2種類あって、全体(俺)と部分(チンポ)が繋がっている場合と、
全体(俺)と部分(チンポ)が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか?
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、50字以内で述べろ!
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は2種類あって、全体(俺)と部分(チンポ)が繋がっている場合と、
全体(俺)と部分(チンポ)が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか?
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、50字以内で述べろ!
422デフォルトの名無しさん
2020/08/23(日) 20:54:14.43ID:QkS8Y3mc まだ言ってる
423デフォルトの名無しさん
2020/08/24(月) 03:51:28.76ID:kS+LJTrm >>1
必要なものと思い込ませて教材商法で荒稼ぎ
必要なものと思い込ませて教材商法で荒稼ぎ
424デフォルトの名無しさん
2020/08/24(月) 12:34:56.77ID:jN2NYQ9A 複雑なあるいは煩雑なデータ構造を管理するとき。
類似したデータを系統立てて扱いたい時。
データが多くのインスタンスで構成される時。
類似したデータを系統立てて扱いたい時。
データが多くのインスタンスで構成される時。
425デフォルトの名無しさん
2020/08/25(火) 01:58:34.46ID:kR3OjXLq enemyオブジェクトとか?
bulletインスタンスとか?
bulletインスタンスとか?
426デフォルトの名無しさん
2020/08/25(火) 04:40:46.72ID:yD81MP45 >>17
T-SQLは問合せ文と制御文が同時に書けるので、かなり複雑なことが手軽にできる(熟練者には)
なのでSQL Server技術者の方がORACLE技術者よりも腕がいいことが多いらしい
工夫する幅が広いので、経験も広くなる
ウィンドウ操作ができないだけ
データ操作とウィンドウ操作を完全に分けると、要件的にはSQLの方が大部分を占めることもある
特に業務系の場合、ウィンドウ操作は定型的で、業務要件にそれほど関わらない
そっちの方がオマケ
データ処理の一部がクライアント側でしかできないと思ってるのは、腕がないだけ
T-SQLは問合せ文と制御文が同時に書けるので、かなり複雑なことが手軽にできる(熟練者には)
なのでSQL Server技術者の方がORACLE技術者よりも腕がいいことが多いらしい
工夫する幅が広いので、経験も広くなる
ウィンドウ操作ができないだけ
データ操作とウィンドウ操作を完全に分けると、要件的にはSQLの方が大部分を占めることもある
特に業務系の場合、ウィンドウ操作は定型的で、業務要件にそれほど関わらない
そっちの方がオマケ
データ処理の一部がクライアント側でしかできないと思ってるのは、腕がないだけ
427デフォルトの名無しさん
2020/08/25(火) 04:55:25.53ID:yD81MP45 MS-DOSの頃はMacを「オブジェクト指向」と言ったもんだが、今の意味とは違う
「オブジェクト思想」と言った方がいいのかな
Windowsはフォルダ構成以外に、スタートメニューがある
フォルダがごちゃごちゃしてるからだ
フォルダ構成とスタートメニューが二重にあるので、「インストール」を経ないと同期しない
実際にはレジストリで三重
なので「インストール」や「アンインストール」に抜けがあるとゴミが残ったり
それは机に物を置くという「オブジェクト思想」のデスクトップじゃない
そのかわり、動作が速く落ちにくい
今のMacは知らんが当時のMacは、「物」をどう置こうが自由なので、
パスも起動してから動的に確定したり、「機能拡張」のファイル数が少ない換わりに大きいので、遅く落ちやすかった
「オブジェクト思想」と言った方がいいのかな
Windowsはフォルダ構成以外に、スタートメニューがある
フォルダがごちゃごちゃしてるからだ
フォルダ構成とスタートメニューが二重にあるので、「インストール」を経ないと同期しない
実際にはレジストリで三重
なので「インストール」や「アンインストール」に抜けがあるとゴミが残ったり
それは机に物を置くという「オブジェクト思想」のデスクトップじゃない
そのかわり、動作が速く落ちにくい
今のMacは知らんが当時のMacは、「物」をどう置こうが自由なので、
パスも起動してから動的に確定したり、「機能拡張」のファイル数が少ない換わりに大きいので、遅く落ちやすかった
428デフォルトの名無しさん
2020/08/25(火) 05:00:39.88ID:yD81MP45 APPDATAで四重かw
Macは設定ファイルもアプリケーションの隣に置かれた
Macは設定ファイルもアプリケーションの隣に置かれた
429デフォルトの名無しさん
2020/08/25(火) 05:02:41.90ID:yD81MP45 ところがそのスタートメニューもごちゃごちゃしてるので、もう長年見てないw
使う物をタスクバーにピン留めしてる
使う物をタスクバーにピン留めしてる
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【地震速報】青森県で震度6強 沿岸部に津波警報 ★6 [ぐれ★]
- 「日の丸にバツ印」掲げた大学生 あいまいな国旗損壊罪に「怖い」 The Mainichi [少考さん★]
- 高市内閣「支持」64%「不支持」19% NHK世論調査 ★2 [少考さん★]
- 【音楽】BARBEE BOYS・KONTAが事故で四肢麻痺を公表、新体制で活動は継続 [少考さん★]
- 高市首相「多様なコメの増産を進める」 方針転換への懸念払拭狙いか ★2 [どどん★]
- 中国「捜索レーダー起動は各国の通常の手法」 火器管制用か回答せず [蚤の市★]
- 🖐( -᷄ὢ)俺様が寝るぞ……
- 運よく「オーナーが高齢などの理由でコインランドリーそのものを買えた新オーナー」になれた人
- 初めて顔パックしたけど凄いなこれ
- 巨大地震 [957955821]
- ぺこーら、地震で同僚が次々配信を止めるなか強行し続けるので悪目立ちするwww [268244553]
- 【🏡】岩手ビックウェーブ🏄うおおおおおおおおおおお🌊
