オブジェクト指向とは結局メンタルモデルのモデリング手法である - assertInstanceOf('Engineer', $a_suenami)
きしださんのエントリが話題です。 オブジェクト指向は禁止するべき - きしだのはてな 「禁止するべき」とはまた随分と煽りタイトルですねと思いつつも、内容自体はとても納得のいくものでした。 ただ「オブジェクト指向」というのはいろいろな観点で語られることが多く、多少モヤモヤとはしているので僕の考えを書いてみようと思います。 なお、きしださんご自身は以下の補足エントリで立場は明確にされています。本エントリはこれを否定するものではありません。あくまで違った立場からの意見です。*1 オブジェクト指向について - きしだのはてな 参考までに、ぼくの基本的な定義は、ランボーの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」という定義に従っています。そのようなオブジェクトが単体ではなく組織化されるということが重要です。オブジェクト指向を勉強するとはそのような組織
リスコフの置換原則
それらは、先人達がオブジェクト指向を研究したり実践したりしていく中で、発見されてきたものです。 どれも、オブジェクト指向を正しく利用するためには非常に重要なことですので、今後順次解説していきます。 今回は、リスコフの置換原則のお話です。 英語で言うと "the Liskov Substitution Principle" ということで、LSP と略されたりします。 コンテンツ 例えれば職能 あなたの羅針盤 実際のはなし 契約 犯罪者 ポリモーフィズムの羅針盤 オススメ リスコフの置換原則…と聞くとまず思うのが、「リスコフ」ってなに？ということだと思います。 はい、「リスコフ」というのはこの原則を提唱した人の名前です。 「そういう名前の人が言い出したんだな」とだけ思っとけば OK です。 そうすると、肝心なのは「置換原則」ってとこだけですね。 じゃあ、何と何を置換するでしょう？ はい、スーパ
クラス継承、リスコフの置換原則、部分集合の型 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「クラス、オブジェクト、型； なんだか変じゃない？」に、まだチラホラとコメントが付いているようです。んじゃ、少し補足しておきましょう。 何人かの方が「リスコフの置換原則」に言及しているので、その話。それと、列挙型や部分範囲型についても触れます。「クラス、オブジェクト、型； なんだか変じゃない？」に挙げておいた事例（Point3D extends Point2Dとか）は断りなしに引用します。 継承では、受け継ぐ財産を拒否できない 「クラスはデータと手続きを一緒に定義したものだ」とか言われますね。データはヒープ上のメモリブロックで、手続きはサブルーチンのセットです。クラス継承によって、データも手続きもいやおうなくサブクラスへと押しつけられます。要らないと言ってもダメです。 例えば、bonotake方式で UserHandle extends UserID とした場合、UserHandleでは
その３ 拡張できて修正不要の原則 ： OCP
ホーム < ゲームつくろー！ < オブジェクト指向設計編 < 拡張できて修正不要の原則 ： OCP その３ 拡張できて修正不要の原則 ： OCP オブジェクト指向には幾つか「原則」と呼ばれるものが存在しています。原則（Principle）というのは約束(Promise)や指針（Guideline）よりもはるかに強い戒めです。オブジェクト指向における原則は、よっぽどの理由が無い限り破る事は許されないものばかりです。沢山ある原則の中で、ここではオブジェクト指向の基本原則である「Open-Closed Principle : OCP」について見ていくことにします。尚、今回の話は「まさーるのページ」（石井様作成）にあるオブジェクト指向に関する素晴らしいお話の影響を多大に受けております。このページをご覧になりますと、オブジェクト指向の本が読みたいと熱望してしまうこと間違いなしです。私も思わず関連本を
継承にかかわる諸問題
継承にかかわる諸問題2003-05-07「継承」はオブジェクト指向ではよく話題になり、また問題視されます。しかしそれは使い方が間違っているからです。 今回は少し専門的に、継承のお話です。「オブジェクト指向とは?」と問われ た時、多くの人は「クラス・継承・多態性だ」と言います(そしてそれは間違っ ています)が、そのくらい継承というのは世の中で重要視されています。 「継承」というのはオブジェクト指向言語の一番かっこいい部分であり、また 一番問題になる部分でもあります。ここで「オブジェクト指向言語の」と書い た事に着目して下さい。継承の問題のほとんどは、システム分析などの上流工 程を知らないプログラマが、下流工程であるプログラミング言語の知識をその まま持ってきてしまうことに起因します。つまり、「オブジェクト指向とは？」 という質問と「オブジェクト指向言語とは？」という質問の違いがわからない 人
私が愛するオブジェクト指向とそれを使わない理由 - takuto_hの日記
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
オブジェクト指向のエッセンス
オブジェクト指向のエッセンス 目次 目次 オブジェクトの発見 汎化／特化を使用する場合のポイント 責任の振り分けについて 更新履歴 ぜひ、感想をお送りください オブジェクトの発見 オブジェクト指向をはじめたばかりの頃は、何をオブジェクトとすればよいか悩むところです。 BERTRAND MEYER氏によれば、「オブジェクトはそこに転がっている」らしいですが、凡人の私にはそこに転がっている物が見えません。 オブジェクトを発見するための視点を以下のようにまとめてみました。 オブジェクトを発見するための視点 ユースケース図よりシステムの外部との接点に注目する。 ユースケースシナリオより名詞を抽出する。 ユースケースシナリオより責務を探し出し、それをだれが行なうべきかを考える。 たとえば、線を描くシステムを考えた場合、線はオブジェクト（クラス）でしょうか？ 初期の段階ではオブジェクト候補と言えるかも
究極のインターフェース指向設計
オブジェクト指向言語では、メソッドを定義しただけで中身を実装しない、インターフェースが登場します。 インターフェースを使うと、クラスやメソッドの再利用性が高まります。インターフェースさえ同じなら、同じコードを、いろいろなクラスに適用できるためです。 しかし、インターフェースを使うのは、コードを再利用するためだけではありません。たとえ再利用しなくても、敢えてインターフェースを作ることもあります。むしろ、再利用するか否かに関わらず、インターフェースを使うべきだ、という考えもあります。 ここでは本屋さんのシステムを例に、インターフェースの存在意義について考えてみます。 本屋さんのクラス設計 本屋さんですから、まずは「本」クラスが必要です。「本」クラスは、下記のようないろいろな属性を持ちます。 題名 著者 発行者 値段 重さ ページ数 次に、本を購入するための「会計システム」を作りましょう。 レジ
メソッド設計で守るべき10個のルール - A Day In The Life
以前メソッド設計の原則に関する記事を書きましたが 質問をすることで答えは変更されない原則 メソッドの引数はオペランドのみにする原則 それ以前にメソッド設計する上で最低限守った方がよいルールをまとめてみました。 プロパティをメソッドの戻り値代わりに使ってはいけない ファンクションメソッドでプロパティの値を変更してはいけない プロパティをリターンしない インスタンス変数やプロパティをメソッドの引数に渡さない 参照渡の引数をリターンしてはいけない 例外処理を GoTo 文の代わりに使ってはいけない 理由なく id 型をメソッドの戻り値にしない 特定メソッドの呼びだしが前提になったメソッドを作ってはいけない パブリックメソッドからパブリックメソッドを呼ばない プライベートメソッドからパブリックメソッドを呼ばない 以下その詳細です。 プロパティをメソッドの戻り値代わりに使ってはいけない メソッドが呼
オブジェクト指向再入門/なぜわからなくなってしまうのか?
いい加減、わけのわからない「たとえ話」はやめよう オブジェクト指向の入門書では、 「謎のたとえ話」から始まるものが多いように思います。 典型的な例は、はじめにでも挙げた、 「哺乳類を継承して犬と猫を作り、 『鳴く』というメッセージを送ると犬なら『わん』、猫なら『にゃあ』と鳴く」 って奴でしょう。 他にも、ちょっとWebをぐるぐるすると、清原選手をオブジェクトにしてみたり、 箪笥をオブジェクトにしてみたりなどなど、 およそプログラミングとはかけ離れた説明が蔓延しています。 こんな説明を読んで、なんだかわかったような気分になれる人は、 どっちかというと思考力に欠ける人なんじゃないかと思います。 「わけわからん」という反応のほうが技術屋としては正常でしょう。 いい加減、こういうわけのわからないたとえ話はやめたらどうかと。 あんなもん、わかったつもりの半可通と、 理解できない挫折組を生み出すだけで
クラス設計の考え方
ソフトウェアの開発において、クラスの設計は、大切なポイントの１つです。どのようなクラスや関数を作るのか。ソフトウェアのデザインは、それによって決まります。 現在のソフトウェア工学で主流となっているのは、オブジェクト指向の考え方です。開発言語も、C++やJavaといったオブジェクト指向言語が広く使われています。しかし、いくらオブジェクト指向言語を使って開発していても、クラス設計の考え方が誤っていれば、まったくオブジェクト指向的でないソフトウェアができてしまいます。 貴方が、あるちょっとした機能の追加を頼まれたとしましょう。さて、いくつのクラスや関数を作れば良いのでしょうか。また、そのクラスや関数の名前は、どのように付ければ良いのでしょうか。貴方なら、どのように考えを進めて、クラスや関数を設計していきますか？ ここでは、ワイルドカードを使った文字列の検索を例に、クラス設計をする際の考え方を紹介
シリアライズ - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "シリアライズ" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2020年8月) コンピュータプログラミングにおいて、シリアライズ (英: serialize) もしくはシリアル化という用語は、次のような異なる2つの意味を有する。 コンピュータ実行時の用語として：一つあるいは複数の「コンピュータ資源」（コンピュータ作動時に必要なもの、通常プログラム実行時に要求されるコンピュータリソース。具体例：CPU、メモリ、入出力先など）を、複数の主体（具体例：プログラム）が利用しようとする際、一時点に一つの主体だけが利用するように、順番づけて調整す
Objective-CでのDelegateについて
Objective-CでのDelegateとは iPhoneアプリケーション開発において、結構頻繁に出てくるのがこのDelegateという言葉です。プロジェクトを作れば必ず～AppDelegateというクラスが作られますし、 他にも様々な場面で～Delegateというものを目にすることになります。Delegateとは代理人とか代表者とか委譲などという意味があります。 通常あるオブジェクトへと送られてくるメッセージはそのオブジェクトで処理するべきなのですが、いちいちそのオブジェクトのファイルを作るのは面倒という場合があります。 その場合に、別のクラスに送られてきたメッセージを丸投げしてしまうと、そのオブジェクト自体に特有の処理を書くなどしなくて良くなるため便利、というわけです。 たとえば、iPhoneアプリケーションで画面にメッセージを表示するUIAlertViewというクラスがあります。
まつもと直伝 プログラミングのオキテ---目次 - まつもと直伝 プログラミングのオキテ：ITpro
第0回 あらためてRuby入門 まつもとゆきひろ氏自身による「Ruby入門」をお届けします。日経Linuxの連載開始前の特別企画（2005年4月号）として，Rubyが他のスクリプト言語やオブジェクト指向言語とどこが違うのか，なぜ便利なのかを中心に解説してもらったものです。 ● 基本と他言語との違い ● 実装とRuby誕生の秘密 第1回 プログラミングとオブジェクト指向の関係 プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。 ● その1 ● その2 ● その3 第2回 抽象データと継承 オブジェクト指向プログラミングを構成する3原則のうち，前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後，残りの「データ抽象」と
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
2011-09-25 - オブジェクト指向言語が生まれた必然性を考える(1) - プログラマ―ズログ
さて、4月からこのBLOGを書いていますが、プログラマーズログと銘打っているのにこの記事が初めての技術系の記事ですw なぜ唐突に技術系の記事を書き始めたのかというと、ダジャレクラウドの使用技術が JAX-RS(RestEasy) Google App Engine/Java Slim3 Twitter4J jQuery という技術を使っているので、これら周辺の技術を身につけたいIT技術者も結構いるんじゃないかと考え、ダジャレクラウドの実装で得た知識をベースにした実践的な勉強会を開こうかと企画しているからです。 とりあえずは、技術者向けでなく自分でWebサービスを立ち上げたいが、フロントエンドはともかくとしてバックエンドがよくわからないWebデザイナーやイラストレータだけどWeb系の知識をつけたい人のようなグラフィック系のスキルを持った人を対象に基礎的な講座を開こうかと思っています。グラフィ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
存在しない記事 - 標高+1m
SOLIDオブジェクト指向ルールのオープン・クローズド原則への批判
オブジェクト指向の設計と実装の学び方のコツ
https://atmarkit.itmedia.co.jp/ait/subtop/features/da/dt_oop_index.html