7. 6 既存のOOシステム • S3 – クラスはclass属性として個別のオブジェクトに対して設定 • フォーマルなクラス定義はない • 継承もclass属性で行う – メソッドはジェネリック関数 john <- list(name = "John", age = 40) class(john) <- c("Employee", "Person") # printはジェネリック関数 print #> function (x, ...) #> UseMethod("print") # メソッド定義 print.Person <- function(x) { paste0("こんにちは，", x$name, "です．") } # printで実際に呼ばれるのはprint.Person print(john) #> [1] "こんにちは，Johnです．" 8. 7 既存のOOシステム • S
M. Watanabe @labidochromis クラスを動物や野菜に例える説明の多くは、「操作」の概念が欠落していることのみならず、「データ」の観点からの説明としても問題があることが多いのだ。 2010-08-17 12:41:55 M. Watanabe @labidochromis クラスを野菜（とか哺乳類とか整数とか）に、インスタンスをトマト（とか犬とか５とか）に例えると、クラスが変数でインスタンスはそこに格納される値の事だと思われそう。 2010-08-17 12:59:00 大' @satodainu 整数と５に例えたら、int じゃん！(^^;; QT @labidochromis: クラスを野菜（とか哺乳類とか整数とか）に、インスタンスをトマト（とか犬とか５とか）に例えると、クラスが変数でインスタンスはそこに格納される値の事だと思われそう。 2010-08-17 13:
プログラミングで使う「クラス」という概念を説明するときの例えに、なぜか「哺乳類」などの生物分類上の概念が使われることが良くあるらしい。 でも「哺乳類」は、メソッド持ってないしー。
2011年12月6日火曜日 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説 「ぐへへお姉ちゃんパンツ何色」はこれ以上ないほどオブジェクト指向であり、しかも理想的な実装をしていることに気づきました。これを用いてオブジェクト指向を説明してみようと思います。 ある人が「ぐへへお姉ちゃんパンツ何色」と質問するのは、お姉ちゃんオブジェクトの保持するpants_color変数を取得しようとする手続きと見ることが出来ます。つまり oneechan.pants_color を取得しようとしているわけです。 ではどうすればいいのでしょうか？ 考えてみましょう。直接パンツを見ればpants_colorを取得することができますね。 クラスを使わないとすればこんな書き方が考えられます。 struct oneechan{ int pants_color; }; 構造体でひな形を宣言します。
Haskell Advent Calendar2011 2日目です。 もう42時になってしまいました...さすがに遅いですね。 Haskellと言えば型クラス オブジェクト指向のクラスとHaskellの型クラスは違いますよ的な説明は見ますがどう違うか比べた情報が無い オブジェクト指向知っている人からの理解を簡単にすればHaskell理解する人が増えますね！ という目論見の元にスライドを作りましたが、ユーザ視点が足りずに混乱させてしまったかも知れません。 Programming haskell chapter10 View more presentations from Ruicc Rail Haskell Advent Calendar明日はid:melponさんです。
地理情報の国際標準化においては「地物」を概念世界のものと定義しています。しかし、この最も基本的な定義が、すでに躓きの石だったのです *1。 従来、「地物」は現実世界のものであった。 地理情報に携わる人々の間で話をしていると、地物が概念世界のものとして定義されているのか、現実世界のものとして定義されているのか、用語の定義で混乱を生じることがあります。概念世界のものと認識している人は情報系の人が多く、現実世界のものと認識している人は伝統的な測量についての知識が豊富な人が多いようです。この混乱は、次のことが理由だと考えています。 地理情報の国際標準化の世界では、地物(feature)は「実世界の現象の抽象概念(abstraction of real world phenomena)」と定義されているそうです。つまり、地物は概念世界のものとして定義されています。 一方で、地物を現実世界のものとして
はじめに この本はオブジェクト指向技術を利用してソフトウェア開発することを目指す技術者および管理者のために書かれた本です。プログラムのコードや難しい数式などを排除してあり，図と文章によって基本概念や適用技術を平易に解説しています。オブジェクト指向技術を数学(形式)ぬきで探求する試みといえるでしょう。 本来，オブジェクト指向技術を，瓶から瓶へ水をもらさぬように，正確に伝えるには，数学(型理論)を必要とします。数学的形式化が行われていないと，オブジェクト指向で表面化する問題の議論がかみ合わず空転することが多いからです。あの時はこうだっだ，この時にはああだったと経験則の披露になりかねないのです。やはり何かしらの形式化は必要でしょう。しかし，数学的形式化の苦しみときたら並大抵ではありません。特に，後述するインヘリタンス(継承) や並列などが絡んだあかつきには残酷なのです。私だけかもしれません
ソフトウェア開発の落し穴2013-09-01ソフト開発はプログラムの文法だけを知っていてもうまくいきません。 ソフトウェアのよい開発の仕方について考えます。 ソフトウェア開発はよくトラブルに巻き込まれます。納期がずるずる延びたり、 プログラムがスパゲッティ状態になったり、非常に使いにくいものが出来てき たり。こうした問題をどう解決するかについては今までに多くの人が研究して きました。そして「よいソフトウェアを作るには」という方法論について一定 の成果が上がっているにも関らず、ソフトウェア開発に携わる実務者にまでは 浸透していないのが実状です。 近年では、「ソフトウェア開発方法論」あるいは「ソフトウェア工学」という 名前でこうした成果を本にしたものを数多く見かけるようになりました。これ はこれで望ましいことです。しかし、こうした本を読んだだけでその精神をよ く理解しないまま適用するとかえって
コンテンツ 第1章 基本的な用語 第2章 オブジェクト指向開発 第3章 設計の問題し 第4章 オブジェクト指向設計の原則 第5章 単一責任の原則 第6章 Visitor パターン 第7章 LSP、DIP、ISP 第8章 パターン技術 第9章 ユースケース 第10章 実例 第1章 基本的な用語 第2章 オブジェクト指向開発 オブジェクト指向開発 オブジェクト指向分析 機能外要求 User インタフェース Student クラスとTeacher クラス Student クラスのソースコード Teacher クラスのソースコード 演習2-1 UserLocator クラスのソースコード 演習2-2 演習2-2 の解答 Teacher.java UserLocator.class 第3章 設計の問題 演習3-1 演習3-1 の解答1（返却値を利用した方法） 演習3-1 の解答2（条件分岐による方
7. 保守しやすい設計が良い設計だ 保守容易性 EoM: Ease of Maintenance テスト容易性 EoT: Ease of Testing 変更容易性 EoC: Ease of Changing EoM = EoT + EoC 「ずっと設計し続ける」から保守が重要！ リファクタリングしやすい設計を保つべし × 再利用性 参考： An Agile Way > 「保守しやすい」ことが、良い設計 (EoM = Ease of Maintenance) : ITmedia オルタナティブ・ブログ : http://blogs.itmedia.co.jp/hiranabe/2005/08/eom__ease_of_ma_8db3.html
僕は、オブジェクトもthisもサッパリ理解できなかった より引用 それで、一番わからないのが、thisとかselfに対するメッセージ・パッシング。「自分にメッセージを送る」って何よ、それ？ 他人を動かすならともかく、自分ならサッサとやりゃいいじゃん。イチイチ「俺、お茶飲め」とか「私、ドア開けましょう」とかメッセージしないといけないわけか。 この問題ですが。 なぜ、自分に対するメッセージを送る必然性があるのか、という問い掛けは、ある意味でもっともに思えます。しかし、実際に必然性のあるシステムが存在するので、その仕様、あるいは実装をベースにすれば、なぜ必要なのかを説明できます。 そのシステムとは何か? § オブジェクト間でメッセージをパッシングして動作するモデルを採用しているシステムというのは、実はみんなが使っているWindowsです。ほとんどのプログラム言語では、メッセージ・パッシング・モデ
アラン・ケイの“メッセージングによるプログラミング”という着想に基づき（非同期処理などいろいろ足りていないながらも──）比較的忠実に実装された1970年代の非常に古いSmalltalk-72に実際に触れてみるシリーズ 第2弾です（なお最新のSmalltalkについては Pharo などでお楽しみください！）。 今回は謎言語「Smalltalk-71」で書かれたスペースウォー・ゲームを Smalltalk-72に移植して動かすことを目指しました。なんとか完走できてよかったです。前回(2019年)を含む他の記事はこちらから→Smalltalk-72で遊ぶOOPの原点 | Advent Calendar 2023 - Qiita ユーザー入力を受け付ける ask とゲームをスタートさせる start いよいよ仕上げの start です。 まず、Smalltalk-71 では組み込みのプロシージャ
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
プロトコルとインターフェースの比較 http://d.hatena.ne.jp/carver/20071202#p1 やっぱり両方を使っている人の意見は参考になる。 ただ、ここで指摘されている「interfaceとprotocolの違い」は、正確には「JavaとObjective-Cの違い」ではないだろうか。また指摘されている違いは、「interfaceとprotocolの本質的な違い」と言えるだろうか。 以下、詳細。 定義できる要素 ・インターフェース 定数、メソッド、ネストしたクラスとインターフェース ・プロトコル メソッド インターフェースはクラス-2（インスタンスを生成できない、メソッドを実装できない）の機能を持つ。インターフェースと強く関連するクラスやインターフェースを、ネストすることで定義できる。 一方プロトコルはメソッドしか定義できない。Javaと異なり、ObjCのクラスとプ
前ふりは「型→代数→…それから：型理論入門（の前半）」にあります。これは本編（後半）。1回読み切り（長いけど）で、比較的新しい*1型理論を紹介します。「入門（門に入る）」というよりは門の外から中を覗いてみる程度。 説明用コードはJavaの構文を使います。ただし、パッケージ宣言は書かないし、publicはなるべく省略。 内容： インターフェースなんて、所詮こんなもの 心理的効果とか、人間-人間コミュニケーションとかは、別問題 わけわからんインターフェースに制約を付加する もっと制約を足してみる 謎のインターフェースに意図されたもの で、それが型理論にどうつながるの？ インターフェースなんて、所詮こんなもの まず、次のインターフェースを見てください。 interface AB { int a(); void b(); } これスゴイでしょ。何がスゴイって、これを見てもなんのことやらサッパリわか
(thanks to id:koyachi、del.icio.us/rtk2106) OOPとFPと。関数、オブジェクト、クロージャの使い分けについて考えます。 関数型が良いのか、オブジェクト指向が良いのか、知りたいと思っていました。色々なページを読み、現時点で一応の答えを得ました。 カウンタを例にして、関数、スコープ、オブジェクト、クロージャの順に見て行きます。関数関数は処理です。入力と出力があります。関数型プログラミングでは、関数同士の入力と出力を連結しプログラムが構成されます。 var current = 0; function next(v){ return v + 1 } function previous(v){ return v - 1 } ok( 1 == ( current = next(current) ) ); ok( 2 == ( current = next(cu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く