  |
はてなキーワード: オブジェクト指向とは
個人的にTcl/Tkの今の立ち位置は、これはこれでありというか、
例えば、何か新しい言語ができると、まずTkをバインディングしてGUIも作れます！するとかなんだけど、
Tclはオブジェクト指向なの作ってたけど、頓挫してしまったというか、
まあ、MacPortsがTclだったか、所詮シェルスクリプトの延長なので、
Tclはこれはこれでこのままでもいい気もする
TkとかFltkとか、GUI周りは動作するOSとか環境に振り回されがちだし、
独自のレンダリングとかlook and feelを貫き通してもいいんだけど、
それもまた夢がないというか、古臭いイメージが漂いすぎてしまうんで、
Tkもナウでヤングな若者にウケるようにしようぜ、って動きが20年近く前にあって、
こっちもほんのちょっとだけ手伝ってたんだけど、
最近、ネット彷徨ってたら昔懐かしい次世代Tcl/Tkの話を読んだんだけど、
まあ、Pythonだよね！
猫も杓子もPython！
蛇が嫌いなおいらはどうすればいいの？と思ったけど、
その辺の指摘が正しいのではないかと思うんだけど
そもそもはJavaで分散オブジェクト指向が流行したのが問題の歴史的な発端だと思ってる
つまり、RMI（いわゆるRPC）とかCORBA（それは紛れもなくヤツさではないです）とかHORB（産総研だっけ？）とか、
ネットワーク透過だのRPCのスケルトンだの、そういう話が発端な気がする
つまり、インターネット上ではマシンは当然ネットワークで繋がってはいるけど、
マシンAのJavaのプロセスがマシンB上のJavaのクラスを読み込んで実行できたり、
マシンBに肩代わりさせても、それを意識しないように書けると便利だよね、
という話であって、
ぶっちゃけ、今になっても、
世の中的に、今はJavaよりイケてると思われてる言語にも、この手のネットワーク透過にする機能とか、
よー知らんけど、クラウドコンピューティング（）だなんだの機能としてあっても不思議ではない気がする
昔で言うなら、ソニーのTelescriptとかよー知らんけど、
ネットワーク上の複数のマシンを渡り歩くプロセスというかプログラムみたいなのが実現できるのって、
今になって考えてみると脆弱性の温床でしかない気がするし、理解はできる
理解はできるが、じゃあ、まったくメリットがないのかというとそうでもなくて、
しかし、Javaのかつての流行が放置されたままになってるとか、そういう問題はあるわけで、
その辺がセブン＆アイだったかの、Struts2のOGNLインジェクションもそんな感じで、
ぶっちゃけ、マシンAからHTTPでマシンBのJavaクラスとか実行できたら便利だよね、みたいな話で、
マシンAとマシンBが外のネットワークと敷居があるという前提があるから問題がないのであって、
CGIでもよくあったけど、サーバー側の任意のコマンドを実行できるというのは、
サーバーの状態を監視するとかには便利だけど、当たり前だけど危険だよね、という話であって
眠くてまとまらない…
おやすみ…
あ、言い忘れるところだった
知らんけど
就活時の適性検査って優劣じゃない名目の奴でも実質的な足切りラインみたいなのが設けられているところは結構あって、
IT系とかの場合、実績とかはそこそこある人間でもこの辺りで足切りされてそもそもアピールする場所にすら立てないみたいなことが結構あって、
自分は学生時代で開発系のコンテストで結果残したり作ったアプリがニュースサイトに取り上げられたりそこそこの規模のWebサービス運営してたりってまあまあ強みはあったと思うんだけど、
就活時この辺りですっっっげーーーー苦労した。
MVCやオブジェクト指向の意味がわからないどころかプログラミングすらやったことない同期が次々内定取る中で俺だけが最後まで取り残されてった。
この手の企業が「弊社は多様性が尊重します」「どんな人種、ジェンダー、性的指向の人でも働きやすい環境を！」とか偉そうなお題目を並べてるとつい白い目で見ちゃう。
「ああ、この人達の言う多様性という言葉の中に俺みたいな人間はどこにも含まれてないんだろうな」
「ちゃんと（今話題になっているポリコレ属性リストに書かれている範囲内の）多様性を尊重しますって書いとけよ」
そんなことをつい考えてしまう。
手続き型が主流でひたすら頭からだらっと書いてあって、せいぜい「サブルーチン」に処理が分けてあったくらい。 Web だと .cgi に全部書いてある。
そういう世界では、こういうまともな書き方もあるんですよ、という紹介ができる良いものだった。今はどんなに酷くても当時よりまともなだけ。
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
アラン・ケイらによってAlto上で開発された世界初のGUIベースのオペレーティングシステム (OS) 的存在であるSmalltalkは、パーソナルコンピューティングの方向性をエンドユーザーに示すだけでなく、オブジェクト指向の概念を本格的に取り入れた設計で開発者にもアピールし、このときのオブジェクト指向によるOS（APIやフレームワーク）設計は、現在最先端と言われるOSにも今なお色濃い影響を与え続けている。
1970年代半ばにはすでに、ウインドウシステム、メニュー操作、アイコン付きパレット、WYSIWYGエディタなど、現在のパソコンに匹敵する特徴も備えていた。出資受容の条件に要求してこれを見た、Apple Computerのスティーブ・ジョブズに大きな影響を与え、LisaやMacintoshを開発させるきっかけとなった。
NewsWeek日本版によると、インドで新型コロナウイルスの新たな変異株「デルタプラス」が「懸念される変異株」に指定されたそうだ。
https://www.newsweekjapan.jp/stories/world/2021/06/post-96559.php
かつてインド株と呼称されていた変異株がデルタ株であることは把握している方も多いであろうが、デルタプラス株とは何かNewsWeekの記事では説明されていない。
調べてみると、インドで2番目に発行部数が多いという地元英字新聞のザ・ヒンドゥーには既に3日前にデルタプラス株の解説記事が出ていたようだ。
ザ・ヒンドゥーによれば、デルタプラスはAY.1またはB.1.617.2.1と呼ばれていたもので、デルタ株(B.1.617.2)の変異株だそうで、これまでに143のゲノムがAY.1としてラベル付けされ、インド以外にもネパール、ポルトガル、スイス、ポーランド、日本、ロシア、トルコ、イギリス、フランス、アメリカ、カナダからも報告されているそうだ。
つまりネーミングから察せられた通り、デルタプラス株はデルタ株の変種であり、既に日本を含む多くの国で確認されていることになる。
(ここまで普通の内容)今後の状況推移が気がかりであるが、既存事例を参考に占ってみよう。(以降、大喜利)
●事例1「ラブプラス」
「ラブプラス」は恋愛ゲームとして異例の20万本を超えるヒット作となり、その後各種シリーズが製作された。
最新作となる「ラブプラス EVERY」は当初は2017年冬の配信を予定していたがクオリティアップを理由に遅延を重ね、2019年10月31日に配信開始された直後、不具合により一か月以上のサービス停止が発生したようだ。そして、配信開始から1年も持たずに、2020年8月5日にサービス終了となった。
この事例に則れば、デルタプラスも20万以上の患者数が発生する可能性がある一方で、1年以内に収束する希望が持てると言えるかもしれない。
●事例2「C++」
C言語の発展形としてオブジェクト指向が導入されたプログラム言語である。
ベースとなったC言語そのものも含め、多くの場面で現在も利用されている。さらにC#のような発展形も存在する一方で、JavaやPythonなども広く利用されており、開発言語として支配的な立場を維持し続けているわけではない。
この事例に則れば、デルタ株もデルタプラス株も長期にわたって相当数の患者を生むことになるだろう。加えて、デルタシャープのようなさらなる変種が一定の猛威を振るうリスクにも備える必要があるだろう。
●事例3「ラプラス」
多くの理系学問の基礎理論を支えるラプラス変換やラプラス方程式の人気はいまいちであるが、ラプラスの悪魔はシュレディンガーの猫と並び中二病患者に人気である。
このような背景を踏まえると、理系出身者は一定程度の抵抗力を有する可能性、または逆に親和性が高い可能性のいずれも否定できない。中二病患者が罹患した場合の重症化リスクも不明である。
