プログラマに聞きたいんだけどオブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
staticおじさんとは、2010年に@ITに「実はオブジェクト指向ってしっくりこないんです！」と投稿して炎上したおじさんのことである。
staticおじさんが爆誕した2010年ごろのIT土方界隈ではJavaを中心としたオブジェクト指向が主流であり
「なんでもかんでもオブジェクト指向」という風潮があった。このためstaticおじさんは多勢に無勢で
ボロクソに叩かれる結果となり、さらにはプログラミングそのものの話を飛び出してオブジェクト指向
推進派による学歴差別などに発展したすえに、無事炎上した。
それからわずか数年後、staticおじさんの主張に「static変数は使わない」「関数ポインタを多用する」
というコーディング規約を加えた「関数型プログラミング」がJavaScript界隈を中心に爆発的に流行し、
その流れに乗るかたちで半ば強制する仕様の「関数型プログラミング言語」も多数登場するなど一大ブームになった。
ちなみにstaticおじさんの主張と非常に酷似したものが、staticおじさんの登場より遥か昔、
インターネットを支える中核技術である「IP」のRFC（仕様書）にも「階層化の有害性」として書かれていたりする。
また、海外でも同様の主張を面白おかしく書いた「Bjarne Stroustrup インタビュー」なる怪文書が出回り、こちらも大炎上した。
https://monobook.org/wiki/%E3%82%B9%E3%82%BF%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF%E3%81%8A%E3%81%98%E3%81%95%E3%82%93 オブジェクト指向は結局慣れなかったな
オーバーロードとオーバーライドと継承ってシステムがどう動いてるか全部分かってる人間じゃないと無理だろと思ってた 日本にはその議論ができるほどのプログラマーは割合的に少ない バグらなくてちゃんと動いてメンテが容易ならなんでもいい 誰も仕様を理解していないブラックボックス関数が受け継がれていく vb屋の俺にはいまだによくわからないしどうでもいい 昔と違ってメモリは腐るほどあるんだからガベコレやメモリ解放なんてしなくていいじゃん 天才なら
そもそも構造体の段階で
要らないと気づかなきゃ どうあがいても、オブジェクト指向に構成された、ブラックボックスやライブラリの上で書くしかないんだから、愚痴っても仕方ない。 >>16
むしろ中身を理解せずともライブラリやAPIが使えて
必要ならば安全に変更もできるって凄くね？ ドキュメントがろくになくてどう使うのか、結局クラスの中身読み込む羽目になった エンジンとかハンドルとかタイヤを別々に作って
最後に合体させて車にするって誰かが言ってたけど合ってる？ >>17
オールグローバル変数一本グソ
長編プログラミングなら
俺に任せろ >>21
ほんとこれ。
上流では優秀なプログラマがオブジェクト指向を理解してライブラリを作ってる。
下流がついて行けないだけ。 システム間でのファイルの共有関係が管理できてないとバグの温床になる >>26
全部のパターンを使わないとと思うから。
得意なワンパターンつーパターンでよい。 オブジェクト指向わかんないやつって
糞じゃん
勝手にわけわかんないPG作って満足してろ
使えん奴は死ねばいい きちんと管理できて引き継ぎも出来るならいいんじゃね >>30
コードより長いコメントを埋め込んで、書き足して引き継いできた頃よりはるかにまし。
Javaのヘルプみたいなもの書いとけ大体わかる。 >>25
ここではなんか上流前提で最新技術がー英語がーとか言ってるけど大多数は下流だからな よくわからんライブラリから帰ってきた結果にIF文とか普通にありそう OOPの核心とは、カプセル化による構造化と言ってよい
どうだ そら上流こんな所見ないか、見ても書きこまないだろうからな
忙しすぎてそんな暇ない OOPできますって人を面接しても、大抵はデザインパターンつかえるどころか
存在すら知らないソフト技術者（）が多い日本・・・ COBOL時代からサブルーチンコールや定義参照はやってる事だし
オブジェクト指向云々なんていちいち意識した事も無いわ 何で関数型プログラミングとオブジェクト指向が同列に語られてるんだよ >>32
日本ではどれだけ優秀なプログラマーでも下流扱いされる矛盾。 >>40
javaかけるいうても
継承のメリット生かしてない奴らばっかやで
何でおんなじソースポコポコうんでんのかわかんねえ DIってのが未だにピンとこない。
依存性の注入って、日本語になってねーよ 結局理解出来ないままおっさんになっあわ
関数型しか分からん カプセル化とは、人間が一度に把握する情報量を少なくするって事やで Javascriptが難しすぎて営業SEになったわ >>28
覚えたてだったのか、無駄にシングルトンだらけのソースを見たことある。 流行でクライアントの方針に係わるから仕方ない
趣味でプログラムしてるなら好きにすればいい >>50
関数型が分かるほどならオブジェクト指向も理解できそうだが >>13
メモリは増えたけど、使い続けると動的に生成されるオブジェクトがどんどん増えていく一方だから、
メモリ解放しないとメモリオーバーフローで止まる。 みずほ銀行どうなんの？
もうプログラマーを精子から育てるしかなくね？ >>25
そもそも付いていく必要があるのか？とは考えないのか
もっと簡単だったらほっといても皆使うだろうし オブジェクト指向なんてわかる奴がやればいいのにjavaを底辺ITドカタに広めたせいで悲惨なことになった >>57
昔のCしか俺はしらんが今どきの言語は勝手に処理終わったらメモリ解放してくれたりしないの？ オブジェクト指向じゃなくてオブジェクト思想と言う言い方の方がしっくりくる。
作成時にどう言う子に育って欲しいかを明確にしないと、情緒不安定なオブジェクトが出来る。
>>12
VBでも理解して使うと仕事が半分になるよ。 >>61
オートリファレンスカウンティングなら可能 >>61
JavaやRubyはガベージコレクタを実装してるから不要になったメモリは自動的に解放する。
C++は処理の最後でメモリ解放するようにコード書かないと残る。 static使う頭が有るなら
後はフィールド変数化してDIでインジェクションするまで後1歩では こういう風潮が少しでもあるのは初期のとんでもオブジェクト指向本のせいだと思う
憂鬱本とか 半年前に書いたものとかもう宇宙語やし
再利用とか幻想じゃね 一切手を入れずにそのまま使い続けるならいいんじゃね？ >>67
本来は、宇宙語を理解しなくても、何が出来るのかが解れば使えるのがウリじゃないのか？ >>12
オメーみたいなのがクソコード量産してんだよ。引退しろよ クソかもしれないけど、オブジェクトマンセー時代のクソコードを大事にメンテしないとならない仕事がまだまだある >>51
完全に見えなくなると困ることも多い。
「見えない」と「見えにくい」には絶望的な差がある。 しっくりくるまでに時間がかかる
しっくりきてしまえばすごくよくわかる
理解能力の差で片付けられるもんじゃないので、どう言えばうまく伝わるのかでずっと苦労してる ここでされてるような議論というか話は
30年近く前からされてて今になっても何にも変わってない気がする
オブジェクト嗜好が糞なのか、プログラマーが糞なのか、実際の使われる現場が糞なのか
分からないが
そんなこんなしてるうちに自分はプログラマーには成れなかったのだと知った >>75
なんか結局設計がヘタクソって話が書いてあるなw
上の時間軸の問題や規模の問題は、カプセル化による疎結合で解決する話
>>76
見えなくするというより、アクセスの禁止だよ >>67
便利なオブジェクトを作ってみんなで再利用するという夢は破れた。
一見使えそうに見えても
機能の範囲、パフォーマンス、使用リソース、制限、信頼度
はてはエラー処理ルールなどの違いで
似たようなものをもう一度作るハメになる。
特に限界がよくわからないライブラリは使えない。
結局再利用したかったらパッケージレベルまで仕上げる必要がある。
今オブジェクト指向を採用するメインの目的はシステムの保守性向上だと思う。
それが成功しているかはなんとも言えない。 こうしておけば将来役に立つとか助かるよりも
ろくな設計仕様もないままとにかく早くやれ、何時間かけて考えてんだ、とにかく手を動かせって言われるから
後の面倒なんか俺が見るわけじゃねえし知ったことか糞上司、糞職場め！
が勝る そのうちAIがプログラミングもやってくれるようになるさ >>84
AI「仕様をオブジェクト指向で書いてくれ」 >>84
AIなんて高そうなもの使わんでも
そこらの一山幾らの派遣奴隷にやらせりゃいいだろ
って根性の職場でしか働いたことがない pascalいじってて初めてdelphi使った時は感動したがなぁ
0から作る努力をどんどんしなくなったけど オブジェクト指向よくわかんないけどとにかくオブジェクト指向でやれって奴は間違いなくクソ >>90
オブジェクト指向大好きだけど激しく同意
何事も適材適所がある >>16
Linuxの内部システムコールとかはLinusかアンチオブジェクト指向なんで分かりやすくて助かってるわ >>85
AI 「仕様をオブジェクト指向で書いてくれ」
人間「それをするのがおまえの仕事だろ」 >>71
コードを書くときは使える機能は何でも使うから、本人以外いくらでもわかりにくく書けてしまう。 いいえ？
っつーかぶっちゃけ今のUIなんて全部オブジェクト指向じゃん
まさか今更ゲームみたいにメインループで全部のUIの処理回せと？ オブジェクトが悪い訳ではない
必要のない物まで無理やりオブジェクトにしたり、必要のない物にも関わらず直接修正するならまだしもラップして機能修正するからダメなんだよ
使い回さないならstatic
スコープを広く跨ぐならstatic も検討とか使い分けろよ 糞ではないが
オブジェクトサイズがでかくなるのが組み込みに向かない 全機能を全員が把握できてるなら有効なんじゃないかな オブジェクト指向を理解してないのにオブジェクト指向の派生版みたいなのをちまちま追っかけてるやつはアホだなと思ってる めんどくさいからさーデータ型とかやめよーぜ
容量大きくなっても知らんがなー
ここ呼び出してグルグル回せって声かけたらその通りに作ってくれよーAI いちいちvbaのプログラムにprivateを使うやつがいるが目障りなので消す なんだかわからないけどエラーになるメソッドをオーバーライドしました
のような現場猫方式当たり前になるからな オブジェクト指向が糞なんじゃなくて分からない頭が糞
そんな頭をどんだけ集めても肥だめしかできないに決まってる
じゃあ今度は関数指向だとか言ってとびついた奴らの死体が
ノマド壁の前でいっぱい転がってるんだろｗ >>46
継承ばかり言っているのも危険だけどな。
実装の継承は結合が密になるのでよくない。 >>28
そやな、で少しづつ使うのを増やしていけばいい。
上手く使えると凄くスッキリする。
でも、これ使いたいで無理に当て嵌めるとかえってグダグダになる。 何がなんでも二次元で表記しようとするから
プログラマー間で形状を共有できないので
デザインがぐっちゃぐちゃになるんだよ こういうのが話題になるということは、
プログラミングが新しい技術であり、
まだまだ作り上げる技法が確立されていない、
手探りの段階ということなんですか? 生産性を落として強固さを得るので
短期的には損する
資産流用できてないなら更に損する 初見ソースでデータ読んでる所を探そうとファイル検索すると、
readって関数がいくつも出てくる。
正直、使いやすいと思わない。 >>112
その現場、オブジェクト指向もどきを導入してもしなくても多分同じだから大丈夫。 フレームワークがオブジェクト指向そのものなんだからそこに文句言ってもしゃあないやろ そんな何個もインスタンス作るようなクラス、めったにない。static class最高や >>120
話の内容があまりにもアホすぎるから気にしなくていい DIコンテナでinjectionしまくったオブジェクトで
ディープコピーされてないコード見ると泣ける そのうちAIが全部コーディングしてくれるようになるからプログラミング手法なんて気にしなくてもいいよ
AIをデザインする人を目指してんだったら別だけど どう考えても、確保解放を繰り返すより、static で使いまわした方が速いと思う。 オブジェクト指向の概念はコンパイル後には一切残らないんだし
プログラマーの無能を補うための翻訳機でしかないよ >>134
なんも理解できないアホは
無理して話に入ってこなくて良いからw ただでさえ納期に間に合わすのが、やっとなのに
再利用とか継承とかやってたらコストが掛かり過ぎる
暇な連中がやってくれ 汎用フレームワーク作るとオブジェクト指向が理解できるぞ クラスの中にいくつかメソッドを入れて、構造体の延長として考えるだけでも便利になるぞ
オブジェクト指向にびびりすぎなんだよ 文章をそのままコーディングしたような
やたらネストが深くて長い
馬鹿みたいなコード書いてるような奴とは
相性が悪いと思うよ オブジェクト指向的思考があると簡単化できるパターンもあるが
全てをそれでやろうとするのは無理がある ケースバイケースで使い所の違いだけだから
両方有用だわｗ
何でお前らはゼロイチで考えたがるキモオタなん？
ヲタのくせに流行に弱いの？ｗ メモリ上ではどうなってんだかな
Cの時は理解できたんだが 嘘だが 階層化して役割分担して会社組織みたいな全体像が見えてきたのはいいけど、
具体的な処理内容が変数の値によって可変になるようなのばかりで、
結局自分がWeb画面の電文になって旅をしないと目当ての処理が見つからないクソコード >>141
それはオブジェクト指向に限らず大抵の考え方とは相性が悪いような気が、、
まあ、大体がオブジェクト指向とか以前の問題だな。 Javaだとinterfaceとabstract classのどちらを使うべきかよくわからなくなる >>151
んー、それも大事だと思うけど、疎結合を実現するための方法の一つとして、抽象化もあるとも言える。
まあ、「一番」と言ったのは言い過ぎだったとは思ってる。他にも重要なポイントはあるし。 >>151
疎結合は別にオブジェクト指向じゃなくても普通に重要なんだよなあ
何も分かってないね 慣れる、使い続けるとオブジェクト指向がいいかもね。関数メインでも
いいけど。 >>150
正解は無いけど、どっちかと言えばinterfaceを第一候補に考えて、ただ共通で継承すべき具体的な処理があるならabstract classという順序と思ってる。
逆に全てのクラスがそのabstract classを必然的に継承するなら、無駄にinterfaceは入れる必要は無いけど。
ただ、実装の再利用が目的なら無理に継承を使わない方がいいかと。実装の再利用なら、staticメソッドでもコンポジットでも出来るから。 プログラマ自身の適応しなければならない棲息環境からして種々様々だからね職場の上司の云う事を聞き容れて楽になりなさいm9(´・∀・｀) オブジェクト指向とはどんな物なのか分かりやすく教えて マ同士の意思疎通ですらボヤっとした漢字単語で
続いて出る言葉が「お前は理解していない」
端から見てりゃ明らかな情報量不足なのに
提供側も受取側も情報を得た気になってるだけの業界なんだよな >>160
それが難しい。関数プログラムより何が凄いの？と迫られたら困る。
オブジェクト同士で自律的に連携しあってとか云々言っても、究極的には関数同士で呼び合うプログラムやからな。
オブジェクト指向の方が高度ではあるには違いないが、関数プログラム以上のパフォーマンスを発揮する
「決定的な何か」は何なのか説明できん。 COBOL からJAVAのリプレースとかやるとコボラーが設計書起こして「この通り作れ」とか言ってくるからオブジェクト指向もなんもないやたら長いソースコードが出来上がる。 >>160
従来の構造化言語はデータを操作するために関数を呼び出すけど、オブジェクト指向はオブジェクトを操作するためにメソッドを呼び出す。
細かいことはたくさん違いがあるけど、実はあまり変わらない。 >>160
仕様以外の目的に仕事を増やす
客に必要の無いドキュメントを増やす
客に対して、余計な仕事をしたので工数分のお金ください。資料代ください。と言うことです オブジェクト指向好きだから推したいけど、冷静に考えて生産性が上がってるとは
言い難いんだよな
オブジェクト指向の為に新たな知識がかなり必要になり、やれクラス設計だ
デザインパターンだ、多態性だ、継承がどうのこうのだの、インターフェイスでーとか
余計な手間が増えたとも言えるだろうな
若手の育成もより面倒になったと言えるかもね
なんでもオブジェクト指向でーとか必要ないものにも押し付けるべきじゃないと思う だがしかしC言語とアセンブラで
全部出来ちゃうじゃん？
机上の空論だよ >>13
数時間使って終了のソフトなら、リソースは腐る程あるんで勝手にしてくれ。
問題はシステムなんかでは、24時間365日ノンストップで動かし続けなければならないことなんだ。 実際過去に作ったクラスをよそで流用できたことなんてないよね マルチプルインヘリタンスは使わない
そもそもインヘリタンスも使わない
普通に作ればオブジェクトコンポジションになる アジャイルでもペアプロはされない
ソースコード管理システムとバグトラッキングシステムが機能してれば十分 >>173
そりゃちゃんと書けてないだけだろうな。
よく見るよ。汎用性のないクソライブラリ >>160
メモリ管理等ができない下手くそをなんとか無理矢理レールに乗っけようという試み
のこと 言語仕様を熟知してて設計経験の豊富なベテランだけでコード書くならgolangやnode.jsは凄い効率いいけど、
そうじゃない人達が設計思想を台無しにする破壊的なコードが書けないように、作業範囲もカプセル化できるのがクラスベースの言語の良いところだと思う。 >>173
納品しちまうからな。
内製前提の海外向けの言い分だよ。 >>176
ダメな人に、さらに難しい仕事をさせたら
さらにダメな仕事をするだけだしな なんでもかんでもクラスにするとか継承を多用するとかデザインパターンとかはクソ
データ構造に限定して使うのが良さげ 可読性向上にはなってると思うけどね。
新規に参加したプロジェクトがオブジェクト指向で設計されてれば全体的な構造の把握も局所的な機能の把握もしやすいんじゃないかな。 可読性はコードに求める物ではなく仕様書に求めるべきだと思うがね 上手に使えば外国にオフショアしたとしても上流工程で作ったフローから逸れることなく
作らせることできそうだけど、難し過ぎておれにはできなかった 仕様書と異なる実装がされているならそのコードを改修する意味が無い バカでもザコでも開発現場で働けるようにするためのものだよ。
ビジネスロジックだけコーディング規約に従って書かせる。
ライブラリとフレームワークはできるヤツしか書く必要がない。 >>25
上流と下流って工程であって
どちらが優秀かって話しじゃないんだが >>193
無能だって自覚出来てないんだからほっとくのがいいよ といっても
派遣プログラマのやってることって
部品のつなぎ合わせ
やん。 日本のIT産業の人間は自分の仕事を卑下するのはなぜなのか？ >>197
専門職のはずなんだけどな。
従事者は夢も希望もない事言いやがる >>198
専門職扱いされるのは極一部の優秀の人くらいだからかもね
優秀なプログラマーとして扱われるまで行かなかった(行く見込みもない)夢破れた
人たちが愚痴を言ってるというのがほとんどなんじゃないかな
オブジェクト指向もどうしても理解できなくて苦しんでる人も
それなりに居るようだし >>199
オブジェクト指向の理解って、どの辺まで理解してれば理解なんだ？そこがわかんねぇな 「最初の入り口がオブジェクト指向なんだよね最近の子って ほとんどのPGがオブジェクト指向で作られたライブラリ使うだけじゃねーの？ >>197
建築に例えると、建築の勉強をして、世界の名だたるビルディングに負けないようなものを作ろうと意気込んで飛び込んだが、上級企業が全てを仕切ってて、やってることは欧米の後追いオンリー、下手すれば後追いのレベルですらない。
そして、自身は土運びとコンクリート流しの土方作業、または辻褄合わせのドキュメント作成を朝から晩までやらされ、できあがるものは世界的には数世代前の時代遅れの建築物か、公共事業的な必要のないもの。 オブジェクト指向言語で書かれたコードってエラーチェック省きすぎじゃね？ >>200
まあ、難しい問題だな、一言で言い表せんわ
強いて言えば自他ともに文句ない程度かな
うまく言えなくてすまん オブジェクト指向ってことはまだオブジェクトそのものじゃなくて、そこへ向かう途上ってこと？ >>207
俺はクラス、カプセル化、オーバーライド、継承、その程度なら普通にわかるんだがなぁ。
多重継承はバグる原因だから知らないｗ
.netプログラマならオブジェクト指向については皆知ってる気はするんだがなぁ… .netプログラマはオブジェクト指向で自分がプログラムをしていることに気づいてないのがいる
フォームの継承も「そのような機能」で終わらせちゃっていたり >>212
フォームの継承は便利だよな
基本は同じなんだけど微妙な亜種みたいなフォーム量産する時助かる 業務アプリケーションの開発には向かない
初期構築に時間がかかる上に、機能追加等で基底クラスに手を入れると継承している全ての機能をテストする事になり金がかかるので、結局似て非なるクラスが作られオブジェクト指向が崩壊してゆく >>120
プログラム言語の歴史は60年くらいあるが、オブジェクト以前はきちんとコーディング規約を決めてみんながそれを守って
作れば良かった。オブジェクトの概念が入ってくると、既存の言語とは概念が違うので混在させるのが難しい。
で、どちらを使うかから検討しないといけなくなり、オブジェクトでいくと決めた場合は既存の開発手法が使えなくなるので
手探りで開発していかないといけなくなった。オブジェクト以前と違って抽象的な概念が多いので、書いたコードが動いても
それを正確に理解し、保守したり拡張するのが難しくなった。開発者が辞めるとそれを引き継いだ人もオブジェクトの開発経験が
ないと引き継げないのでいろいろ大変。年寄りには無理。 >>129
業務処理は大抵逐次処理で済むからオブジェクトでなくても間に合ってしまう。 >>132
OS作りや速度・効率を考えたらその方がずっと良いと思う。 >>142
C、Pascal、アセンブラなどの旧言語はオブジェクト指向とは無縁 COBOLerがよく口にする「コピー句」って何のことかサッパリ分からんけどなんか格好いい！ >>145
インスタンスを生成したら、そのメソッドを指すポインタ表を作り、処理するときはそこに飛んで処理して、終わったら戻る。
Cでもこうなるようにコードを書けば同じことができる。 >>160
昔の言語は、必要なコード(サブルーチン)を呼び出して動かすのが当たり前だったが、動作に必要なデータは好き勝手に扱っていた。
そのため、あるデータをどのコードが読み書きしているかわからなくなったりしてバグの原因になっていた。そこで、何か処理をするときは、
それを処理するコードとデータを1つにまとめて扱うことにしたのがオブジェクト。こうしておけば、そのデータをいじるのは同じクラス内の
メソッドしかないのでバグがあってもその辺を調べれば原因がわかるようになるし、他のクラスが何をしても別のクラスのデータには影響が
ないから扱いやすい。 >>170
理屈の上ではそうだけど、UIなんかはオブジェクトでやった方がずっと簡単に書ける。
仮にオブジェクトで書いた簡単なコードを全部アセンブラで書いたら何十倍もの時間とコストがかかる。
仕事では開発コストと時間が決まっているから事実上無理。無理にやってそれを超えてしまうと赤字になり給料が出なくなる。 1人で開発する時や何年も同じチームでやっている場合は、オブジェクト指向の恩恵を受ける。
それ以外だと、恩恵が無いだけでなく、トラブルシューティングの工数が増大する。
オブジェクト指向は作った人の考え方が影響するので、オブジェクト「思考」だと思う。
その思考を次のプロジェクトリーダーに継承出来ればうまくゆく。
ちょっと、うまいこと言ってみました。 >>132
ほとんどの場合、オブジェクト指向を使っているかとパフォーマンスは直接関係無い。それ以外の要因だったり、あるいは単に設計やアルゴリズムが悪いだけだったりする。 >>212
どんな現場だよ
煽り抜きに底辺にも程があるぞ… >>217
そんなのまともなテストコード作っとけば基底クラスの変更くらい余裕だろ 俺初めてまだ半年も立ってないけどオブジェクトクラスがどういう子をさしてるかとかよくわからない。
strutsはしね テスト自動化はセットなんだなぁ…まぁどっちにしてもまともなテストコード書くコストはソコソコ掛かりそうだ… >>211
お？やっぱりキチガイだったかw 早く死んどけよ >>153
疎結合のためのカプセル化が本質なんだよ。
だから結局疎結合なの。
staticおじさんが原因で関数化なんっすねー。
へぇｗｗ初めてしったっすｗｗｗｗ
つーか記事書いた奴バカだろｗｗｗぶっちゃけ
static変数を使わないじゃなくて、クラス変数を使わないのが関数型だし
関数がクラスの状態によって返す値が変わってくるのを防ぎたいがために
クラスに状態を持つ変数をもたせたくないよねーつうのが関数型の出発点の一つ
staticおじさんが関数型の出発点とかｗｗｗ
こんなトンデモ史観はじめてっすｗｗｗｗｗｗｗ
継承は結局プログラマのお遊びを助長するだけで
そんなに価値のあるもんではなかった なつかしいなstaticおじさん・・・
でもオブジェクト指向ももう昔の話になってきたと思うな Java覚えたけど、組み込みだと全然使わないな
結局PICもルネサス系のマイコンもARMも全部Cで書いてる
なんか組み込み分野で活かせないかな クソではないでしょ
ゲームの話だが、ポップンミュージックってあるじゃん。あれの「おじゃまポップン」って、まさにオブジェクト指向のポリモーフィズムの仕組みを使ってると思うんだ オブジェクト指向には議論の余地がある
→まあわかる
オブジェクト指向理解できない、だからクソ
→ガイジかな？ APIとかマイクロコードとかっていうの？なんか昔もそういうのあったと思うけど・・・
あれはどうなんだろうか。
しかしハードの進歩は素晴らしい。それを実装してもそれなりの速度出るんだしなあ。
業務プログラムってことだと上に出てる通り結局似たようなものを作る羽目になる気がする。
もちろん下の層のフレームワークは再利用ばりばりでつくられるんだろうけどさ。 ■ このスレッドは過去ログ倉庫に格納されています
