はてなキーワード: オブジェクト指向とは
5年前ならともかく、今は全然そんなことはないです
それはそうですが、Rustがオブジェクト指向の言語かどうかには関係ありませんね
「Rustがオブジェクト指向言語なのか?」という話題においては、traitがインターフェースの機能をより一般化して強力にした機能であるとか、
そのあたりの方が「誰がどのプロダクトを作ったか」より遥かに重要ですね
実際にどんなサービスを作ったとかの話になるの
「Rustがオブジェクト指向言語なのか?」という話題においては、なりませんね
君その辺空っぽだよね
別に関数型言語だろうがオブジェクト指向言語だろうが業務によって使い分けるけど
普通に考えると型付けの関数型ならバグが少なくなりそうなのに実際には全くそんなこと無い
観察したことがある感じだとオブジェクト指向的に状態を整理するようなことが苦手で
それが嫌でオブジェクト指向から逃げて関数型を主張してくるので
例えば商品として服と靴があったとして、カートに入れたら服は税込みなのに靴は税抜きになってたりする
ちなみにオブジェクト指向をやたら主張してくるやつはバグは少ないけど開発がめちゃくちゃ遅い
俺の考えた最強のデータ構造を模索し続けるし他人にもそれを求めるのでめちゃくちゃ面倒くさい
服と靴を買うだけのサイトなのに「靴磨きのサービスを追加する場合は?」みたいなことを考え始める
何事もほどほどがいいと思う
Rust言語が公式で「Rustはオブジェクト指向もできるよ!」ってアピールするための3つの主張の2番目が「カプセル化もできるよ!」なんだぞ
そこから考えれば
「カプセル化はオブジェクト指向の本質の1つとみなされている」
と
カプセル化がオブジェクト指向の本質の1つであるという見方は(当然異論があるやつはいるだろうが)主流では?
同じプログラマなのに話が通じないと思ったことはないでしょうか
どうやら私の思うオブジェクト指向と貴方の思うオブジェクト指向は別のもののようだ
A君はウィキペディアを見ながら、カプセル化、継承、多態性だと言う
B君はC++/C#/Java等でプログラムを書くことだと言う
なぜかみんな見ている世界が違うようだ
俺もそんな意識高くないけど、オブジェクト指向が間違えづらいなんてこと無いでしょ
周りがある程度優秀なプログラマーに囲まれててクソコードに遭遇してない
まぁ、幸せな人だと思うな
「どうして人間はこんな愚かな発想でコードを書いてしまうのか」
という感想を持つし、その中でオブジェクト指向が一つの解だと理解する
人間は間違いを犯す生き物で、愚かな発想で愚かなコードを書いてしまう、という前提に立って
間違いにくく間違えることができないようにしよう、というのがオブジェクト指向の目指しているところであって
「プログラムとは何か」みたいなアホみたいなことはこれっぽっちも考えてないよ
プログラミング言語側に組み込まれている「型」だけでなく、プログラマーが独自に「型」を定義する方法も用意されています。
struct、class、interface、type, enumなどを使って独自の「型」を定義します。
開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります。
多数の「型」を分類し、組織化するために名前空間を利用します。
近年「クラス」が「型」の定義であるという基本概念を理解していないエンジニアが増えているので、エンジニアを採用する際には注意しましょう。
ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています。
例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。
業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります。
これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます。
CPUは機械語しか理解できません。一方で人間は機械語でプログラミングすることは困難です。
人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。
CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまいます。
そこで、人間にとってプログラムを読みやすくすることと、CPUに意図しない演算をさせないために、データの種類を表す「型」という概念がプログラミング言語に用意されるようになりました。
金融やECサイトなどのお金の計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。
メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります。
例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。
オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。
自分には6年付き合った年上の彼女がいた。名前はPHP。学生の時からの付き合いで、自分にとっては初めての彼女だった。付き合った当初は全てが新鮮で、オブジェクト指向やSOLID原則、大事なことは全て彼女から教えてもらった。(そう思われるかもしれないが、)時間が経って彼女の魅力が感じられなくなってしまったということはなくて、彼女は歳をとっても魅力的なままだった。むしろreodonlyプロパティやEnum、null safe演算子など、新しい機能が導入されてますます綺麗になっていったように思う。最近ではジェネリクスさえ導入されたようだ。彼女は本当に努力家だ。
(褒められた話ではないが一応、彼女以外の女性を全く知らなかったわけではなく、TypeScriptという若い子と少し遊んでいたこともある。TypeScriptは昔からの知り合いのJavaScriptの妹で、大雑把な姉と違って几帳面で、少しオタク気質もある個性的な子だった。よく新しい型パズルを考案して楽しそうに話してくれたが、自分には正直よく分からなかった笑。)
そんな中でも基本的には6年間PHPとずっと一緒に過ごしてきた。前述の通り彼女に何か不満があったわけではない。ただ、彼女との将来に不安を覚えるようになってしまっていた。周囲に彼女と付き合っていることを話すと、「え、まだPHPと付き合ってたんだ?(昔は人気だったけど、最近はそうでもないよね)」みたいなことを、彼女のことをよく知らない人から言われたりもした。そこまで直接的ではなかったけれど。自分も、彼女以外の女性のことをほとんど知らずにずっと彼女と付き合っていて大丈夫なのかななんて思ってしまったりしていた。
結局自分はPHPと別れて、新しい女性と付き合う決断をした。新しい彼女の名前はGo。彼女は若いのに自分の芯がしっかりしていて、みんなの憧れの格好良い女性といった人だった。そんな彼女と付き合いだして、最初は戸惑うことも多かった。
例えばこんな感じだ。
また、今まで当たり前だと思っていたPHPの良さに気づくことも多い。PHPStanを使えば静的型付け言語と同じように型安全性を担保できていたし、彼女のWeb FWには歴史が長いだけあって痒いところまで手が届く様々な機能が完備されていた。経験豊富でこちらの要望をなんでも受け止めてくれるような包容力があったことに今更気づいた。
とはいえ、いつまでも昔の彼女を引きずっていてもしょうがない。Goにはこちらに積極的に合わせてくれるような包容力はないが、彼女なりの哲学を持っていてそれ故の美しさがあると思う。そして正直、まだ彼女の10分の1も理解できていない。彼女が得意だという並行処理や、実行速度が求められるような処理も、自分はまだ実際に実装したことはない。でもこれからしっかり向き合って、Goのことをもっと理解して、実りのある交際にしていきたいと考えている。PHPと別れてGoと付き合う決断したのは自分なのだから。
オブジェクト指向とかかっこいい言い方をしても無駄だ。従来の構造化プログラミングから進歩したことなど一つもない。オブジェクト指向がなぜダメであるのか、それを今から話すぜ。
1. データと処理をまとめるという発想。
データと処理をまとめてクラスとして置くという発想がある。しかし、このようなことをしなくとも、モジュールという単位で利用データと処理の集合をまとめればよかったので、クラスを使う必要はない。しかもクラスはインスタンス化のときに、不要な情報まで持ってくるのでメモリ効率が明らかに悪い。コンピュータが進化しているからメモリのことはあまり考える必要がないとはいえ、必要ない処理をまとめて閉じ込めるのは無駄が多い。なぜクラスという名詞で概念分類できると考え始めたのかは不明だが、アルゴリズムとデータ構造という構造化プログラミングの手法を、クラスと型というパラダイムに変換することで型にうるさいC++馬鹿を生み出し、彼らが発狂することになってしまった。しかもデータと処理にわざわざ依存関係を持たせて、変更に対する柔軟性を失わせている。
2. 継承
継承によって既存の構造を持ってこようとする必要性が全く無い。それどころか、継承を使うことによってプログラムがスパゲティ化し、依存関係のグラフがややこしくなってしまう。継承など使わず、必要な情報はスコープの限られた共通の変数、または関数の引数として用意しておけば良い。もしクラスをどうしても使いたければ、共通のインターフェイスをもたせたほうがマシである。インターフェイスを使えば、クラス利用者が意識すべきpublicメソッドがなんであるか把握できる。
3. カプセル化
オブジェクト指向の中で役立つ概念はカプセル化だけである。しかし、カプセル化はクラスなしで構造化プログラミングの方法で実装できる。pythonでは、モジュールの中でアンダースコアから始まる関数を用意しておけば、それがprotectedやprivateと似たように機能させることができる。オブジェクト指向がなぜカプセル化が独自の概念だと言い始めたかは謎。
4. ポリモーフィズム
同じ名前のメソッドを、入力に応じて処理の内容を変える。このようなことはオブジェクト指向などと誇大宣伝をするほどのことでもない。構造化プログラミングで似たようなことができる。
プログラミングをサッカーに喩えると、巷にいるプログラマーは小学生サッカーレベルからJ1レベルの選手まで全部いるんよ
他の人から見たら
だけど普通に会社とかフリーランスとかでドヤ顔でプログラマーとして働いてるわけ
面接でそれを見抜くのはそれなりの能力を持った人、つまりはスカウトじゃないと無理なので小学生レベルでも普通に採用される
その結果リフティングしかできないやつがJ3のチームに普通に所属してしまう
小学生の昼休みサッカーでそこそこ上手いって言われてるレベルなのにJ3の試合に出てくるっていう地獄ね
いざ試合になってボールが回ってきたらリフティングばっかしてて、いきなり敵にパスするみたいなことを平気でやって
「パスミスはしょーがないでしょ」
具体的に言うとオブジェクト指向を理解できてない状態でTypeScriptでanyを連発してバグだらけのクソコードを量産しておいて
とか言うくせに
「別にオブジェクト指向で書く必要はないけれど、だったらどこでメンテナンス性と堅牢性を担保してるのか教えて?」
って言うとフガフガ言いながら逃げるっていうね
でもガチのCSを勉強しようと思ったらアルゴリズムとデータ構造は必須で、それに適した言語となるとC以下あれやこれやでしょ。
あと、デザイン・レシピとかいう考え方なら OCaml とかの関数型言語が入門に適しているし、オブジェクト指向ならCじゃ無理だし。
時は金なりという意味か?
public class Person { BasicInfo info; float stock; float Value; public string Name(bool isSpy){ return isSpy ? info.Name : info.Name.ToSecondName(); } public string Sex(bool isNormal){ return isNormal == info.isMan ? "Man" : "Woman"; } public float Earn(bool isExtra = false){ float sexPad = info.isMan ? 1f : 0.5f; float racePad = info.isWhite ? 1f : 0.5f; var delta = DateTime.Now - info.Birth; int age = (int)(delta.TotalDays / 365); float result = Value * sexPad * racePad * age; if(isExtra){ Value += result; } return result; } enum Race{ White, Black, Yellow }; class BasicInfo{ public string Name; public int NationalId; public bool isWhite; public bool isMan; public DateTime Birth; public BasicInfo(string Name, int NationalId, Race race, bool isMan){ this.Name = Name; this.NationalId = NationalId; this.isWhite = race == Race.White; this.isMan = isMan; Birth = DateTime.Now; } }