オブジェクト指向がわからない！ そんなあなたの脳味噌をオブジェクト脳にする準備体操
オブジェクト指向で挫折しないために オブジェクト指向のプログラミング言語は当たり前の存在になり、たしかに目新しさはなくなりました。業務でオブジェクト指向のプログラミング言語が使っている方も多いと思います。 だとすれば、そもそもオブジェクト指向とはどういうもので、実際のプログラミングでどう役立つのか、特別に学ばなければならないようなものなのでしょうか。 考えてみてください。たとえRubyやJavaを使えているとしても、オブジェクト指向プログラミングができているとは限らないのです。Rubyを学び、Railsの本を読んで自動生成されるコードを書き換えることはできても、自分でクラスを追加することができない方もいるかもしれません。 Ruby、Java、Pythonといった個別の言語を学習すると、どうしてもその言語の特徴や機能を中心に学ぶことになります。オブジェクト指向は技術書を読む前提知識として扱わ
どのようにしてクラス設計を行うのか？クラス設計の考え方とコツ
今回は、詳細設計（内部設計）におけるクラス設計について、考えてみたいと思います。 クラス設計とは 外部的な振る舞いを設計する基本設計（外部設計）と違い、クラス設計は、プログラム内部の構造を設計する詳細設計フェーズに位置します。 極端な話、クラス設計などなくても、全ての処理をひとつのメソッドに書いてしまうこともできます。 では、なぜそうしないのか？先に述べたようなプログラムでは、様々なコストが掛かってしまう可能性が非常に高いからです。 劣悪な設計によるコスト増大 保守コスト たとえば、一人でプログラムを組むとしましょう。プログラムの隅々までしっかり把握しており、何か変更を加えなくてはならなくなったときでも、素早くその箇所に辿り着き、変更を加えることができます。 しかし、現実に、一人でそのプログラムを永久にメンテナンスすることはあり得ません。自分ひとりで運営しているサービスであったとしても、不
オブジェクト指向言語で処理したら保守性が悪い！：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 如何様にも結論づけられる主観的な話になるので、宗教論争にしかならないからあまり書きたくないのですが……。いつも以上に、布教活動というか、独り言みたいなものですので、気楽に読んでいただければ。 一般的なシステムで、オブジェクト指向言語で処理を記述することと、SQLで処理を記述することについて、「保守性（拡張性）のために」というのが、オブジェクト指向言語で処理を記述することの金科玉条になっていますが、本当にそうでしょうか。 そもそも、業務システムの保守性とは 【保守性】 オブジェクト指向言語 ＞ SQL ＞＞ 混在型 が成り立つと、わたしは考えています。 オブジェクト指向言語推進派の方は、インピーダンスミスマッチをものすごく嫌う（わたしも嫌いですけど）。つまり、オブ
[PHP] そのプロパティ、privateに出来ませんか？ - Qiita
前書き 最初に言っておきます、オブジェクト指向をちゃんと理解している人は読む必要のない記事です。おぼろげにしか理解していない人のために、またつい最近までちゃんと理解していなかった自分へのメモのために書きます。 プロパティは全て private が当たり前だと思っている人は読まなくていいです。 プロパティは全て public が当たり前だと思っている人はもうちょっとクラスの継承・カプセル化について勉強してから読みに来てください。 2014/11/25 タイトル変更 コメント欄の@xipxさんの指摘、ならびにそれに対する私の回答を併せてご覧ください。 問題 外部からのアクセスに対してアクセス修飾子が持つ意味 「プロパティは全部 private が当たり前だ！」とは言いましたが、当然 「継承するときどうするの？」 って思いますよね。ここで例を示します。文字列のみをプロパティとして格納することを許
![[PHP] そのプロパティ、privateに出来ませんか？ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f2c7b48ce6ac8b3b451176159bd8eb84345b361/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCUEhQJTVEJTIwJUUzJTgxJTlEJUUzJTgxJUFFJUUzJTgzJTk3JUUzJTgzJUFEJUUzJTgzJTkxJUUzJTgzJTg2JUUzJTgyJUEzJUUzJTgwJTgxcHJpdmF0ZSVFMyU4MSVBQiVFNSU4NyVCQSVFNiU5RCVBNSVFMyU4MSVCRSVFMyU4MSU5QiVFMyU4MiU5MyVFMyU4MSU4QiVFRiVCQyU5RiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZTBiNTMwODQ1MjkwNzgyZTI0NDZiNmIzNWEwYzcyYWY%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbXB5dyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZTcxMDU2ZjgzMjg0YmM3ZWY2NDM1OThkMjkyNmU4Yzg%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D2e9fcd55c9af7731bb9c45b2fb929c1a)
訳しました:「オブジェクト指向設計実践ガイド」 - 弥生開発者ブログ
こんにちは。Misoca開発チームのtaiki-tです。 先日、本を訳したのでそのことについて書きたいと思います。訳した本は「オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方」。 オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 作者: Sandi Metz,?山泰基出版社/メーカー: 技術評論社発売日: 2016/09/02メディア: 大型本この商品を含むブログを見る 原著は”Practical Object-Oriented Design in Ruby” です。 Practical Object-Oriented Design in Ruby: An Agile Primer (Addison-Wesley Professional Ruby) 作者: Sandi Metz出版社/メーカー
オブジェクト指向設計（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（条件分岐
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
オブジェクト指向に近づく9つのルール (ThoughtWorks アンソロジーより) - Qiita
ThoughtWorks アンソロジーの5章オブジェクト指向エクササイズから 9つのルールを学んだのでメモします 1. 1つのメソッドにつきインデントは1段階まで 巨大なメソッドになればなるほど凝集度が低くなる。 メソッドが1つの仕事を行う場合、制御構造はあって1つ。 制御構造が複数ある時点でメソッドに対して仕事が複数ある。 だから、制御構造を1つに抑える 下記は書籍から引用 リファクタリング前 class Board { String board() { StringBuffer buf = new StringBuffer(); for (int i = 0; i < 10; i++) { for (int j = 0; j < 10; j++) { buf.append(data[i][j]); } buf.append("\n"); } return buf.toString();
「独習Python入門」は一生付き合える入門本だと334回言いたい - Lean Baseball
私がリスペクトするエンジニアの一人であり、ITエンジニア界隈の三大野球バカの一人*1であるござ先輩が本を出版されました. gothedistance.hatenadiary.jp 大変ありがたい事に、献本を頂いたので久々に書評など書いてみようかなと思います. [書評]「独習Python入門」 どんな本なのか 私の感想も含めて. Pythonを元にしたプログラミングの入門本 一人で学ぶ(独習)するときにハマりがちなポイントや、ステップアップするときに必ず覚えたほうがいい事を言葉の緩急を駆使していい感じに解説している！ 本を一冊やり切った(写経)した後も自宅の本棚に置いておきたい&必要に応じて再び読みたくなる本 私は読者層に当てはまらないのですが（汗）、初心者の気持ちになって思い出しながら読んで、 「ああ、最初にプログラミングを学ぶ本がこの本みたいなスタンスだと凄くいいな」 と素直に思いました
オブジェクト指向の欠点をカバーする努力 - Qiita
オブジェクト指向の問題点 インターネッツを良くするポエムというのは、「こういう問題に対して、こういうソリューションでカバーしてきたよ」をみんなでシェアすることだと思うので、ここに挙げられていることの一部に対して、オブジェクト指向界隈が今までこんな工夫をしてきたよとか、僕の目から見えている「技術発展の流れ」について書いてみようと思います。まあ僕も全ジャンルをまんべんなくやっているわけじゃないし、一部想像で補っている部分もあります。他にもあればぜひシェアしてください！ 上記のサイトで書かれている内容のうち、 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 関係性が表現できない ユーザレベルでの部品化再利用に全然なっていない について取り扱います。 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 元は2項目ですが、内容的
基礎 第8回: オブジェクトの関連―依存
さて、今回はオブジェクトの関連の一つ、依存について考えてみましょう。 依存という言葉は、まぁよく聞くとまでは言えなくとも、そこそこ聞くこともありますよね。 あまり印象の良くない言葉が多いかもしれませんが。 「アルコール依存症」みたいなね。 依存とは、何かが他の何かに頼ること、または、頼ることで成り立つことです。 では、オブジェクト指向の世界での「依存」とは、どういうことなのか見てみましょう。 コンテンツ依存ってこういうこといろいろな依存依存の網！あらためてオブジェクト思考ってオススメ依存ってこういうこと オブジェクト指向の世界での依存は、それほど悪い意味ではありません。 (まぁ、悪い意味になっちゃう場合もあるんですが、それはおいおいということで) あなたがカレーを作るとき、あなたはカレーに依存しています。 はい、なんのこっちゃですね。 これを紐解いてみましょう。 カレーを作るということは、
基礎 第9回: オブジェクトの関連 ― 包含
今回は「包含」について考えます。 包含は非常に自然な考え方です。 また、実例が身近に溢れていますので、すんなり理解していただけると思います。 非常に簡単なので、記事も短いです。 しかし、簡単なことなのですが、これが実はすごく奥が深いものなのです。 コンテンツ 包含って 最後の(かもしれない)カレー コンポジション わかりやすいですね オススメ 包含って 包含は、実は前回お話しした依存の一種です。 ただ、包含は頻繁に現れる依存関係であり、また特に重要ですので、別に挙げました。 ちょっとお話しするだけで、これはご納得いただけることと思います。 さて。えー、包含とは包み含むことです。 読んで字のごとしなんですが、これだけでは全然ピンときませんね。 またまた例を使って考えてみましょう。 最後の(かもしれない)カレー はい、今回もカレーです。 ここで、カレー大好きさん(私もそうなんですが)には、ちょ
is-a関係とhas-a関係: 継承と包含
あるオブジェクトが、他のオブジェクトを継承しているのか包含しているのか。 一見すると継承と包含は全く別物ですが、これが意外と判断が難しい場合があります。 is-a関係、has-a関係という言葉は、そういう場合の判断の指針として使われるものです。 コンテンツ はじめに 分類による分析 分割による分析 分類法と分割法をオブジェクト指向で表現 本質はアプローチ はじめに 最初に知っておいていただきたいのは、そもそも、is-a 関係と has-a 関係というのは、オブジェクト指向に限った話ではないということです。 これらは、一般的な物事の本質を捉えるための分析のしかた、考え方についてのメタファです。 分類による分析 is-a というのは、以下のような関係を表しています。 A is a B. 日本語で言うと、A は (is) B の一種 (a) ということになります。 これは、分類法によって物事を捉
オブジェクト指向の問題点 - ビスケットのあれこれ
オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです． 以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されて
「継承より委譲」≠「継承使うな」 - ネットの海の片隅で
TL;DR 適材適所。 「継承より委譲」 オブジェクト指向に関する有名な警句に「継承より委譲」があります。 僕はオブジェクト指向について語れるほど立派な人間じゃありませんが、 「むやみに継承使わないほうが良いよ」 「移譲のほうが良いケースが多いよ」 ってことですね。 ただ、今回は継承の価値を見なおしてみようという話です。 仮定 次のようなものを作りたいと仮定します。 文字列に対して署名を行い、署名された文字列が欲しい。 HMAC/SHA256で変換した結果をBase64に変換。 引数として「署名対象の文字列」と「署名に使うkey」を渡す。 設計1 まず、何も考えずに書いてみました。 class Signatory def initialize(key) @key = key end def sign(text) digest = OpenSSL::HMAC.digest("SHA256",
ORMは不快なアンチパターン | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
オブジェクト指向プログラミングにおいてユーティリティクラスに代わるもの | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、OOP Alternative to Utility Classesを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 ユーティリティクラス(またはヘルパークラス)は、スタティックメソッドだけを持っていて、状態を内包しない「構造体」だ。 Apache CommonsのStringUtils、IOUtils、FileUtilsや、GuavaのIterables、Iterators、またJDK7のFilesはユーティリティクラスのいい例だ。 ユーティリティクラスはよく使われる共通機能を提供するので、この設計手法はJava(やC#、Rubyなど)の世界でとても人気だ。 要するに我々は、DRY原則に従い、重
本には書いてないオブジェクト指向 | そるでぶろぐ
ソリューション開発部の田中です。 普段の仕事の中で疑問を覚え、さまざまな書籍やサイトにあたったけれども見つからない・・・そんな「今まで無かった!」オブジェクト指向の原理原則を紹介いたします。オブジェクト指向言語を使う開発者の方や、ソフトウェアの保守性を高めたい管理職の方にお勧めします。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dies irae オブジェクト指向の勉強その１
オブジェクト指向の参考書はこれが一番分かりやすかった | ワンナリ-NotOnlyBooks