インスタンスとオブジェクトは混同しがちで区別がようわからんになりがちです。 とりあえず某所で説明したものを再構成します。 ※2022/12/10追記: クラスに対するのはインスタンスになるべき(たとえばクラス変数とインスタンス変数)なので、ちょっと修正するべきですが、このエントリはそのまま残してます。 クラス・インスタンス・オブジェクト クラスをインスタンス化(実体化)したものがオブジェクト(物)です。 実際に在るものはクラスとオブジェクトで、インスタンスはそれらの関係です。colorsやsportsが並んでるツリーが「オブジェクト」で、右のパレットに並んでるTreeが「クラス」、Treeからみたときのツリーが「インスタンス」ということになります。 ここでツリーはオブジェクトでもインスタンスでもあります。 このように、同じものをオブジェクトともインスタンスともいうことができるので混同してし

ベルギーで飲んだときにこれはうまいと思って日本でも飲みたいと思ってたノンアル ヒューガルデン、2年前に日本で買える話が流れて残念に思っていたのですが、ようやく買えるようになりました。 ヒューガルデンの味がする！コリアンダーの華やかさとオレンジピールのさわやかさをちゃんと感じます。少し香りの華やかさが控えめになって甘めになった感じ。 もちろんアルコールがない分の物足りなさはありますが、逆にいえばほんとにヒューガルデンからアルコールを抜いた感じです。 酵母が入っていて、最後に振って注いで酵母を入れると味がかわるのもヒューガルデンと同じです。甘さが気になる場合は、振らずに注いで飲んでみるといいかもしれません。もったいないので最後だけ酵母いれましょう。 ベルギーではビールを飲んだ帰りに1本ノンアルヒューガルデンを買って帰ってホテルで飲んでたのですが、そうすると普通のヒューガルデンでした。一度まちが

オブジェクト指向って継承による多態があるからこそなんだけど、継承が非推奨になって以降に雰囲気でオブジェクト指向を知った人には、継承はオプションでカプセル化だけでオブジェクト指向って言ってしまいがちに思います。 実際はカプセル化はオブジェクト指向固有じゃなくて、クラスでカプセル化を実現してるだけです。 さまざまな人のオブジェクト指向の定義 本来ならどのように継承こそがオブジェクト指向なのかという説明をするんですが、かなり長くなりそうなので、とりあえずはいろいろな人たちのオブジェクト指向の定義を抜き出してみます。 「ここに挙がってるのはオブジェクト指向の一派にすぎない」というような意見もありますが他の派閥についてまとまって定義され共通認識になっているようなものは見当たらないので、プログラミングの指針には なりづらいと思います。 ストラウストラップ C++を産んだストラウストラップは「C++の設

1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から

おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。 工数としてはコード管理費みたいな感じで乗せるのがよさそう。 まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。 なのでリファクタリングの価値というのは、その後で新しいコードを追加したり既存のコードを変更したりといった作業がどれだけ作業時間短く品質高くなったかという間接的な指標で測ることになります。 ここでまず、最初のコードを書いた人とリファクタリングする人が同じなら、そこまで保守性か

某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー

基本的にオブジェクトと関数はおんなじもので、Javaのラムダ式では記述は関数だけど扱いはオブジェクトになってたりします。逆に、関数でオブジェクトを実現することもできます。 なので、オブジェクトと関数が、モノとしてどう違うかっていう話にはあまり意味がなくて、問題は表現としてどう違うかってことになると思います。 表現として、オブジェクトはフィールドとかプロパティとかで状態をもって、その状態をもとにいろいろ動いて、状態を変えます。 関数は引数をとって、その引数をもとにいろいろ動いて、戻り値を返します。 オブジェクトは状態が大事、関数はデータの流れが大事、って感じになります。 アプリケーションの中では、ユーザーインタフェースとデータ構造・ストレージは状態が大事です。処理に関してはデータの流れが大事です。 ここで、ユーザーインタフェースやデータ構造はプラットフォームごとに一揃えあれば充分です。ストレ

参考までに、ぼくの基本的な定義は、ランボーの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」という定義に従っています。そのようなオブジェクトが単体ではなく組織化されるということが重要です。オブジェクト指向を勉強するとはそのような組織化のしかたを勉強することだと考えています。 現在のシステムは、データはデータベースに格納され、振る舞いとは分離して管理されています。そのような中では、システムをオブジェクトの集まりとして組織化することはできません。 局所的にも、ステートレスを前提としたHTTPの処理では、オブジェクト組織の必要な局面はありません。 個別のオブジェクトの共通化に継承を使うという点では「クラスは単にユーザー定義型であり、継承は部分型と差分プログラミングを実現する仕組みだととらえる」だけで充分だと考えています。 そうしたシステムにオブジェクト