オブジェクト指向 トレンド
0post
2025.11.17〜（47週）
:0% :0% （30代／男性）
人気のポスト ※表示されているRP数は特定時点のものです
COBOL云々の話が出てきたので、少し思うところを。
実際のところ、COBOLはよくできた言語で、今でも現役でいられるのはなかなかすごいと思う。
COBOL技術者がJavaになじめなかった理由としては、「パラダイムシフトだ」とか「オブジェクト指向だからだ」といった説明がよく挙げられる。
しかし、僕は データ管理の方法の違いこそが本質 ではないかと考えている。
僕自身はCOBOLの実務経験がないので伝え聞いた話が中心になるが、COBOLはとにかく データを“桁”で厳密に扱う思想 が強い。これは固定長データとの相性が驚くほどよく、むしろ データ定義そのものがCOBOLの主役 と言ってよい。
「データが決まれば処理が決まる」
――そんなコンセプトがCOBOLの根底にあるのだと思う。
当初のコンピューター環境はリソースが極めて限られており、一度に扱えるデータは可能な限りコンパクトである必要があった。
桁での厳密なデータ定義は、この制約と見事に噛み合っていた。加えて、当時の業務システムは SOR（System of Record）型 で、扱うデータの構造は最初から明確だった。
標準化された銀行間取引用データなども固定長レイアウトが主流で、COBOLにとっては非常に都合がよかった。
しかし、桁による厳密なデータ管理には弱点もある。
・設計確定の時期を後ろに延ばしたい というプログラマの本質的欲求と相容れない
・データ構造の変更・追加に極端に弱い
特に前者の弱点は、社会全体で「システム化」を進める際に致命的だった。“厳密すぎる”設計は学習コストが高く、人材供給の課題と直結していた。
その結果、業界は厳密さの一部に目をつむり、
データを桁で持つのではなく、“型”に基づく参照で扱う言語（Javaなど） へと移行していった。
コンピューターのリソースが指数関数的に増え、多少の冗長さを許容できるようになったことも追い風だった。
やがて、国際決済網や保振のデータ規格も
固定長 → 可変長（XMLやISO20022など）
へと移行していった。この時点で、COBOLの最大の強みであった「桁を基準とした固定長データの扱い」は弱点へと転じてしまった。
本来であれば、この時点でCOBOLは歴史的な役目を終えていてもおかしくなかった。しかし、そこで立ちはだかったのが “膨大なCOBOL資産” である。
その物量ゆえにCOBOLは淘汰されず、
XMLなどの可変長データを受け取って Java 等の処理系でCOBOLが想定している固定長データへ変換する仕組み（逆方向も含む）を用意することで吸収していった。
こうして、可変長データが標準となった以降の時代においても、COBOLは変換レイヤーに支えられながら 今日まで生きながらえている のだと思う。
ここで話を「なぜCOBOL技術者はJavaなどに移行しにくかったのか」に戻すと、理由はオブジェクト指向やパラダイムそのものの問題ではない。
COBOLが持っていた“厳密なデータ観”と、Javaをはじめとする“型と参照による緩やかなデータ観”が根本的に相容れなかったからだと僕は思う。
これは、Javaで育った僕が動的型付け言語に触れたときに、どこか「品質が維持しづらい」「不安がある」と感じてしまうことに近いのだろう。
文化として身に染みた前提が違えば、それを壊す方向の技術には本能的な抵抗が生まれる。それが「型」であれば、動的型付け言語に「型のような仕組み」を後付けすることで違和感を吸収できるが、
COBOLが前提にしていた 固定長／桁基準の厳密なデータ観 は、可変長へ移行する際にそのまま引き延ばすことができない。データ構造そのものが哲学的に異なるからである。
つまり「パラダイムシフトについていけなかった」という言説は、クラスや継承といったオブジェクト指向の概念が難しかったからではなく、“データをどう捉えるか”という文化的で深い部分の違和感と嫌悪感 こそが最大の障壁だったと個人的には思っている。
そして最後にもうひとつ。
文化による「えり好み」は、本来職業プログラマにはとても不利に働く。
新しい言語にしか市場がないのなら、移行を拒めば失業に直結してしまうからだ。ただし、COBOLには前述した「巨大な資産」があった。
その保守には莫大な予算がつき続けたため、
COBOL技術者は結果として 「移らない自由」 を持つことができたのだ。 November 11, 2025
223RP
「OOPを何か悪いもので置き換えているのではないか」(We are replacing OOP with something worse) という主張の記事から：
・オブジェクト指向プログラミング（OOP）は消え去ったわけではない
・OOPは適用される領域が移動しただけであり、それは悪いことだと、記事の著者は考えている
・昔のプログラミングはシンプルだったが、複数人で作業すると問題が起きた
・バグは機能と機能の接点で発生しやすいことがわかった
・そこでインターフェースという契約で機能を切り離す発想が生まれた
・プログラマーの行儀の良さに頼るのではなく、言語仕様として強制するようになった
・カプセル化や継承といった概念が、情報のやり取りを制限するために作られた
・これと並行して、OSの世界でもプロセスの境界線が作られた
・OSはプログラム同士が互いに干渉しないように監視する保護者になった
・コンピュータ同士が通信するようになり、信頼関係はさらに希薄になった
・信頼できない相手に対して、開発者は強固な壁を築くようになった
・その結果、プロセスやネットワークの境界が、かつてのOOPの役割を担うようになった
・現代はマイクロサービスやDockerやKubernetesの時代である
・多くの人がJavaのようなOOPを批判しながら、実は同じ構造を巨大化させて再構築している
・現代のアーキテクチャは、OOPと同じ欠点を持ち、さらにそれを悪化させている
・OpenAPIスキーマは、かつての型チェックの代わりである
・Docker Composeは、かつてのサービスファクトリの代わりである
・Kubernetesは、かつてのイベントループの代わりである
・コンポーネント間の呼び出しには、今や多くの失敗リスクが伴う
・データのシリアライズとデシリアライズという遅い処理が必要になる
・カーネルのスケジューラを通る長い旅も必要になる
・キャッシュの無効化やソケットのポーリングといったコストがかかる
・単なる関数呼び出しだったものが、重たいHTTPリクエストに変わった
・記事の筆者は、OOPの約束事にも懐疑的だったが、現代の代替案はさらに信用できないと考えている
・現代のシステムは、OOPの哲学をプロセス単位やネットワーク単位に置き換えただけであり、その置き換えには、パフォーマンス上の莫大なコストがかかっている
・マイクロサービス化は、OOPの悪い部分を10倍に拡大したようなものである
・開発者はお互いのソフトウェアのことを知らず、信頼もしていない
・信頼がないため、最大限の防御壁としてネットワーク境界を利用しているのだろう
・結局のところ、OOPを捨てて、もっと悪いものを使っているに過ぎないのではないか
https://t.co/1cA1abSFDD November 11, 2025
88RP
世代なんですが、そもそも元ポストの小説が書かれた時期だとまだ 8bit パソコン時代ですから、基本的に BASIC しか選択肢がないのです。C を使える環境はほとんどない。
※CP/M を使うのであれば BDS-C か α-C、LSI C-80 が使えはする
当時の BASIC からだと C って結構なパラダイムシフトになるんですよ（構造化の概念が必要になる）。加えて高級低レベル言語なんて言われるように、ハードに密接に関わった処理を書くことになる（ポインタ操作）ため、アセンブラなどの知識や経験がないとハードルが高かったのです。
加えて、書いてすぐに動かせる BASIC と、長い時間をかけてコンパイルしなきゃならない C とでは、手軽さが全然違うので。
（アセンブルも多少は時間がかかるがコンパイルほどではない）
同様に Java はオブジェクト指向が理解できないと使えないので、COBOL や BASIC などからだとハードルが高かったわけで。 November 11, 2025
1RP
純粋関数型が結局あんまり好きになれなかったというのと、オブジェクト指向紛いが好きということでRustに落ち着いているが、一方でHaskellは本当に思想が良いので、また勉強したい。 November 11, 2025
1RP
とりあえず、プログラミングはC言語やっておけば、オブジェクト指向言語のC#とか普通に分かるようになり、C#理解するとJavaも理解できるようになる。C言語の課題はネットのどっかのサイトにあるのでそれをやってレベルアップすればよい。課題をこなせばC言語もできるようになる。基本のキはUdemyの講座みるとよい。IDEはVisual Studio 2026でよい。C言語は空のプロジェクトでよい。C#のフレームワークはWindows Form アプリケーション .NET Frameworkを使ってプログラミング学習すると楽しく勉強できる。 November 11, 2025
とりあえず、プログラミングはC言語やっておけば、オブジェクト指向言語のC#とか普通に分かるようになり、C#理解するとJavaも理解できるようになる。C言語の課題はネットのどっかのサイトにあるのでそれをやってレベルアップすればよい。課題をこなせばC言語もできるようになる。基本のキはUdemyの講座みるとよい。C#のフレームワークはVisual Studio のWindows Form アプリケーション .NET Frameworkを使ってプログラミング学習すると楽しく勉強できる。 November 11, 2025
すごい！めちゃくちゃ読みたくなった
いくつか読んでたのは嬉しい
フロントメインで行きたいので
オブジェクト指向UIデザイン使いやすいソフトウェアの原理はマストで読んでみよう
エンジニアの技術土台となる知識を得るための本の紹介 https://t.co/0n2ibgneW2 #Qiita November 11, 2025
まんまと欲しくなってしまったが、前の技評セールで買った「オブジェクト指向UIデザイン」積んだままだろと内なる自分にツッコまれゴットア事なき。
勉強が！全然！！出来とらん！！！！仕事だけで精一杯や俺は！！！！ November 11, 2025
はじめての Kotlin【Java 知らなくてOK！丁寧な解説で Android に必要な Kotlin の基本を学習】
3章 2→7/7
4, 5, 6章 済
オブジェクト指向周りの知識がJavaやPHPでも学んだのに忘れてしまう。。。
個人的に保守運用案件多かったから既存プログラムの改修がメインであまり触らないからな気がする🤔 November 11, 2025
気持ち的な話だと会社の研修でオブジェクト指向わからなすぎてすごく講師の人に質問したり教えてもらってるのに、自力で練習問題解けなかった時にすげえ近い。
そのこと思い出して胃が痛いかも、まずい。 November 11, 2025
最近、プログラムの変遷に関する情報をざっくり見た。
それによると…
①機械語（0・1の二進法）による記述
②人間語（C言語など）による記述
③ダイクストラによるプログラム方法の体系化
④オブジェクト指向
…という歴史があるらしい（事実かどうかは未検証）。
↓ November 11, 2025
@giant_more_1014 私はも1番最初はJavaでした！
オブジェクト指向に関する技術書はほとんどJavaで書かれているので、Java読めると学習効率が上がりますよね！ November 11, 2025
もっと具体的な話を書いてほしかった気もするが、まぁ、時と場合によるだろうし。
とはいえ、オブジェクト指向界隈でやたらとコンポーネントの粒度を小さくしたがる理由のひとつにUnit Test自動化の影響は確実にあるな、と。テストのために可読性が下がることが本当に良いことなのか疑念は残るが November 11, 2025
【オブジェクト指向UIデザイン／ソシオメディア株式会社,上野 学,藤井 幸多】
自分には少し難しい内容に感じましたが、ワークを通して実践的に理解を深められた点が良かったです💻
https://t.co/Gy1sn6bQHc
#読書記録 November 11, 2025
最初の勉強におすすめなのは古いですがJavaですね！
あれが一番オブジェクト指向を学ぶ上では良い言語化と！
WEB業界に行きたい人にはおすすめしている https://t.co/OLrQUCdvVj November 11, 2025
圏論、物と物の関連が、構造を作る、すなわち構造がまた、物になる。と、理解すると、さらにそれらの関連があることも理解できるね。設計とか、オブジェクト指向と同じ感じ？なんか、違和感がない。再起的関係？ November 11, 2025
＜ポストの表示について＞
本サイトではXの利用規約に沿ってポストを表示させていただいております。ポストの非表示を希望される方はこちらのお問い合わせフォームまでご連絡下さい。こちらのデータはAPIでも販売しております。
倭人速報公式アカウント
