オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>848
ドアって開口部を制御するための具体的実装の一例にすぎんのだかw
抽象とは真逆の概念ですよ?オブジェクトハカセw >>851
だから、お前、オブジェクト指向を現実世界をシミュレートするために使うなって
それが間違ったオブジェクト指向の解釈なんだよ。
ドアを抽象化して考えろ。細かい枝葉は取り除け
抽象化
https://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E5%8C%96
> 抽象化(ちゅうしょうか、英: Abstraction、独: Abstraktion)とは、
> 思考における手法のひとつで、対象から注目すべき要素を重点的に抜き出して他は無視する方法である。
https://goo.gl/soXPyb
> ▼誤解されがちな、「抽象化」という言葉
> 結構な人々が抽象化を「曖昧にすること」とか思っていて、抽象絵画は「なんか曖昧な絵」みたく思っているので始末に負えない。
> まず「抽象(abstraction)」っていうのは、「物事の共通部分を抽出して把握すること」だ。
> 「対象物の特徴をつかみ、枝葉を切り捨てた本質をとらえる」思考力を抽象化思考力と呼びます。
> コンサルタントが「抽象度をあげろ」というときには、実は「抽象的にしろ」とは言っていません。「概念化して語れ」と言っているのです。 具体的実装(抽象化の逆)とか言ってるからこれも引用しておくべきだったw
> 抽象化とは、一般化(上位の概念に包括)することです。例えば亀→両生類→動物→生物という具合に、上位の分類の言葉に置き換えていくことです。 >>852
お前が抽象化できんかったからドアが残ったって言いたいんだろ?
知ってるってw
ハカセそれ抽象化ちゃうw細分化やw >>854
ドアが残ったってなんだ?
またお前が言い出した言葉を
俺が言ったことにしたいのか?
お前が言い出した言葉に対して、「知ってるってw」って
なに自分で自分にレスしてるんだ?
妄想も大概にしろ 「ドアが残った」 = それは細分化や
これも意味がわからん。
こいつバカなのか? >>855
端的に言ってお前支離滅裂だぞ
少なくとも今夜俺は
お前に抽象化のなんたるかを垣間見せてやったのだから
明日からもう少しまじめに勉強しろよ
まあ今夜は恥ずかしくて顔から火がでてるだろうから
多少の発狂は仕方ないけどなw > お前に抽象化のなんたるかを垣間見せてやったのだから
え? どれ?
具体的実装の話をすること?
それは抽象化の逆だけど? これ、自分のことを話してるのかな?
> 端的に言ってお前支離滅裂だぞ
ID:ZkAshefq が支離滅裂
> 少なくとも今夜俺は
> お前に抽象化のなんたるかを垣間見せてやったのだから
ID:ZkAshefq に俺が見せてやった
> 明日からもう少しまじめに勉強しろよ
ID:ZkAshefq が勉強しろ
> まあ今夜は恥ずかしくて顔から火がでてるだろうから
ID:ZkAshefq が恥ずかしくて顔から火が出てる
> 多少の発狂は仕方ないけどなw
ID:ZkAshefq が発狂している。
本当は自分のことなのに、それをごかます
幼稚なやつがやる手段だなぁ コイツは根本的に馬鹿なのか?
はたまた恥ずかしすぎてトボケてるだけなのか?
いまのところ前者が優勢ですけどねw >>857
俺が言いたいのはこれ(三度目のコピペ。二度目はID:ZkAshefq にもう一度書けと言われて書いたのに無視されたw)
それは現実世界のドアの話だろう?
ゲームの世界のドアは、現実世界を参考にできるが
ゲーム特有のドアという仕様を作る。
3Dゲームであれば、ドアには開く閉じるという状態は必要ないだろう
なぜなら物体をすり抜けられないという仕様と
蝶番を支点にドアを動かせるという仕様があればよいからだ
だけど2D RPGみたいなドアであれば、ドアの状態というものがあってもよい
開いているドアであれば、その上を移動することができ、
取っじているドアであれば、その上に移動することはできない。
このようにオブジェクト指向は現実世界の物シミュレートためのものじゃなくて
作りたい仕様を、みんなが持っている現実世界の共通認識を使って
わかりやすくする表現するための技術なんだよ
それにしても現実世界のドアについての人間の認識ってのも面白いよな。
ドアからすれば、物理的にはどういう位置にあるかでしかないのに、
人間は「開いている」「閉まっている」というドアの状態として認識しているわけだ
この認識、利用しない手はない! >>857
オブジェクト指向は抽象化して考えるためのものでもあって
どういう具体的実装であるかは置いといて、
「ドアが開いてる・開いてる」という状態で表現できるわけよ もはや完全に意地になってるなw
学習できない奴の特徴まんまw >>864
ごめん。もうお前にレスはしてないんだw 開口部ってなんですか?
ドアとどう関係があるんですか? おまえらがどう対立してるのかがわからん
オブジェクト志向には色々な側面があるんだし、その二つは別に対立せん気がするが 対立じゃなくてオブジェクト指向は現実世界のものをシミュレート
するものじゃないってことを言ってるだけだよ。
オブジェクト指向で現実世界のあれができないこれができないっていうのは
的外れだってこと
ま、そもそもオブジェクト指向で「ドア」を実装するにはどうすればいいだ?って
ドアというオブジェクトを持ってきてる時点で、
オブジェクト指向は人間の認識と相性が良いんだってわかるんだけどねw あ、違うID:ZkAshefqは俺にレスしてないのか
すまんやっぱり>>867はなしで
>>868
主張のまとまりがいまいち良くないけど、好意的に解釈する限り言ってることは間違ってないと思うよ どっちも主張がよーわからんが
ID:ZkAshefqを抽出したらびっくりするほどなんにも言ってなかった。
「ばーかばーかおれの勝ちィ!」しか書いてなくね?
なんでスレ進んでんの? https://ja.wikipedia.org/wiki/Simula
Simula 67 ではオブジェクト、 クラス、サブクラス、継承、動的束縛(仮想関数)、
コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。
Simula はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように Simula はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、Simula 当時「オブジェクト指向」という言葉はまだない。
この用語はアラン・ケイが Simula の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では Simula が世界最初のオブジェクト指向言語であり、
Simula は「オブジェクト指向として再認識が可能な最古の言語」ということができる。 >>870
> ID:ZkAshefqを抽出したらびっくりするほどなんにも言ってなかった。
だろ?w 志村 けんは、日本のコメディアン、お笑いタレント、司会者。ザ・ドリフターズのメンバー。
生年月日: 1950年2月20日 (67歳)
https://ja.wikipedia.org/wiki/Simula
志村(67) ではオブジェクト、 クラス、サブクラス、継承、動的束縛(仮想関数)、
コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。
志村 はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように 志村 はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、志村 当時「オブジェクト指向」という言葉はまだない。
この用語は 荒井・注 が 志村 の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では 志村 が世界最初のオブジェクト指向言語であり、
志村 は「オブジェクト指向として再認識が可能な最古の言語」ということができる。 >>871
シミュレーションをするための言語を作ると
オブジェクト指向になるってのは
やはりオブジェクト指向は現実世界の人間の認識と
相性がいいってことなんだろうね。 >>871
毎回思ってることだけど、アランケイのオブジェクト指向のポイントは
むしろメッセージセンドでオブジェクトに命令を送るという方式の発案なので
(さらにいうと、インスタンスを作るのにクラスそのものに「複製を作れ」と命令して作らせる
言語システム(予約語)から離れてクラスが自律的に動く思想の方)
Simulaはかなり毛色の違うオブジェクト指向だし
言ってしまうとこれがカンチガイされたままオブジェクト指向だと思われた結果
C++というそびえ立つクソの山が産まれて業界を何十年も混乱に陥れた元凶だから
Simula持ってきて「オブジェクト指向とは〜」ってやった瞬間
お話にならないぐらいオブジェクト指向を理解していないバカが来た。
で話が終わるんだけど。 そういやエージェント指向ってどうなんたんかな?
昔、15年ぐらい前に学生だった時に先生がこれからはエージェント指向だって言ってたんだが
その説明きいて、俺はそれってオブジェクト指向+メタデータじゃね?程度に思ってた。
オブジェクトが自律的に仕事をする。みたいな事を言ってたんだが、
それを実現するにはどんな要望であっても、それを実現するためのモジュールが存在し
その要望を完璧に判断してモジュールを選択できるAIでも搭載してなきゃできないような
ものだったのでエージェント指向でもなんでもないし実現は不可能と思っていたが。
まあエージェント指向とやらにはさっさと見切りをつけたので
俺が間違って理解してるんだと思うけどねw
でも事実としてオブジェクト指向を置き換えるものにはならなかったようだね。 >>875
シミュレーションをするために言語を作ったけど、
本来の用途としてはあまり使われず、(よくよく考えてみれば
シミュレーションなんてそんなにするか?ってことなんだろう)
副産物として生まれてオブジェクト指向の技術の基礎とでも
呼べるようなものが独立しそれが洗練されてオブジェクト指向言語
として生まれ変わったってことなんかね。
UMLも似たようなもんだよね。元々はオブジェクト指向分析や設計の方法を
色んな人が考えていたけど、それぞれを比較検討する時、それぞれで図の書き方が
異なっていたので、分析や設計方法が色々あるのはわかる。だけどせめて図の書き方
ぐらいは統一しようじゃないかって生まれたもの。
でもオブジェクト指向の分析や設計方法はみんな飽きてしまったのか話題にならなくなり
UMLという図の書き方だけが広まったと。 歴史的な起源に拘らない人と、
「もともとはこうだったのに変質してしまった。クソが!」と思う人がいるのだなあ。
と感じました、まる 歴史的な起源に拘らないとsmalltalkerなんてやってられないよ ストラウストラップとケイの“オブジェクト指向”は別物なので混同せずちゃんと区別したほうがよい
ストラウストラップの“オブジェクト指向”はSimulaスタイルのクラスを抽象データ型(ADT)とみなして使うアイデア
抽象データ型の提唱者のリスコフ、Simulaの設計者たち(ダールとニガート)はもちろん、メイヤーも同様のアイデア同時期に提示している
抽象データ型というのは簡単にいうと「ユーザー定義型」のことで言語組み込みの具象データ型に対してこう呼ばれる
OOPの古典的三点セット「カプセル化・継承・ポリモーフィズム」に象徴されていて
カプセル化は抽象データ型の要件、継承とポリモーフィズムはクラスを使う際のオマケの機能を表わしている
ただ、早々にクックらにより継承を使ってサブタイプを表現することには問題が生じうることが指摘されていて
また動的型のダックタイピングのような自由度を得るためにインターフェース(プロトコルなど別の呼び名も)が考案され
現在はそれが汎用されている
一方、ケイの“オブジェクト指向”はSimulaのオブジェクトにメッセージの受け手を担当させるアイデア
メッセージングはあくまで方便で狙いはその先の設計・実装・運用等、あらゆる局面での「遅延結合の徹底」
遅延結合というと実装のみに固執してしまう人がいるから「決定の遅延」といった方がよいかも
Smalltalk-72はこのアイデアを元に、クラスはJSのクラスのような関数っぽい性質で実現された
このときはメソッドも関数というよりLISP等のリーダーマクロのようなメッセージとなるトークンストリームを順次処理する手順が記述された
次の世代のSmalltalk-76からはSimulaスタイルのクラスが取り込まれ、メソッドも単なる関数になり
前者のオブジェクト指向もそれなりに意識されるようになったので同じSmalltalkでも
Smalltalk-72は純粋なメッセージングのOOPL、Smalltalk-76以降はADPとメッセージングのキメラと考えた方がよいので
もしケイのメッセージングのOOPの考え方に興味があるならPharoやSqueakのような最新のSmalltalkではなく
エミュレーター等で提供されているSmalltalk-72をやるほうがいい
https://ubiteku.oinker.me/2016/05/09/what-is-oo-all-about/#comment-65
ちなみにアクター理論はこのアイデアを実行時の並行性に応用し定式化を試みたもの 決定の遅延とは即ち実行時に決定するということ
つまりデータと処理の抽象化を徹底するということだ データの抽象化を徹底すると型とクラスが無くなる
型によってデータ長も処理の方法も変わるのが煩雑さの根源だ もともと、コンピュータが巨大にそしてネットワークで接続されると
離れたユニットに「この処理をお願いします」と頼むことになって
シーケンシャルな処理待ちしていたらコンピュータが止まっちゃうし
周りの環境も実行時に刻々と変化してゆくから
オブジェクトにはある種の他と切り離された自律性がいるよね。なのに
なぜか21世紀のインターネット時代に「いいや!カッチリ制御して
他に影響が出ないように書ければこの『世界が勝手に変化するバグ』は排除できるはずだ!」
という謎のカルトが一部で流行り出してるのがどうにもよくわからないw 歴史的にオブジェクト指向の後にテンプレートとかジェネリックとか言われるのが導入されたけど、継承とかより移譲が重宝されてる辺り、ジェネリックだけで十分じゃね?って気がしなくも無い。 C++以外にテンプレートがある言語ってあるの?
C++のテンプレートは本来ジェネリック程度の機能で良かったのに
ちょっと道を外したら、意外と高度なことができることが分かっちゃって
本来の目的から大きくはずれてコンパイル時コードジェネレータみたいな
もんになっちゃったでしょ? そもそも継承なんてものの80%はゴミ
protcolとdelegateこそが至高 Haskellでガンガンよく使う処理を個人ライブラリ化なう。
Myfunc.hs
1:module Myfunc where
2:
3:import Data.List
4:import Text.Printf
5:
6:consnum::(Int,String) -> String
7:consnum (i,xs) = printf "%4d:%s" i xs
8:
9:fline f = unlines.f.lines
10:
11:fnumbering f = fline ((map consnum).(zip [1..]).f)
12:
13:numbering = fnumbering id
14:
15:revnumbering = fnumbering reverse
16:
17:allrevnumbering = fnumbering (reverse.map reverse)
18:
19:searchword w = fline (filter (isInfixOf w))
20:
21:putfc (f,c) = printf "%s\n%s" f c
22:
23:mulfileput fs f = mapM readFile fs >>=
24: return.(zip fs).map f >>=
25: mapM_ putfc number.hs
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \fs -> mulfileput fs numbering
6:
revnumber.hs
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \fs -> mulfileput fs revnumbering
6:
searchword.hs
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \(w:fs) -> mulfileput fs ((searchword w).numbering)
6: ん。
だってオブジェクト指向言語使ってた時って、ここまで似たようなコード書かなくて良いくらいライブラリ化出来たことなかったんだもん。 PythonやRubyのopenと大差ないと思うが。。。
嫌ならもっと低レベルの関数もあるよ? 型クラスの仕組みが姑息
LISPのSETFと同じくらいガッカリ感ある 猫ドアは後出しでドアの要件増やされるけどインターフェイスで振る舞いを追加してけば対応可能じゃないの
オブジェクト指向言語的に考えたら >>898
それはインタフェース自体を増やすと言ってるように聞こえるけど? >>898は新規インターフェイスの追加じゃなくて既存のインターフェイスへ機能追加だろ new ってなんなのか、なぜ必要なのか教えて、
オブジェクト生成元クラスのコンストラクタ関数の結果を得るだけなら、
Foo obj = Foo();
とすれば new なくても書けるのに、なぜ new を書く必要があるの? newがあるから僕らはそれがコンストラクタを呼ぶものだと知ることができる
newがなければ何をすれば良いのかわからない
コンパイラの気持ちになって考えろよ C++の例
Base *base_pointer = new Base();
Base base(); pikeという言語は、newをつかわない
bird tweety = bird("Tweety", 0.13);
tweety->eat("corn");
tweety->fly();
tweety->max_altitude = 180.0;
fish b = fish("Bubbles", 1.13);
b->eat("fish food");
b->swim();
animal w = fish("Willy", 4000.0);
w->eat("tourists");
w->swim();
Inheritance | Object-Oriented Programming | Beginner’s Tutorial - Pike Programming Language
https://pike.lysator.liu.se/docs/tut/oop/inheritance.md >>902
コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
人にわかりやすいようにしてあるだけ
なにがコンパイラの気持ちだアホ パラメーターがないとややこしいからある場合で考えると
(new Foo)(p1,p2,p3) ととらえるか、new (Foo(p1,p2,p3)) と捉えるかの感覚の違いじゃない?
前者なら宣言的に「新しくFooのインスタンスを作って(初期化パラメーター渡して)るんだな」感が出てnewはあったほうがいいし、
後者なら「新しいFooのインスタンスを作る関数のFoo()を呼んでるのにnewなんて余計やろ?」ってなる
従ってコンストラクタとしてFooを定義する言語や、クラスがそもそも関数的な存在の言語ならnewは蛇足 >>902
コンパイラとしては無いと困るもんでもない
newのあるなしで挙動は変えられるけど >>908
> コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
class Foo { }
function Foo() { } class Foo { }
function Foo() { }
が両立する言語の場合、
a = new Foo(); // Fooクラスのコンストラクタ
b = Foo(); // 関数Fooの呼び出し
を区別する必要があるから、newが必要 >>913
それをnew無しにもできるでしょ。クラスと関数で区別つくんだし Activator.CreateInstance()とかは? >>914
newなしだったら、
a = Foo();
b = Foo();
なんですが・・・ new を付けなかったら、インスタンスが作られないから、
this が正しく、インスタンスを指さない
JavaScript だと、prototype 継承が動作しない JavaScriptができた当時の仕様だと、
インスタンスを作る方法はnewしかないでしょ? まぁ言ってる意味は分からんでもないんだよな
コンパイラはFooがクラスか関数か、何なのか知ってるから
区別できるよねっていう
ただし意味解析をしなければFooが何なのか分からない
newがあれば構文解析だけで何をしようとしているかわかる
Fooが何かのか解析するまでもなく、字面の並びだけで関数呼び出しなのか
インスタンスの生成なのかの区別がつく
いざコンパイラを作るとなったらこの差はでかい
あとなんつーか、そういうこと言い出したら
(int i = 0; i < 100; ++i ) なんていう並びの書き方はfor文の時にしか使わないんだから
「for」って要らなくね?とか、goto ERR;って書くけど、ERRがラベルであることは
コンパイラは知っているんだから「goto」って要らなくね?とか Foo()というメソッドが定義されてなければnewなしだとコンパイルエラーになるんじゃないの... コンパイラはソフトウェアにとって重要なものであるので
ちゃんと専門の学問があってセオリーがある
必ずしもセオリー通りにする必要はないが、いちおうセオリーがある
セオリーに従えばコンパイラは
字句解析→構文解析→意味解析、というステップを踏んで
プログラムを解析することになっている
ここで、Fooがクラスであるか関数であるかによって
インスタンス生成か関数呼び出しか、切り替えるという文法にしてしまうと
意味解析をしなければ構文解析ができない、という逆流現象が発生してしまう
また、コンパイラ生成器にBNFか何かを食わして自動で構文解析のコードを生成してもらうと
思っても、意味解析をしなければ構文が判明しない箇所のある文法では都合が悪いじゃろ
ただし、セオリーはセオリーでしかなく、従わないことも多々ある
たとえばC++の字句解析において、これは最長一致であるので
「>>」は右シフトと判断されそうなものであるが
出現場所によっては「>」と「>」の二つに分解される
これは字句解析がその後の工程であるはずの構文解析を先回りして少しだけ
してしまっている状態 >>922
> コンパイラはFooがクラスか関数か、何なのか知ってるから
> 区別できるよねっていう
知らないぞ?っていうかJavaScriptにおいて
クラスは関数と全く同じもの。 なんかニワカが長文書いているようだが、
JavaScriptにclassキーワードが追加されたのは比較的最近。
互換性を保つ上で、classキーワードは関数に変換される。
また
function Klass と書けばクラス
function func と書けば関数
というふうに先頭が大文字か小文字かで区別する
というのはあるがこれは慣習であって言語仕様ではない。 JavaScriptの話などしていないから関係ない
なぜなら元の>>901の質問者のコードはどう見てもJavaだから
>>919あたりで何故か脱線したようだけど、これは全くのノイズであるから関係がない オブジェクトが請け負う役割の範囲が未だよく分からん。
例えば、武器を装備するという行為は、
オブジェクト自身に機能を持たせるのか、
actorを第一引数とする処理を別に作るのか。
対象を省略できるからオブジェクトに実装したりするけど、コンテキストの依存性などの問題でゲームマスター的なクラスに処理を任せるべきだなと思ったり。 「武器を装備しろ」と命令したらあとは当該クラスがよしなにやって
こっちには結果教えてくれればいいだけなので
その「役割の範囲」そのものが当該クラス任せです。
クラスが自分でやっても、武器総合管理クラスに聞いてても
上位は感知しないことで切り離してるので。 equip(soldier, weapon)
soldier.equip(weapon) オブジェクト試行の「オブジェクト」っていうネーミングって
誤解を招かないか、
どっちかというと「モノ」じゃなくて仮想的な「生命体」じゃない?
だって動きを持ってるし、誕生して活動して死ぬわけじゃん。
「モノ」なのはコンストラクタやメソッドでやり取りされる「引数」
の方だろ。
「プロパティ」は「生命体の所有物」だと思えばスッキリする。
なのに生命体の方をオブジェクトと言うのはおかしいよ。
クラスはその生命体の「家系」みたいなもんだな。
両親がいる必要がないから単細胞生物の分裂のほうが近いか、
クラスは「遺伝子情報」だな、これでかなりスッキリするじゃないか。 つまり美少女の母親もまた処女懐胎した美少女なわけだな まだいたの?
オブジェクトを無理やり現実に当てはめるやつ >>937
新鮮な意見だな。
コードと現実は違うって概念のカテゴリー分けに使われてるだけだと思った。 じゃああなた方はバイナリの0と1をCPUの信号レベルで
全部機械的に把握できるんだな?すげえなぁ、さすが
コンピュータの熟練技術者は違うね。
言語化してるんだから抽象的思考は重要に決まってんだろ。 抽象化ってなんだっけ?
どこら辺が抽象化してるの? 「1+1ってなに?りんごは?りんごはどうなっちゃうの!?」 少しずつまともに美少女うんこ問題を議論できる土台が出来てきたようだな レス数が950を超えています。1000を超えると書き込みができなくなります。