オブジェクト指向ができないと言われる YouTube動画>1本 ->画像>3枚

デザインパターンに沿って製造しているから、ソースレビューでフレームワークの使い方の指摘はこない。

女性というだけで、論理的じゃない、オブジェクト指向ができないと言われる。
具体的な指摘はこない。

ただ、論理的じゃない、オブジェクト指向ができない、という言われるだけ。

ウゼェぇぇぇっ。
具体的に論理的に指摘してこいや。
論理おばけさんがよ。

女だからが先に来る時点で無能なのがわかる。
男が具体的に説明してるのに、それを理解する知能すら持ち合わせてないというだけだろう
企業も穴目当てに雇用してるんだからそれだけ全うすればいいよ、どうせ女なんだから

>>2

そういうのが抽象的な指摘なんだよな。
まじでやめてほしい。

IQ検査で128しか出ないからダメなのか。
女なら130はないと戦力にならないのか。

男は110くらいで戦力として認識される。

男は棒採用！！
女は穴採用！！

棒採用はIQ低くて良い！！

食いチン棒！万歳
チンコーマンの提供でお送りします

棒ってだけでlえぇぇ

ざけんじゃねぇぇぇぇぇ！

オブジェクト指向ができないってどういう意味なんだろ
これからオブジェクト指向しようとしてるってこと？？？

製造でオブジェクト指向ｗ
オブジェクト指向は設計手法だ

アジャイルで作りながらオブジェクト指向なんてねぇわ

だからいつも言ってるんだよ、＋＋じゃないCからまずは勉強しろって。
コンピューターは女にも忖度なんてしねーんだよ。

成果物にじゃなくて人の指摘すんのはレビューじゃない
もうその現場諦めろ

>>1みたいな文章を書く人間と一緒に働きたくねぇ

＞オブジェクト指向は設計手法だ
確かにそうだな。
指摘されたのは、オブジェクト型がわかってない、ではなく、オブジェクト指向がわかってない、
だからな。
ソースレビューでオブジェクト指向（ソースの設計）についての指摘はぜろ。
validationで最終的なレスポンスの成形とかしてないからな！！

＞成果物にじゃなくて人の指摘すんのはレビューじゃない
そうそれ！
こういう視点が抜けてて、会話にならなくて発狂してた。
レビューもDRYやYAGNIも知らなくて、
みんな好き勝手に「こうしたらいいんじゃない？ああしたらいいんじゃない？」
と書いてただけ。
だから、別の人のレビュー指摘で修正したソースにまた別の人の指摘が入る。
好き勝手にみんなコメントしてただけ！！

＞もうその現場諦めろ
途中退場にしてもらった

>>12
好き嫌いの感情論はやめろ。
〇〇がだめだ、と指摘は具体的にしろよ。

設計の話なんだから、ゲームでもなんでも
自分でアプリ作るぐらいやってないと
理解は出来ないだろうね。

抽象的で感情的な文章だなぁ...

クラスにstatic変数やグローバル変数を扱うくらいのことをしたらオブジェクト指向の理解から教えることにはなるけどね
どんなコードを書いたのか気になるなぁ

「マナー違反だ！」ぐらいの浅い指導するぐらいのやつは
グローバル変数使ってるやつの地に足の着いた理屈にどうやって対処してるの？

java学び直したら？

グローバル変数なんか書くわけないだろ、、
書いていたら、レビュー指摘で「この部分がオブジェクト指向的観点からNG」
って書かれるだろ。
そんなのなかった。

まぁ、具体的指摘なく批判されたら困るわな

指摘されるのはコミュニケーション能力がないから。
オブジェクト指向ができる証明にプログラミング系の資格取っても無駄だから。
無駄な足掻きするな。
って営業に言われた。

資格持ってたら「具体的に言ってください」の一言に重みが出ると思うんだよな。
Javaでもいい。

マナー違反だからNGっていうべからずを書いてた本の著者が炎上してたわけだけど
おまいらは実務だとそういう指導してるよね

つーか具体的具体的いうわりに具体的な内容が一切出て来ないのは
具体的の意味はよくわからないけど、とりあえずバカにされたってことだけは受け取って反射的に連呼してるだけなんだろうな

女なら理解ある彼君がいるかすぐ見つかるだろうから、さっさと引退して
具体的にいうと専業主婦したほうがいいんじゃない？

仕事でもさい男に囲まれて、
家帰っても、もさい男いるとか地獄やんか。

性欲ない男は結婚しなくてもいいから楽でいいなぁ。

私も性欲も結婚欲もないから結婚したくないし、性欲ない女と結婚した男がかわいそう。

女は結婚すりゃいい論は、結果的に不幸な男を増やしてるだけなんだわ。
いい加減気づいて欲しい。
周り見たらわかるだろ。

あ、友達いないのか。
ごめんな。
母親だけがしゃべれる女性だもんな。

ビルダーだとかファクトリーだとかは理解して使ってるレベルなのか？それ以前か？あるいはそれ以上か？

具体的に指摘しろと言われてもあっちもこっちも基本からできてないとかだと指摘してたら仕事にならんからな
コミュ力ない相手だと尚更

1がそうだと言ってるわけではないがコミュ力には問題ありそうだしコードも出てないからなんとも言えない

デザインパターンの本くらいは読んで理解して自分で使えてはいるの？

>>28
具体的に指摘しろと言われてもあっちもこっちも基本からできてないとかだと指摘してたら仕事にならんからな

これはちょっと納得したわ。
しかし、既存ソースを真似てほぼコピーしたソースをみて、オブジェクト指向ができない、と言われたんよ。
既存ソースに問題はなさそうだったし、レビューしたやつが書いた。

デザインパターンは本で読んだ事がある。

確かに、コピーしたソースに何か問題があったのかもしれない、とは考えられる。
具体的にはわからないままだけど。

「オブジェクト指向ができていない」
の内容が何なのかだな
フィールド変数を作らずに
全部引数で渡して
全部リターンするとか?

指摘が入った部分は仕様についてしかなかった。
クラスやメソッドなど、このメソッドはここじゃなくない？
等々はなかったんだよな。

>>30
それがわからないから、言いがかりつけられた気持ちになってる

>>29
なるほど
おそらく俺の方が相当なベテランだけど例えば俺の場合だとコピーすることはほぼないしあえてする場合でもどこがどういう理由でどうやって何をしてるかは理解してるのでまずはその辺からかな

レビューする方もする方で俺は具体的な指摘以外はしないけどな

オブジェクト指向はね、論理じゃないんだ感覚なんだ

>>33
なぜ、コピーしたからというと、初めてさわる言語だったから。
初めてさわる言語だが、少しは読めた。
既存ソースと同じ書き方してオブジェクト指向云々いうなや。

一つ一つのアクセス修飾子をなぜそうなっているのか考えて決める

一つのメソッド・ファンクションが一つのことをしていてやっていることがコードを読んだだけでわかりやすいように書く

個々のパーツをそれぞれで完結するようにする

これくらい出来ていればあとはSOLID原則で（とは言っても実際に使いこなすまでは時間かかるが）オブジェクト指向が理解できてないとは言われない気がする

まあ具体的に指摘されないんじゃ反論のしようもないがそれは「具体的にどの辺ですか？」と普通に聞けるかどうかというコミュ力だな

>>34
それ、まじでもめるわ。
ケンカになる。

>>36
聞けない状況だったんだよ。
具体的にここに書くとみばれするから書かないけど。
聞きたかったなぁ。
何が悪かったんだろ。

>>35
初めて触る言語でも俺の場合はコピーはしないし言語が違ってもOOPは変わらないけど

既存ソースと同じ書き方したなら「初めて触るのでここをコピーしたんですけどどこかおかしいですかね？」と聞けばいい話なので営業の言う通り実力つけるよりコミュ力一発のが解決早いな

>>36
プリンシパルいいよね。
シンプルになる。

>>38
じゃあ仕方ないな
仕事で仕方ないことはいくらもあるからな本読んでたくさん書いて実績つけたらレベルの低いのがなんか言ってきたくらいで流せるよ

>>39
そうだな。
ちょっと話聞いてもらって客観視したら、コミュ力な気がしてきた。
30人の前でいきなり言われたけど、会議止めて聞けばよかった。

>>41
初めての言語もやっぱり書かなきゃだめだな。
ぶっつけ本番でやろうとしたのが良くなかった。

>>40
フレームワークなんか絶対に使ってるからコピペするにしてもここはこれに当てはまるんだなとか考えながらやるといいかもね

>>44
それはやってたんだよ。
だから、わからない。

>>42
30人はかなり場慣れしてないと厳しいなw
30人でソースリビューってのは経験ないわ

>>45
じゃあまあやることはやってたんだから向こうがおかしいのかもしれないし
ダメなエンジニアに限ってあれがダメこれがダメと言い出したりってのもよくあるので

絶対の自信つけるにはやっぱ本読んで自分で書いて実績つけるしかないな
できれば英語の本がいい

>>46
まじであの状況恐怖だからw
人に話してネタにするw

>>47
別の言語マスターしたからいけると思ってしまった。
やった事ないのはセオリーがわからないな。

>>48
コンサルやってた時にそういう状況沢山あってもう面の皮が厚くなったけど最初は汗びっしょりだったわ

30人でってのは不適切だと思うね本来なら数人から慣らしてくべき
まあ仕事で不適切なことなんてたくさんあるけどw

>>50
2～3人しかやった事なかったから、びびった。
オブジェクト指向できない事だけ発表されて会議進むの。
具体的な内容は？なんてあの状況で恐くて聞けなかった。

>>49
まあ言語にもよるしフレームワークも大事だし個々のコードベースでも全然違うし
いいコードベースならやってるだけで勉強になるし

ひどいコードベースも逆に勉強になるけどそれは自分でちゃんとしたものを作れるようになってからかな

あまり酷い現場なら計画的に転職だわな

コンサルタントなんかできないヽ(ヽﾟﾛﾟ)ﾋｲｨｨｨ!

集団のなかに入るってことは立ち位置を与えられるってことで
既に途中退場したってことは>>1は与えられた立ち位置に満足出来なかったってこと
いろんなクラスのなかに埋もれながらも振る舞いで自分を主張するよ
その集団のなかで>>1に期待されてた振る舞いってなんだ？

>>54
サンドバッグだろ
みんなのストレスの捌け口

>>55
なら逃げて正解
生きるために感じろ

>>56
穴は穴でもゴミ箱だ

まぁ、やっぱりコミュ力より資格だな。
よくわかったわ。
人は資格にひれ伏す。

ゴミ箱は生きる。

30人の前で個人攻撃とか
パワハラでしょ
本気で喧嘩を売っているとしか思えない
駄目だと思うんだったら上司とだけ話して
プロジェクトから外してもらうとか
もっと穏便な方法はいくらでもある

本来なら30人の前で冷静に具体的にどこなのか聞いてSOLIDだとかGoFのデザインパターンだとかで反論して勝てればその場の30人および関連部署から一目置かれるチャンスなんだが

コミュ力や知識や経験的に3年やそこらのやつがいきなりそんなのできるわけないからな

まあでも気持ちの持ち方ひとつだよ
実害ないならバカがなんか言ってるwで流しときゃいいんだし

基本とか応用情報はまあとってもいいけどあんなの常識だからどこまで意味があるかはわからんぞ

>>59
それも思った。
オブジェクト指向できないとかいらないでしょ。
30人の前で発表じゃなくて、プロジェクトからはずせよ。
この人達バカなの？
って会議聞きながら考えてた。
ただただ恐怖を浴びせられた草

>>60
IPAなんかもってるわ。
3年目とか想像おつ。
どっからでてきたその数字？
あと、プログラミングの資格だっつってんだろ。
君みたいな想像だけで会話進める奴らばっかだった。

やっぱコミュ力に問題があるな

>>63
バカにはっきりバカって言っちゃうんだよな

別にそうだと決めつけてるわけじゃないんだから違うなら違うでいや3年どころではないんだけど、とかIPAくらいは持ってるんだけどとか訂正すればいい話で

別にばかにしてるわけでもなんでもないのにいきなり噛みつき始めるとかそういうところに問題を感じるね

30人の前で攻撃の前に何かあったんじゃないのかな

30人の前でセックスします

大体見えてきた

>>65
ごめんごめん。
具体的に言うと身ばれするから言わないけどIPAはもってる。
取ろうとしてるのは、オブジェクト指向を理解している事が証明できる系の資格。
言いがかりつけられたくないからね。
Javaはそういう資格があるから、こんなトラブル起きなそう。

OracleのJava certificationもSunの頃は良かったけど今はどうだろうね
まあないよりはマシかもしれないけど

とりあえずOOPが出来てないとか具体的にコードを上げずに30人の前で言ったってことはじゃあOOPを教えるクラスを開こうとかいう話でない限りその人は１はプロジェクトに要らないという意思表示なわけだから

何にもなしに言い出したのか、その前に１が「バカにははっきりバカと言っちゃう」ことで相手がこの人いらないと思ったのかはバカな俺にはわからないけどね

>>69
普通はいらないと思ったら、30人の前で意思表示じゃなくて、即退場だよ。
パワハラがうるさいから、昭和のノリはアウトだよ。

あと怒ってごめん。
3年目とか見下された上から目線で言われたと感じてしまった。

>>70
ええんやで

3年が3倍の9年でも俺はそのさらに倍以上やってるので3年というのは他意はないんだけれども例えば9年やってたら30人の前で議論できてもいい頃というのもある

例えその人が人事権握ってても日本だと即退場は難しい

怒鳴ったりしたら別だけどOOPの技術的な理解が浅いですねとか経験と実績のあるエンジニアに30人の前で冷静に言われたら俺は不適切だとは思うがパワハラとするのは難しいね

とりあえずそういう状況を打破するのは資格じゃ難しいんじゃないかと俺は思う
まあその現場が資格をすごく重要視するなら別だけどそれが通用するところは技術的にあまりレベル高くない

>>71
あなたは想像で会話を進める癖があるようなのに、わたしのコミュ力を指摘してきたのにｲﾗｯとしてしまった。

コミュ力、、難しいね。

コミュ力もプログラミング力も自己流で年数重ねるじゃだめなのよ。

資格とって基礎固めしよ。
昭和世代は資格を進めない傾向があるのは知ってる。
それでIPAとるの遅れて損してるから、聞かない。

たぶんだけど、
周りが持ち上げて合わせてくれるからコミュ力あると勘違いしてる人いるのよ、社会って

周りは勝手に想像するな、って思ってるけど、穏便にすませようと合わせてる。

上に行けばいくほど、裸の王様

>>72
出てない情報はとりあえず仮定して進めるのもコミュ力だよね
営業もコミュ力と言っている、バカにはバカと言う、30人の前では厳しい、等ヒントは色々ある

戦場みたいなミーティングには会社でやってればいつか出る羽目になるわけで30人の前で論理的に戦って勝てる自信がないとバカにはバカとかやってたらわざわざ戦場にしてるようなもんだよ

まあいきなり向こうが言ってきたのかもしれないし完全に仮定だが

資格をどうだろうねと言ってるのはOOPもそうだけどアルゴリズムとかデータストラクチャーだとかはちょっと勉強して取れる資格では難しくて大学でCSのBSだのMS取ってて10年やってるエンジニアのレベルにはかすりもしないから

まあないよりはあったほうがいいけど上でも書いたけどなるべく英語の本なりCourseraだののコースなりでちゃんとやった方がいいと個人的には思うよ

>>75
ん～、営業も現場の状況を知らない、&途中退場でお金貰えないで、感情的になって怒ってるだけなんだよね、
適切なアドバイスだと思ってない。

まぁ、その教えてくれたやつの証明が資格なんだけどね。
バカみたいにお金かけてもかけなくても成果物同じなら、お金はかけない方がいいし。
カリキュラムあった方が学習進捗はかりやすいし。

もういいよ～。
ありがとね。

日本のミーティングなんて根回しで決まってることも多いし納得いかないならそのOOPわかってないって言われた相手に直接友好的にメールして具体的にどこを言ってるのか教えてもらうとか逆に納得してもらうとかもコミュ力やで

まあ余計なお世話だけどな

ここで話聞いてもらって、パワハラされた、って確信がもてた！
ありがとう

どいつもこいつもオンナがくると寄ってたかって、
ずいぶんと盛り上がってたみたいだな。

男も女も糞コードしか上げてこない
なお中華

コミュ力とは技術力のこと。
技術力がなきゃ、相手が何を言っても
具体的なことなどわかりゃせんわな。

アウアウアーと言ってるようにしか聞こえない。

>>1
具体的ではない指摘は無視していいんだよ
「こうしたらいいんじゃない？」「ああしたらいいんじゃない？」
な指摘も同様
レビュアーも大した考えなしにマニュアル的に指摘してるだけ

とりあえず、デザインパターンを何個か言ってれば周りが持ち上げて合わせてくれて、コミュニケーション能力あると勘違いできる事がわかったのが収穫。
やっぱり知識なんだよね。
知識をつけるには資格が一番楽。

知識があれば周りが持ち上げてくれる。

英語の本、ってなんだよ。
英語で書かれててもゴミ本あるだろ。

英語で書かれていれば神、みたいな勘違いどっから来るの？

スレ主、意味不明なスレ立てるなよ

やっぱりどこか荒ぶってるんだよなあw
他人は自分を映す鏡っていうよ
穏やかに過ごしたいならまずは自分が穏やかで居なきゃ

>>86
確かにそうだな。
読み返しても、無駄に突っかかって、揚げ足とって
勝ち誇った気持ちになって、恥ずかしい。
他人を嘲笑っても、今の状況は何も変わらないのに。
傷付けられた人ごめんなさい。
自分バカみたいだ。
もうだめだ。。

>>87
だめじゃないよ、ちょっと疲れてるだけだ
まずは生活を整えろ
食事、睡眠、運動が基本になるよ
この３つを整えてなるべく乱さないように気をつけて生活するんだ
不思議とゆっくりゆっくりだけど自己肯定感が高まってくよ
自己肯定感が高まればあまり動じなくなるしリカバリもはやい
それから技術書だけじゃなくていろんな思想に触れろ

クソスレ立ててる時点でダメだけどな

>>88
ありがとう。
目の手術したばかりで運動が制限されているんだ。
そういえば、運動が制限されてからだ。
こんなにイライラしているの。

いや、パワハラを受けたのと手術したのが近かったから、
どっちが原因かわからないや。

パワハラされ続けたらどうなってたか、考えるとこわい。
短期間でこんな攻撃的な性格に変わったんだから。

>>90
しっかりしろ無能

>>90
オブジェクト指向って何？

プログラマーじゃない素人の俺に分かりやすく説明できるならオブジェクト指向が分かってるって事になるから説明してみてよ。

俺なら目の前で継承のやり方をドヤ顔で教えて黙らせるね
継承すら知らない無能ならもう知らない

>>92
このスレッドでも言っている人がいるけど、プログラミングの設計手法だよ。
昔はオブジェクト指向がなくて、手続型という手法でプログラミングがされていたんだよ。

手続型プログラミングでも顧客の要件は満たせるんだけど、次の問題があった。
・場当たり的
・同じソースが何度も書かれている
・処理を一つ一つおわないとどう動いているかわからない
・一つのバグを直すのに時間がかかる
・同じソースが何度も書かれているため、1つの修正をしたいだけなのに、数カ所直す必要が出る
Etc

これを解決するのに、オブジェクト指向が出てきた。
この利点を説明する。

車であれば、タイヤ、ドア、エンジンなどに分解できる。
車クラスの中に、タイヤ、ドア、エンジンを元々から用意しておく。

車と言っても、レクサス、ホンダ、トヨタいろいろあるでしょ。
その車を用意する度に、車にはエンジンがあって〜、タイヤもあって〜、ドアもあって〜みたいなのを一々ソースに用意していたら、
あっちにも車、こっちにも車が書かれてる！
みたいな事態が発生する。
しかも、レクサス、ホンダ、トヨタも個別にカスタマイズしたい。
デフォルトの装備しかないんじゃ個性がないよね。

>>94

だから、
車の基本機能を持っているクラスを用意する。
このクラスには、タイヤ、ドア、エンジンを持たせる。
そのクラスを使って、レクサス、ホンダ、トヨタという子供クラスを作る。
これが継承。

レクサスはエンジンがいい、とか、ホンダはタイヤがいい、とかそれぞれに個性を持たせる。

顧客から実は車って、座席数決まってないんですよ。
２シートの車もあれば、６シートの車もあるんです。

なんて、車クラスを作った後から告げられる。
だけど大丈夫。
親クラスに座席数を用意してあげればいいだけ。

子供のレクサス、ホンダ、トヨタもそれを受け継ぐから。

めんどくなっった。

継承を説明させられるなんてなんて屈辱なんだろう。
これはソースで書くから楽しいのであって、他人にドヤ顔で話すなんて恥ずかしい。

てかもう、オブジェクト指向なんか古いんだよ。

>>94
書いてる内容だけではピンと来なかったけど、旧来の順を追って全部書くという手続き型の手法で問題となっていた非効率さを、オブジェクトと呼ばれる構成体を使用する事によって効率化を図る設計なりプログラミングの手法がオブジェクト指向という事か。

コードの重複解消、再利用、バグ発生箇所の特定、チームで認識共有、対応柔軟性などで効率化が図れるようだね。

オブジェクトと呼ばれる構成体はデータとデータを操作するメソッド達でなりたち、オブジェクトを定義するのがクラスか。

オブジェクトのデータやメソッドに他から想定外の干渉をさせないのがカプセル化、クラスを機能を引き継いで階層化して各種効率化するのが継承、同じメソッドでも違う結果を出す特性がポリモーフィズムでオブジェクト指向の3大要素。

これが素人が調べた結果。

>>97
素人に説明するときは専門用語使わない方がいいだろ。
インフレの説明も専門用語を使わずに物語形式で、説明できるで。

ネットで話題になった意識高い系の社長の挨拶文じゃねえかw

インフレの説明させたら、横文字のオンパレードになってなにいってるかわからない状態になる。

>>98
俺が書いたのは素人が調べた結果であって素人向けの説明じゃないぞ。

オブジェクト指向なんか古いんだよ。
出来るやつにしか出来ない技法なんだからさ。
出来るやつに頼ったやり方は、出来る個人が儲かるだけで
会社の儲けにはならねーんだよ。

んーなんだかスレ主の性格に問題があるような気がしてきた
説明がくどいのか、相手をイライラさせる傾向がある

結論から話す、へりくだって話すようにした方がいいような気がする
余計なおせっかいかもしれんが

あるいはコードに思想が反映されていないのかも

DB読み書きするだけの業務システムにオブジェクト指向なんていらんのよね
デザインパターン踏襲してフレームワーク入れときゃだいたい
処理が同じになるし
むしろゲームプログラミングとかね　そっちのが向いてるでしょ

そのデザインパターンが高度なオブジェクト指向なんだが
理解しないでコピペしてるだけだともう上はないぞ

>>84
OOPの本もデザインパターンの本も英語が原書だし訳されてない英語のものは10倍ほどもあるだろ
英語で書かれてれば神ってなんで勘違いしたの？

オブジェクト指向の時代は終わった。理由は単純。オブジェクトとメソッドの関係がわかりにくくなったから。これからは「モダン・スタイル」が主流。このままQiitaの記事一本いける説あります

オブジェクト指向を厳密に説明が出来る人は世界でも数人しかいない。と、オブジェクト指向をそれなりに詳しい人なら大概この話をする。だから他人に向かってオブジェクト指向ではないと指摘するという事は詳しければ詳しいほどあり得ない。

オブジェクト指向できる議論は必ず
ネットでありふれている検索ワードでのみ議論を許す法律が必要

どこの書籍にも載っていない俺々定義をいきなりブチまけてくるアホが絶えない

そんなに有名ならネットで文字列が見つからないのはおかしい

だからお前のは

真のオブジェクト指向じゃないんだ

わかるか？

>>102
ネカマのおっさんが暇つぶししてるだけだと思うぞ

健常者のフリをする気がない発達障害者は、だいたいこういう感じだしな

関数作るのも、クラス作るのも、オブジェクト指向だよな？

クラスの中の関数を全部staticにしてたおじさんいたね

クラス毎staticならよくやる
インスタンスいらんならそれに越したことない

実際「なぜただの関数じゃダメなんですか？」って問いにオブジェクト指向だからみたいな答えしか返せないならstaticメソッドのほうがいい
修正時にフィールド触ってるかとか、余計なことを考える必要も減る

変数毎回リセットすんの？マルチスレッドもガン無視？
仕事でやってんの？

もしかして、static変数とstaticメソッドの違いをわかっておられないか
staticメソッド＝シングルトンパターンだと思っていらっしゃる？
そんな低いレベルで仕事での開発について行けるの？

え？なにまさかクラスに変数持たないで全部メソッドに入れんの？
それ関数型もどきじゃない？

Modelオブジェクトとかどうすんの？ListとかIntegerとか全部オブジェクトなのに自分の書いたとこだけ関数型もどきにするメリットは？

まさかとは思うがそう聞こえたんだけど、メソッドのローカル変数で済むものを全部フィールドに持たせることでオブジェクト指向！とかいってる？

後、正しく状態を保持する意味があればクラスにすればいいんじゃない？
staticメソッド以外使わずシステム作ります！とは誰も言ってないんだけど・・・

だったら結局ユーティティーメソッドみたいなのしかStaticにならないわけで何を今更言い出してるの？

半分以上Staticで書いてんの？

オブジェクト指向より関数型をやった方がいい
より敏感になるから

いや関数型なら関数型でいいんだけどね
オブジェクト指向の言語やフレームワークで自分だけStaticまみれじゃStaticおじさんでしょ

いや、業務ロジックでも関数でいいようなものは普通に出るよ
思考停止はプログラマを無能にするので、息抜きに疑いながら既存のコードを眺めてみると学べるかもね

プログラム言語の進化はスコープ小さくすることでもあって
グローバル→クラス→関数の順で小さいんだから
関数で終わればそれがいい

関数は小さめの方が読みやすいのはそう思うけど関数型とOOPの違いは小さければいいという問題ではないと思うが

半分以上Staticで書いてるの？

もし半分以上でないなら原則としてStaticで書くべき（=理由を述べられない限りStaticにするべき）と言うのは違うよね

Staticで書く理由があるならStaticで書くべきという話でそりゃ当たり前やろ
じゃなきゃStaticなんて無くせばいいんだから

OOPの言語やフレームワークでは原則としてOOPで書くべき（当たり前）で逆

まあ話の内容的にあなたが多分Staticおじさんじゃないというのはのはわかったよ
この板たまに（よく？）Staticおじさんが出るんだよ

実際のところフレームワークはクラスだし、状態持ちたい場面も普通に多いので半分はいかないな。

staticおじさんが何故staticにするのかっていうと、呼び出す側ですべてをコントロールする手続き型をやりたいわけじゃん？
オブジェクト指向にしろ関数型にしろ、呼ぶ側は入力だけ与えれば
「あら不思議！それだけで完全な結果が戻ってくる！しかも呼び元に副作用なし！」ってのがやりたいんだし
それが関数1個で仕上がると判断すれば、シンプルなstaticを優先はするだけ。

staticなんて小規模なアプリとかなら気にすんなって

>>124
やろ？だから原則はOOPで書けという話なんだよ
理由があるならStaticにしないとそもそもOOPがまるでわかってないStaticおじさんが蔓延る

原則関数型でやるなら言語やフレームワークから関数型でやらんと
実際には最近はOOPでも細かい部分は関数型でやってるけどさ

大規模で全部関数というのは俺はやったことないし見たこともない

>>125
まあそりゃ小規模ならなんでもいいよ

staticメソッドなら、ワザワザnewする必要もないからねぇ。
下手にnewさせちゃうとdeleteを忘れてメモリが溢れたりするバグが後を絶たない。

これはStaticおじさん

staticおじさん湧くだろうなぁと思ってたら案の定湧いてた

>>128
JavaのArrayList<>が全部staticだったらどう思う？

staticフィールドだけはやめてくれ...
あれは本気で害悪にしかならん...

関数型ってlisp系統由来の引数が関数だったりメソッドチェーンを採用したりするニュアンスが強くて、単なる構造化を関数型とは呼ばんだろ
c#ならラムダとか多用されるパターンに転用されてるやつ
staticメソッドとは関係なくねーか

そう、オブジェクト指向をちゃんと考えた設計なら、
ところ構わずnewなんてさせないんだよね。
どのタイミングでどの範囲にインスタンスを取るのかってのは、
設計の上では重要だからね、ましてオブジェクト指向なら。

>>126
「Hoge.fuga()」はオブジェクト指向ではないけど「(new Hoge()).fuga()」はオブジェクト指向！
になるだけで意味がないと思うけどな。どうせfugaの中は手続きが500行くらい書かれることになるし。

自分の頭で考えてない以上、どうころんでもおかしなものしか生まれない。
問題があるのはstaticを使うことではない。

>>133
だから「もどき」って置き論破されてんじゃん￥

>>135
誰もStaticが問題なんて言ってないじゃん

半分以上Staticなら「原則として」意味が説明できないならStaticでいいけどOOPの言語やフレームワークで「意味が説明できないなら原則としてStatic」はおかしいという当たり前の話や

最初の言葉の使い方がおかしいしそこは認めないと
原則としてはちゃんとインスタンス化とかを考えてやらないとただのStaticおじさんやぞ

ちなみにずっとStaticのSが大文字なのは単に日本語のIMEだとそうしないと面倒臭いからで他意はない

別に適材適所の話してるだけで、思考停止の原則論の話なんてしてないから、なんか噛み合わないなと思ったけど
staticを許すと、クラスにしたほうがいいかな？なんて誰も考えないで、みんなstaticにするじゃん！って言ってるのか？

つーかクラスにした理由、staticにした理由、どちらにせよ説明できない時点で終わってるので
そうなら、もっとまともな開発者と触れ合えば？って話なんだが・・・

誰もStatic許さないなんて一言も言ってないしむしろ逆だし、そもそもすぐ上でそんなこと言ってないって言ってるのにそれは悲しいね

なんでstaticで盛り上がってんだろ　(´・ω・｀)？
俺くらいのアホプログラマーになると
staticは直接編集、instanceはコピーして編集
くらいにしか思ってねぇわ　エクセルを共有するかコピーするかみたいなｗｗｗ

staticかどうかは割とどうでもいい
どう見ても単なるデータしかないdtoのようなクラスと、それが保証するべき状態または検証が別クラスにいたり上位の手続きに直書きされてたりすると、無言でそっ閉じしたくなるって話よ

速度が速くなるなら使う

クラス変数は名前付きのグローバル変数で、
静的関数は名前付きのグローバル関数
クラスが機能を集約したものならば、機能に関連した関数や変数がひとまとめに
入っていること自体は理にかなってると思うだけど
問題はPGがそこら辺のことをちゃんと理解してないと
グローバル変数を作る罪悪感の軽減として、クラス変数をたくさん作ったりする

さっきから何を言ってるんだこの人達は

OOPが分かってなくても出来る仕事って高度なのばかりという印象
計算科学の世界とか

そらOOPも開発技法の一つでしかなくて研究目的のコードなんかは書き捨ての汚いコードが多いこともあるよ。

ねね
SOLIDの原則守ったらよくない？

SOLIDの原則を崩していい状況はかなり限られてるから
よほどの上級者にならない限りは盲目的に守らないと駄目だと思う

大抵の職場は、ド新人以外はSOLIDの原則を無意識に守れていること前提で回ってる
プロジェクトに話の通じないヤバいPGが紛れ込んでしまった時に、
守るルールに従わせる形で彼らを制御するためにこのような原則が明文化された

お前らそんなこと言ってるが、後ろ3つはともかく単一責任と開放閉鎖が具体的にどうならないと守れてないか論理的に説明できるか？
大半の人間はふんわりした事やセンスとか言い出すぞ

厳密に守れてることが大事なのではなく、明らかに守れてない奴がまずいんだから
倫理的に説明できるか否かなんて問いの建て方自体がナンセンス

どこまでなら破っていいかの判断基準が出せないならセンスって言ってんのと変わんねーぞ

もちろん
動けばいいに決まってるだろ

万物に万能の原則なんてないよね

>>152
理屈ではそうだけど、実務だと明らかにヤバいコード弾ければ十分だから
境界が問題になることはまずない
ヤバい実装でもきちんと動作していて、かつ保守性と拡張性が十分に担保されていればスルー

とか言ってる奴ほどバカなバグを仕込んでくる
ユニットテストもガバガバだからそれを指摘すると
「ここは複雑じゃないからこの程度のテストでいいよ」
いや、すり抜けて他の人のパートに悪影響でてるから言ってるんだけど

テストいらないだろと思えるくらい簡単なコードほどバグってたりするんだよね

テストされてないコードはバグであるって誰かが言ってたけどその通りだわって思った痛い経験はあるなあ

>>155
逆だろ
境界をテストしなくてどうすんだ
むしろどうしても選ばなきゃいけないなら境界だけでもいいからテストしろ

境界値テストの話じゃなくて、設計がセーフかアウトか境界はどこか、その判断基準は？の話やで

オレオレオブジェクト指向

つか全部スタティックでいけない理由を説明しろよ

>>137
意味が説明出来ないなら原則としてスタティックとどこに定められてるの？
どこにも定められていないでしょ？

>>162
オブジェクト指向の発想に伴っていないから

オブジェクト指向は「オブジェクトに管理を任せること」が根本的な考え方だと思う
全部staticならオブジェクトが管理する状態ではないから好ましくない

>>164
それじゃ説明になって無いだろ
スタティックがグローバルと勝手に脳内変換すんな

スタティックの方がメモリ消費量が一定で管理らくだし、確保したり消したりしないからメモリの断片化も起きないような気がする

設計の綺麗さでいったらライフサイクルあった方が美しいんだろうけど、コンピュータには全部スタティックの方が優しい気がする

全部シングルトンで良ければ、全部スタティックでいいよ

スタティックにすることでromに書かれたアプリみたいに扱えない？システムはいつも同じ結果を返すことが要求される
そういう視点でみたらromに焼いたアプリが一番強くて、スタティックで作ればそれに近づけられると思うんだけど

>>168
工場などの電気的ノイズが多い所とかで使う装置なら有効かな
つか、現にそう言うROM化環境はある

>>165
グローバルっていうか、
メソッドはクラスオブジェクト(生成された方)に結び付いていて、static付きはクラス(という型)に結びついているからあまりグローバルと大差ないっていう…

staticで性能がとか使いがってが良くなるとかそういう
問題じゃないスレッド処理もstaticにする気か？

スレッドのメソッドをスタティックにするのは危険な感じ
フォークにすると安全そう

むしろ、コードやデータの場所が固定されるstaticの方が安全だろ
解放されたオブジェクトにアクセスとか絶対に無いんだから

staticは同じクラスの別オブジェクトを扱うのに大変なだけだしなぁ
単一オブジェクトで全部済んじゃうなら何の問題も無い

>>173
スレッドだからパラで動かすんでしょ？
複数のスレッドをスタティックなメソッドで処理することになるわけで、パラレルになるのか、シリアルになるのかよくわからない
想像が追いつかないことはやらない方が良いっておれの直感が告げてるw

ああ、バカ相手にしてたのか
そりゃあ理解出来ないかw

え？だってスタティックってヒープに置かれるんじゃないの？

メソッドはスタックに置かれる！
そんでスタティックなメソッドもスレッドごとにスタックに置かれるらしい
勉強になったw

https://atmarkit.itmedia.co.jp/bbs/phpBB/viewtopic.php?topic=37022&forum=7

>>176
お前みたいに議論も尽くせない癖に首を突っ込むバカって居るよな
どういう心理で動いてるんだろ

基本的な事も分からず思い込みでトンチンカンな妄想を根拠に判断してる奴とは話にならないだけだからなぁw

根拠を求めないで思い込みで行動しちゃうおれの悪い癖がでてたw
申し訳ない

乳首ダブルクリックしちゃうぞ★

女だから論理的思考が出来ないとか言えちゃう職場って反社のフロント企業しか無いだろ
去った方が身のため

女がやってることが多いWeb系のソースみるとマジでゴミだし
ちょっと並程度の人の頭脳で考えた新しいコーディング規則みたいなもので
ソース大量生産されて散布されるの普通に迷惑なんだけど
それでプロですだのフリーランサーですだのPｆに書いてると他の人まで参考にしだしそうで最悪過ぎる

品質Ｓの無名のソースコードよりも
品質Ｂランクくらいのしょーもない名前だけの女が描いたソースコードが参考にされてったら
技術退化していくわ

生物学的視点に基づくオブジェクト指向生体機能シミュレーション
https://jglobal.jst.go.jp/detail?JGLOBAL_ID=200902277633713182

解剖学や生理学でもチンコの話になるとぐっと理解しやすくなるのはなんでなんだろ！
https://tottokotokoroten.hatenadiary.com/entry/20130516/1368716650

ところで「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？

チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

241 伝説の名無しさん sage 2020/10/13(火) 15:00:15.08
「胸がドキドキする」というのはいわば生理現象であり、抑えることはほぼ不可能だ。
月末のクレジットカードの支払額に、想像以上に可愛かったデリヘル嬢のおマンコにと胸を
突かれるのは悪いことではない。

翻って「チンポがシコシコする」というのは能動的な衝動であり、極めて不埒な責任転嫁である。
シコシコはチンポが勝手にやったことであり、決してチンポの持ち主の意向ではないという、どこぞの
政治家の「秘書が勝手にやったこと」のような言い逃れがしばしば聞かれ、あまつさえそれがまかり
通ってきたことは周知の事実である。

チンポからシコシコを奪取し、各人の掌に戻る日は果たしてやってくるのだろうか……。

メッセージングを基礎単位として取ることは、より徹底的な遅延束縛を可能にする。というのも、
メッセージそれ自体は意味を持たず、実際にメッセージがオブジェクトに送信されてはじめて、意味が決まるからである。
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
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。

×
俺.オシッコを止める　俺.オシッコを出す
○
俺.チンポに力を入れる　俺.チンポから力を抜く

>>183
いやいや
かわいい！という理由だけで
バカ女を採用する企業多いから。

男なら採用されないSPI55以下でも
うちはかわいい女の子なら
45でも採用するから。

オブジェクト指向は宮沢賢治の春と修羅に似てる
どちらも因果と関係というキーワードでつながってる

「すべてがわたくしの中のみんなであるやうに
　みんなのおのおののなかのすべてですから」

わたくしのなかにあるみんなの像
みんなのなかにあるわたくしの像

パブリックメソッドが他のクラスとの唯一の通信手段で、そのクラスの特徴。
それはつまりわたくしが持っているみんなへの認識。
反対にみんなが持っているわたくしへの認識。

お互いの関係はそれぞれの認識によって成り立つ
そしてその認識は原因になって結果をもたらす

>>189
>わたくしのなかにあるみんなの像
>みんなのなかにあるわたくしの像

https://mobile.twitter.com/ijh0/status/561134804725284864

バトルチワワ Nitopome
@ijh0
返信先:
@cp_clam
さん
@roa000free チンコってものは自分の意思とは別に反応する事があったり、
逆に自分の気持ちとは裏腹に反応してくれない時があるんですね。
この事から別人格みたいな扱いをするんです。
それで自分の身体の一部なんで
兄弟とか親子みたいな近い存在ってイメージを持つんです。
https://twitter.com/5chan_nel (5ch newer account)

ダウンロード＆関連動画＞＞



令和のコペルニクス さんによって固定されています
令和のコペルニクス
2 年前（編集済み）
六角アミダって有りそうで無かったので自作しました。xyz空間座標も「６方向」ということで。

ソースコードはこちら。

https://drive.google.com/file/d/1hsFT2F4AMgUv1JHqy0si_7Yj7q7TyHnR/view?usp=sharing

室町時代のアミダくじは円形であること、ベンゼン環の六角構造、赤青緑の三色ダイオードを考えてみた。




令和のコペルニクス
1 年前
地動説をとる人には、地動説をとるのを妨げない。天動説をとる人には、天動説をとるのを妨げない。学説上において人びとの所見を妨げず、かつ実生活においても、「令和のコペルニクス」は決して客観的に善悪正誤など認定しない。

>>189
>わたくしのなかにあるみんなの像
>みんなのなかにあるわたくしの像

https://mobile.twitter.com/tanuki_frozen/status/1352658770862608387

たぬを
@tanuki_frozen
チンポを「息子」って表現するのって、もちろん「愛しい突起物」という比喩としての意味もあるが、チンポを別人格で表現することで「理性と性欲が乖離していてコントロールが困難」という含みをもたせられるからではないからだろうか。
https://twitter.com/5chan_nel (5ch newer account)

指向性という言葉があるようにその状態は真偽値ではなく強いや弱い等で表現される
考えても見てほしい酸性やアルカリ性と言うがphは上限下限がない
だからこそ性なのだ
つまりできる、できないで判断し得ない
オブジェクト指向ができないと言ってる本人はオブジェクト指向ができるという事だろうか
とても興味深い

靴磨きの少年が株式投資について語る時、それは天井のサイン
末端の自称エンジニアがオブジェクト指向を語る時、それはJavaの単価が下がるサイン

靴磨きって技術的な世界でもあるな
人類は進歩していかなければならないので、
ザコまで覚えて扱えるようになった技術開発に価値はなくなってる
新しいソリューション
次の時代はGOTOによるラベルプログラミングだよ

オブジェクト指向の背景は「恐れるな、私はあなたと共にいる」だよ
どのオブジェクトにも創造主がいるわけで、その創造主のなかで生きて消えていくんだ

>>196
>どのオブジェクトにも創造主がいるわけで、

我々の創造主は全て「チンポ」！

チンポがシコシコして、人間が産まれた！

なるほど！
似て造ったらあれもついちゃった
あれは力が集中するとこだから気持ち良くなっちゃう
気持ち良いを感じるとこは肉
愛から生まれたと思いたいけど、いやいや肉から生まれたのかもな
で私にもあれはついてた

あれ？
あれってどうやって使ったらいいの？

ブルマのおフクロさんに、俺のチンポがシコシコして、お前は生まれて来たんだ！

☆アルコールは不眠の原因になる

☆アルコールは認知機能の低下や抑うつ症状の原因になる

☆アルコールにより安定していた精神症状が悪化・再発する
　
☆節酒・禁酒により不眠やうつ症状などの精神症状が改善する

飲酒（アルコール）とこころ| 藤沢市の心療内科 精神科 湘南吉田クリニック
http://shonan-yoshida-cl.jp/alcohol.html

>>10
女に忖度するコンパイラ、デバッガあったらカッケーなw

ダウンロード＆関連動画＞＞



令和のコペルニクス さんによって固定されています
令和のコペルニクス
2 年前（編集済み）
六角アミダって有りそうで無かったので自作しました。xyz空間座標も「６方向」ということで。

ソースコードはこちら。

https://drive.google.com/file/d/1hsFT2F4AMgUv1JHqy0si_7Yj7q7TyHnR/view?usp=sharing

室町時代のアミダくじは円形であること、ベンゼン環の六角構造、赤青緑の三色ダイオードを考えてみた。




令和のコペルニクス
1 年前
地動説をとる人には、地動説をとるのを妨げない。天動説をとる人には、天動説をとるのを妨げない。学説上において人びとの所見を妨げず、かつ実生活においても、「令和のコペルニクス」は決して客観的に善悪正誤など認定しない。

意味不明な文章ってどうやって紡がれるんだろ

デカルト座標の導入以降は
天動説でも地動説でもどうでもよくなったんだけどな

おれもオブジェクト指向はしっくりこないな

オブジェクト思考は分ければ分けるほどめんどくさくなる
人間社会と同じ
Aさんに全て任せれば済む話が
Aさん以外の10人のことも考えなければならない

スプラトゥーンの売店の金魚オバチャンはイカタコにとってのインスタンス
イカタコが売店に行かない限り金魚オバチャンは設計でしかない

量子は観測するまで概念でしかなく
観測した時にインスタンス化する
ゆえに現実世界は仮想機械の中にあるのでしょうね

なにこのドクオスレ

>>207
人間社会はお前の言ってる逆だけど？

担当者が居て責任者が居て自分の行動や責任範囲が決まってる
工場だって作業担当とか機械が決まってる

仮にお前の言う通りだとしよう
工場で自動車でも良いしスイーツでも良いけど何か製品を作るとしよう
何で1つの機械とか作業者が全工程を一貫して行わないのか考えた事はあるか

>>211
なにしろ、この世界は能無しが混ざると仕事が止まっちゃうもんだから・・・
否が応でも、できるやつにすべてを任せざるを得ない。

その対価をちゃんと出さないから問題になってるだけのこと。

極論をいうと無能な人は全員死んでくれ
ということになるんだが

>>212
アホやな
能無しが多いからこそ1つの作業だけをやらせる訳やん
幾ら能無しでも数年同じ作業を繰り返せば考える必要も無く体が勝手に動く

>>212
いや、何年やってもできない奴は結構いるぞ
それにそういう作業はAIに淘汰される

>>215
魚の切り身の骨取りとかそういう作業だぞ
蛸の脳みそ取りとか

おまいら、1回聞いただけで理解できた？

1回じゃ無理だった
「ああそういう事か」って思うまで何だかんだ1年掛かった

デザパタというより、SOLID原則に従う事を意識した方がいい
デザパタはSOLID原則のサンプル集みたいなものだから

やっぱ、一回じゃムリだよね
プログラミングまったくの未経験で基礎コースを受講してんだけど
これをみんな理解してるとはとても思えなくて

クラスフィールドとインスタンスフィールド
オーバーライド
for文
色々組み合わさったらどういう風に読んでいいのか全くわからんようになった
文章じゃなく図解のほうがわかりやすいのかなあ
頭は悪くないはずなんだ
教え方が、参考書が悪いと思うんだ
例えば、日本の英語教育
あれで高得点取っても英語ペラペラにならないよね
あれは間違った方法だと思う
それと同じでプログラミングも正しい学び方があると思う
こんなわかりづらい方法ばかりじゃないと思うんだが

メッセージングを基礎単位として取ることは、より徹底的な遅延束縛を可能にする。というのも、
メッセージそれ自体は意味を持たず、実際にメッセージがオブジェクトに送信されてはじめて、意味が決まるからである。
https://qiita.com/ukyo-su/items/8c861f114809a96d1378

オシッコを出したり止めたりというのは、チンポから力を抜いたりチンポに力を入れたりと、
オシッコはオシッコそれ自体は意味を持たず、オシッコが尿道を介してチンポに送られることによって、
オシッコを出したり止めたりが可能になるということだ。

＞ナンチャッテメッセージングスタイルになったのは

チンポ.オシッコを出す
チンポ.オシッコを止める

さっきトイレでやってきた。

＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。

×
俺.オシッコを止める　俺.オシッコを出す
○
俺.チンポに力を入れる　俺.チンポから力を抜く

>>220
機能としては1回で分かったぞ

どう使うとか使った場合にどんなメリットがあるとかそういうのは1年かかった

趣味でデスクトップアプリを作っているが
これはアプリが起動したらずっとインスタンス化してやりとりするから
オブジェクト指向がしっくりくる

逆に仕事はバッチプログラムや手続き型なので
そんなにオブジェクト指向にする必要がないと思う

特に初期からのJava気違いは何でもかんでもオブジェクトオブジェクトってするけど
ほんと意味のないゲッターやセッターを書きまくって
無駄だなと思う

>>224
それは設計と実装を分離していないからだと思う
設計をオブジェクト指向で「ちゃんと」やれば
あとはそれに沿って実装するだけ

>>175
スレッドがメインルーチンとは独立して動くというのは、チンポが本体とは独立して勃起するのと同じ
だからといってスレッドはメインルーチンから制御を受けないわけではない
オシッコを出したり止めたりする時は、本体の制御を受ける

ピストン運動が始まったらもはや制御不能

継承じゃなくて移譲、もしくは子プロセスだと思うんだけど
チンコは喋ったり歩いたりできないから継承ではない

オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。

この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
https://blog.mah-lab.com/2014/03/18/object-oriented/

チンコの随意筋と不随意筋
http://d.hatena.ne.jp/tottokotokoroten/20130516/1368716650

>>229
>チンコは喋ったり歩いたりできないから継承ではない

＜俺＞
「　部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。 」
＜チンポ＞
「　その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。 」

まさに独立した人格を有したチンポという、もう一人の俺がそこに現れるのである！

【藤子・F・不二雄】「みきおとミキオ」現在と未来、憧れの入れ替わり生活！
https://www.google.com/amp/s/middle-edge.jp/articles/0izbO.amp

>>197
クリントン大統領は執務室のトイレでオシッコを出したり止めたりは任意であり実装可能である
けれども「不適切な関係」については大統領権限でもどうすることもできず、
勃起や射精については「別チン格」として、実装をふくまない抽象クラス(Abstract)に

チンコは精子オブジェクトを生成するファクトリー
精子は卵子オブジェクトとコンポジションを形成することで胎児オブジェクトになる
母体から栄養を取り込み出産可能モードへとステータス遷移した後、赤ちゃんオブジェクトとなり出産を終えると生物デコレーターで包まれ飲食インターフェースと排泄インターフェースを備えた人間としてのアクティビティを始める

>>229
委譲と継承の違い

オシッコするときのチンポは委譲、勃起するときのチンポは継承
前者は本体の意思で動かされるメッセージング、後者は独立したチン格で動くポリモーフィズム

継承との違い
継承は親クラスの内容をすべて引き継ぎ、委譲は委譲元の振る舞いを一部引き継ぐ
https://qiita.com/Y_M27/items/a41b2aa8b49e7c3a1a7f

ヘルスで四つん這いにされてアナルを舐められたときに尋常じゃないくらい勃起したのは？

オブザーバーパターンじゃな

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

パスワード忘れとか

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

object もの　目的　は？ｗ
クラス　設計図？　インスタンス　実体
はぁ？ｗ　

やっとわかったｗ
ゆっくり考えたら
平成７年からやっとこのことに取り組んだｗ
そういうことか、たくさん高い書籍ばかり買ってしまった

誰もいない、、

誰もいない、、

なにこれ
同じ処理ばっかりするクラスが40個あるんだけど
なんで継承とかにしないの？
共通の処理で修正入ったら40個全部直すの？

全部違う処理になる予定地だったんだろ？

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

object は物を生み出す力

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、

誰もいない、、