オブジェクト指向について、調べれば調べるほど疑問が募ります。低レベルで粗末な疑問かも知れませんが、ご教授願いたいです。
・データと振る舞いをまとめる？
まとめると何か良いことあるの？
ファイルあるいはモジュールにはまとまってるよね？
丁度いい単位があるのに、何故わざわざオブジェクトという概念を導入するの？
(Javaには1ファイル1クラスという文化あるらしいけど)
・カプセル化？
モジュールのimport, exportでも実現出来るよね？
(構造体などへのアクセスを制限できれば)
・ポリモーフィズム？
別にデータと振る舞いをまとめなくても実現出来るよね？
・モノのように扱いたい？
モノとして扱いたいときに扱えば良くない？ なんでわざわざ全てをオブジェクトにするの？
※前スレ
http://2chb.net/r/tech/1615881962/ > まとめると何か良いことあるの？
人間の一般的な認識と近くなります。
例えば「犬」には走る、鳴くなどの動詞と
色、大きさ、などの属性があります
人間の認識と近いため、より管理がしやすくなります。
・カプセル化？
・ポリモーフィズム？
オブジェクト指向は概念であるため
オブジェクト指向言語でなくても実現できるのは当たり前です。
オブジェクト指向言語というのは、これらをより簡潔に実現するための機能が
言語自体に備わっているということです。
> ・モノのように扱いたい？
> モノとして扱いたいときに扱えば良くない？ なんでわざわざ全てをオブジェクトにするの？
モノとして使いたくないものがないからです。
例えば関数だって、関数名や引数と言った属性を持っています。
メッセージングを基礎単位として取ることは、より徹底的な遅延束縛を可能にする。というのも、
メッセージそれ自体は意味を持たず、実際にメッセージがオブジェクトに送信されてはじめて、意味が決まるからである。
https://qiita.com/ukyo-su/items/8c861f114809a96d1378
オシッコを出したり止めたりというのは、チンポから力を抜いたりチンポに力を入れたりと、
オシッコはオシッコそれ自体は意味を持たず、オシッコが尿道を介してチンポに送られることによって、
オシッコを出したり止めたりが可能になるということだ。
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く クリントン大統領の「不適切」というのは、チンポが独立して主体意思でシコシコしてしまったから。
チンポは独立した生き物であり、アメリカ大統領の権限をもってしても、制御することは不可能だ。
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
class チンポ extends クリントン{
super.不適切な関係;
}
クリントンーーーーーーーーーー
┃ ┃
┃ ┃
┃ ┃
┃ ┃
┃ ┃
ーーーーーーーーーーーーーーー
┃ﾁﾝﾎﾟ┃
￣￣￣￣
『人格を性欲に乗っ取られる』、つまりクリントンはﾁﾝﾎﾟに人格を乗っ取られて、ﾁﾝﾎﾟにｼｺられてしまった！ 『シコシコ』という擬音はどうでもよい。問題は、
自我 チンポ
↑ ↑ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
チンポ≫自我
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。 自分はあたまいいと思ってるトンデモさんが
もっとあたまいい人たちに囲まれて袋だたきにされてんだから
そら「ちんこちんこー！」とか言ってバカのふりしないと
精神の均衡保てないだろ。
もうそれ狂ってんだけどね。
別にいいんじゃない？
もうちょい真面目な話になるけど、今まで言語のスレで他の言語の話はしてもいいかダメかとかでスレが割れたりすることはたまに有ったけど、結局許容されてひとつのスレに戻るんだよ。
なんせ5chはその気になれば規制でもされない限り誰でも自由に書き込みが出来るから、結局のところどんなにスレ内部の取り決めを作ったところで
それが守られなければ許容せざるを得ないってことなんだろうね。
だから5chではスルースキルが問われるんだよ。別にチンポさんを庇護するつもりはないけど、誰かに噛みついてる訳でもないし、
チンポチンポ言ってるだけだから気にしなければそれで済む筈。
もっともたまに「ん？」という書き込みもしてるから俺は一応目を通してるけど。
>>11
>チンポチンポ言ってるだけだから気にしなければそれで済む筈。
オブジェクト指向について、他にわかりやすい説明が有るのか？ 必死になって連投してんのはお前らが褒めてやらないからだよｗ
すごいねって言って欲しいんやろな
認めてほしいんよねきっと…
そもそもクソスレの継続立てる>>1がアホ
スレ立ててまで語る話じゃないとわからない連中がいれば同じくアホ 「オブジェクト志向」（「オブジェクト・オリエンテッド」の訳語。
「オブジェクト指向」ともいう）というのは、
「算体主導言語」とも謂われていて、
「もの（オブジェクト）にメッセージを投げる」というふうに理解すると、大規模な
システム開発においては理解がきょうゆうしやすいのではないか？という
「パラダイム」の話ではないかと考えている。
この「パラダイムの共有」という概念を理解していない上層部から、
「オブジェクト指向」とかいった形式的な規約を押しつけられた挙句に、
人格がこじれちゃった人が「チンポシコシコ」なのだと思う。
正直な話、C 言語の構造体みたいなものをメソッドで返そうとすると、
いちいちクラスを定義しなくちゃならないし、「同じプロジェクトで
似たようなクラスがあったら、統合化できないか」みたいなことを
考えざるを得ないわけですよ。
システム屋は一般社会からは疎外された存在ではあるが、
「チンポシコシコ」は、システム開発の現場においても疎外されている、
という「ぼっち」の鬱憤を晴らしたいのだと思う。
生温かくスルーするのがいいと思う。
関数とかメソッドとかは、「複数の価は返せない」という
縛りがあるので、Ｃ 言語の構造体やら、（オブジェクト志向言語の）
クラスやらに頼ることになるわけだが、C 言語とかとは違って、
Java だと「広域変数」というものがない（というか、
渡すのを禁止している）ので、「シングルトン実装」とか
「（DB を含む）ファイル渡し」になっちゃうんだよな。
とはいえ現場によっては頭の古いヒトがいて、
「シングルトン実装は禁止」とかいう話もあるので、
「チンポシコシコ」は、そのあたりで
人格が拗（こじ）れちゃったのだと思う。
みんな、合掌して送りだしてあげようよ。
「関数」（函数。「ファンクション（機能・機関の漢語訳）」）は、
「入力⇒出力」の関係は一意的なんだが、
「オブジェクト」というのは「内部変数」というのを持てるので、
「setter でメッセージを投げて getter で受ける」といった
ことができる。とはいえ、それだと排他制御が面倒臭いところに
なるので、「基本的に共有しましょうよ」という「static」と、
「他所からチョッカイは出さないでください」というダイナミックな
（new して自分で抱えている）オブジェクトがある。
「オブジェクト志向を教えてくれ」というスレに
「チンポシコシコ」が介入してくるのは、
そのあたりの説明をちゃんと行なって引導を渡す奴が
いないだけじゃないだろうか。
喝を入れて往生させてあげるのが、このスレの住民の
責務ではないだろうか。
>>1
自分のやりたいことの野望は膨らむ一方で、
それに伴いコーディング実装やらなきゃToDoも膨大化する一方。
どうやって脳内混乱を抑止しつつ作業量を最小化する？！
って経験をしたことないみたいだね。
人海戦術など、所詮は無能の寄せ集め感で圧倒するしか能のない、素人相手にしか通用しない小手先技。
オブジェクト指向こそ、一騎当千の猛者の拠り所となる真のソリューション。 素人に理解しやすい以外の意味は無い。
数学が苦手ですか？ではオブジェクト指向コンポーネントをお使いください。
こういうこと。
>>25
C++にせよ、Pythonにせよ、
多次元ベクトルはクラス化して、演算子オーバーロードしたり、規格化メソッド実装したりする方が、
論文のアルゴリズム表記と親和性が高まるじゃん >>25
その例えで「数学」は重要なキーワードですか？
例えば「残業」が苦手ですか？という例えでも良くないですか？
「数学」でなければならないならその理由を書く必要があります。
理由がないならただの主張でしかないです。 数学の大変さは物事を抽象化する能力
残業の大変さは気力、体力的なこと
全然違う
>>28
大切なのは数学ではなく抽象化能力ということでいいですか？ 数学的な意味での抽象化能力
哲学、文学での抽象化能力とはだいぶ違う
理学と工学で「理学の方が偉い」とか言いだしかねないアナクロさ
バイアグラ工場の煙で、チンポがシコシコw >>27
> その例えで「数学」は重要なキーワードですか？
「数学」にも、少なくとも三種類あるので、なんともいえない。
計算数学だと、「有効数字」「誤差」「収束速度」「収束値の安定性」みたいな
話になるので、電算屋には切実だ。これ以外にも、「有限組合せ数学」と
いうのがあって、「組合せ論的な爆発」とかいった切実な話がある。
いわゆる「解析数学」というのは、（「近似小数」の範囲で勝負している）
うちらには関係がないのだが、非線形微分方程式の近似計算とかいった
話があるので、ちょっとは齧っておいたほうがいい。
「数学基礎論」は、記号処理関係の練達のハッカーがいて、わりと怖ろしい
領域ではあるのだが、将来を見つめるという意味では、学んでおいて
いいかもしれないと思う。 そういやオブジェクト指向の先とかいうアスペクト指向はあんま流行らなかったな
>>38
先とかじゃなくてオブジェクト指向とは直交する問題の解決策として出てきたものだっただろ
C#の属性なんかはアスペクト指向の機能だぞ
Lispだとアスペクト指向でやろうとしたことは
MOPがあれば出来る感じだったかな >>38
エージェント指向？
オブジェクト指向で「こうしろ」ってコマンドに対応するプログラミングの先で
オブジェクト自体がもっとAI的に自発的解決策を模索するエージェントになる奴 アスペクト指向もエージェント指向も「指向」ではなく
オブジェクト指向に追加する追加機能でしかなかったからな
アスペクト指向はオブジェクト指向にライブラリで追加するのではなく
言語レベルで機能を追加するという方針と考えればいいかな？
やりたいこと自体はメタプログラミングの一種で、既存のメソッドの処理を外部から
置き換えて元のメソッドをを実行するようなことができれば実現可能
それを言語レベルで記述できるようにしただけ。あとはアノテーションとかあれば
アスペクト指向と名乗るまでもなく、ライブラリで実現可能だろう
エージェント指向は、クラスのメタ情報と検索機能、それを管理するレジストリがあればいい
オブジェクト指向があれば実行に実際に処理を行うオブジェクトを入れ替えることができる。
しかし「こうしろ」という内容は一体どういうものを想定していたんだろうか？
人間みたいに自分で考えて実行できるオブジェクトなんてまだまだ作れるわけがないので
「引数を与えると足し算をするエージェント」という内容で探すしか無いだろ？
勝手にエージェントがそういうことをしてくれるわけではなく、そういうエージェントを作らなければいけない
普通はライブラリとしてそういう関数て提供されていて呼び出し時にリンクすればいいが、
それをわざわざ検索する？これって別のマシンで動かすための分散オブジェクト技術のことなのではないか？
オブジェクト指向だからGetWindowなのかな
Window.Get
サブジェクト指向の方がオブジェクト指向っぽい
AppActivateはサブジェクト指向だな
もっと言うと
App.Activate
こっちの方がいいかな？ IBMだし
https://www.ibm.com/docs/ja/zos/2.3.0?topic=controls-subjects-objects
サブジェクトとオブジェクト
サブジェクト は、システム・リソースへのアクセスを必要とするエンティティーです。 例えば、サブジェクトには次のものがあります。
・人間のユーザー
・開始済みプロシージャー
・バッチ・ジョブ
・z/OSR UNIX デーモン
通常、ユーザー という語は、サブジェクト と同じ意味ですが、暗黙で人間を指定する場合があります。
本書では、特に指示のある場合を除き、ユーザー とサブジェクト を同義で使用します。
オブジェクト とは、アクセスを制御する必要があるシステム・リソースです。例えば、オブジェクトには次のものがあります。
データ・セット
・z/OS UNIX ファイルおよびディレクトリー
・コマンド
・端末
・プリンター
・DASD ボリューム
・磁気テープ >>44
>人間みたいに自分で考えて実行できるオブジェクトなんてまだまだ作れるわけがないので
785 名無し三等兵 sage 2019/12/03(火) 08:03:27.78 ID:sujZBpWD
>>762
＞「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
チンポにチンポ自身を扱く機能が備わっていないので自動詞は不適切だから（34文字）
胸（心臓）には鼓動する機能があるため自動詞の適用対象だが
チンポには勃起する機能はあっても自身を扱く機能はないので「チンポ『が』勃起する」は成立しても「チンポ『が』シコシコする」は成立しない
夢精した状況を「チンポ『が』シコシコした」と称したければ「チンポがエロい夢を見させ夢精した」＝「脳ではなくチンポが思考を司りエロい夢を見させて夢精させた」という状況で可となる
脳でなくチンポで物を考える生物についてなら「チンポ『が』シコシコする」は成り立つ
如何にもだつお的じゃないか Man.Shiko(Chin) とすると
Man.Rec(Recorder) なのか
Man.Push(Recorder.Rec) ではないか
開発対象は Recorder.Rec
従って Man.Run(Chin.Shiko) と言える
開発対象は Chin.Shiko
いろんな物を壊せるフォトリアルなゲームでは、
各クラスの壊すメソッドと、各クラスの壊れるメソッドの両方が必要
普通の死体、バラバラ、灰、液状、と壊すメソッドで分かれてるものはある
バラバラは元の形が残りつつ変形するので、凝れるメソッドが必要
>>47
中学校の英語の時間に「五文型」というのを習ったと思うが、
「サブジェクト（S）」は「主語」で、
「オブジェクト（O）」は目的語。
とはいえ、このあたりの議論を深めないと、「オブジェクト志向」とか
「メッセージング」とかいった話は理解しづらいように思う。 24 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (JP 0H82-LX7o [153.145.207.163]) 2019/11/23(土) 16:54:55.03 ID:l9637O/lH
>>53
Ruby最悪やろ
サリンとRuby
1995年3月、ある事件が起きた。 そう。地下鉄サリン事件だ。
5年生の時だったか、麻布の学園祭に行く時に 日比谷線を使ったが、
まだサリンが残留してるんじゃないかと思って、 怖かったのを覚えている。
同じ1995年に生まれたものがある。 Rubyだ。
サリンはあの時、多くの人の命を奪い、そして後遺症を遺した。
Rubyはどうだろうか。 国産言語としてゴリ押しし、 不幸なことに、
日本では広く使われてしまった。 今に至っても使われてしまっている。
これによって日本の技術はよりガラパゴス化し、
日本のIT業界に負のダメージを与えた。 サリンと同じく、多くの後遺症を遺した。 例え話で分かった気になるのは危ない言うなればサリンみたいなもの
Railsを作ったのは外人でルビーは海外で絶賛されてたけどなあ、ガラパゴスジャパンはルビーの存在さえ知らなかった
70 名無しヒーリング 2021/04/26(月) 09:45:57.57 ID:jZDy/LpM
先生、実際にシコシコするのはチンポでなく俺の右手だと思います。
✖チンポがシコシコする
○ 俺の右手がチンポをシコシコする
71 名無しヒーリング 2021/04/26(月) 09:56:38.18 ID:jZDy/LpM
あと、「胸がドキドキする」と「チンポをシコシコする」は比較対象になりません。
「胸がドキドキする」は「チンポがヒリヒリする」のように状態・感覚を擬音語で現しているのであって、
「チンポをシコシコする」は「胸をモミモミする」の様に人間や動物が対象に対して何かを行う行為の表現だと思います。
データと振る舞いをまとめることこそがオブジェクト指向の中核だよ。
それによって何が良くなるかというと、データ構造の仕様変更があっても、そのデータ構造を持ってる部分、つまり1クラスだけ直せば皆直るように作れること。
データ構造とそれにまつわる処理を1つに閉じ込めることを言語的に強制することによって実現出来るの。
手続き型言語だとこの強制が無いから、同じデータを扱う同じ処理があちこちに乱立する可能性が高まるの。
ただし、綺麗なクラス設計をするためにはデータ構造の粒度の見極めがとても重要で、例えば姓と名だけを持つ氏名クラスのような小さい粒度のクラスもたくさん用意しないと実現出来ないから注意してね。
クラスの粒度を見極める一つの指標として、その物を人間が呼ぶときの単位に着目するの。例えば1伝票とか1明細とか、1社とか1部署とか1氏名とか。
そしてクラス間の多重度(カージナリティ)を表せば、つまりクラス図を書けば綺麗な設計・実装が出来るよ。例えば、
1伝票に対して複数明細
1社に対して複数部署
1人に対して1氏名
など。
他にもコツはあるけど上記が基本。
ポリモーフィズムとか継承はその後に覚えれば充分。上記が出来ない人はむしろ継承を使わない方が綺麗に作れるよ。データ構造の継承はやっていいんだけど、委譲で作れる処理を継承で実現するのは保守性が下がるからやらないことね。
綺麗なクラス設計が出来ると、「1ヶ所直せば皆直る」を実現出来るよ。
でもRDBがこれを邪魔する時が多々あるのが実際の開発での悩みだなぁ。
var chin=chins.get(ikemen);
chin.width++;
chin.height++;
chins.delete(ikemen); これが気持ち悪いですな
chin.delete(); こうしたいですな
しかし要素数が１０００とかある場合
chin.delete(); こうするには１０００個ものdelete関数が持たれる？
chins.delete(ikemen); それで配列系はこっちが多いのかな
>>61
>chins.delete(ikemen); これが気持ち悪いですな
>chin.delete(); こうしたいですな
自分はそうは思いません！
配列から要素を削除するから
chins.delete(ikemen);
これが自然
> chin.delete(); こうするには１０００個ものdelete関数が持たれる？
言語による
昔のVBとかJavaScriptでprototypeを使わずにオブジェクトに直接関数を定義したら
インスタンスの数×関数の数だけメモリが消費される
Javaはクラスの定義ごとに関数が作られる
chinをレシーバ・オブジェクトと呼ぶことにすると
レシーバ・オブジェクトは、関数の引数の一つとして渡される
インスタンスを作りまくっても関数が使用するメモリは増えない デザインパターンで遊んでいればOOPなんてすぐじゃね？
その後はクリーンアーキテクチャーとかDDDとかに進めばええ。
MS$のAdventureWorkshopででも遊んでいれば誰も近寄れなくなるさ。 恐れ多くて。
教科書上で多態性理解より、依存性逆転の原則とか現場ルールを理解する方が大事。
オブジェクト志向というのは、あくまで方向性の問題なんだよな。
C 言語には longjump しかなくてキャッチ＆スローがないとか、
Java には goto 文がないとかいうのは、たぶん「結果論」なのだと思う。
Java には「メッセージング」という概念があるのと、
「広域変数」という概念がないというのは、
うちら老害に苦しんでいたプログラマにとっては
恩恵だと思われ。
WEBと基幹業務では感覚が違うだろうけど
共通部分があれば共通化するのは当然として
基幹業務の各業務はほぼ全て個別で、他の業務機能と合成するような要件はほぼない
その上、各業務のほぼ全てに同じ伝票が絡む
ゆえに、１か所改修すれば連鎖的に共通部分に反映できる、なんて部分はほぼない
くせに、ほぼ全てに絡む
DB脳は整理脳
これが苦手な人がオブジェクト指向を使ったからって整理できない
例えば.NETの、DB構造のコピーを置くDataSetや、DataAdapterの自動SQL
整理どころか厄介なゴミを増やしてる
これらはDBをコントロールのように見たい気持ちなのかな
逆に画面コントロールをレコードセットのように見る中継クラスなら作った
「共通伝票を作る」のがオブジェクト指向じゃなくて
「伝票を扱う担当者を作る」のがオブジェクト指向なのでは🤔
各ユーザーからは伝票詳細は別にわからなくても
自分に必要なことだけ提示されて自分の業務でわかることだけ指示すればいい。
修正は各部署の“担当者”にあたるオブジェクトに集中する。
また、“担当者”側からみた“共通伝票”さんも「あなたにこれ書いて欲しいんですよね」と
なにをして欲しいのか明確にすることで
無用な詳細の暴露と役割の混乱を防ぎ、必要な時の修正を“共通伝票”に集中させる。
オブジェクトを役割に見立てて情報の連鎖を切ることで
修正の連鎖そのものを起きないようにしたいのがオブジェクト指向なので。
https://ie.u-ryukyu.ac.jp/~e085739/java.it.16.html
Commandパターンで、Receiverクラスを独立して設ける意義は何なのでしょうか？
ConcreteCommandA/Bのexecute()に具体的な処理を書けばReceiverクラスは不要に思います。 CommandとReceiverのライフサイクルが異なるからじゃないかな
Recieverクラスを除去するとCommandに
System.out.println(msg);
を書かないといけなくなるっしょ
System.out.println(msg);
を変えたくなったときに複数のCommandを修正しないといけないのが
嫌だったんだと思うよ
>>71
ありがとうございます。
その場合でもconcreteCommandクラスを修正する分には問題ないかと思いましたが、Receiverに分離しておけば、そのクラスにCompositeパターンを適用したりと拡張できそうですし、価値がありそうですね。 オブジェクト指向がよく解らなくてクッキーの型とか勇者とか車とか色々な例を見たけど
自分は結局button1()のフォームへの配置が一番解りやすかったので凄く遠回りをした
みんなどうやってこれを理解したんだろう
クラスは設計図、オブジェクトは製品、インスタンス化はメモリを確保することと覚えて
コード書きまくってたら慣れただけだな自分は
よく批判されがちなことに
入門書のアニマル継承説明があるが
>>73-74の人の意見もあるように
理解への入り口は色々なのが現実なんだよな
鬼の首とったように入門書叩かれたりすることあるけど
アニマルを見せられても分かるやつは分かるんよ
仕組みだけわかったらあとほっといても応用思いつくんよ
それが出来ない人が振り返って教科書が悪い入門書が悪いといいがちだけど >>75
>理解への入り口は色々なのが現実なんだよな
ところで「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ >>73
80年代にBASICやアセンブラベースでパソコンプログラミングで
GOTOで好きなところに飛べる自由とスパゲッティに対して
C言語が入り口と出口をしっかり決めてスパゲッティしないさせない
「構造化プログラミング」で一世を風靡して、「これからはCだぜ！」ってのがあって。
続く90年代前半に「これからはオブジェクト指向でC++って奴らしいぜ！」ってなったの。
ところがいまではC++をオブジェクト指向の主流に挙げる人がいないのでわかるように
こいつがオブジェクト指向の考え方じゃなくて自分に都合のいい仕様だけ
別言語からバラバラに引っ張ってきた奇形言語で
(いわゆる“クラスと再利用がオブジェクト指向！”って奴)
あんなもんを“これがオブジェクト指向”と称して布教したから現代まで続く大混乱と
結局オブジェクト指向がなんなのか一切理解できないまま
「オブジェクト指向ナンテー！」ってほざくアンチジジイを生み出したの。
その後、紆余曲折ありながら「メソッド/メッセージ」(命令、コマンド)の
オブジェクト指向本来の考え方を取り入れたJavaが広く使われるようになって
まだ古い頭の人には意味がわからないにしても
「各オブジェクトが役割を担い“命令”に反応するように作ることで
作業担当と権限を明確にして必要な修正の連鎖を最小限に抑える」
オブジェクト指向本来の目的が広く知られるようになった。
(むしろ、自分のコピーを作れて、命令セット差し替えで多態性って考え方は
この“オブジェクト化による独立性”が根本にあるので
こっちが実現できてないと「クラスの使い回し〜」もなんもないという) >>77
>「各オブジェクトが役割を担い“命令”に反応するように作ることで
オシッコを出したり止めたりというのは、チンポから力を抜いたりチンポに力を入れたりと、
オシッコはオシッコそれ自体は『意思』を持たず、オシッコが尿道を介してチンポに送られることによって、
オシッコを出したり止めたりが、『意思』を介して可能になるということだ。 >>77
>作業担当と権限を明確にして必要な修正の連鎖を最小限に抑える
241 伝説の名無しさん sage 2020/10/13(火) 15:00:15.08
「胸がドキドキする」というのはいわば生理現象であり、抑えることはほぼ不可能だ。
月末のクレジットカードの支払額に、想像以上に可愛かったデリヘル嬢のおマンコにと胸を
突かれるのは悪いことではない。
翻って「チンポがシコシコする」というのは能動的な衝動であり、極めて不埒な責任転嫁である。
シコシコはチンポが勝手にやったことであり、決してチンポの持ち主の意向ではないという、どこぞの
政治家の「秘書が勝手にやったこと」のような言い逃れがしばしば聞かれ、あまつさえそれがまかり
通ってきたことは周知の事実である。
チンポからシコシコを奪取し、各人の掌に戻る日は果たしてやってくるのだろうか……。 こんなスレあるんだな。初めて来たよ。
オブジェクト指向が何かなんてそんな悩むような難しい話かなと個人的には思うけど、
たぶんこれが分からない人はオブジェクト指向を「技術」だと勘違いしてるんじゃないか。
オブジェクト指向は、例えば論理回路をどう組み合わせて加算器や減算器を実現するか？
というような意味での技術じゃない。
>>68
販売管理では、見積から入金まで、複数の業務フェーズに同じ伝票が回る
共通伝票って共通書式じゃないよ、１つの伝票の同じインスタンス
１つの伝票の同じインスタンスが、業務フェーズが進むたびにデータが更新され、ステータスが変わる
（仕入も、高度な場合は複数の受注から在庫管理を経由して複数の仕入に紐付き、互いが互いの明細データになることがある）
業務担当者から見れば受注票、納品書など別の伝票だが、システム的には同一データのステータス違い
受注テーブルから納品テーブルへ物理的に移動させるシステムもあるが、意味的には同じ
同じ伝票を複数の業務で扱うんだから、伝票をクラス化すれば、１か所直せば全部直るじゃんかと
でもそもそも１つの伝票を最初から最後まで追うというシステムなので、巨大なシステム全体が１クラスのようなもの
各業務は１つのクラスのメソッドにあたり、伝票は親インスタンスのデータにあたる
親データの仕様が変われば、各メソッドの仕様を確認せざるを得ない 回路で言うなら
非オブジェクト指向：非同期設計/ディスクリート回路
オブジェクト指向：同期設計
(嘘)
言い方を変えると、業務システムで同じメソッドの使いまわしはないというか
同じメソッドを使いまわす予算の使い方をしないというか
その業務をやるなら、その専用画面でやる
その業務機能を、別の画面から部分的に呼ぶことはない
それぞれ１か所でしか登場しない業務機能が、膨大にあるのが業務システム
（フォームがそれに近いね、クラスだしnewされるが、ほとんど実質スタティックな一意）
なので間接的に実装を記述する意味がないというか
業務要件に関してはね
細々としたものはあるよ
コントロールの反応の仕方とか、権限チェックとか
>>81
オブジェクト指向とは関係ないが
異なる伝票を1つの同じ伝票だと認識してることがそもそも間違ってるよ
エンティティとそのライフサイクルを識別できてれば共通伝票なんて発想にはならない
>業務担当者から見れば受注票、納品書など別の伝票だが、システム的には同一データのステータス違い
同一データのステータス違いじゃない
そういう考え方で設計してれば変更に弱くなるのは当然 そういえばなんでプログラムの関数の名前って三人称なんだろ
アクターがメッセージングするなら二人称がふさわしくない？
>>81
なんか「お盆に乗った巨大な書類綴りが社内の部署を巡回して
各部署が勝手に書類綴りにいろんなものファイルするんだから
書類綴りの変更はすべてに影響するのあたりまえじゃん？」
って言われてるような頭チカチカするものすげぇイメージが
伝わって来たのだが……… >>84
本質は同一データのステータス違いであることを見抜かないと、無駄に冗長なシステムになり、改修困難になる
「見積から入金まで」って、ライフサイクルのことですよ
（入口）見積→受注→仕掛→納品→請求→入金（出口）
ここまで同じデータがステータスを変えて進んで行く
データ変換バッチが大量にある会社は、途中でライフサイクルが終わってるのかなｗ
でもほんとは終わってないから、そんなものが必要になる
「共通伝票」は>>68が勝手に言ったんであって、こっちは否定してるでしょ
「伝票」って言葉が悪いのかな、「案件」と言えば伝わるかな
変更に弱くなる「のは」ってなんだよ、どっから出てきた
変更の速さは神がかりと言われるんだが
むしろオブジェクト指向信仰、ＲＤＢ嫌いはコケ案件にいる印象
（オブジェクト指向自体はゴリゴリに使うよ、でも使いどころが違う） >>88
ステータスを更新したときのタイムスタンプはどこに保持するん？ >>88
>「見積から入金まで」って、ライフサイクルのことですよ
それは何のライフサイクルかな？ >>73
昔は「算体主導型言語」とか言ってたなぁ。
Java なんかは GOTO 文はねーわ（構造化ステートメントで書け、という話だ）
広域変数はねーわ（シングルトン実装しろ、という話だ）で、
「こんな言語で開発ができるのかぁ〜！」と思ったが、
慣れると普通にできるので感心した。
catch ＆ throw はあるわ、動的メモリ管理はあるわ、
わりと至れり尽くせりな感じなので気に入っている。
あえて難をいえば、BASIC の SWAP 文がないのと、
LOOP-UNTIL-DO-REPEAT 文がないことかな。
while(true)から break で脱出するのはいいのだが、
ループ内変数の初期化をしようと思うと、
「{」とかをいきなり書く破目になるのはいまひとつ。 >>93
おじいちゃん、いまはdropWhile,takeWhile,forEachを使うんだよ 使いこなせるやつが何人いるかだな。
功を狙ざれ日すなわち危うし、という話もあるし。
つーか、Java 9 って最新バージョンだろ？
もう一個バージョンが上がってくれるのを待ちたいところだ。
×「功を狙ざれ日すなわち危うし」
〇「技を得て功を練らざれば、すなわち危うし」
『高スペック人材』なら、外資に転職すればいい話だよね？
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者がNTTを辞めた理由が、
私が３２年前（１９８６年）にNTTを辞めた理由とあまり変わらないのに、少々驚きました。
私がNTTを辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたこと
がなかったので、これを機会に書くことにしました。
https://lite.blogos.com/article/341485/
なのにそれが使い潰されるってのは、完全な自己責任では？
「東大・京大あたりの出身者はやはり頭が良く、物事の本質をしっかり考え、理にかなったことを言います。
ただ、自分の考えに自信を持ちすぎ、周囲に合わせて柔軟に行動するということができません。また、
会社では一見無駄な業務や下積み仕事があるわけですが、高スペック人材は自分が無駄だと判断したら止めてしまったり、
手を抜いたりします。結果として、職場で浮いてしまい、あまり評価されません」（エネルギー・経営者）
https://toyokeizai.net/articles/-/430519?display=b ひろゆき氏：試算してみたことがあるんですが、できそうなんですよね。毎月7万円を国民に配ろうと思うと、約90兆円あれば可能です。
そのためには、生活保護をなくしてベーシックインカムで一本化したり、お金持ちから多く税金を取るため
に相続税を増やしたり、高齢者も医療費の3割負担をお願いしたり。そうやっていけば、実現可能です。
https://diamond.jp/articles/-/273191 なんか、このスレ寂れてんのか？
「オブジェクト指向」というのは、
「オブジェクト・オリエンテッド」の日本語訳だろ？
で、「オリエンテーション」というのは「光は東方より」っつって
アレクサンダー大王が東征したワケだ。
昔は「オブジェクト・オリエンテッド」を「算体主導型」と訳していた。
つーか、C 言語の「参照」と「実体」や、「構造体」みたいなモノを、
「メッセージを投げるとメッセージが返ってくる」という
「メッセージング」に帰着させただけの話で、古いコーディングスタイルを
知っている世代にとっては、わりと受け入れやすい概念だと思われ。
メソッド単位での単一責任原則が守られてないオブジェクトは拡張するのが難しい
オブジェクト指向の闇
>>98
東大京大でも院から転入した学歴ロンダが居るからそういうのは排除しないと
>会社では一見無駄な業務や下積み仕事があるわけですが、
>高スペック人材は自分が無駄だと判断したら止めてしまったり、
>手を抜いたりします。
手を抜くというより例えばいちいち手作業やってるのをあほらしいから
プログラミングして自動化してもそれでも手を抜いたと言われる会社なら辞めた方が良い
日本には不合理な精神論が蔓延している >>101
>特定の営利イベント開催
今問題になってるIT相のNTT干す発言も立派な生贄パワハラ確定だが
IT相は臀痛出身でさもありなんだと思うわ
体質が染みついてるんだろう >>108
そういえば、「IDE 使用禁止」「ソースコード管理ツール使用禁止」
みたいな現場が昔あったっけ。
「工数の水増し」のために開発効率を落としているとしか思えなかったが、
当時は携帯電話が売れてたからそれで通ってたんだろうなぁ。
ゲームとか携帯とかは基本イベントドリブンだから
オブジェクト志向とは相性がいいんだが、
C++とか使ってると「そもそもコンパイルが通らない」とかいった
事態が起きるのでどんどん工数が膨らむ。
残業・休出を減らして開発効率を上げて
工数を圧縮して納期を短縮するとかいった発想は、
たぶん派遣業者にとっては許しがたいことなので、
オブジェクト志向なんていうのは
異端思想なんだろうな、と思う。 そもそも日本語として成立してないの気付いてなさそうだ
知ったかくん哀れ
ネットで拾ってきたC++のコードがCコンパイラで使えない！とお怒りのようです
解雇されたエンジニアが、社長、副社長、人事部トップ3人を銃殺するという事件がシリコンバレーで起った。
警察に捕まった47歳のエンジニア、ジング・ウー(Jing Wu)は、ワイアレス半導体のベンチャー企業
SiPort(シポート)の元社員。3人の子供の父親であるウーは不動産投資に手を出し、17軒の不動産を持っている。
しかし、このところの不動産市況の暴落ですべての計算が狂ったようだ。
自分で弁護士を雇えないほど資金繰りは苦しいようで、日本の国選弁護人に相当する米国の公共弁護士がついた。
中国から米国に移民したウーは、不動産投資で子供の教育費などにあてようと資産運用を図ったことが裏目に出た様子。
そこへきて勤務先から「業績遂行能力不足」を理由に11月14日、解雇を言い渡された。彼はいったんシポート社
を出て銃を忍ばせ、シッド・アグラワルCEO、副社長のブライアン・プグ、人事部のマリリン・ルイスに退職後
の相談と面会を求め、同日午後4時、会議室で3人を射殺した。
https://toyokeizai.net/articles/amp/2466?display=b&;amp_event=read-body >>116
チャンコロなんか野放しにしておくからそういうことが起こる。
二階とかの親中議員を放置しておくとその内日本が中国の一部にされてしまうぞ。 漏れも親日じゃない相手には反中で対応するのは賛成だが
たまたま犯罪者が中国人だったたけですべての中国人を問題視するのは
プログラマとしての資質を疑うレベル
不動産投資に失敗したなら自己責任
銃社会が問題
確かに。
1つの事象を見て全体がそうだと決めつけるような
分析力の低い人間にプログラミングは無理だと思う。
プログラミングとはカスリもしない問題をこじつけ
善人ぶって正論かのような言葉を並べ本質を見誤る愚者
或いは被害拡大を狙った偽善者
ところで「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
何とも甘い連中だ
チャンコロ放置した結果どうなった？
5chがチャンコロからサイバー攻撃を受けて今何種類ものブラウザが使えなくなっているじゃねーか。
お前らは一々こいつはいいゴキブリだから殺さない、こいつは悪いゴキブリだから殺すとかやってんのか？
台湾がやられたら次は日本だぞ？殺るか殺られるかのときにそんな甘っちょろいこと言ってるから
中国を牽制している他の国々と足並みが揃わない。このままではレッドチームに吸収されるぞ。
そうだねコロナDNAワクチンで遺伝子弄られて
思考が5Gで政府に筒抜けになるから君に逃げ場は無いね。
ブラウザやクラッキングを言うならロシアも中韓朝以上に危険
