このページでは、JavaScriptのオブジェクト指向言語としての側面を研究します。 JavaScriptは、HTMLの拡張という側面が注目されていますが、 プログラム言語として見た場合にも、興味深い独自の特徴がたくさんあります。 このページでは、これらJavaScriptの言語としての特性、 特にオブジェクト指向言語としてJavaScript を見た場合の特徴について詳しく研究を試みます。 JavaScriptは、ほぼ完全なオブジェクト指向言語です。プログラマによるクラス定義、プロパティ定義、メソッド定義ができます。継承は、言語の基本機能としては用意されていませんが、基本機能の組み合わせにより実現できます。 メソッドのバインディング(binding)はレイトバインディング(late binding)です。これは、JavaScriptが変数の型のない言語だからです。 JavaScriptに
2012/04/26 一部修正しました デザインパターン 4章 FactoryMethod パターン 4.1 FactoryMethodパターンとは 4.2 サンプルケース 4.3 FactoryMethod パターンのまとめ 4.1 FactoryMethodパターンとは 第4章では、FactoryMethod パターンを紹介します。FactoryMethod パターンは、オブジェクトの生成方法に一工夫加えることで、より柔軟にオブジェクトを生成することを目的とするものです。FactoryMethod パターンでは、インスタンスの生成をサブクラスに行わせることで、より柔軟に生成するインスタンスを選択することが可能となります。 オブジェクトを生成する場合、下記のように記述するのが普通です。 Product product = new Product(); しかし、このようなオブジェクト生成方
UMLモデリングツール 調査メモ UMLモデリングツールの調査メモです。オブジェクト指向設計やデザインパターンを勉強してみたので、せっかくなので試しにちょっとしたWebサービスでも設計してみようかなと思ってUMLモデリング始めました。そこで、どのUMLツールがいいか調査したメモを残しておきます。 JUDE http://jude.change-vision.com/jude-web/ ・ジュード ・私がいま使っているツール ・スタンドアロン ・日本製で使いやすさに定評 ・有償版と無償版(Community)がある ・無償版は簡単なユーザー登録が必要 ・無償版でも8種類の図が作成可能 ・無償版にER図はない(DBモデリングは別途ツールが必要) ・ソースコードの生成・読込には対応しているが、同期はできない模様。 Eclipse UML http://www.omondo.
「アジャイルソフトウェア開発の奥義」を読んで第二弾。オブジェクト指向設計の原則に関するメモです。自分で読んで思い出せるくらいの内容しかメモってないと思われるので、もっと詳しい解説が欲しければ本書を買ってください。 本書には、クラス設計の原則として5つの原則が載っています。 単一責任の原則 (The Single Responsibility Principle: SRP) オープン・クローズドの原則 (The Open-ClosedPrinciple: OCP) Liskovの置換原則 (The Liskov Substitution Principle: LSP) 依存関係逆転の原則 (The Dependency Inversion Principle: DIP) インターフェース分離の原則 (The Interface Segregation Principle: ISP) パッケー
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。(ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない) アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現(オブジェクトにメッセージ送信)するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ(前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている)による、ユーザー定義型(抽象データ型)を SIMULA67 にあった「クラス」という言語機能を使って実現(カプセル化、継承、多態性)するアイデアに基づく「抽
Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか? - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く