JavaScriptのオブジェクト指向の書き方｜jQuery入門5 « きんくまデザイン
こんにちは。きんくまです。 今回はオブジェクト指向の書き方についてです。 ⇒今回の作成物です ⇒html一式はこちら ■ex1 単純なオブジェクト指向 クラス //----------------------------- // ClassA //----------------------------- var ClassA = function(){ //プロパティ this.prop1 = 'Hello'; this.prop2 = 'World'; //メソッド this.method1 = function(){ var message = this.prop1 + ' ' +this.prop2; alert(message); }; this.method2 = function(){ alert('method2'); } } //クラスプロパティ、クラスメソッド Clas
オブジェクト指向っぽい話が分かるかもしれないJavaScript講座 その1 | Takazudo Clipping*
自分はスーパーJavaScripterでこんなすげーのが5行で書けちゃう。やばいだろ！とかいうのでは全然無いですが、オブジェクト指向っぽい話が最近分かってきたつもりで、それでやっときゃ問題無いってことを思い始めているので、なんかそんな話を書いていきます。 こんな短く書くテクニックがあるぜ！ var hoge = hage ? huga : hoga; とか書けちゃうんだぜ！とかより、長くていいから分かりやすく拡張しやすいようにするにはどうするのかとか、そういう話ができればなーと思います。内容的には全くもって新しくも何とも無いですが。jQuery使ってやる前提です。 まんじゅう製造スクリプト 今日はまんじゅうを5個作ります。なんと、まんじゅうは、クリックすると隠れます。 まんじゅうサンプル var Manju = function(){ this.elem; this.hidden = fa
憂鬱本は死なぬよ。何度でもよみがえる - みねこあ
なんか定期的に JavaBlack さんからわたしの憂鬱本のエントリにトラックバックが飛んできます。本当に「憂鬱本は死なぬよ、何度でもよみがえる...」なのかしら。 というわけで、JavaBlack さんのエントリの元のエントリを拝見させて頂きました。 今回はいつもと違って不思議な光景が浮かんでいて新鮮でした。だって、憂鬱本と Head First デザインパターンが軒を並べているのです。 憂鬱なプログラマのためのオブジェクト指向開発講座―C++による実践的ソフトウェア構築入門 (DDJ Selection) C++ によるオブジェクト指向への本。 シューティングゲーム等を例に挙げて、その処理の責務を持つのはどっちのクラス？がわかりやすく書かれてます。 超良書、有名だよね。 Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本 本屋で必ず目に入る本（笑） パラパ
憂鬱本を買ってみました - みねこあ
javablack さんが最近とりあげ、 ちょっとだけ話題再燃したの憂鬱本 こと「憂鬱なプログラマのためのオブジェクト指向開発講座」。以前借りて読んだことがあるのですが、「酷いわ」と思ったこと以外具体的なことは何も覚えていません(^^; で、具体的になにが酷かったのかのかな？とザザッとWebを流してみたのですが、見つからない。というか「これはいい本だー」という感想ばっかりで、予想以上に「酷い」というレビューがないのに改めてビックリです。 むー、これはネチっこいレビューの需要があるかな？とスケベ心をだして買ってしまいましたョ。 憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) 作者: Tucker出版社/メーカー: 翔泳社発売日: 1998/05/31メディア: 大型本購入: 10人 クリック: 508回この商品を含むブログ (78件) を見る で、改めて読み
Smalltalk勉強会で夢を語ってみた - ずっと君のターン
シンコム・システムズ・ジャパンさんのオフィスで行われた今年最後のSmalltalk勉強会で積年の夢を語ってきた。今回の勉強会は控えめに言っても言語の内臓丸出しの変態トークばかりだったので、「こんなの作りたいです」ってだけの私のLT?はかなり浮いてた気がするけど、そんなことは（ﾟεﾟ）キニシナイ！！ で、その夢なんだけど、要するに「Smalltalkっぽい日本語プログラミング言語を作りたい」って話。だけど、せっかくの夢なのでここではさらに風呂敷を広げて「世界中の人が使える多言語化可能なプログラミング言語＋ツールを作りたい」って話にしたい。 ・・・ もし全ての人がプログラミングできればきっと世界がかわる。普通に生活してるだけでもプログラマが、役所で、レジで、窓口で、「YOU！自動化しちゃいなYO！」って思うことがどれだけ多いか。 日本人は識字率が高くて算数も得意なんだから、うまくすれば識プログ
オブジェクト指向プログラミングの学習法(初心者向け) - カレーなる辛口Javaな転職日記
個人的な話をしますと、オブジェクト指向の入門書に出てくる、「クルマのたとえ話」とかは本当に意味わかりませんでした。こちとら、すっかり手続き脳なもので、そんなんでmainとかどうやって書くのよ？みたいな。＜我ながらヒドイ http://d.hatena.ne.jp/LazyCoder/20070806/1186417299 追記 PHPのオブジェクト指向を勉強してる。というか仕事での必要性を感じてやってるけど、正直オブジェクト指向の良さがさっぱりわからん。(中略) よくあるオブジェクト指向の解説本には車がオブジェクトでタイヤがファンクションでみたいなんかいてるけど、実務で使うプログラムの設計の仕方がわからん。 http://anond.hatelabo.jp/20070427093912 こんな説明を読んで、なんだかわかったような気分になれる人は、どっちかというと思考力に欠ける人なんじゃない
オブジェクト指向開発を理解した開発者に、設計書は不要：アジアのソフトウェア開発現場にて：エンジニアライフ
シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしのソフトウェア開発者としての経歴は10年程度。10年間、いろいろなものを作ったが、「設計書」と言えるもの、つまり「基本設計書」「詳細設計書」がある形でプログラム開発したことは一度もない。たぶん、これからもないかと思う。 「大したものを作っていないのでは」と、わたしのソフト開発者としての能力を疑う人が出てくるかもしれない。しかし、大企業で大勢の人に使われるようなシステム――規模にして数十年月のしっかりしたシステムを作ってきたことは事実である。ということで今回は、「設計書なしでかなりの規模のシステムを作る」ことに関するわたしなりの方法論を少し書いてみる。 オブジェクト指向は必須である。「設計書なしである程度の大きさのソフト
Re:業務アプリの業務部分で、オブジェクト指向なんか使わないよね - No Programming, No Life
業務アプリの業務部分で、オブジェクト指向なんか使わないよね - プログラミング言語を作る日記 というエントリを読みましたが、ちょっとだけ突っ込みを入れてみたいと思う。 「使わない」ではなく「使えない」のでは？ 実際に業務アプリの実装において、オブジェクト指向が使われていないというケースはよく耳にする。ところで、オブジェクト指向が使われない理由についてだが、本音を言えば、「使わない」のではなく「使えない」の方が比率が高いではないだろうか。 例えば入社してすぐに戦力に回された新米プログラマは、研修でしか触ったことがないようなプログラミング言語を覚束ないながら使用していくことになる。そんな新米率が高いプロジェクトに至っては「なんでもかんでもオブジェクト指向で書け」というのは少々敷居が高いというのも事実であるとは思う。ちょっとした処理をするのに重厚なクラスを書いて、そられを巧みに連携させる必要が出
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
第4回 オブジェクト指向の本質 | gihyo.jp
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
オブジェクト指向言語として必須な要素とは何か? - Smalltalkのtは小文字です
ときどきの雑記帖 リターンズ -おしえて(OOPLの)えらいひと より。お呼びでない…とは思いましたが、私のこれまで調べたことを頭の中で整理するのに役立ちそうなので、できるだけ簡潔にまとめてみます。 ケイのオブジェクト指向（メッセージングのオブジェクト指向）に立脚する場合 このオブジェクト指向のコンセプト パーソナルコンピューティングに係わるものをメッセージングで表現。 それをサポートする言語に必須のもの メッセージング（あるいは、それに準ずる）機構と、メッセージのレシーバ（たいていは、オブジェクト。状態や処理の保持・保護・隠蔽を行なえることが期待される）。 原則として欠いてはいけない機能 可能な限りの動的性。 ストラウストラップのオブジェクト指向（ユーザー定義型のオブジェクト指向）に立脚する場合 このオブジェクト指向のコンセプト 抽象データ型（この文脈ではユーザー定義型を指す）を「クラス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Turbo Pascal 5.5 Object Oriented Programming Guide
『個別案件にオブジェクト指向は要らない - 設計者の発言』へのコメント
今日のDDDの重要性についてEric Evans氏に聞く