『オブジェクト指向』⬅これなに?10年ぐらいプログラミングしてるけどわからん [158478931]
■ このスレッドは過去ログ倉庫に格納されています
自分でクラス作ってオブジェクトを作れるってだけだろ 毎回オーダーメイドは大変だから設計図作って量産しようねという話 プログラミングって言葉遣いが直感的じゃない、センスがないよね
ややこしい言葉使ったほうが勝ちみたいな世界 あれ。学研の電子ブロックのように、プログラミングも、しよう、と。レゴとかさ。 堀江に言わせればオブジェクト指向から入ったプログラマは能力が低いらしい ただ関数を渡すというのをクソ回りくどく表現してるだけ 狭義のオブジェクト指向はもう廃れたから覚えなくていいぞ 機能毎に振る舞い(関数)と変数を持たせて
整理がついてスッキリするんだ🥺 >>15
全体像が見えにくいからでしょ
経験値つめばそんなことはないよ 厳密にやろうとしてあれもこれもクラスに分けてクソ面倒で最終的にやっぱバランス取って程々に密結合したほうが実装の思想がつかみやすくなっていいよねってなる >>19
BASIC世代がなっとくがゆく説明は、パーツブロックプログラミングだよ、という、その、狭義の意味であろうな。あのだなあ
新規参入を締め出したくて、わざとわかりにくく言うバカおるのよな。 インタンスの概念がよく分からん
クラスのコピー品とか実体とかなんなん? >>28
おまえ、自作のプログラミング、一度もしたことない大先生やろwwww >>28
安倍ちゃんは安倍晋三クラスで俺達は安倍晋三インスタンス >>28
おまえが毎回こういうスレでやっとることは
そういうふいんきレスだけなwwww >>28
実体は仮想メモリ上にロードされたデータ
人によって個別の年令や性別を管理するように、インスタンスごとに個別のデータをもたせる必要がある 依存性を保つために関数渡したいです
関数そのものは渡せないのでクラスに持たせます
オブジェクト指向の本質はガチでこれだけ 外国人はずるいよな
母国語で書けるんだもん
GHQは日本語廃止しとけよ 例えばドライビングゲーム作ろうとしたら、
・車クラス
を作るんだよ。
で、車を走らせようとした時に
車の位置座標を直接移動させるんじゃなく、
アクセル踏むってメソッド呼んだ結果、位置が動くようにするんだよ。 >>28
クラス定義ってのは型紙なんよ
生地に押し当てて型抜きした実態がインスタンス オブジェクト思考と聞いてOOPの話しか出来ないドカタには理解できんわなw オブジェクト、って
まあ、物体、よな。マテリアル。
高学歴ならば頻出単語やけどなあ
大衆の、言葉では、ねえ。それを敢えて選んだとこが、実にいやらしい。 25年前はそうだったけど、もう10年くらい前にはそんな言葉出なくなってたわ 鯛焼きの型 「クラスです」
鯛焼き 「インスタンスです」
あんこ 「アトリビュートです」
カスタードクリーム 「アトリビュートです」
どや!100点やろ? 継承と多態で抽象化してコードを使いまわせるようにするんだろ
知らんけど プログラムの構成要素は手続きとデータで、これのどちらに注目するかの違いだ
手続きにデータを生やすのが手続き型プログラミング
データに手続きを生やすのがオブジェクト志向プログラミング >>44
ほならオリジナルとコピーつーと
わお~わかりやすいになるんだけども
敢えて、そうしない。 プログラムとか全然わからんけど◯◯って何?っていきなり結論に行くんじゃなくてなんでそういうものが必要になったか・なんで新たにそういう考えが生まれたのかって所から勉強すれば理解できるんじゃないの?
最近の人が作ったものなんだし プログラマの上位層とかになるとHaskellからLispに行くけど、
現時点でオブジェクト指向から自由になると言えるのはそれくらいのハッカーだけ 色んな役割の人や物を配置してプロジェクトを実行する
人 や 物オブジェクト >>54
クラスとインスタンスとかはただの機能であって重要なのはこれだと思う モジュールとかアプリの単位でくっつけてある程度は要件満たしてる物を作る
それで足りない部分は関数型や手続きで使い捨てコードを書くのが一歩進んだやり方だからもう覚えなくてもいい >>60
内部の状態変わるのがメソッドで変わらんのが関数 鯛焼きの型 「クラスです」
鯛焼き 「インスタンスです」
あんこ 「アトリビュートです」
カスタードクリーム 「アトリビュートです」
どや!100点やろ? 今どきの言語でオブジェクト指向じゃない言語なんてないんじゃないの
自然に使ってるもの、それがオブジェクト指向だよ なんちゃら.ほんにゃら
↑
こういうのやめて欲しい
意味わからん テンプレとかマクロとか使いだして訳わかんなくなること受け合い ドメイン駆動!オブジェクト指向!手続き型言語!
俺はプログラミングを諦めた >>63
メモ帳でjavascriptでも書いてブラウザで実行すれば? 授業あるらしいけど最近のキッズはプログラミングできるの? >>68
をれ、ギコナビのをれの読んだスレとレスの過去ログの、ワード全検索
まず、BASICでつくって、そのあとで、CとJavaに移植した
半日かかってたのが10分で済むようになった。 処理も書けるでっかい構造体でしょ
継承とか部品単位での利用ってどうせ使わずにまた1からコード書くし >>75
先生がわかってないのに生徒がわかるようになると思う? DB操作や共通部分はクラス化しちゃうけどメンテの多いとこは流れがわかり易いようにあえて手順形式で優しく書いてるわ
>>15
堀江はそんなこと言ってない定期 Cの段階で構造体やユニオンという形でデータのパッケージ化やジェネリクスの理念はあった
構造体だとアラインメントや可変長データの取り扱いが難しくBuggyなのでC++などの後発言語ではクラスを導入してコンパイル時にうまく最適化、警告できるようにした
より厳密なオブジェクト指向言語が生み出されてインターフェースと実装をデカップリングしデータドリブンな構造を徹底しようというのが潮流だった 20年コード書いてるけどいまだに意味が分からないし調べてもピンとこない
たぶんもう実践しているような気がする >>69
関数型プログラミングは、オブジェクト指向の基本的な手法をいくつも否定してる >>76
そーゆーことは、DB使ってやるもんなんだよと、ここで助言されたは。そうすると、一瞬で、済むらしい。 バカ「アニマルクラスを継承した犬クラスと猫クラスに吠えるを実装するってことだよ」
こんな説明してるから一生理解できないんだよな なんもわからんやつはSwitchのゲームプログラミングやれば良いぞ。知らんうちにオブジェクト指向が身につく 継承が多すぎて泣きたくなる事がある
統合環境でツール任せで開発しないと無理だよな
Emacsでの作業が本当に無駄だったと思う 機能の塊を抽象的な表現にまとめたというか
ゲームだと
「動かす物体」が存在して、その中に「敵」「味方」という分類、敵の中に「スライム」「ゴブリン」等々があり
上で言う「」部分の機能をコード化するときにひとまとまりに階層化して管理しましょう、という思想のことだと思ってる 心理学崩れの糞文系が「人間にとってわかりやすい」とか嘘ついてきてたのが
最近のエンピリカルな研究でどんどん否定されてるんだよね グラフィック系だと解るけど
処理をオブジェクトにしろと言われるとちんぷんかんぷん >>28
印鑑がクラスだったら、押された印がインスタンス >>15
ホリエモンはプログラミングに詳しいからホリエモンが言うならそうなんやろな わかりづらくしておいて
わからないのはおまえらがバカだからという屁理屈がまかり通る
そんな世の中です >>95
「戦闘終了後に敵から味方になるモンスターを実装しよう!」ってなったらその設計崩壊するんだよね
だから下手にオブジェクト指向で継承だーとかやったらダメだってみんな分かってきた オブジェクト指向はiPhoneをスマートフォンと呼んでみんなでパクってるのと同じ
Javaをオブジェクト指向言語と呼んでみんなでJavaの仕組みをパクってるだけ
Javaを使い続ければオブジェクト指向は自ずと理解できる
難しい概念から学んでも仕方ない >>103
Cの開発はネオナチ疑惑がある、選民主義している。万人に開かれた扉じゃねーのな。しかし
激速よ。ここが、さすが、ナチス、なのよな。 >>28
変に略すからわからなくなってるだけ
略さずに言うと
クラスの定義
クラスのインスタンス
ってだけ
プログラミング用語は抽象的すぎてわからん
わかるように説明しろ だから、をれらが嫌儲でやったほうがいいのは
Cの、民主化、なのよ。 >>78
昔は前回の開発で使ったクラスをそのまま次の開発でも使えるようにしよう
みたいな芸当がクラスを教える書籍ではまじで推奨されてた
何にでも使える素晴らしい汎用クラスを作って、各プロジェクトはそのクラスから継承する~みたいな べつにプログラミング用語でもねえじゃん
車つくるのにぜんぶ自分でつくるのめんどくせえから
タイヤはタイヤ屋がタイヤだけつくれ
エンジンはヤマハな
ハンドルはって最後に車として組み合わせてるだけだろ BASICは、さいしょから、民主化やったやろ。かんたんなプログラム、誰でも書けるよな。 Juliaならコンピューターが命令を理解する仕方が学べるから
コンピューターの気持ちにまた1歩近づけるらしい C、そうじゃないねんな。うっ、となるように、さいしょから、できてんねんな。敷居たけーのよ、わざと。 ITとは無関係の業界で働いてるがGUIアプリ作ろうと思い立って.NET MAUIとかいう流行ってるのかどうかわからないフレームワーク触ってるが
サンプルアプリがどんな構造してるかどんな流れで動いてるかすらよく理解できんわ で、おまえらが食えるようになるのかい?
IT業界で 継承は駄目
インターフェースはOK
移譲はOK
これで合ってる? オブジェクト指向は、名詞と修飾語の関係だとお前らが言ってた DQで言うならあれだ
パペットマンとかいるじゃん?
あれパペットマンabcと複数出るやん?
でも性能大体一緒やろ?
だからパペットマンの型紙用意して量産する訳よ
でもHPMPは戦闘進んだら個別に減るやろ
そのへんは型紙じゃなく型抜きした実態にメモってく訳
特技だの呪文だのは型紙に書かれてるから型抜きされた実態の方にもある
ざっくりこんな感じ 何?ってHTMLだからjsやれば何となくわかるよ
Document Object Modelというくらいにド直球オブジェクト指向だからね 2000年前の哲学と同じ
当初は学問=哲学だったが、他の分野にノウハウが吸収されていき、現代となってはそんなに重要じゃない
いまオブジェクト指向をありがたがってるようなのはバカです >>114
Pythonのオブジェクト指向は中途半端できもい >>127
じゃあどうでもいいの?
不毛な議論なの? >>120
をれは年内の政権交代狙ってるのと
未解決事件のこたつ探偵やっとるが
自作のギコナビ過去ログワード全検索は、重宝してるで。メシは、生活保護と、フードデリバリーでまかなっとる
今日も五時から深夜一時まで入る予定な。 >>95
オブジェクト指向とは
オブジェクト指向(OOP:Object Oriented Programming)とは、ソフトウェア開発の考え方のひとつで「処理を部品化して、部品を組み合わせることで1つのプログラムを作る考え方」のことを指します。 人がシステム開発を効率的に行うために、多くの言語で取り入れられている概念です。
全然違います >>28
ウマ娘の育成前の解放・覚醒・スキルレベルアップetcの状態がクラス
それをもとに育成した後の状態がインスタンス 変数に専用のサブルーチンプロラムのライブラリをくっつけて
変数名.サブルーチン名
で実行するようにしたものがオブジェクト指向
プログラムは変数っていうオブジェクトに結びついて存在してる >>134
ガチャページに載ってる性能がクラスで、引いたデータがインスタンスな >>130
哲学とかオブジェクト指向とかの単位ではどうでもいいし不毛
議論するなら個別のSOLID原則レベルの粒度まで落とせ >>117
まずWebアプリにすればどのプラットフォームでも動くから特別な理由がない限りjsで書いたほうが楽
センスがあればvueとか使えればもっと楽
それでもアプリ化したいならelectron使えばいい 🎁←こいつが何か機能もっててそれをいろいろ他で使い回す感じ >>133
これが一番わかりやすい
>>136
こいつがわかりにくい説明しているのは
近寄んなしっしっ、が、本音のばあいあるよんこいつな。 (ヽ´ん`) ← 名はケンモメン、能力は嫌儲のスレで書き込みすることです
これがオブジェクトだとしたら関数型とか他のプログラミング言語はどんな風になるの eclipseでJavaを使ってみて何が許されて何が許されないかを体得していけばそれでオブジェクト指向は終わり
結局不特定多数の素人に仕事させる上で継承やら実装やらは品質がブレにくくて便利というお話 最先端のプログラミングではオブジェクト指向は古い悪癖みたいな扱いになってると聞いたことがあるのだがマジ? プログラミングの解説サイトって自動翻訳やらで不自然に横文字が出てくるから全然頭に入ってこない
横文字の意味調べたら大抵日本語で表現出来る言葉だったりするし
>>131
ChatGPTに聞いたら教えてくれたぞ 20年くらいプログラミングの仕事してるけど俺もわからん >>104
あくまで説明用の例だけどね
っつーかスライム・ゴブリンとかは本来はデータで実装するもんであって、この例だとそこまで具体化する必要はないのは確か 自民党でカプセル化して内部でやりたい放題するんだよ。 >>144
マジだよ
今はデータと処理分けるのがナウい
この動画とかずんだもん解説でガイジでも理解できる
https://youtu.be/YuMBCWbXtuw >>121
継承とインターフェースの違いは単にフィールドの有無な訳だが
単なるgetter、setterだけでパフォーマンスを重視するならVTableを挟まずに直でフィールドアクセスさせた方が良いので継承の方が良い Android frameworkはオブジェクト志向の塊や
OS作ったりする場合は必須やろな
事務系のビジネスロジック書いたりする場合はうーんオブジェクト志向いらねってなる 「コンポーネント指向」ってのもあるよね
Reactなんかがそうなんだっけ
意味がよくわからず、何かモヤモヤする >>1
銀河系(全体)に対しての地球(オブジェクト)と月みたいな? 継承できる便利なやつ
時短出来るしカプセル化で安心安全 >>146
偉い
なんか速くなってんねChatGPT >>154
こいつの書いたプログラム絶対いじりたくない >>144
多様態っていうので処理するのが効率いいらしい >>144
時代や分野でベストプラクティスなんていくらでも変わるのにオブジェクト指向にしがみついてるのはバカ丸出し 魔法使い クラス
ハリーポッター オブジェクト
詠唱 メソッド
闇の魔法使い クラスの継承
ヴォルデモート オブジェクト 誰でも自由にアクセスできる変数とかはバグの元なんだぞとC言語にゆいたい >>25
>15の"堀江"は実在の人物ではなく、漫画の登場人物にホリエモンの"顔"を借りてきて喋らせて
いるだけだから、まじレスする必要はない。漫画じゃない実在の堀江貴文は、ライブドアでは
コードを書かずにCTOの↓の人に丸投げしていたが、その人の見解は、良く纏まっている。
オブジェクトは難しくない。難しいのはクラス|小飼弾 2006.11.18
https://xtech.nikkei.com/it/article/Watcher/20061117/254159/ >>154 は
>>121 より物を分かってなさそうな予感 >>151
だよな
オブジェクト指向でAI作れないし >>144
結構マジ
OOP厨はクラスの外に何か持つことを脳死で非難するが
現実問題そんなの事実上不可能だってかなり早い時期から知れてきた
だから厳密なオブジェクト指向なんてやる奴は全員老害 >>163
それはちがう
デカいプログラム書くときは分担作業になるんで自然とオブジェクト指向になるよ。これは永遠に変わらんよ。 スマホンゲーで色んなキャラがいるけどステータスは同じだろ
キャラは一定の雛形に従ってHPとか力とかのステータスをみんな持つわけだ
それは自分でステータスの雛形を決めてそれに従ってキャラを作ってるからだ
雛形がクラス
キャラがインスタンス
特殊能力を決めて行使させる部分がクラス関数
オブジェクト指向は規格を定めて
規格通りのパーツを作って
パーツごとの効果を定めてるわけ >>172
継承とインターフェースの違いを分かっていない点
つまり継承で不要なメソッドをクラスが強制的に持ってしまうコードを書く男であり、それでいいと思っているガイジ ちょっと前までは最先端のOOPが分からないとプログラマ失格!老害!とか言われてたかと思えば
今やOOPは有害とか言い出されてて本当パラダイムの流行り廃りははえーよな ごちゃごちゃとたくさんオブジェクトを作って設計するとスパゲティのゴミになるだけ
頭が悪いんだからシンプルにやるほうがいいよ >>151
普通にオブジェクト指向の範疇じゃん
この動画は勝手に継承をオブジェクト指向の定義の一部みたいな扱いにしたうえで否定してるからおかしい 今どきオブジェクト指向って…
もうかつてのstaticおじさんと同じ存在
いや、むしろ今どきならstaticおじさんの方がいいまである 安倍晋三みたいなものだろ
技術者を導く聖書だけど
原理主義者になってはいけない 哺乳類クラスがあって犬やら猫やらのサブクラスがあってみたいな入門書がもう、ネ…… 無理やりオブジェクトに落とし込むのがナンセンスだと言うことに気がついた人が増えたんだよな てかパーツ化された部品はみんな使ってるだろ
オブジェクト指向に文句言うならライブラリ全部消して一から作りや >>178
まぁな
理論未成熟というかトライ&エラーの過渡期の産物だ
必要な過程ではあった >>36
関数そのものを渡せる言語(関数型言語)は存在している。関数型言語が求められる条件の一つは
関数に関数そのものを引数として渡せる事だが、それらは高階関数という。 オブジェクト指向言語でできること全部Cでも書けるからね適切なライブラリがあれば
Cで書いてみて本当にやりにくいとかfreeがめんどくさいとかいう感想が生まれて初めてオブジェクト指向のありがたみがわかるというか >>178
そんなのは20年以上前の話
パラダイムの発展は恐ろしく遅い おまえらのレス読むより、ChatGPTと対話する方が有益な気がしてきた…… 美少女は排泄しないをゾンビは回避しないに置き換えたのか
流石に例としては下品だもんなw >>172
発言態度でそうみえるのよ
>>121は「何もわからない」「少しはわかる」
>>154は「完全に理解した」みたいなかんじなんだわ
ダニング・クルーガー曲線にあてはめると
121の方が理解度高そうじゃん。 >>139
何基本的なことを聞いてるんだ?と思われるかもしれないけど
スタンドアロンで動くようなデスクトップアプリをWEBアプリで作る場合は
アプリを使いたいPC上でサーバーを立ち上げてそこにブラウザからURLでアクセスして使う感じになるの? >>189
高階関数って聞くと再帰関数のことを思ってしまう 昔の肥大したソースコードってようは
コンパイル済みのライブラリ化してもよくね?ってところがまだ外側に追い出せてなくて繋がっちゃってるだけだ
それがどんどん的確にソースコードの外側に追い出され続けたら、オブジェクト指向はライブラリ開発者だけがやる話になる オブジェクト指向はクソ!
って言って関数型にいった奴らは元気なんだろうか?
〜〜はクソ!
とか言ってるやつは大体どこいってもくそなのでちゃんと今までの経緯とかリスペクトしてやった方が良いよ オブジェクト指向の理想に近ければ近いほど偉いと思ってる頭のおかしい人がいるんだよね >>192
ほんとそう。脳死で継承非難するやつとかの方が害悪
だわ
—-
オブジェクト指向で、継承が有害と言う人がいますが何故ですか?
オブジェクト指向プログラミングにおいて、継承が有害と考えられる理由の一つは、継承を過度に使用すると、クラス間の依存関係が複雑になり、コードの理解やメンテナンスが難しくなる可能性があります。また、継承を使うことで、サブクラスがスーパークラスの内部実装に依存することが増え、柔軟性や再利用性が低下することもあります。そのため、代わりにコンポジションや委譲などの手法を使用することが推奨されることもあります。 デザインパターンとか好きそうwwwwwwwwwwwwwwwwwww >>189
それができないからクラス化したりデリゲート型とか用意してるのがオブジェクト指向ね 動物という抽象クラスから犬や猫を作ってわんわんとかにゃーとか鳴かせるのはオライリー本にも載ってるからな
アメリカ人が始めた奇習や 正直railsでweb屋やってると継承しない方が大体問題起きないからなあ >>177
VTableって言ってるのに実装だと勘違いしてるアホだったか
やっぱりオブジェクト指向批判してる奴ってずれてるんだよな その直後にこれからはアスペクト指向って言われたが火がつかずに消えた オブジェクトっていうネーミングが悪い。
これが全ての元凶。
>>10の説明なんてこの世で最も最悪な説明 >>201
要するにクラスデザインが糞ってだけの問題なんだよな
継承するたびにその糞さが加算されていくから糞な奴が継承使うとより問題が広がるというだけであって >>15
ホリエモンを擁護するわけではないがそれは漫画のキャラクターのセリフであって
現実と創作の区別をつけるけんもめんはちゃんと判断できる 継承とインターフェースの違いを理解するだけでオブジェクト指向の大先生になれるぞ >>201
継承って言語ごとにも微妙に仕様違うからじゃね?
言語ごとに違う挙動をする概念を使うのを良しとするよりは
先頭でライブラリをロードするようなinclude形式で行う事に統一したほうが良いよ
誰かが「継承はこうあるべき」っていう定義を詰めれなかった事にあると思うが getter, setterほど無駄なものはないだろ
イミュータブルにしてフィールドにアクセスしろよ >>25
◯◯すればっていう条件付けてる時点でアウトなんですよ
そんなこと言ったら、なんでもそうだww
答えになってない basicでいうところのgosubやろ
しらんけど >>196
①どっかのサーバーにHTMLを配置する
HerokuやAWSなどは少しハードルが高いし料金もかかる(可能性が高い)、DBなどを使わないレベルの静的Webページならgithub pagesなど手軽に無料で可能
②ローカルでWebサーバーを起動してそこにアクセスする
デメリットはページにアクセスするときにPCを起動してサーバーを立ち上げないといけないだけで、個人的に使うなら全然これでいい
アナタが言ってるのはこっちで、その通りの使い方になる
>>89
例えば何があるの? >>1
プログラマー10年やったけど結局よくわからんかったなあ 昔いた会社で使ってたフレームワーク
一度処理したインスタンスは破棄してもっかい作らんと挙動がおかしくなる意味分からん作りだったの思い出したわ >>204
じゃあScalaのオブジェクト指向は何をしているんだ…? あらゆる工程で金型作った方がより複雑でより迅速に大量のものを作れて便利でだよねって話じゃないの
金型の金型作ったり金型の亜種を作ったりしてあらゆるものや工程を再利用する >>211
いうて他に思いつくか?
テンプレートいうたら別もんだしよ
箱いうたら変数の説明に困るじゃん? 昔の2Dスクロールシューティングゲームを知ってる人はオブジェクト指向をあっさり理解できる 平たく言うと元々はハードウェアのようにパーツ毎で作って誰でも色々と使える
部品=モノを意識して分類整理しようって概念とそれをプログラミングで記述
できるようにしたヤツだったけどソフトはそんなには再利用できんかった
むしろ閉じ込めたから修正難しい事のほうが多い感じ >>216
デバッガーとかが貧弱な頃の苦肉の策だよ
変数へのアクセス時に何らかのアクションが欲しいときにゲッターセッターのメソッドを通してないとデバッグしにくくなるっていう
今は言語レベルでも開発環境レベルでもいくらでもやってくれるんで、ソースコードがそんな業態になる必要がなくなってる つうかもうクラス定義とかChatGPTに作ってもらうしな。使い道も伝えたらめっちゃ綺麗に作ってくれる
—-
犬と猫のクラスを作ってください。継承を使ってもいいです
class Animal:
def __init__(self, name):
self.name = name
def speak(self):
pass
class Dog(Animal):
def __init__(self, name):
super().__init__(name)
def speak(self):
return "ワンワン"
class Cat(Animal):
def __init__(self, name):
super().__init__(name)
def speak(self):
return "ニャー" >>210
Javaの人気WebサーバーSpringのアノテーション連発記法はAOPで今も隆盛なんじゃない?
黒魔術的だからAOPはログ出力だけでいいわってのが全体的なトレンドだとは思うけど ChatGPTに書いてもらうからどうでもいいんだ😠 >>226
さすがにイミュータブルにはならんくないか? >>231
ピションのコードじゃん
どうあがいても見にくい >>235
それで言うならreadonlyとかconstフィールドだって機械語的には別にイミュータブルではないし >>222
プロじゃないから正しいか知らんが完全コンストラクタの考えで作ってるなら安全だし正しいんじゃね >>197
高階関数で自らの関数を渡すのが再帰、他の関数を渡すのが(単なる)呼び出しだが、再帰は
必然的に関数の最終ステートメントで行うので"末尾再帰"となる事が殆ど。関数型言語に
一端のクチを叩いていた著書もある人物が、末尾再帰を知らずに恥をかいていたのは、数年前w 20年以上前に実装継承はどこに実装あるかわけわからなくなるから?ダメだとJava作った人の一人が言ってる
https://www.infoworld.com/article/2073649/why-extends-is-evil.html
>You should avoid implementation inheritance whenever possible. チームとかで開発すると必要になんのかな
未だにウォーターフォールでしか書けない ちょっとした処理で、改良もしないってわかってるなら手続き型が一番手っ取り早いけどな >>228
いうて10年ほど前だけど配置newとかしてた思い出
弾幕系とかだとたしかにそうか >>241
当時の貧弱な開発環境だとそうかもな
でも今はそうじゃないから >>209
ちょっとした茶化しに
あんま真面目に反応されても困る😅
でもまあ真面目な話
インタフェースと継承の違いが
フィールドの有無の違いにすぎないってのは
雑な感じしたのは確かかな〜
昔はJakarta Struts みたく
「ぼくちんのクラスを継承して使ってね」という
くそFWが沢山あって、
その使いづらさにウンザリさせられた連中から
「継承」がヘイト集めまくってるって背景は
この手の議論では弁えててほしい 0か1かで考えてるやついるけど程度問題だから永遠に平行線 >>247
雑も何も実際C++だとそうだけど?
C++にはインターフェースなんてもんはないからね
純粋仮想関数のみのクラスの事を勝手にインターフェースと呼んでるだけであってな
Javaとかそれ以降の言語と違ってC++はJavaなんかのインターフェース同様に継承だって多重でしまくれるしね 各オブジェクトが自分に割り当てられた処理をして
オブジェクト間でやり取りをするような仕組みにすることで
オブジェクト間の依存関係を減らしたりオブジェクト単位の再利用をしやすくする
ってことかな >>232
Javaで一番嫌いなのがアノテーションだわ
Pythonのデコレータがカレー味のカレーなら
Javaのアノテーションはウンコ味のウンコ クラスの話する上で車の部品とか犬だの猫だのの話するやつ死ぬほど嫌いなんだよな
オブジェクト指向=Java だけでいい
ちなみにJavaとは無関係のJavaScriptもJavaと関係があるように装うためにこの名前にしてるくらい大昔からプログラミング言語はJava中心に回ってるわけで・・・
結論Javaは義務教育なんだけど商用の言語だから勝手には使えずオブジェクト指向なんて面倒な言い回しせざるを得ないだけで(Excelを表計算ソフトと呼ぶように)
オブジェクト指向はJavaって呼ぶべきだよ
Javaは神 >>250
C++20 で concept が入ったよ Javaという奴隷言語を覚えさせられて船に無理矢理乗せられて強制労働と搾取されたケンモジ(´;ω;`) >>254
今の時代に合わせるなら「オブジェクト指向=Java」よりも間違いなく「オブジェクト指向=HTML」の方が分かりやすいよ
君の理屈で言うなら神はC++だしね >>254
他の言語でもオブジェクト指向採用してるだろ 今日も貸与されたうんこパソコンでeclipseが重いと愚痴を言う日々なんだろうな 継承が有害なのではなく
人間が継承を使えるレベルに進化できなかったのが悪い 車のパーツで例えると大抵多重継承の発想になるよなぁ
コンポジションに行き着く奴は中々いないんでないか >>255
ん?conceptってC#で言うところのwhere T : struct的な制約でしょ
継承・インターフェースとは違う話だよ 趣味プログラマーだが
設計図書くのはオブジェクト指向の方が楽しくて
コード書くのは関数型の方が楽しい サーバーサイドでDDDやり出すとコード書くのが1/10くらいの速さになる
フロントエンドは今は関数型というか宣言的になんでも書けるからいいよなあ >>254
俺はオブジェクト指向嫌いでJAVAが最も嫌いな言語だから多分そうなんだろうな
イデオロギーが違い過ぎる お前らの仕事用PCのスペックどんなよ?
俺のはM1の16GBだわ
M2の32GBが欲しい 参考書の例が犬とか車とかで実際どう使うのかよく分からんかった
実用できるサンプルにすればいいのに >>254
こういう人って要は業務WEBシステムしかやってないから、オブジェクト指向がしっくりきてないんだろな
上の方で誰か言ってたけど、ゲーム作ったら犬猫の例でもなるほどって思えるからな >>104
スーパークラスで
仲間にならないか仮想関数じゃだめか? カプセル化とかいっても例えばRepository系のクラスをUseCase層でトランザクションだのロックだの意識し出すとクラスの知識外に漏れているよな?
こんなの無理なんだよ Java=オブジェクト指向の説明は割と間違ってないと思う
そもそもオブジェクト指向ってSmalltalkが発祥だけど別にもう関係ないしJavaのコンセプトが所謂オブジェクト指向みたいなとこあるし
でも今のJavaはもう他の言語からいい部分を取り入れる側だよね プログラミングの解説の単語がまず意味をイメージできなくて詰むわ >>250
25年前ならともかくいま
「C++におけるオブジェクト指向」を前提に
オブジェクト指向語られても、それこそ
周りがみえてないお馬鹿さんですねとしか、、、
この手の議論は言語によってOOPの意味するものが
ちがって話が噛み合わないのよ。
アランケイとかsmalltalkとか知らずにOOP語るなと
言う原理主義者もいるくらいで >>269
webだけやっててもモデルとかコントローラとかで理解できるよ
でも自分で継承元から作ってはほぼしないな >>204
高階関数を一般に使えないと思われている、Perl,Python,Ruby,JavaScriptは、実は高階関数を
実装できるので、関数型言語のようなスタイルのコーディングが可能。更に言えば、Unixの
ShellScriptの殆どで(関数がサポートしていれば)高階関数化可能。 >>270
「仲間にならないか」が使えたらおかしいボスキャラとかがいる可能性があるから継承よりかはインタフェースなんだろうね >>263
普通の人がプログラミングをするなら関数型言語の方が自然で理解しやすいだろうね
俺みたいに中坊の時にアセンブラから入ったハードウェア寄りの人間は逆に理解しにくいけども gofの23のデザインパターンに合わせて実装とか昔覚えたての頃よくやったけど
大体改修を重ねる中で新しい仕様に耐えきれなくなったりメンテナが変わると理解できなくなったりするよな >>275
25年前も何もC++23に至ってもインターフェースなんて存在してなくて上で言ったとある条件下の継承をインターフェースを勝手に呼んでる状況は変わってないけど Excelの図形オブジェクト(◯、△、□)とかで説明してほしいよな
それのほうが個人的にはしっくりくるわ 手続き型オブジェクト指向両方出来る奴が勝ち
ちなstaticおじさんはアプリ容量増えるから無しで >>276
モデルとかコントローラーはフレームワークの機能だからな
自分で効率の良いクラス設計する必要がないから継承はいらないんだよ >>276
てかむしろwebフロントエンドの方がド直球にオブジェクト指向まみれだと思うんだけどね
まあ確かに自分でクラス書く事はあんまりないのかもしれんが 一旦オブジェクト指向ではなく手続き型で書いてみれば分かる
例えば普通の言語で引数と戻り値にクラスを使わないしない縛りで書こうとすると限界があるのが分かる
ある変更をしたい場合その場所が関数のネストのネストの深いところになってしまう
これを解決するには関数を書いて渡すことで変更したい処理を手前に持ってくればいい
オブジェクト指向では関数をクラスに持たせることでこれを実現してるってわけ
あとのポリフォなんちゃらとかカプセルとかはオマケでしかない >>275
原理主義者からすりゃDIとか絶許やろ
もうこの手の思想を語る意味なんてない
それこそ言語仕様に則った仕様書けってだけ オブジェクト指向ってネットでネタにされてるぐらい使っちゃダメなことなんでしょ?
本に出てきても読み飛ばしてるわ >>286
ほとんどの場合では宣言型って呼ぶと思われる Javaはそれなりに良い言語だと思うけど
オブジェクト指向という言葉は
人によって意味付けが違いすぎるから
禁句にしていいと思う
私はボブおじさんの考えに賛成で
依存性逆転という規律を働かせることが大切で
そのための仕組みが言語に備わってれば
いいよねくらいに思ってる。
Javaは備わってるかというと微妙で、だからこそ
SpringみたいなDIコンテナが使われたりしてて、、 なんかのフレームワーク使ってる時点で、知らないうちにオブジェクト指向使ってるんやで 小学生でもわかるオブジェクト指向って動画あげれば再生増えるよ オブジェクト指向の全盛期は継承に継承を重ねて逆に読みづらいコードばかりだったわ >>120
20代じゃないと厳しくね🤔
40近くのケンモジ達が資格取っても実務経験ないから無理だと思う🤔 そんなに使いまわせる事ない問題。
結局、一点モノを構造的に整理する以外の意味あるのか?
本気でわからん ガチャコンガチャコンってプログラムを区切ってる感じ 相当物事の原理原則がわかってないと再利用できるクラスなんて常人には作れんやろ
もう誰かが作ってるし グローバル変数使いまくりの迷惑人間はカプセル化と継承だけでも使えるようになれ >>59
コンセプトわかるけど結局色々依存したり、構造深くなったりして責務どこってなるの俺だけ? バックエンド:オブジェクト指向
フロントエンド:宣言型、手続き型、関数型
これでいいやろ 端的にわかりやすく説明できるやついないんだよね
事務しかやった事ないエクセルとかsumレベルでしか使いこなせないレベルでも理解できるように翻訳できる奴がいない
結局どーいうことなのかと クラス作ってインスタンス化して動かすところまでは誰でも分かると思うけど
こいつらをどう組み合わせるか真面目に設計しようとすると急激に難易度が上がる
難しいというかとりあえず仕様通りには動くけどどんな設計が正解なのか誰も分かっていない そんなのどうでもいいだろ
1
12
123みたいな表示さえできればいい >>306
まぁ分かる
最終的にはまぁこっちに処理させるかみたいな雰囲気で決める事が多いけど、責務を意識するのが重要って考えとくといいのかなと思ってる
理想的には色々な原則を守りつつ設計するという前提もあるけど >>313
そんなのforでできるだろ
forはオブジェクト指向なのか? >>311
スタートは現実通りに設計
それがわかりやすさにつながる
ただ要らないことまでやりすぎると冗長になる >>63
ぶっちゃけどれもにたようなもんだから
なんでもいい
cシャープが一番簡単かも
ウニティでゲーム作るとか? >>291
ラムダ式もそれを使わない制御構造(for文やif文等)で書いたものと、lambdaで書いたものを
交互に書き直すことで、理解が進む。又、最も単純なShellScriptを例に出すが、for文の
代わりにxargsでlambdaに近い書き味のコーディングが可能となる。 >>144
どうしてもインスタンスのアトリビュートを書き換える実装になりがちだからな
コピーを作って値を後進して、新しいインスタンスを返すのが >>54
これ
OOP知らん今のスクリプターマジでカオスな実装する >>121
中級者が、継承を安易に使うのを控えるっていう意識を身につける意味ではそれでオッケー
そうやっていつも考えておくと、これは継承、これは移譲ってすぐに判断できるようになる 流石にマクロは組んでるやろ
大体はそれと変わらんわ >>36
二人目だけど聞いていい?
依存性ってなに? 既に何かあるもので何か作っていこうって言うそういう考え方 ゲームで考えると分かりやすい
今マリオを作るって言ってクリボーの動きを一匹一匹直書きするバカいないだろ
普通はクリボーってクラスを作ってそこに動きを書いてそれをステージに置く
まあゲームはゲームで複雑になってくると良く分からなくなってくるけどな >>314
説明下手なのは否定しないが
OOPって一括りが雑にデカすぎるんだよ
原初の説明忠実に守って実装してる奴なんかもはや誰もいない
ガンダムみたいなもん
ぞいぞい言ってないでさぁ! 5chでオブジェクト指向の雑談は
アイドルクラスは人間クラスから継承して良いのか
理由は継承してしまうとアイドルはウンコしないから人間クラスの肛門を継承してしまうことになるからで延々と議論してきた クラス、カプセル化、継承、多態、抽象化を意識して設計すればオブジェクト指向と呼べるのではなかろうか >>330
オブジェクトってクラスを作ってクリボーっていうラベルをつけるわ >>337
いやいや、肛門がついてる事こそが不浄やろという議論になる >>327
クラスを利用する側と利用される側の関係が一方向に保たれていること
たとえば画面クラスはデータベースクラスを利用するがその逆はしないようにする
なぜならコードを変更したい場合変更箇所を限定できるから
話せる人がめっちゃ多いのに何故か人材不足な世界 オブジェクトクラスでやったらアイテムとかエフェクトもそれなの? >>240
なるほどー
こうやって大枠と分類を示してくれるとわかりやすい
いっぱいあってどういう風に分類していいかわからなくなるから >>336
排便は口から食物を取り込み肛門から便として排出する一方向なので、一種のpipeと見做せる。
ある食物やその組み合わせや量がどうあろうと、一意の組み合わせについて、一意の便しか
出ない場合は、チューリング完全が満たされ関数型言語の要件の一つとなるが、実際の人体は、
時々の体調によって便の状態は多様なので、チューリング完全とは言えない。 オブジェクトとは「もの」です
↑
これ言う奴は100%無能だから無視した方がいい
英語を訳した気になってるだけ
そんなのバカでもできる 俺も対してわからん
適当にパクればいいだろ
つかオブジェクト思考がーとか言ってるやつ仕事できないやつ多い 二分ヒープや赤黒木なんかはオブジェクト指向で綺麗に書けるのに実務コードになるとゴチャつき始めるのなんなんやろね
自分としては色んなライブラリが汎用性持たせ過ぎてやる必要ないことまで出来るのが悪い気がしてる >>279
仲間になれるかどうか?を返すapiも一緒に生やしといたら良い 上司「こういう敵キャラ作りたいよねー」
(ヽ´ん`)「おかのした(オブジェクト指向ならちょっと弄るだけで済む ほぼコピペ)」
こういうことですね 海外だとなんで言われてるの?
ガラパゴス日本の説明聞いても「?」ってなるだけやろ オブジェクト指向存在論っていう哲学がある
多分それだろ 他動詞と目的語の関係のように作ると理解しやすいですね、っていう英語思考の考え方 電子ブロックのことって理解してる
ブロック組み立てるとラジオができたりトランシーバーできたりする 疑問なんだがこんなとこでつまづいてたら仕事進まなくね?
あとプログラミングを懇切丁寧に他人に教えるのはありえない たぶんC言語でさんざんな目に遭ってみないとわからない何かだな オブジェクト指向から入った新人は使い物にならないって偉い人がいってたな class MonostateObj:
func doIt(): //...
new MonostateObj().doIt()
こういうのたまに見るけど普通の関数じゃダメなの?🤔 この掲示板行頭の空白消えるやん
こんなんじゃペエソン勢ぶち切れっぞ >>370
普通の関数置くとこあればいいんじゃないの
なんでnewすんの?って話なら別だけど しょうじき全然わからん
JSなんかもオブジェクト指向なんか?
PythonとかVBAマクロもそうなん? >>370
言語も書けよこの野郎
クラスありきじゃないと関数かけない(書きづらい)言語もあるだろ >>373
普通の関数にするといわゆるクラスの中のインスタンス変数が今後必要になった時に色々厳しくなるだろ?
ラムダなら何とかする手段あるからそういうクラス1個につきメソッド1個ってのはラムダで書き直すやり方知ると良いよ いろいろな関連データをそれぞれ別の方法で保持して
おのおの好き勝手に書き換えたり、関数に渡したり
したら、あっという間にスパゲッティのゆで上がりさ
だから、前もってバックに全部詰めといて、決まった方法で
やり取りすれば、少しはましになるだろ?そういうことさ >>370
普通の関数is何
頭にnew付けない奴ってことならJavaScript系以外ではほぼ書けないぞ >>380
根っこまで辿るとスタートはグローバルなmain関数 ぺえそんはスペースとインデントの数がおかしいとブチギレてエラーはくからこのスレは読み込めないよ >>376
それらは拘束が弱いオブジャクト指向かな
オブジェクト指向じゃない方法でも実装できる >>41
なんか分かった気がするぞ
これで俺も一端のプログラマー名乗るわ
独学だからボートレースの自動投票プログラムをVBAで作る以外は一切できないけど オブジェクト指向とは簡単に説明すると
オブジェクトを中心に考えるということ
例えばケンモメンを表す変数kenmoがあったとすると
kenmo.ageでケンモメンの年齢を扱ったり
kenmo.kikou()などでケンモメンの奇行を関数化したりする これはkenmoというオブジェクトを中心にして
他の変数や関数などをkenmoに関連付けるとこによって
一元化しているということだ
それによって全てのの要素はkenmo.~と表現できるようになる >>386 , 388
その段階だとC言語の頃からやってる構造化プログラミングの域
オブジェクト指向はカプセル化云々の話が出来ないと説明になってない モジュール化して抽象度を上げつつ再利用性を高めるための設計手法
一言で言うとこうなる 手段と目的をわかってない奴がいるからダメなんだよな
>>392 これとかただの手段であって、目的は全然別 ポリモーフィズムやカプセル化ってプログラミング以外で自然にやってること じゃあ構造体がオブジェクト指向ではないかと言えば
そんなことはない このスレはスレタイ読まずに発展した内容語るやつが初心者の心折るんだなぁという良い教科書 >>359
「仲間になれるかどうか?」をチェックすれば例外ハンドルせずに済むみたいな感じかあ
うまく言語化できないけど型やインタフェースで防げる例外は型ガードで避けたい
例えると実行時にtrue/false以外にnullとかundefinedみたいなものも返り得るのが苦手的な感じ
極力性的チェックに寄せるみたいな >>192
回答の当否というかもっともらしい嘘が見分けられるならその方がいい わかってなくても
オブジェクト指向言語でソース書いてたら
それすなわちオブジェクト指向プログラミングやってるってことでいいと思うがな C++とかはポインタをキャストすれば何でも渡せちゃうからなぁ >>401
継承元に仲間にできるモンスターと出来なないモンスターがいるよ
という概念を入れておけばええやん
という話をしとる >>394
それをやると単なるByte列を渡している事になるので、Perl以後のLL言語は元より、Sedや
AWKの頃から文字として扱う抽象化が行われてきた。但し、例外的に>240で触れた末尾再帰や
末尾呼び出しではStorageは勿論、それよりずっと軽いmemoryであっても、例外的に処理が
軽く省memoryな"末尾"を指定してする事で、一種の(末尾に限定した)pointer渡しといえる。 もう今どき知る必要なくね?
よほどのマイナー言語いじってない限り お前らが10周遅れでオブジェクト指向を学んでいる時
世界はアドホック多層に向かって進んでるんだよな 組み込みLinuxとかだと最初の準備段階で構造体に値設定して関数呼び出しが延々と続くからオブジェクト指向言語なら楽なんだろうなって思ってた >>360
と思いきやそれでは要求を実現できず、ぐちゃぐちゃの実装になってオブジェクト指向モドキと化すのが現実 オブジェクトを物って訳すなよ
オブジェクトはSVOのOのことだぞ
英語の文法がSVOで命令文もVOだったから
コンピューターでもその文法が当たり前だったけど
Oを先にすることで得られる利点に着目したのがオブジェクト指向な >>341
いわゆる「依存性の注入」辺りの依存性かな
コンポジションしたりする時の話と理解
ありがとう 再利用やらが理念と言うならね
オブジェクトの数は減るほうがいいとも言える訳で
実際はStringと検索するだけで数々のプログラミング言語が出てくる
それどころかjs見てもフレームワーク毎にそれぞれ設計思想を現すように作り
仮想DOMなど速度のためにもまた作る
この辺が限界で当初の思想よりその限界はだいぶ低い 一通り読んだけど
ID:ojHSA8w90 は駆け出しの無能だなって分かる
特に>>104はおかしい
キャラの内部パラメータを継承するクラス構造を作ったとして、そもそも各々のキャラクターが敵か味方かを個々のキャラクターインスタンスに持たせる必要がない
現実の人間関係を考えればすぐ分かるが、個々の人間の中にある「好感度」「好き嫌い」などの主観的認識とは別に客観的な視点の「関係性」は存在する訳だから、
その関係性までをもパラメータとしてキャラクタークラスに持たせて継承するのは完全に間違い
また他のレスも抽出して読んだがオブジェクト指向を古臭いものとして否定したいがあまり感情的になってるとしかか言いようがない
若い人の中には定期的にこういう「古臭い知識は全部ダメ」と感情的に否定したいだけの人間が出てくるので厄介
使える概念は使えば良いだけでわざわざ似たような、あるいはスライドさせただけのような類似概念(>>151の動画にあるような)で置き換える必要はない
どっちも良いとこ取りで使えば良いだけ ハハ、ハッサクゥート!
* o ??:??? o
* o :∴:.: : .:: ::∴ o *
+o ∴:::.. 人 ..:::∴ o +
* o ∴::. (__) .:: ∴ o *
* o ∴::.. (_____) .:: ∴ o *
o ::::..: (___) .:: ∴+
* o ??::.:??.::.:? o
Wolfenstein: Enemy Territory >>425
あれはほぼアセンブラや
そこかしらにgotoやjumpしまくるクソ言語 >>426
アベはいつでもインスタンス化されている 昔だいぶやったけど、今考えるとアレはただの意識高い系だわ。やる必要ない。 >>389
もうちょっと実用的だよ
要はボートレースは3連単がほぼ主流でそれも120通りしかないから
120セルに購入するフラグが立ってるかループ処理で確認する
後はSelenium使ってクリックする要素とかをコードに入れてけばExcelと連動した自動投票プログラム自体はすぐできる
まあ肝心なのはセルにフラグを立たせる条件をどうするか、だから上だけできてもあまり意味はない
プログラマーとしては別にここまでで十分だけどね、ここから先は舟券師の領分
毎回1流し買おうと思えばそういうフラグにすりゃいいだけだからできるよ、たぶん勝てないけど プログラミング初心者やけど
英語とジャップ語の組み合わせ何とかならんの インスタンスは分かるけどオブジェクトが何かが分からない >>432
それって株にも応用できますか?
買うフラグ立ってるかをループ処理みたいな
銘柄は数千あります 一連の処理をラッピングしたものが関数(ファンクション)
その関数をラッピングしたものがクラス
クラスを呼び出して部品化したものがオブジェクト >>436
できると思う
データyahooファイナンスとかでサクッと取れそうだしね クラスの中にあるのは関数(ファンクション)じゃなくメソッドのほうが的確 >>432
なるほどね。たまにボートやるけど、競馬よりパターンは少なそうだからプログラム向きな気はするんだよね
なんかもっと過去のデータとか天気とかを分析してって感じかと思ってたけど、そこは人間がやるんだね コードもデータと同様定数として再利用しやすい形式で記述できる
それだけの話 >>439
無茶苦茶だから気にしなくていいぞ
クラスをインスタンス化したらオブジェクトになる
ってだけ >>440
たし🦀
日本語にするときに用語が変化するのが一番の混乱の元だわ >>441
それもやるよ、というかもう99%はそこの研究だよね結局
そこはプログラマーとしての腕ってより舟券師としての経験やセンスで差が出てくる部分かなと
統計的なデータを鵜呑みにしてそのまま数字突っ込むととんでもない目に遭ったという経験は一度や二度じゃない 構造体で変数を整理する技術がないのにいきなり思想とか教えても身につかない気はするよ。
俺はZ80アセンブラやってた時に構造体の作りしてたから余裕だったけども 関数をクラスという形式にはめ込むことによって
まるごと変数の中にブチ込んで便利に利用できるということなんだ
うんちゃら.ほんにゃらとか具体的に修飾することで
まるごとブチ込んだクラスの一部の機能だけを利用したりできる
はいはい便利便利 ていうかプログラミングしてるならわかるだろ使って覚えるんだよこういうものは
Don't think feelだろ殺すぞ >>446
そこの経験やセンスをアプリにしたら売れると思うよ >>444
英語だと細かく定義が分かれてるのに部分的に日本語で訳す言葉がない事ってあるね
日本語で表すとメンバ関数なのかな
カタカナ混合するけど 最初にチューリングが考えた概念だけど当時の一流の科学者エンジニアたちも理解できなかったしわからなくて大丈夫 嫌儲で聞いてないで技術書買ってきて読めよって話
最初の一冊は絶対ネットの断片知識じゃなくて本で入れた方が良いぞ 深く考えずにまあいいじゃんそういうのの感覚で自然と身につくだろ アフィがまとめるためだけのスレだから本当の初学者なんてここに居ないぞ 難しく考えずに構造体と関数をセットにしたものと思えばいいんだよ
引数で全部渡す代わりにあらかじめオブジェクトに持たせておいてメソッドで処理するだけ 安倍晋三は神オブジェクト
アベノキッズはインスタンス 分かりやすくする単純化するための物なんだけど説明は非常にわかりにくい ドメイン駆動設計の説明読んで頭おかしなってる俺にタイムリーなスレ >>457
それな
範囲広めのスコープ直下で生成されたインスタンスとかグローバル変数みたいなもんだからな
だからこそクラスに持たせる権限や責任をきっちり設計しておかないといけない >>450
売れるほど勝てるアイデアなら自分で回す方がええやんっていうのがこの業界のジレンマよね
AI予想とか言って◯号艇の◯着率は何%とか出してるサイトとかあるけどそれで勝てるなら自分で買えばっていう
だから俺はゴールドラッシュで言うジーパンやスコップなら売りたいけど、自分が実際試してゴールドが出なかった鉱脈の情報を売るのは詐欺みたいでちょっとなあって思っちゃう データ(変数)と処理(関数)のパッケージングと継承による拡張のルール化
C++の場合はそんな感じだと思ってる >>456
定数やで
アリゴリズムとデータ構造 って話だよ多分 >>438
一応言っとくけどYahooファイナンスのスクレイピングは禁止な 組み込み系の教本に湯沸かしポットをのクラス図の例が載ってて水クラスとかあったのを思い出したわ
どういうフィールドやメソッドを持ってたかは忘れたけど
なんでもありだと思った オブジェクト指向だと有形物のロジック化ばかり言われるけど
無形物のロジック化の方が遥かに重要 >>463
まあ100パーなんて誰も思ってないし、ちょっとでも参考になる情報なら値段次第で買う人いると思うよ。信頼度をどうアピールするかが難しいけど >>469
これな。
猫とか飛行機とか現実にあるものなんて簡単で、それこそ競馬の予想ロジックをクラス化せよとかが難しい C++20で入ったとある機能はオブジェクトと組み合わせると漏れなくセグフォする
標準化委員会はOOPアンチか…? (a b c d)
(a b c d (e true) (f false) )
データ構造でもあり、アルゴリズムでもある プログラム(クラス)は文字の羅列、定数
パソコン中の領域を定数で初期化してやることによって実行可能なオブジェクトが出現 中学までの英語教育の敗北だよ
物理や数学、コンピュータサイエンスの言語ぐらい授業で網羅しろや
糞アマ文学部食わせるための科目が英語だろ 嫌儲の教えたがりおじさんたちの居酒屋IT講義もう終わっちゃった >>475
わざとデタラメ書いて初心者を混乱さすなよ
クラスはアルゴリズム(プログラム)も定義できる構造体 VB.NETとLaravelとVue(Nuxt)で社内システム作ってるわ
サクッと作るならここら辺とSQLかじっとけば余裕 やりすぎるとマジで何がなんだかわからないコードになるぞマジで >>478
あほくさ
プログラムの中にいろんな構造体やら含むのは当たり前で、分けるほうがナンセンスだし流行んない データ □
配列
[□,□,□,□,□,□]
アクセス方法 ary[0]
構造体
[□□,□□,□□□,□]
アクセス方法 obj.x
や 理解しているかどうかがバレるというか
これを作れないでコード書いてるのは悲しい x = 0
a = ->{ x += 1 }
b = ->{ x += 1 }
a.call # => ???
b.call # => ??? バカにも分かるように説明できる人が誰もいないのはなぜ? コレで書けるという事は
物事の整理や理解ができていて
仕様も理解していると思う ラムダを返すラムダ
a = ->{
x = 0
->{ x += 1 }
}.call
a.call # => 1 >>487
堂々としてればいいと思うけどなあ。必要なことができてればいいじゃんそういうの
チーム開発でそれが求められてるとかなら話は別だけど オブジェクトとか思想うんぬんより
わかりやすいコードにろや >>494
これよね
自分の書いたコードをメンテするのは他人ということを理解してないやつが多いのよね 食べ物とか商品とか現実にある物体で例えておしえてくれ ネットに上がってるサンプルコードってメイン関数内で完結してること多いから勘違いしちゃうよね
かくいう僕も最初に教科書読んだとき変数の名前はaとかbにしなきゃダメなものだと勘違いしてた >>496
料理人クラスがあるとする
そいつは「料理」かできる
ところで、肉料理は焼きたいし、鍋料理なら煮たい
料理と言っても食材によって調理法が変わってくる
そのへんの知識やスキル(メンバ変数、メンバメソッド)を全て持ってるのが料理人クラス
とする
そうすると、我々は料理人クラスに食材を投げるだけで、妥当な料理が返ってくることを期待できる
いちいち、油の温度はいくらだとか調味料の分量がどうだとか、外野がくちを出すまでもない
ちなみに、俺は減塩派だ
だから料理人に塩少なめでオーダーしたい
クラスがすでに持っている知識を、敢えて外部から注入する仕組みを依存性の注入という
料理人はいつもどおりの料理をするけど、外部からうけた注文に料理の塩味は依存する
だから、依存性を注入するという
ちなみに、この依存性の注入が便利だからといって
片っ端からすべての料理に砂糖塩酢醤油味噌が入れられるようにしたバカタレがJavaだ 名前が悪すぎるよな
例えを出せばすぐ理解できるし今時はレゴブロックでプログラミングできるから視覚的にもはるかに理解しやすい >>452
アラン・ケイじゃなくてチューリングなの? >>496
マザームーン:親クラス
継承
政策集団:子クラス < マザームーン
extend "🏺"
private:
先生方
public:
安倍晋三、岸田文雄
KICKBACK(okane){ okane--; return okane; }
destructer(){ /*山上*/ } >>500
その人知らないからどっちが先かは答えられないけど
チューリングのは棄却された案で評価は受けてない 10進数
1 + 1 = 2
2進数
01 + 01 = 10
ナニカ
() + () = (())
(()) + (()) = (((()))) ここ見てるとアホばっかりでしばらく安泰だなーと安心する 俺パソコンのこと何も知らなくて、プログラミングの知識とかなんもないんだけど
文章書くのにTeXってソフト使ってるんだけど
これってオブジェクト指向だったりする? どの分野にもある、最初の発見者がネーミングセンスなかったせいで変な感じになるやつだろ >>507
まずプログラミング言語じゃなくてマークアップ言語
そのうえでオブジェクト指向かどうかと言えば、オブジェクト指向ではない
しいて言えば手続き型 >>507
TeXはプログラミング言語じゃ全くなくて、自分の書いてる文章の整形と見栄えを指定してるだけだよ >>511
マクロ作ったりもしてるんだけどそれも無関係? テフもマクロも、対象をどうにかする
ってことだからしいて言うなら手続き型だよ
オブジェクト指向ってのは、その対象自体にどうにかするって処理がくっついてんだよ
どうにかする(対象)
と
対象.どうにかする()
の違い >>513
プログラミングがプログラミングたる所以は「逐次処理」
これは難しいことじゃなく、順番に処理するような仕組みのこと
つまり、そのマクロがセルだか文章だかを全部一つづつ読み取って処理してるならプログラミングと言っていい
これはプログラミングにおける初歩的かつ重要な仕組み
全てはココから始まる
だから0でもあるし1でもあるとか言い出す頭のおかしい連中の言うことは聴くな
恐らく一部の処理において早い可能性がある程度の量子コンピュータよりまずはチューリングマシンだ 今夜勤中で職場だから無理だが
家だったら作ったマクロ貼っつけれたんだがな 基本情報の試験勉強してるけど、アルファベットばかりで覚えられない。
MUP、IR、CRとか色々なの覚えられない、 >>507
Texはオブジェクト指向の"オ"の字もない、markupに特化した特殊な記法の言語。 >>510-511
Texはmarkup language(代表的なものとしてHTML)の一種であることは明らかだが、同時に
programing languge特有要素である、制御構文(条件分岐、loop、再帰等)も備え、チュー
リング完全でもある。その点でmarkup languageかつprograming langugeであると捉えうる。 すまんがマークアップってなにンゴ
あとマークダウンってのもあるよな、あれもなにンゴ マークアップの定義は困難
マークダウンの定義は困難 クラス指向だと勝手に解釈してるわ
オブジェクト指向っぽさで徹底するとかなり面倒 >>522
まぁそうだが、その程度で 俺はプログラマーだぜ とかとても言えないだろ? >>521
LuaLaTeXというものがあってだな オブジェクトって名前がわかりにくいよね
人に例えるとわかりやすいんだけど
誰かに仕事させる感じでプログラム作っていくイメージかな 俺「買ってこい」
後輩「何を買ってくんの?」
俺「助六!」
これはオブジェクト指向ではない
俺「助六!」
後輩「助六がどうした?」
俺「買ってきて」
これがオブジェクト指向 A: print "hello"
B: "hello".print
この違いだけで大体は理解できそうだけどな オブジェクト指向って
どういうメリットを目指して生まれたんでしょうか
最近あまり聞かない気がするのは
もっと良いものが生まれたんでしょうか
あるいはデメリットが明らかになってきたからなんでしょうか >>537
同じアルゴリズムを使い回せるから全体のコード数が減る
コード修正箇所も少なくて済む >>538
データに処理をくっつけたものをまとまりとして捉えて
それに別のデータを投げて処理をさせたり
そのまとまり自体を別の処理に投げたりすれば
カブってる部分を何度も書かなくていいよね
ということでしょうか guiコントロールがゴミな時は継承して拡張する時ある >>537
保守性と拡張性に優れた設計をするためだよ レゴブロックみたいなもんやろ
適当にくっつけたらええねん >>539
データに処理をくっつけた まとまり とかって文言がモヤっとするんだが
データと処理が一か所にあったら手続き型に近い
オブジェクト指向なら、まずデータと処理は分離されてる
カブってる部分を何度も書かなくていい 程度なら関数の機能で十分やれる程度のメリット お前が右腕動かす際にお前の右腕の骨だとか脳の神経回路だとか気にしてないだろ?
つまりそう言う事だよ(´・ω・`) 動作をすべてメソッドで定義して、変数をすべてプロパティで定義する
これがオブジェクト指向ということです WEBプログラミングではフレームワーク側はオブジェクト指向しまくってるけど
使い手は手順に沿って実装するだけだから
意識せずに済んじまうのだろう >>31
俺たちはどちらかといえば安倍を引数にしたメソッドを持つインタフェースでは 大きな括りだとマイクラとかもそういう枠じゃないかな
コマンドブロックがあるがそれ単品だと何も動かないけど枠組みは決まってる
何を継承するか決まってる空クラスとかインターフェイスだけ決まってる空メソッドとか コンテナクラスくらいしか使いまわせないよな
メインまでオブジェクト化する意味はない オブジェクト指向っていう日本語がややこしくしてんね 現実世界に無理に例えようとするから余計に訳わかんなくなるのに、まだ例えようとする人がいるんだな >>537
今使われてる大体の言語がオブジェクト指向だから
あえて書かないんじゃね インスタンスコーヒーって入れるメーカー変数で味が変わるけど、コーヒーである事には違いないから安いやつに変えたわ 最近は処理速度を早めるために
データ指向とかも広く聞くようになったな >>546
プログラムリストに
亀動け
って書くだけで動くやつって認識でいいんだよね 他人が作ったやつだと、実装がどこにあるのか訳わかんなくてメンテが逆に面倒になる。正直言って諸刃の剣。陳腐化したら捨てていいようなアプリ開発くらいしか使い所がない。 犬じゃない
SSDに収録されたinuプログラムを
RAMのINU番地に転送した時点でINUは物理的に作動してる現実の物体なのよ オブジェクト指向もそうだけど、IT界隈はパワーワード作って儲けるのが主流だからな
昔からある技術に名前つけて新しく見せたり分かりづらくしたりして、そのコンサルしますよ、とか代わりにいい感じにやっときますよってな感じで商売してる
DXもそうだよな
Web界隈も結局はどうhtmlを吐き出すかってだけなのに、やたら複雑なんだよな
ただのjsonと雛形を分けてhtml形成するだけの仕組みに、手段とか担う所が違うだけで何通りか名前あったりするし
オブジェクト指向の醍醐味は引数でのオブジェクトのインジェクション(Strategyパターンなど)にあるけど
あんま使わんよな
デザインパターンはライブラリやふいれーむワーク側で使っているってだけで
実際にプログラムを実装することはほぼなくね 英語文法のSVOやSVCO、SVOOのVO・VCO・VOOが幾つも集まったのがコード
これを出来るだけVOの種類だけにして可読性と改修しやすさを求めたのが始まり
そのためにデータと処理の分離が必要になった
実際にはVCO・VOOの処理自体は必要だから、できるだけ各クラスの継承下部で書く >>563
たまにお前みたいなまともなホワイトカラーに就かないマジモンの無能が現れるのが嫌儲なんだよな 最近の開発環境だと実際には画面操作のラジオボタンやコンボボックスの中などで既に自動で行われているからわざわざ書く必要は無い
共通モジュールとして使う時にクラスモジュールのほうがコード行数が少なくなる傾向があるから、クラスモジュールのほうが好まれる ·全部の処理を1メソッド内に書くな別けろ
·全く同じ処理あちこちコピペすんな
これだけ守ってくれりゃなんでもいいよもう >>568
それを守らせるための手法の一つがオブジェクト指向 >>569
ここまでなら構造化プログラミングでも出来るでな
そっから先とか別に要らなくね?
話小難しくなるぱっかで大してメリットないじゃん
ぶっちゃけフレームワークが強要してくるから嫌々合わせてるだけよ
俺は便利機能が欲しいんであってお作法()なんか知らねーよ >>570
みんなそんな感じだろ
バカでも使えるようにしないとプロジェクト破綻するし >>570
みんなの共通認識作った方が効率いいだろ。
プロジェクトごとにルールが細かく違ったらだるいわ。それを賢い人が一つの手法として確立してくれてんだよ 状態を保持する変数を、グローバルに持ったりいちいち引数で渡したり
しないで済むのが便利ってだけだわな
継承だの多態性だのなんて、自分がクラスやライブラリを作る側に立ってから
学べばよいものなのに、それを初学者に、それよりも大事なことと横並びで教えるから
やれ動物クラスを継承してワンだのニャーだのという話をしなければならなくなるのさ 多態性とか使ってるソースの読みづらさは異常
テクニックいらんからシンプルに作れや >>572
共通ルールとか言い出すとぼくのかんがえたさいきょう()の押し付け合いにしかならんし現にそうなってるじゃん
必ず厳密化しろと言い出す輩出るからな
実際最近は規約というより指針程度に留めてる現場増えてるみたいよ
ガチガチに縛って失敗した経験が生きてるんだろう >>166
小飼さんが堀江の下請けしてたのか知らなかった >>574
Pythonのfor文なんてまさにその多態性の賜物みたいなもんだけどな 人類には早すぎた理論
抽象化して多態性によりコードをシンプルに、よりif文羅列してシコシコ読んでる方が分かるが9割なんだよ デザインパターンとかまだ勉強してないんだけど、クラスとかインターフェースとか継承とかで共通の動作を保証しつつ、中身はオブジェクトによって変えてくみたいな理解なんだけど合ってる? >>537
pthreadとか関数渡しのライブラリをいじってみればわかるが、変なキャストが絶対に必要になる。
その辺をうまくやったのがオブジェクト指向。
最近の言語は関数型でカリー化が普通に使えたりするから役割は減りつつある。 >>575
そうだよ。だから最低限の共通認識としてオブジェクト指向ってのがあるんですよって話 色んなやり方が試されて、その中で全体最適な要素の組み合わせをオブジェクト指向と読んだだけ
これも30年以上前の話 >>583
オブジェクト指向と聞いてシュバってくるアホウ共もれなく余計なこと喚き散らすやん
上で誰か書いてたがオブジェクト指向って呼ぶのやめたほうがいいわ
下手に名前つけないで中身箇条書きにしたほうがマシ というかオブジェクト指向が共通認識って自体が幻想だわ
誰もが納得する説明誰も出来てないのがその証拠
俺も含めてな >>580
動作よりも責務、役割に注目するといい
責務が同じなら共通化を検討する
責務が違うのに動作で共通化するとぐちゃぐちゃの神クラスが生まれる
継承は完全に理解したレベルになるまでオススメしない、委譲すべし EPICで「ドキドキ文芸部プラス!」っていエロゲタダで配ってるよ > というかオブジェクト指向が共通認識って自体が幻想だわ
同感、学術博士なんて恥ずいもの持ってそうな心理学崩れの糞馬鹿エンジニアもどきの戯言だよね
だいたい、「空腹」みたいな共通の現象だってゲルマン系みたいに is-a で認識する人達もいれば
ラテン系みたいに has-a で認識する人達もいるし、ジャップランド人なんか「お腹が空いた」というイベントとして認識してるし >>586
アホはほっとけばいい
コーディング規約レベルなら箇条書きでいいけど、それも共通認識としてのオブジェクト指向という考えがあるから。それがなかったら
・クラスはこう定義すること。
みたいなことすら箇条書きで書けんよ >>588
その種の話は全く役に立たない。
間違ってる奴らはそれが全部債務が共通だと思ってる。
結局その程度の言葉遣いの分け方じゃ間違いを全く正せない。 >>592
そうなんよな、実際に設計してみて熟練者にレビューでボコボコにされないと理解するのは難しい… >>591
オブジェクト指向てのがもはや呼んではいけない名前になってるつう話よ
話が早いどころか宗教戦争しか呼ばないやん
多少長くとも書き方羅列した方が誤解もない オブジェクトになって誰でも簡単にスマホアプリが作れるようになった
オブジェクトじゃなかったらイベント受付処理で頭がパンクしてる >>594
結局コードの健康を保つためのツールセットでしか無いのにただ気持ち良くなりたいだけのおっさんが
こんな言葉を使ってプログラムを教え込めると信じながら初心者向けにマウントを取る形になってるだけだもんな
コードを読んだり書いたりしながら教えないとこんな言葉だけ吸収したところでろくに技術として身に付かないってのに プログラムの本読んでいきなりオブジェクト指向連呼されると読む気がなくなる。
一応説明はあるけど理解できなかった。 クラスという箱に色んなツールをぶち込んで改造せずに扱いましょうって意味やろ 別にオブジェクト指向つう発明を否定する気はないぜ
マイルストーンとして必要な過程だった
ただ今じゃ殊更名前持ち出す意味はないどころか害悪の方がデカい
歴史に興味がある奴が雑談ネタに知ってればいい 逆に言うと最初のクラス設計でやらかすとプログラミング進んでからはアフターカーニバル >>604
アーキテクチャの指定もなしに機械語を?! >>594
呼んではいけないってじゃあクラスって何経由で学ぶんだよw学び方がアホな奴が手段と目的を混同してるだけだよ。そんな奴はほっとけばいいだけ >>595
わしも初心者みたいなもんだがCでwin32apiとか今の人には発狂もんだと思う 無理に部品にして再利用しなくたって
エディタ側でコピペさせて1本のメイン関数に仕上げちゃってもいいわけで
エディタ側に便利機能を持たせたほうが見通しがずっとよくなるに決まってる 再利用が目的じゃなくて、同じコードは一回書くだけにしたい。それをどうまとめるか?ってだけ >>606
今時なら使いたい開発環境·言語の入門書で学ぶんじゃね?
わざわざオブジェクト指向の本なんざ選ばんし開いたところで役立たんやろ
言語入門書の最初の方にオブジェクト指向と書かれてるかも知らんが
クラスの説明はそっち見ろとか書いてある入門書は返品でいいやろ
普通はクラスやらの説明くらい書いてある 普段から外国人作のオブジェクト指向の部品で飯食わせてもらってると思う 結局VBとかでActiveX貼り付けて楽してますやん >>611
その結果使えない奴が出来てるってことやろ
オブジェクト指向の概念も知らずクラスを使う奴が出来上がり >>14
懐かしいなw
ネットにLibraryがたくさん転がっていて今は楽だよな。 APIとかオブジェクト指向だろと思われがちだがソフトウェア設計として
プログラミング外からの視点で見るとそうでもない
命令を機能で分類してそのラッピングしてるなんちゃって指向が
多いし分類整理はできてるからそれでいいやになってる現実 最近のシステムで1番大事なのはデータベースの効率だよね
オブジェクト指向を基盤として設計するのは本当に正しいのか?
>>618
データベース(笑)
データなんぞ全部オンメモリで処理できる >>619
100件のデータと1万件のデータと1億件のデータの違いを未だに理解できていないアホ
お前ほんと歳ばかり無駄に取って一向に成長しねえよな >>615
今時のフレームワークはオブジェクト指向に固執すると使えんよspringとかな
逆にオブジェクト指向強制されるのもある
銀の弾丸なんか存在しない >>622
固執の話なんかしてねえよ。知った上で使うか、知らないまま使うかの話やろ まあ用語としてはオブジェクト指向言語とオブジェクト指向プログラミングを分けて考えるべきではある。
基本的にはオブジェクトを第一級の型とする言語はオブジェクト指向言語だが、オブジェクト指向プログラミングは「道」みたいなものなので人により定義が厳しい。 所詮、知能にあったことしか理解できないし、知能にあったプログラムも書けない
能無しを業界から排除しないといつまでたっても停滞するだけのこと >>625
言ってて気づいたけど、これってプログラミングのすべての要素に言えることで。
関数型だって言語仕様と副作用のない関数設計できるかは別。
そもそも高級言語を使いながらチューリングマシンそのままの低級な設計も可能。
プログラミングはすべてチューリングマシンの言語糖衣に過ぎないのだから、完全な思想通りの設計なんて存在し得ない。というか非効率。
>>621
1億件のデータ?
数TBぐらいオンメモリで処理できるんじゃね? >>624
用語知らなくたってそれ前提にしてるフレームワーク使うならそういう書き方強制されるから心配すんな
聞きかじりの方がフレームワークに合わない書き方して自爆する確率高いまである 某漫画でプログラマーが悪徳社長と話している時に出てきた謎のテクニカルな用語。 設計と実装を完全に切り離すことはできない
これを言うと原理主義者は怒りだす >>576
ホリエモンもさいしょのころは自分でプログラミングしてたよ クラスのことだよな?
何か動くプログラムを作って
あとからリファクタリングしてそのときにクラスが合うかもしれないし合わないかもしれない
ライブラリで提供されてるのはクラスが多いし
身近な例だと嫌儲を荒らすスクリプトだとクラスは必要ない >>629
メモリに展開できる事と
それをナメて処理していくことは別物や
>>638
なんのためにプログラマがいると思ってるんやねん
データ構造ぐらい考えるやろ >>630
お前の言ってること破綻してんな
知ってるに越したことはないの反論になんもなってない ■ このスレッドは過去ログ倉庫に格納されています