Pythonのオブジェクト指向プログラミングを完全理解 - Qiita
1. オブジェクト指向の起源 2003年チューリング賞の受賞者アラン・ケイさんはよくオブジェクト指向プログラミングの父と称されます。ご本人も憚ることなく、幾度、公の場で発明権を宣言しています。しかし、ケイさんは「C++」や「Java」などの現代のオブジェクト指向言語を蔑ろにしています。これらの言語は「Simula 67」という言語を受け継いだもので、私が作った「Smalltalk」と関係ないのだとケイさんは考えています。 オブジェクト指向という名称は確かにアラン・ケイさんに由来するものです。しかし、C++とJavaで使われている現代のオブジェクト指向は当初のと結構違います。ケイさん自身もこれらの言語を後継者として認めないです。では、ケイさん曰くC++とJavaの親であるSimula 67という言語はどんな言語でしょうか。ここで、簡単なサンプルコードを見てみましょう。 Class Recta
オブジェクト指向設計実践ガイドを読んだので基本部分をPythonでも書いてみた - サーバーワークスエンジニアブログ
オブジェクト指向設計実践ガイド is https://www.amazon.co.jp/dp/477418361X その名の通りオブジェクト指向の原則に沿った設計を実践しながら学ぶという内容です。 私は今年の3月からCloud Automatorを開発するサービス開発課に配属になりましたが、これまでのプログラミング経験が乏しいこともあり、 オブジェクト指向というものがいまいち掴みきれませんでした。 そこで夏頃からこの書籍を読み始めたのですが、これまで頭の中でぼんやりしていた概念が丁寧に論理立てて整理できた感覚があり、とても勉強になりました。 オススメの書籍ですので、今回はこの書籍の基礎部分をPythonでご紹介したいと思います。 なぜPython? 私自身、普段の業務では主にRubyを利用していますが、 社内の他部署ではPythonが主に使われていて、新人研修で初めて学んだプログラミング言
オブジェクト指向が0.05%も理解できない記事
尽く書を信ずれば即ち書無きに如かず 《孟子『尽心下』より》 イントロダクション 「最も理想的なオブジェクト指向を実現しているプログラミング言語は何か？」と問われたとき、君は何と答えるだろうか？ C++、Java、C#。君がそうだと思っているのは表面だけで、たぶん何もわかっていないのだろう。無知であることを知っているのであれば、無知のまま過ごした方が幸せなときもある。 Simula、Smalltalk、Ruby。君は本質をいくらか知っているようだから、引き返すなら今のうちだろう。深淵を覗けば、君もまた怪物にならざるを得ない。 JavaScript、Python、Go。君が真剣にそう答えるなら、私とは異なる真理に辿り着けたのだろう。君と私のどちらかが正しいのではない、どちらも常に正しく、どちらも常に間違っている。 Erlang、Elixir。君は既に答えを知っているようだから、この記事は全く以
ポリモーフィズムを活用するとなぜ if や switch が消えるのか？ - Qiita
if (売上.勘定科目 == 勘定科目.現金) { // 計算するロジック } else if (売上.勘定科目 == 勘定科目.売掛金) { // 計算するロジック } else if (売上.勘定科目 == 勘定科目.有価証券) { // 計算するロジック } このようなコードはしばしばスパゲッティになりがちですし、 項目が増えるたびに、条件分岐を増やさないといけないので保守も大変です。 売上の課目ごとに計算方法が違いますが金額計算するという振る舞いは同じです。 このコードからif文を駆逐するにはどうしたらいいでしょうか？ 型やフラグ、enumによる条件分岐はたいていの場合、ポリモーフィズムによって消し去ることができます。 ポリモーフィズムとは異なる型のオブジェクトを同一視し、そのオブジェクトの型によって動作を切り替えることです。 ポリモーフィズムは動的型付け言語ではダックタイピング、
staticおじさんの逆襲 - Qiita
実はオブジェクト指向ってしっくりこないんです! 私はJavaでキャリアを始めたので、当然、オブジェクト指向を前提としてプログラミングを学んでいきました。オブジェクト指向の概念を聞いたとき、なるほどこれはよくできているなと思ったのを覚えています。オブジェクト指向では、現実世界の「もの」をそのままオブジェクトに表現します。なるほど、合理的でプログラミングが簡単になるように感じます。ちょうど現実のものを操作するようにプログラミングができるのですね。 実際にオブジェクト指向でプログラムを書こうとして分かったのは、私が作っているのはコンピューターのコードであって、現実のものではなかったということです。ArrayListって現実の何に対応するんでしょうか? 本棚? 「プログラミングはデータの入出力と、その変形のことだ」というデータ指向プログラミングの考えを知ったことが、決定的にオブジェクト指向への興味
オブジェクト指向とは結局何なのか あるいはプログラミングをする上で気をつけるべきたった一つのこと
本題の前に まず「オブジェクト指向」という言葉を知っただけのまったくの初心者の方のために例を出してイメージをつかんでもらいます。あくまで例なので色々不完全なのはご了承ください。言語はJavaですがJavaを知らなくても何となく分かるように書きます。 オブジェクト指向とは （即物的に言えば） データとそれに関わるメソッドを クラス(class) にまとめてプログラミングすることです。 例えば友達の情報を管理するために以下のような「友人」クラスを考えてみましょう。 class Friend { String name;//名前 String phoneNumber;//電話番号 String mailAddress;//メールアドレス Friend(String name, String phoneNumber, String mailAddress) { //thisは自身を意味する thi
「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
オブジェクト指向設計（2016年度）
コンテンツ 第1章 基本的な用語 第2章 オブジェクト指向開発 第3章 設計の問題 第4章 オブジェクト指向設計の原則 第5章 単一責任の原則 第6章 Visitor パターン 第7章 LSP、DIP、ISP 第8章 パターン技術 第9章 ユースケース 第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（条件分岐
オブジェクト指向の欠点をカバーする努力 - Qiita
オブジェクト指向の問題点 インターネッツを良くするポエムというのは、「こういう問題に対して、こういうソリューションでカバーしてきたよ」をみんなでシェアすることだと思うので、ここに挙げられていることの一部に対して、オブジェクト指向界隈が今までこんな工夫をしてきたよとか、僕の目から見えている「技術発展の流れ」について書いてみようと思います。まあ僕も全ジャンルをまんべんなくやっているわけじゃないし、一部想像で補っている部分もあります。他にもあればぜひシェアしてください！ 上記のサイトで書かれている内容のうち、 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 関係性が表現できない ユーザレベルでの部品化再利用に全然なっていない について取り扱います。 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 元は2項目ですが、内容的
オブジェクト指向と20年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav
オブジェクト指向の問題点 - ビスケットのあれこれ
オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです． 以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されて
オブジェクト指向初心者にありがちな後に後悔しない為の7の事inJAVA - プログラムdeタマゴ
私はプログラム歴2年と半、オブジェクト指向プログラミング(以下OOPと略記)歴1年とちょっとというかなり浅いプログラマーである。 私が一年前、OOP初心者時に書いたプログラム（1万行ぐらい）を現在誠意修正作業中なのだが、全く持って読めた物ではない。 この記事はOOP初心者にポリモー何とかだとか、再利何とかだとか、隠蔽何とかだとか、インターフェ何とかだとかそんなことを理解してプログラムしようと啓蒙する為の記事ではない。 何時かあなたが初心者の頃に書いたソースを修正するときに後悔と過去の自分に殺意を向けない為の記事である。 ポ何とかのあたりの事は、いかに述べていく事を守っていれば、1年後のあなたがEclipseをバンバン使いこなしてスムーズに勝手にやってくれるはずだ。今のあなたが気にする必要はない。 1:やたらオーバーロードしない これはOOPではないが、Perlだとか、JavaScriptだ
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
JavaScriptにおける継承のパターン4種類の概要と対比 | POSTD
JavaScriptはとても強力な言語です。強力がゆえ、実はプロトタイプをデザインしたり、オブジェクトのインスタンスを生成したりするのに何種類もやり方があります。それぞれの方法には長所も短所もあります。そこでJavaScript初心者の皆さんのために私がそのあたりを整理して説明したいと思います。今回の投稿は、以前私が書いた 「JavaScriptを分類するな」 の続編です。前回の投稿でたくさんのコメントをいただき、コードの例を出してほしいをいう反応をいただいたので、今回はそれらにお応えします。 JavaScriptはプロトタイプを使って継承 つまり、JavaScriptでは、オブジェクトは別のオブジェクトを継承することができます。 { } 波括弧を使って生成されるJavaScriptの基本的なオブジェクトは、唯一のプロトタイプとして Object.prototype をプロトタイプに持ちま
オブジェクト指向プログラミングデザインルール : 一生涯プログラマ
2014年04月01日00:00 カテゴリProgramming オブジェクト指向プログラミングデザインルール プロのプログラマとはただ仕様通りに動くプログラムを作ればいいという物ではない。 保守性や拡張性を考慮し、変更に強くバグの混在しにくいプログラムを効率よく作る必要がある。 その為に、プログラミングする上で心に留めておかなくてはならない事がある。 今回はその中でも、オブジェクト指向言語においてプログラミングする際に私が意識している事を書き留めたい。 デメテルの法則 オブジェクト間の依存度を最小限にする為に任意のオブジェクトが参照出来る範囲を下記の4つに制限する。(メソッドチェーンを許容しない) 但し、メソッドの戻り値が呼び出し元インスタンスと同じクラスの場合はメソッドチェーンを許容する。任意のオブジェクト自身メソッドの引数に渡されたオブジェクトメソッドの内部で新たにインスタンス化され
JavaScriptの少し独特なオブジェクト指向についてまとめてみた - Rails Webook
Photo by Flickr: slworking2's Photostream 既にJavaやPHPなどオブジェクト指向言語を生業としてやっているが、その感覚でJavaScriptを少し扱っているて、いまいちJavaScript分からないという方を対象に、それらのプログラム言語とは違う、「少し独特なJavaScriptのオブジェクト指向」について説明します。 目次 オブジェクトの作成 プロパティの定義と代入 プロパティの削除 アクセサプロパティ（getter / setter) クラス定義 コンストラクタ引数 インスタンスメソッドの定義 クラスプロパティとクラスメソッドの定義 クラスの継承 クラスプロパティとクラスメソッドの継承 1. オブジェクトの作成大かっこ({})でObjectクラスを作成することができます。 また、new演算子で特定のオブジェクトを作成することができます。 //
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
オブジェクト指向とは何だったのか？ – ゆびてく
5分でわかるガベージコレクションの仕組み
