Museumソフトウェアエンジニアのブログ。JavaScriptエフェクティブジャバスクリプトシリーズの続き。本自体は今日読み終わったけど、まとめるのはまだ半分だ。仕組みを勉強してより深く理解できた気がする。動的に解決されていて、呼び出しのコンテキストに依存して値が結合されているなぁと思った。種類のアクセッサを持っている。プロパティを持っている。メソッドを追加している。格納されたオブジェクトが自動的に代入される。property)のサーチから開始される。プロトタイプオブジェクトの中からルックアップされる。メソッドが取り出される。関数(二番目)はオブジェクトのプロトタイプを取り出すのに使える。プロパティ(三番目)はこのプロパティを取り出す方法の非標準の方法である。おけるクラスとは、コンストラクタ関数と、クラスのインスタンスの間でメソッドを共有するためのプロトタイプオブジェクトを組み合わせたものである。利用するのが望ましい。プロパティを持っている。使った実装を提供できる。持つ特別な能力は、プロトタイプリンクを変更する能力である。様々な問題があるので、プロトタイプリンクを変更するのは避けた方が良い。理由として以下のような問題が挙げられる。すべてのプラットフォームがこの変更をサポートしているわけではない性能の問題。変更はオブジェクトの継承構造そのものを変更する。これによって最適化の一部が無効になってしまう場合がある。メンテナンス性の問題。プロトタイプリンクを動的に変更すると継承構造が動的に変更され、プログラムをメンテナンスするのが困難になる。いう標準の関数を利用しよう。演算子付を呼び出すことを忘れない必要がある。このコンストラクタはレシーバができたてのオブジェクトであることを前提としている。グローバルオブジェクトに束縛され、分かりづらいバグをもたらす。呼んでしまう方法がある。利用できない環境では、以下のコードで提供できる。演算子付で呼び出すと、コンストラクタの上書きパターンが適用され、関数呼び出しの場合と同じ振る舞いになる。式の結果をコンストラクタ関数から明示的に返された結果で上書きすることを許しているためだ。演算子付で呼び出してほしいのならそれを強調して文書化しておこう。プロトタイプなしでプログラミングすることは可能であるが、プロトタイプオブジェクトで共通してメソッドを実装した方が効率が良い。関数(オブジェクト)が毎回作成されるため、メモリの無駄になる。実装すると、メモリの無駄を省ける。エンジンはプロトタイプオブジェクトのルックアップを強力に最適化しており、その恩恵を得られる可能性が高まる。hiding)を強制する機構を特に持っていない(誰かが「オブジェクト指向の本質は情報隠蔽である」と言ってた気がするのだが...)。命名規則(アンダースコアをつけるなど)を使ってユーザーに「これはプライベートプロパティですよ」という意図を明示する場合がある。厳密にプライベートプロパティを作成したいのであればクロージャを利用する。直接アクセスできないのでプライベートプロパティとなる。このようにクラスを定義すると、各メソッドのコピーがインスタンスごとに増殖するため、項目33の「メモリが無駄になる」というデメリットが露呈するので注意する。項目36:インスタンスの状態は、インスタンスオブジェクトにだけ保存するインスタンスの状態を示すプロパティは正しくインスタンスオブジェクトに配置する必要がある。間違ってインスタンスで共有されるプロパティをプロトタイプオブジェクトに配置するとバグとなってしまう。一般的にはプロトタイプオブジェクトに状態を持たせてはいけない。関係を正しく把握してプロパティに配置したりするのを考える作業ってプログラミングの中の作業でもけっこう好きだったりする。JavaScript』を読んで(項目43~52)久しぶりの更新。一気に第5章全部まとめた。手習い』はじめました。Museumスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。