オブジェクト指向の「クラス」ってなんなの？
■ このスレッドは過去ログ倉庫に格納されています
インタビューア（以下「I」）： あなたがソフトウェアデザインの世界を一変させてから何年にもなる。振り返ってみて、感想は。
Stroustrup（以下「S」）： 実はあなたがここへ来る直前、当時のことを思い出していたんだ。
おぼえているかな。
誰もが C 言語を使っていたけど、問題はみんな結構うまくコーディングしていたことだった。
大学も C 言語を教えるのがうまくなっていたしね。驚
異的な割合で有能な――「有能」という言葉は強調しておきたい――卒業生を量産していた。
それが問題の原因だったんだ。
I： 問題？
S： そう、問題だったんだ。誰もが COBOL を使っていた頃のことはおぼえてる？
I： もちろん。僕もそうだった。
S： はじめの頃、COBOL ができる人間は神のような存在だった。給料も高かったし、王侯貴族のような扱いだった。
I： いい時代だったなあ。
S： うん。で、どうなった？ 嫌気がさした IBM が何百万ドルもつぎ込んでプログラマを養成したものだから、COBOL プログラマは「一盛り十円」になってしまった。
I： だから僕は辞めたんだ。たった1年の間に給料が急落して、とうとうジャーナリストの方が給料がよくなったんだ。
S： そのとおりだ。で、当時は C プログラマにも同じことが起こっていたんだ。
I： なるほど。でも、要するに何が言いたいのかな。
S： ある日、オフィスにいたときに、ある策略を思いついたんだ。バランスを少し回復させる策略をね。
「プログラマが余るなんてことが絶対にありえないくらい、複雑でおぼえにくい言語があったらどうなるかな」ってね。
実は、この考えの一部は X10――例の X Window の――から頂いたんだ。
あれはひどいグラフィックシステムでね、Sun 3/60とかでないと動かなかった。
ばかばかしいくらい複雑な構文規則とか、わかりにくい関数とか、疑似オブジェクト指向的な構造とか、僕がほしいと思う要素は全部揃っていたんだよね。
今でさえ、生の X Window コードを書く人間なんていない。
正気を保つには Motif を使うしかないんだ。
https://monobook.org/wiki/Bjarne_Stroustrup_%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%93%E3%83%A5%E3%83%BC クラスってのは俺やお前が馴染めなかった場所のことだよ EXCELマクロしか組めんけどクラスの説明してるページがアホみたいに少なくてちょっと覚えるのに苦労した
普通のがロボット作るような物ならクラスは量産型ロボットの設計図みたいなもんだと覚えた
VBA以外は知らん 構造体が分からないと、どうして変数と関数をまとめる必要があるのか、面倒じゃん。ってなるわな クラスとかインスタンスとか
車とか設計図とかの例えはわかるが
結局プログラム上では何かわからない 中国共産党の中国人と電通で繋がってんのけ
なんか必死にいまごろ20年まえの話題してるが EXCELVBAでも、クラス定義したら '.'を入力すると同時にメンバー一覧を表示してくれるから非常に楽
オブジェクト指向に興味なくても、そのためにクラス作るだけで元が取れる気がする 抽象化した入れ物のことだよ
インスタンスは、クラスを具体化したもの ドレッドノート級(クラス)って言うだろ
戦艦クラスを継承したのがドレッドノートクラス
空母クラスと重巡洋艦クラスを多重継承したのがアドミラルクズネツホフクラス
そゆこと
自由度が高いからな
データを保存するだけのクラスもあるし、そのデータを操作するためのＬｏｇｉｃが書かれたクラスもある
Ｖｉｅｗへの参照を保持するクラスもあれば、そのＶｉｅｗに値を渡す方法としてＭＶＣやらＭＶＰやらが存在する。
Ｃｏｎｔｒｏｌｌｅｒはあくまでデータクラスを操作するためのもので、ＰｒｅｓｅｎｔｅｒはロジックとＶｉｅｗを管理する。
このPresenterをViewを担当するxmlに直接操作させるようにしたものがＭＶＶＭ
そしてＭｏｄｅｌとＶｉｅｗのこの危うい順序の関係をＭｏｄｅｌからＶｉｅｗへとしたのがFLUX
これらすべてクラス
インターフェースは何かオーバライドするためのもの程度の認識のやつは触らないで
グループで規則作ってプログラミングする際に
適切に運用できればまあ便利なのかなって感じ クラスはデータとメソッドを１つにまとめたもの
クラス：たい焼き器
インスタンス：たい焼き
オブジェクト：たい焼きor設計工程ではたい焼き器 反日で、日本への恩を仇で返すのが
朝鮮半島を脱出して日本に密入国して来た
不可触民の白丁
白丁 https://ja.wikipedia.org/wiki/%E7%99%BD%E4%B8%81 僕らのクラスのリーダーは
ミッ○ーマウス、ミッキー○ウス、ミッ○ー、ミッ○ー、○ウス(´･ω･｀) 理解が曖昧だわ
オブジェクトの種類がクラスで、変数に対しての型定義みたいなもんだっけ >>41
で上の例のニミッツクラスのインスタンスがコンストラクト時にshipnameジョージワシントンとか入れてジョージワシントンになるわけ
新規ならトップダウン設計でいいが、
既存の物をモデリングするなら
タマとミケが似てるから猫クラス作って
猫クラスと虎クラスの共通点多いから猫科アブストラクトクラス作るとかな 猫クラスはオスとメスあるの？
交尾すると子どもはできるの？ プログラミングなんて、そのうちAIがやってくれるようになるよ
今、どんどん自動化が進んでるしね >>59
みんなAIもてはやすけどさ、あれって商売にならないんだよね。
期待した機能が実現できるかどうかすら誰も保証が出来ない代物だからなぁ 指示待ち人間
指示されたら指示された通りに動く
自主的にやろうとしないのでいちいち指示しないといけない >>1にC++のプログラマーは時給70ドルって書いてあるけど今はどうなの？ 凡人向けになんらかのメタファが必要なだけ
バリバリアセンブラで書き始める人間には不要な概念 >>54
class Cat {
public enum Sex {
male,
female,
tamanuki,
hininzumi
};
} >>67
段取りも方針作成も出来ずに丸投げする奴の多いことよ Pythonを初めてできそうな気がしたときに、やっぱり自分には向いていないと気づかせてくれる仕組み >>5
こういう言い方されて初めてわかったよ。そこまで猫の鳴き声がどうの色がどうのって説明は全く無駄。 >>3
>>22
設計図と言えばそうなんだけど、企画や営業、技術でこれからどういうものを作るかを検討するのに分かりやすい
というかそのままプログラムに落としていきやすい
デザインシンキングなんかでいろんな要素を付箋で貼ったりするけど
あの付箋がクラスになると考えると近いかも
そうすると実装されるプログラムの動きと要求が一致しやすい 事務職員にとっての
エクセルの雛形ワークシートみたいなもんだよ 最近はintとかもクラスになってるからな
大昔のビット構造前提でバイナリ演算やったら悲惨なことになる >>70
性別になんで生殖器の処置まで入れてんだ？
それは性別と関係ないだろ。 グルーピングでもあるんだよな。
親クラス、子クラスでいろいろと便利。
画面遷移とか同じ1行で勝手に振り分け出来るし。
まあ関数をポインタで呼び出してるようなもんだけど。 セイバー
アーチャー
ランサー
ライダー
キャスター
アサシン
バーサーカー >>45
これ有名なJavaの本に出てくる例えだけどさ
これでクラスを理解してプログラミングに繋げるとか無理あるわ
ある程度分かってきたら糞本だっていうのがわかる まず、UMLで設計しようよ
オマエら、即コーディングしてないか？ >>14
クラスは外部仕様
インスタンスはその仕様を実現する
色んな奴らのうちの1人
だから全くの別物
インターフェイスクラスやら
純粋仮想関数なんてのもあるだろ 文字通り「分類」だよ
クラスってのは変数と関数の集まりだろ
変数はデータで関数は処理だ
「何らかのルールによってシステムに必要なデータと処理を分類したもの」
オブジェクト指向とは、モジュール分割の手法だ RPGで言うところのジョブって考えれば分かりやすい クラスはポケットモンスター
インスタンスはピカチュウ
クラスはヒト
インスタンスはイッチ
クラスは犬
インスタンスはガイジーヌ >>1
X-Windowプログラミング専門学校でやったなぁ
それまでX68kしか触ったことなかったからイベントドリブンの考え方がよく分からなかった Cの良いところはコンパイルされた後の命令をはっきり意識しながら書ける所
オブジェクト指向の奴ってメモリ上にどうオブジェクトが展開されてるかって分かりにくいよね OOP＝複雑な改造に耐え切れないモノ
不具合が出たときに、同じ名前の関数が山ほどあるから、
どこが動いてるのかわからない。 Go「継承なんて飾りです。偉い人にはそれが分からんのですよ」 X Windowとか Motif とかいつの時代の話しだよw えー？クラスっていったら実現するその結果を導くための雛形だろ
お手本
言語開発チームがこれが全体通して割とコストパフォーマンスが優れてるよーって公開してくれてる雛形 結局コピペした方が簡潔で100倍速かったという試行産物 ITドカタのみなさん
もっとマシなソフトを作ってね クラスはDNAみたいなもんだ
インスタンスがRNAな
細胞が小さなオブジェクトでメッセージを送りあって出来るのがヒトってわけ >>113
ドカタに期待しすぎだろ
名は体を表すんだよ >>43
偉そうに書いても全角英字使ってる時点でプログラマとは思えん 末端の開発会社は思ってる結果をだすのに1番合いそうなのをピックアップして成型していく
継ぎ接ぎだらけになるからなだらかになるようにバリという矛盾をとっていって、一般向けに粗方でいいのか、芸術的に鑑賞にたえるものにまで仕上げるのかの差 オブジェクト指向てオジさんの青春って感じでキモい
関数型のパラダイムに乗り遅れちゃったみたいな 関数をぶち込める構造体だよなそれ以上でもそれ以下でもなく なんでクラス使うの？
構造体と関数別々でもいいじゃん クラスも自分で書いたステップと言って実績に含めてたら出来る男と勘違いされた >>124
現代では別々のほうがメンテナンス性高いとわかってきてるんや
ステートをクラス内に持つオブジェクト指向開発はスパゲッティの素でゴミな >>124
C言語エアプか？
関数名がバカ長くなるだろ 複数の多次元配列を使い勝手良くするために作られた手法？
ぶっちゃけわからん だれにも正解を断言できない奇妙な世界
（確からしい）で動いていくしかない 車だのたい焼きだのワケわからん
誰か、かいけつゾロリで例えてくれ >>32
いまVBA勉強してるのになんて意味かさっぱり分からない(´･ω･`) >>132
継承は現場では全く使わんので気にしなくていいぞ
仕様変更入ったら破綻するだけのゴミ あんまり難しく考えんでもclassは人間、instanceはお前らと考えればいいんじゃね クラスってさ、要は関連する処理をまとめたものでしよ？
文字を受けとる
文字を格納(変数)
文字を出力
文字を削除
みたいな？ X Window懐かしい
確かに糞ライブラリだった 昔読んだオブジェクト指向入門って本には、クラスには、
・モジュールとしての側面
・データ型としての側面
があると書いてあったな。
モジュールを知っていれば、これ以上の説明は無いわ。
変な例え話が書いてある本は捨てろ。 今のプログラミングってGOFとかあんの？いわゆるデザインパターン的な スーパープログラマがちゃんと設計した全体として一貫性のあるクラスライブラリ群は有用だと思う。
IT土方がその場の思い付きで作りまくったクラスの山はゴミ同然。 継承も分からん。
普通に、関数とか、サブルーチンとかで良いじゃん、と思うのだけどな。 >>14
クラスはそのままでは動かない。ひな形だから。
インスタンスやオブジェクトは指示を与えれば動く。 >>15
それがいくつも並べてあったり階層化していて、さらに実行するコードも含めてあるのがクラス。 >>147
しかもそのゴミに似た様なクラスが複数の無能によって大量生産されるのなw >>20
Railsの人が来たらもう何言ってるかわからないと思う。 >>32
me.って打てばモジュール内の関数は出てきたような。
モジュール名.でも出た気がする。
インテリセンスのためにクラス定義するのは時間の無駄よ。 >>28
使うだけならクラスからオブジェクトを生成(new)して、それにパラメータを渡せば動いてくれる。
使い方さえ覚えればクラスの中身は見なくていいので手抜きができる。 >>43
そういうのは頑張って覚えてコード書いてもすぐ流行が変わって使わなくなる。
数年経ってから見直すと、自分でも「何やってんだw」と思うようになる。
複雑過ぎるのは結局誰も保守できなくなるから、いずれ他のものに差し替えられる。
せいぜい基本がわかってればいい。 >>6
結局の所、ほとんどのことは
理解しようとするよりも
実際に使いながら、
ああ、そうかと思えて腑に落ちる体験が
必要なのだと思う。 >>45
こういう説明は、オブジェクト指向の意味がちゃんとわかった人が読めば理解できるが、
初心者が読んでも役に立たない。誤解されるだけになる、ということが後になってわかる。 ナマポ、金持ち、共産主義者、自民党を数値化するための階層表現、それがクラスだ。 >>101
トレースすればわかるけど、面倒くさいのはその通り。 >>108
後からそれに手を入れる人の身になってくれよ。コピペした数だけ同じ修正入れなきゃいけないんだよ。
修正の手間が100倍になるんだよ。残業代払えよ。 ざっくり
class≠typedef
インスタンス≠変数宣言、malockで確保したアドレスのポインタ
で良いんじゃね
実行に必要なメモリが確保されてるかされてないかだよ
※staticは除く >>124
別々でも同じことはできるんだけど、ある構造体をどの関数が使ってるか正確に把握してないとバグの原因になる。
1つの構造体を複数の関数が使っていたとして、どれかの関数が構造体の仕様を少し変更したいと思っても
変更すると他の関数が正常に動かなくなる可能性があるから手直しに神経を使う。
逆に、必ず1つの構造体に1つの関数しかアクセスしないのなら1つにまとめた方が保守しやすい。
1つのクラス内に両方書いてあるからわかりやすいわけだ。
クラスの外からはその構造体にアクセスできなくしてしまえば余計なことを考えなくて済む。
つまりバグが出にくくなるということになる。 >>143
GOFを理解して使うならその方がいいが、GOFを知らない仲間がいると話が合わなくなりやすい。
「なんでここはこう書いてる？」と聞かれて、「○○パターンだから」の一言で話が通じない。
いちいち解説しないといけなくなる。 >>45
この説明ですんなりイメージできた俺は少数派らしいw クラス = 料理の手順と必要な材料を書いた紙
フィールド = 材料の分類と名前
プロパティ = 材料を下拵えする調理器具
メソッド = 調理の詳細な手順
インスタンス = このレシピに必要なものを実際に用意したキッチン
キッチン = new レシピ( 材料 )
キッチン.切る()
キッチン.炒める()
料理 = キッチン.配膳()
こんな風に俺は考えてる クラスで何ができるかわかってれば
クラスが何か知る必要はない インスタンスって何？
NSZombie 使ってるとこ見てみたい >>174
>キッチン = new レシピ( 材料 )
なんでインスタンス化したら変わるの？
キッチン = new キッチン（new レシピ（材料））
とかじゃないもんなん？ 人間クラスから派生クラスとして朝鮮人クラスを定義したら先輩にしこたま怒られました
なんで？ >>174
なんでキッチンが切ったり炒めたりするの？
それは料理人のメソッドじゃないの？ >>174
こういうのが混じるからな。
末端は賢い人が作ったクラスライブラリだけ使っとけばいいと思うよ。 保守しやすさとチーム開発のしやすさじゃないですかね >>108
せめて関数にしろよバカたれ！
お前の知能じゃクラスが分からないならな そんなことよりもインスタンスを分かりやすく教えてくれ >>196
犬で言えば
クラスはチワワって犬種
インスタンスは実際に飼ってるチワワ クラスとはあるオブジェクトの群に共通した特性です
オブジェクトとは、何か内と外の境界で区切られ、外とのやり取りが決まっている物です
そもそもオブジェクト指向でクラスは同じような特性を持つものを一括して扱う手段に過ぎず
大事なのはオブジェクト。
問題を切り分けて解決方法を構築する方法として如何にしてオブジェクトに分割するかこそが大事
クラスとは、オブジェクト指向で楽をする枝葉末端の手段の一つに過ぎない いわゆる開発できないSEなんだが、感覚的には大体理解してるけど
うまく言語化できないわ C言語のメモリ管理バグを減らすために考案されたんで
Cのメモリ管理の難しさを知ってないと何がすごいの？としか思わん
オブジェクト指向な作りはCでもできた 適度にカプセル化・ブラックボックス化できれば手法は何でもいいよ
マイクロサービスに分割してAPIで疎結合にするのも大きい単位でのカプセル化・ブラックボックス化 >>196
モデルを実体化したもの。
戦車を破壊するゲームでは、
戦車クラスが設計図で、戦車1、戦車2、戦車3・・・みたいに戦車の実体(インスタンス)作って敵の戦車がうじゃうじゃ出来る感じ。 >>119
許してやれ
教えてやりたい病気の人もいるんだからな。 Rubyのリファレンスとか見ると用意されてる既存のクラスが便利なので楽できる 「オブジェクト指向」のことを論じても分からなくなるだけ。
「オブジェクト指向プログラミング」か「オブジェクト指向設計」か切り分けて考えるべし。 >>205
？
newとdeleteのこと？
オープンソースなんてほぼほぼCだしC++をCに書き直してるものさえある。
使いどころだよね 人格的に立派な人、立ち居振る舞いが洗練されてる人をhe is a class. he is classy. って言うね クラスとインスタンスはなんとなくわかるんだがオブジェクトがよくわからん >>217
クラス＝たい焼きの型
インスタンス＝たい焼き
オブジェクト＝何らかの焼きモノ classはいいけどabstractとかinterfaceとか持ち出して意地悪するのはやめてほしい わりかし理解してる人間に解りやすく説明してもらったら、クラスの説明が始まったと思ったらinterfaceありきで進んで、急に移譲と継承が出てきた
市販本読んだら似たような感じで焦った
C組み込み系の人間にはオブジェクト指向は使いこなせない。結局Cライクに記述してしまう。 >>205
今はC/C++にもGCライブラリあるよ >>156
VBA(VB6)のクラスは継承ができない。
モジュールとの違いはインスタンス化しないと実行できないから一応メモリの節約にはなる。
モジュールはstaticクラスみたいなもんだな。 オブジェクト指向なんて別に無理して理解する必要ない。
もう古いし。 オブジェクト指向も理解出来ない奴は何をやっても駄目！ >>226
20年古い
フレームワークでサクサク作れればそれで良い コード再利用を考えてるならオブジェクト指向で作っといたほうが後で楽ってくらい プログラムのことを難しく言っただけでしょ。所詮コードだし そのへんが分かったつもりでJavascriptで書こうとするとドヒャーとなる
話は変わるが、いわゆる『大手SI』のパッケージ(Java)でマルチスレッドの概念がない
クソコードで性能が出ない（システム全体で1スレッドしか動いてないんだから
何億のサーバを客に買わせようが性能が出ない）出ないと騒いでいた
これが2005年ごろの話
「Javaにはマルチスレッド機能があるんだから多重度を上げればいい」と誰かバカが言い出し
（多重度とは本来MVSなどIBMのメインフレームで同時に実行するジョブ数を意味する）、
やってみたところスレッドセーフティなど知るはずのない「アーキテクト」が作った
「コーディング規約」に基づいて全体が書かれていたもんだから異常処理の嵐
そこでバカなPMがこの問題に「static問題」というレッテルを貼った
これが2010年頃
この名前がどこから来たのか大多数には分かるだろうが、クラスメソッド (クラス宣言の中でstaticで定義する) を使うと
複数インスタンスを作ったときの挙動が分離されないことによる
The Gang of Fourが"Design Patterns"でシングルトンパターンを提示したのが1994年
それから15年経っても日本の大手SIにはその内容が伝わってもいないどころか
本質的な機能が「問題」呼ばわりされている
そのパッケージは現在も基本的に同じ仕組み、つまりド素人の思いつき設計で動いている
デザインパターンの影響を受けた何らの形跡も見られない
日本中の多くの自治体はこんなものを高いハードと抱合せで買わされて税金をドブに捨てている
人口30万の市だったらたぶんセットで10億ぐらい
これを5年で買い換える >>229
それもなぁ
大半のシステム開発なんてまず１点物だし
再利用なんかまずしないから
フレームワーク開発してる連中にまかせてりゃいい話じゃね >>215
C++では当たり前のように一体化されてるけど
Cだとコンストラクタとデストラクタが自動で実行されない
末端のコーダーが忘れずに呼び出す必要があった
漏れが１箇所でもあれば破綻する 最近、継承が悪者扱いされすぎてて辛い
そりゃ、has-a的な関係では使うべきじゃないだろうけどさ
どうでもいいが、うんこしないアイドルは人間クラスではないと思う >>205, >>237
しったか乙
ライブラリのstdやboostのsmartポインターがだいぶ後に実装されるまでは、
C++だってポインタの管理は大変だったんだぜ？ 人間に例えると二重らせん構造を織り成すDNAかな。
それは神(俺)が定めた運命でありクラス(聖典)なのだよ。 >>1
>正気を保つには Motif を使うしかないんだ。
俺直接使ってネットワーク越しにチャットと画面共有するシステム作って使ってたぞ1995年頃だったかな オブジェクト指向でなぜつくるのか
を今日買いに行くぜ。 業務処理ではオブジェクト指向で作る必要性なんてまずないし >>221
いやいや、そもそもモジュール分割をちゃんとしましょう、というところから生まれたのがオブジェクト指向だぞ
Cでもオブジェクト指向ライクにかける
ハードウェアの設計でもオブジェクト指向は適用できる
「オブジェクト指向言語の機能を使うこと」は
「オブジェクト指向設計」と等しくは無いんだよ
オブジェクト指向言語が産まれる前から、オブジェクト指向設計の概念はあったんだ
そうじゃないとオブジェクト指向言語なんて産まれないはずだろ 真のオブジェクト指向はプロトタイプベース。
クラスなど無用の長物。 GOTOでそこら中に飛び回って制御が追いにくい → 構造化プログラミング
データとロジックが別々に管理されているので追いにくい → オブジェクト指向 Xwindow(widget)とMotifで組んでたよ
確かにあの頃は単価が高かった
今は楽だなUIだけじゃ食えない そもそもオブジェクト指向ってどういうプログラミングなの？
wiki見てもチンプンカンプンだしだれかサルでもわかるように説明してくれよ >>250
データと処理を、システム化対象領域の物事=オブジェクトの単位でまとめてモジュール化する、という設計手法 プログラマがやりがちなのは、
「処理が似てるから」
「データが似てるから」
という理由で共通化してしまう
その似ている理由が、システム化対象領域において本質的なものであるならいいんだが、
そうでなく、たまたま似てるだけかもしれない
似てる事に本質的な理由があるのであれば共通化しても構わない
でもそうでなく、たまたま似てるだけなら、そのような共通化はシステムに「必要のない複雑性、依存性」を導入する行為かもしれない
例外的で、その場しのぎで行き当たりばったりな仕様が混入してしまう事を避けようとしてるんだよ 役割単位にクラスを作り、各クラスは外部との関連性を極力排除して独立性を高める作り方。
例えるなら、プログラムを電子ブック的に部品として使う手法の一つ。
メリットとしては、一度作成したブロックは他のシステムでもそのまま組み入れて使えるから、やればやるほど使えるブロックが増えて後のお仕事が楽になって行く。
デメリットとしては、その場しのぎで関連性を排除し切れて無いと意味が無いから作るのにそれなりの手数が掛かる。 日本はカスタム業務システムが多くてクラス化のメリットあんまなくね？ >>256
業務システムで使うのは、データベース設計の時だと思う
概念クラス図とかER図とか作るモデリングの工程ね
よくできたデータベース設計というのは、
実装する機能名と、その機能が使用するテーブルさえわかれば、処理の内容がほぼ想像がつく
逆に悪いデータベース設計は、まるで関係なさそうなテーブルの更新まで要求されたり、
機能ごとに使用するテーブルのリストを作ってみると、全部の機能で使用するテーブルが全く同じで区別がつかなかったりする オブジェクト指向の特徴である継承も多態性もカプセル化も全部あたり前に使うでしょ
クラスに責務を定義して、その振る舞いはインタフェースにしとけばテストしやすい
複雑なシステムではテストコード使わないとバグだらけになるし、リファクタリングできない
テストコードを書けるクラスというのはそのクラスの責務や振る舞いがちゃんと定義されているものだけ
クラス使えばオブジェクト指向ではなくて、
ちゃんとデザインパターンとかSOLID原則を学べばオブジェクト指向のメリットを享受して描けるようになる
>>242
それオススメ >>250
チンプンカンプン→分からない
チンチンプンプン→分かる
この様に似たものをまとめると分かりやすくなる
だからプログラムも似たものをまとめようって発想 同じ目的に使われる関数と変数をクラスでひとまとめにしちゃえば
他のプログラムに同じ機能を流用したい時にコピペが楽でしょみたいなノリ
必ずしもコピペする訳じゃないけど、再利用しやすい >>250
例えばプログラムAと似たようなプログラムBを新たに作るときに
従来型であれば物理的にソースをコピーして作るが
オブジェクト指向であればプログラムBは独自の処理だけ作って後はプログラムAの
を再利用したりと。業務処理であればあまりない
納得できないし理不尽だろうが納得するしかないｗ >>223
継承無くても良いけどね
それほど高度な事しないならVB6(VBA)までのクラスモジュールでも十分 >>1
プログラムを中心に考えるのではなく、
データを中心に考えるのがオブジェクト指向。
転じて、扱うデータの型(構造体)と、
そのデータに対して行う処理(入力、変更、削除、参照など)のプログラム全部を
1セットの部品にまとめたのがクラス。
て理解で合ってたっけ。 >>124
犬と猫の構造体orクラスがあって
犬.喜ばす()
猫.喜ばす()
と実装するのと
喜ばす(&猫)
喜ばす(&犬)
と実装するのとで
どっちが実装すっきりするか考えてみよう
更にここに兎が追加されたらどうなるかな？ >>267
犬をよろこばせるのは
犬以外の何かだろ
人.喜ばせる（犬）
が自然 go書いてみろよ、どんだけ大規模モノリシックな旧態依然システムに向かないかわかるから 男.喜ばす(女)
男.喜ばす(男)
女.喜ばす(女)
女.喜ばす(男)
喜ばすメソッドは引数によって異なる
男クラス、女クラスのベースクラスは人間クラス
人間クラスは様々な喜ばすメソッドを知っている
男と女の喜ばすメソッドは知っているが、兎は知らないので追加する
こうして喜ばすメソッドは肥大化していく >>171
前提として共通の認識がないと意味ないよねｗ 日本語は、オブジェクト指向と相性がいいはず。
フォルダを右クリックすると出てくるのが
フォルダクラスの(公開)メソッドで、
フォルダを削除する
フォルダをコピーする
フォルダを開く
フォルダを移動する などなど
この場合、
「を」だから目的語は「フォルダ」
なのに、「が」〜する。みたいなメソッドを作っちゃうと訳が分からなくなる。 >>269
犬と猫が人間を喜ばせるんだよ
猫の実装はnopかもしれんが この手の解説を色々見てきたがどれも説明が下手すぎる
何かに例えたり専門用語並べたり本質から逸れて長々と持論展開したり GUIはオブジェクト指向で書かないと収集がつかんようになる
何もないデスクトップが全体の親 (root)
アプリケーション（例えばブラウザ）は例えば「ウィンドウ」
ブラウザのタブやボタンやスクロールバーも全部「ウィンドウ」
子「ウィンドウ」は親「ウィンドウ」に含まれるという形で、どの一つの子をとっても親がある
サイトの中身が表示されている部分はDOMで、これも階層構造
そしてそれぞれの「ウィンドウ」は少しずつ挙動が違う >>282
分かっとるがな
イベントのエスカレーションや各オブジェクトにイベントリスナーのあるあたりからが分かりやすいオブジェクト指向 >>279
まあプログラミングパラダイムの歴史を分かってないと感覚的には理解できないだろうな
何を中心にして考えるかで概念が進化していく
手続き型ではメソッド中心
データ指向ではデータ中心
オブジェクト指向ではメソッド＋データ中心
つまり構成要素をどう定義するかということだ データ型を拡張する方向で考えようというのがオブジェクト指向でそのためにあるのがクラス。
ビルトイン型に加えて独自定義型を考えましょうということで、そうして作ったクラスは再利用できる可能性が高いよ、ってこと。 コピー出来て機能も追加出来る関数の集まりって認識じゃダメ？ デカンショデカンショで半年クラス
後の半年ゃ寝てクラス >>287
またかよ。
で、美少女は排泄する機能つける？付けない？ 継承は便利。
継承元を変えると、継承されるクラスに新機能が勝手に加わるからね。
継承がないと「このソース変えて、これも変えて」と面倒臭い。 >>291
そんなこと言ってると合成房がでてきて、
継承は悪、使うやつはｼﾈとか言われるぞ VBAのクラスに継承がないのはまだ許せる
コンストラクタに引数渡せないのが糞 >>291
いずれ異なる実装をしなきゃならなくするんだから
継承するのはインターフェイスだけでいい ■ このスレッドは過去ログ倉庫に格納されています
