オブジェクト指向って自然な文法だな 3

1 ：デフォルトの名無しさん：2017/04/02(日) 16:30:38.65 ID:n7h/bBRg.net

前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

952 ：デフォルトの名無しさん：2017/07/06(木) 12:27:47.00 ID:jsnas7L+.net

何を面白がるかみたなもんにこそ知性が出ちゃうと思ってる
悲しいね
自覚が無いのか意固地になっちゃってるのか知らんけど

953 ：デフォルトの名無しさん：2017/07/06(木) 18:21:22.89 ID:j+3WJv+Z.net

モデルは問題解決のために設計するので、
まったく的外れ。

世の中を表現したいわけじゃないし、
世の中に似せる必要も全くない。

954 ：デフォルトの名無しさん：2017/07/06(木) 19:22:23.33 ID:0T2UvbzF.net

なんか最近「モデル」って言うの馬鹿の間で流行ってるの？w

955 ：デフォルトの名無しさん：2017/07/06(木) 19:24:13.39 ID:NwSzXY2t.net

(？ なに言ってんだこいつ…)

956 ：デフォルトの名無しさん：2017/07/06(木) 19:40:14.63 ID:rLOZYnLv.net

オブジェクト指向ってDBのエンティティを拡張したものだろ

1事実1箇所と考えたら現実に当てはめないとダメだろ

957 ：デフォルトの名無しさん：2017/07/06(木) 20:22:03.68 ID:ZZVNNqrh.net

>>956
いいえ

いいえ

958 ：デフォルトの名無しさん：2017/07/06(木) 20:29:21.13 ID:Dxq//V42.net

>>956
残念ながら見当外れ

959 ：デフォルトの名無しさん：2017/07/06(木) 20:45:03.97 ID:ecitQSu4.net

エンティティとオブジェクトは対応するものだよ

960 ：デフォルトの名無しさん：2017/07/06(木) 20:47:16.64 ID:ecitQSu4.net

エンティティからクラスを自動生成するのが今のやり方
対応しないとしたら正規化できてない

961 ：デフォルトの名無しさん：2017/07/06(木) 21:08:11.46 ID:ZZVNNqrh.net

リソース系ならまだわかるが

962 ：デフォルトの名無しさん：2017/07/06(木) 23:39:48.30 ID:x/UayICR.net

対応と言われても抽象的で分からんな。
エンティティは実態でオブジェクトはその射影だよ。

何を持って対応とするの？
エンティティとオブジェクトで可逆性は保証されてないけど

963 ：デフォルトの名無しさん：2017/07/07(金) 00:03:06.17 ID:ZLKHtWHA.net

エンティティだけがオブジェクト指向だと思ってるCRUDマンワロタw

964 ：デフォルトの名無しさん：2017/07/07(金) 00:06:20.53 ID:ZLKHtWHA.net

そーゆーさ、入れポン出しポンっていうの？超シンプルなCRUDの経験しかない奴が
オブジェクト指向とはをなんぞやを語るのやめてよマジでww

965 ：デフォルトの名無しさん：2017/07/07(金) 05:43:32.56 ID:1OiH67XQ.net

>>943
何が言いたいのかわからんが、プログラミングしたい事象を、そのままオブジェクトに丸ごと落とし込むんじゃ無くて一旦分解して考える。
共通点とか過去の資産使えそうなのはそうする。
ここは他でも使えそうとかあったら分けておく。
再利用出来そうな場所と、そうでない場所を分ける。

人と車って系統的に全然違うからオブジェクト指向の動物クラスみたいなのじゃ全然違うだろ？
でも移動出来るってのは同じだ。
食事と燃料補給は違うが、エネルギーが無いと動かないってのも同じ。
そうやって全然関係無さそうなものの共通点を考えると抽象的なクラスが出来てくる。
現実のオブジェクトと違うけど、より本質に近いオブジェクトになる。

966 ：デフォルトの名無しさん：2017/07/07(金) 07:21:29.95 ID:5Fyb0GDQ.net

>>965
人と車を動くという共通点によって同じ操作をインターフェイスで作るみたいな感じ?

10画面程度の業務システムしか組んだことないから知らんのだけど大規模システムはそんな風にオブジェクト指向で設計するの?

オブジェクト指向入門見て分類学的に設計するものだと思ってた

967 ：デフォルトの名無しさん：2017/07/07(金) 07:25:14.64 ID:5Fyb0GDQ.net

966だけど、ゲームでオブジェクト指向すると動くという操作は人も車も変わらんか

業務システムじゃエンティティが正義だと思うけど、ゲームや制御じゃ事情や適用方法が違うんだろうね

制御は構造化しかやったことないけど

968 ：デフォルトの名無しさん：2017/07/07(金) 07:33:06.32 ID:DRnLdr12.net

>>937
アラン・ケイのメッセージングのオブジェクト指向がまさにその着想だな

http://worrydream.com/EarlyHistoryOfSmalltalk/
My biology major had focused on both cell metabolism and
larger scale morphogenesis with its notions of simple mechanisms
controlling complex processes

でも残念ながら現在の主流は抽象データ型のオブジェクト指向
クラスやそれに準ずる言語機能をユーザー定義型として扱うストラウストラップらの着想が根底にあり
生命体とのアナロジーはそぐわない

969 ：デフォルトの名無しさん：2017/07/07(金) 07:44:57.59 ID:JJYyKRQq.net

大規模かは知らんが、最近は継承はあまり好まれなくなった。
委譲やインターフェースによる多態性のが好まれる。

これはおいらの推論だが、昔はCUIからGUIに移行するときの規模に対応するためにOOPが誕生した。
今度はPCやスマホなどの多様なGUI、webプログラミングでビューとロジックを分ける必要が出てきた。
ここにOOPは対応しきれてない。

そこで関数型言語が注目されたりした訳だが、今のOOPは関数型言語と同じ所を目指してる最中な気がする。
なぜなら、関数型言語にはコード資産が無いけどOOPには有るから。
全く違うプラットフォーム行くのは怖いから。
実際、言語は優秀でもツール類が絶望的に足りない。

970 ：デフォルトの名無しさん：2017/07/07(金) 08:16:46.35 ID:G2hd19q1.net

継承を使わないのは、複雑になるから。
多重で継承すると、デバッグが大変。

継承でロジックの一元化を狙うより、
1番トップの1階層目ぐらいの継承で妥協しておいた方が、
ソースを体系化しやすく、プロジェクトの見通しが良くなる。

971 ：デフォルトの名無しさん：2017/07/07(金) 08:31:15.22 ID:SENaJwbT.net

>>970
言語として多重継承できる言語の方が少ないと思う

あとロジックの一元化は継承とまた別の話だよ

972 ：デフォルトの名無しさん：2017/07/07(金) 08:42:08.67 ID:G2hd19q1.net

>>971
多重じゃなくて、継承の継承でした。
垂直の継承。

継承がロジックの一元化の全てではないが、
手法の一つなので別問題にする必要もないと思うが。
どう別問題に扱うの？

973 ：デフォルトの名無しさん：2017/07/07(金) 08:54:11.36 ID:3/JgoNbI.net

継承はあるけど継承の継承は出来ないって例えばどの言語？

974 ：デフォルトの名無しさん：2017/07/07(金) 08:54:25.16 ID:8UX+Q+HA.net

オブジェクトが必ずしもDBとだけ対応してるってのは
間違いじゃないかな？
関数オブジェクトとかあるし、
GoFのデザパタとかで出て来るオブジェクトは全然DB関係ない
のばっかりじゃん。
JavaScriptやUIプログラミングもオブジェクト指向化してるけど
UIなんてDBと無関係だぞ。
俺は >>937だけど、JavaScriptやっててオブジェクトは「生命体」
だと思ったんだよ、「xxxer」 ていうオブジェクト作ること多いじゃん、
だから「xxxをする人」ってことでしょ。
DIとかオブジェクトを引数としてやり取りしたり、
メソッド内で他のオブジェクトを new したりすると何やってんだか
はじめはわからなくなったけど、
「ある生命体Aの部下として生命体Bを『配属』させ、所有物のように受け渡したり、
部下として仕事をさせる」と考えると結構上手く説明がつくことに気づいたんだよ。

975 ：デフォルトの名無しさん：2017/07/07(金) 08:59:17.56 ID:6QLBDLc9.net

「おいら」って20年ぶりくらいに見た

976 ：デフォルトの名無しさん：2017/07/07(金) 09:00:08.09 ID:U3HkjAD4.net

クラスあるいはそれに準ずる言語機能を抽象データ型（簡単にはユーザー定義型）として扱う着想において
クラスの継承により部分型を表現するのは危険をはらむということはかなり早い時期に指摘されている
だから言語機能としてのインターフェースが考案され、以降はそれを使って部分型を安全に表現する言語が汎用されている

継承は部分型を表現すること以外に、実装の重複をなくす（簡単にいうとコピペによる分散を防ぐ）役割も担っていたが
初期のインターフェースは実装を持てなかったため、継承のメリットのうち後者は捨てるか、クラスとの併用で気をつけて使うしかなかった

ただ、型クラスやトレイトという考え方や言語機能が考案され、インターフェイスも実装を持てるようになったので
クラス（というか継承）の役割はほぼ終わりつつある

977 ：デフォルトの名無しさん：2017/07/07(金) 09:28:29.21 ID:G2hd19q1.net

>>974
初心者への例え話レベルですね。

客、ウェイター、料理人、冷蔵庫(データベース)

客がウェイターに指示をする。
ウェイターが料理人に指示をする。
料理人が冷蔵庫から材料を取り出す。
でも、プログラム上では冷蔵庫から食材を料理人に渡す人がいる。
現実世界では包丁は料理人が使わないと効果を発揮しない。
プログラム上では、包丁だけあれば食材を切り刻むことができる。

店長は、店員を部下を持つ。
だが、店長の所有物ではない。
店員のリポジトリから、店コードでアクセスするものだ。
店長も店から見れば店の所有物なのだから。

だから、データにアクセスする機能は人オブジェクトにはない。

978 ：デフォルトの名無しさん：2017/07/07(金) 11:35:17.41 ID:6eecx6PE.net

「おいら」さんはいつもの変な子でしょ。
なんか今日はこまめにID変えてるけど。

そうじゃなくて、むかしは大型コンピュータしかなかったから
大きな処理を行うにつれて「ネットワークで繋がった他のコンピュータに処理を委譲する」という
処理形式が現実になってきた。
そうなるともはや処理時間も通信状態も不明な他所のコンピュータで動いてる処理を
シーケンシャルな一意の順番で行ってゆくというのが非現実的になるのが明白で
そういった視点から「こういう処理をせよ」とクラス(独自の処理単位/物理的に別な機械)に命令したら
その単位が他に依存しないで自律的に処理を行う「オブジェクト指向」が提唱された。
(オブジェクトの再利用がどーのというオブジェクト指向とは別物)

そして、現代では「このシーケンシャルに処理が行われるとは限らない」は
薄れるどころかますます重要性を増してる要素なのだけど
なぜか亡霊のように『処理の間に他人が絡まなければ』って
局所的処理があたかもこれからも可能だと"信心"してる
関数型言語とかいうのが地獄の底から這い出してきて
世界の皆が困惑してる。だいたいそんな状況。

979 ：デフォルトの名無しさん：2017/07/07(金) 11:57:04.53 ID:U3HkjAD4.net

>>969
> 昔はCUIからGUIに移行するときの規模に対応するためにOOPが誕生した。

それはアラン・ケイのメッセージングのOOPの話で、継承を前提とした現在主流の抽象データ型のOOPとは関係ないよ
念のためメッセージングのOOPというのは所謂「オブジェクトにメッセージを送って」とかいうお題目を唱えながら
設計・実装・実行・運用と幅広い局面における「可能な限りの決定の遅延」を徹底する考え方ね
http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeringAnOxymoron.pdf

>>978
> そうなるともはや処理時間も通信状態も不明な他所のコンピュータで動いてる処理を
> シーケンシャルな一意の順番で行ってゆくというのが非現実的になるのが明白で
> そういった視点から「こういう処理をせよ」とクラス(独自の処理単位/物理的に別な機械)に命令したら
> その単位が他に依存しないで自律的に処理を行う「オブジェクト指向」が提唱された。

そんな「オブジェクト指向」の出自は初耳なんだけど誰が提唱したもの？

ちなみに抽象データ型のオブジェクト指向は、C with Classe（後にC++）のスウストラップのこちらの所謂 what-is 論文が有名
http://dl.acm.org/citation.cfm?id=624721
同時期にEiffelのメイヤー、抽象データ型のリスコフ、SIMULAでクラスとオブジェクトを考案したダールとニガードも
同様の着想（SIMULAスタイルのクラスを抽象データ型として扱い、その継承機構で部分型を表現する）を得ている

980 ：デフォルトの名無しさん：2017/07/07(金) 12:01:56.23 ID:xvg52mfm.net

困惑してるだけなら関数型言語の機能取り入れたりしないだろ。
その再利用とは別のオブジェクト指向ってどうなったんよ。
MVCとかMVVMじゃ無いよね？そんな昔じゃ無いし。

981 ：デフォルトの名無しさん：2017/07/07(金) 12:11:51.38 ID:6QLBDLc9.net

出所とか歴史上の経緯とか大切なことなの？

982 ：デフォルトの名無しさん：2017/07/07(金) 12:12:45.80 ID:6QLBDLc9.net

それと「だれそれが提唱した〜」とか

983 ：デフォルトの名無しさん：2017/07/07(金) 12:13:19.21 ID:xvg52mfm.net

>>979
そのsmalltalkやRubyのオブジェクト指向が関数型言語と同じ方向目指してるなって感じてて、でも今の所関数型言語のが相性が良いように思える。

984 ：デフォルトの名無しさん：2017/07/07(金) 12:31:03.55 ID:vHHwjjQx.net

>>981
継承の概念を作ったのはC++
そのさきは

985 ：デフォルトの名無しさん：2017/07/07(金) 12:32:20.58 ID:U3HkjAD4.net

>>981
そりゃ大事だろ
誰がどういう背景でどんなことを目指して考案・発案したかって知らないでどうやって使いこなすのさ？

特に「オブジェクト指向」は同名の違う考え方が混在しているうえに
想像で語られるオレ定義が跳梁跋扈しているから、それらに翻弄されないためになおさらでしょ

>>982
誰が提唱したかを知っていれば、それを冠することで区別が付けやすいってだけの話
同じ「オブジェクト指向」でも異質な考え方があるのを区別しなければならない特殊事情を鑑みてこれは必要なこと

986 ：デフォルトの名無しさん：2017/07/07(金) 12:33:44.47 ID:vHHwjjQx.net

>>983
いいこと言った
つまりオブジェクト指向に継承やカプセル化は
必要ないし害悪ですらあるってことが明らかになってきているってことだな

987 ：デフォルトの名無しさん：2017/07/07(金) 12:35:07.48 ID:vHHwjjQx.net

インターフェイス、つまり型による契約プログラミングこそがオブジェクト指向の本質

988 ：デフォルトの名無しさん：2017/07/07(金) 12:35:11.95 ID:SENaJwbT.net

>>972
あ〜深いヤツは見ててしんどいですね

ロジックの一元化を「このメソッドいろんなところで同じ処理するからまとめたよ！継承したら呼べるよ！」って感じで使ってる所だととても大変
振る舞いを一元化して異なる動作をさせたいメソッドのoverrideで使ってたら苦にはならないよ

手法としては存在するよね？って聞かれたら存在する
でも問題は設計であって継承ではないと考える

989 ：デフォルトの名無しさん：2017/07/07(金) 12:37:16.77 ID:SENaJwbT.net

>>986
お、出たな
カプセル化不要論は浸透したかい？

990 ：デフォルトの名無しさん：2017/07/07(金) 13:06:08.89 ID:xvg52mfm.net

>>986
ありがとうだけど、継承はともかくカプセル化は必要。
モジュールも広い意味でのカプセル化だからね。
それまで不要とは思わないし、副作用と縁のきれない手続き型言語にカプセル化ある種運命共同体。

991 ：デフォルトの名無しさん：2017/07/07(金) 13:30:17.87 ID:XBLDwFYK.net

結局どこまで行っても、ここで議論されてる事とは
「どう構造化し記述すべきなのか」なんである

992 ：デフォルトの名無しさん：2017/07/07(金) 14:05:53.15 ID:vHHwjjQx.net

>>990
カプセル化が必要なくなるように設計するべき
手続き型に逃げちゃダメ
オブジェクト指向やりたいんでしょ？

993 ：デフォルトの名無しさん：2017/07/07(金) 14:06:56.46 ID:vHHwjjQx.net

オブジェクト指向っていうのは言わば関数型なんだよね

994 ：デフォルトの名無しさん：2017/07/07(金) 14:08:59.90 ID:vHHwjjQx.net

手続きをカプセル化するだけじゃただのモジュール指向手続き型
カプセル化が要らなくなるまで設計を洗練させること
これ即ちオブジェクトの正規化なり

995 ：デフォルトの名無しさん：2017/07/07(金) 14:43:00.99 ID:G2hd19q1.net

無駄に正規化したところで、クラスの粒度、階層がバラバラになるからほどほとにしないと無駄だよ

996 ：デフォルトの名無しさん：2017/07/07(金) 15:22:06.11 ID:6QLBDLc9.net

こだわるポイントが不適当だな

997 ：デフォルトの名無しさん：2017/07/07(金) 18:42:32.82 ID:eVPhxI3P.net

>>992
いんや。
関数型言語したいん。
だから対岸の火事なのん。

998 ：デフォルトの名無しさん：2017/07/07(金) 19:12:56.87 ID:8UX+Q+HA.net

>>977
ごめん、ちょっと言い方間違えたは、別に部下として配属する
必要はないな。
あと、thisって何かイマイチしっくり来なかったんだけど、
「この」って解釈するからどういう意味なのかわからかったが、
「俺の」と解釈しほうがいいと思った。
つまり任意のパラメータを「俺のもの」として保持しておけば、
外部から「こいつの(xxさんの)」として呼び出せるって訳だ。

999 ：デフォルトの名無しさん：2017/07/07(金) 19:32:27.33 ID:6QLBDLc9.net

なにがなんでも日常とか物理的現実に結びつけなくたってええんやで

1000 ：デフォルトの名無しさん：2017/07/07(金) 19:38:53.61 ID:SENaJwbT.net

>>992
カプセル化は最重要だよ
おまえは何もわかってない

わかろうともしていない

1001 ：2ch.net投稿限界：Over 1000 Thread

2ch.netからのレス数が1000に到達しました。