継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
クラスが増えても大丈夫！成長するソフトウェアを支えるリファクタリングの技術 - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
開発部門（基盤本部）でエンジニアの育成を担当している高玉です。 基盤本部ではさまざまな勉強会を開催しています。先日も、BIGLOBE Styleでその様子をご紹介しました。 style.biglobe.co.jp 「クラスを増やすの、怖くないですか？」 オブジェクト指向プログラミング（OOP）を学んでいた時に聞かれたことです。業務ではJavaやドメイン駆動設計を活用しているので、クラスベースのOOPが題材になることが多いのです。OOPに慣れていない人からすると、クラスの数が増えることで全体を把握しづらくなったり、適切なクラスを見つけるのが大変になりそう、と感じるそうです。 「大丈夫！クラスを増やしたほうが楽になることがあるよ！」 と伝えたくて、この記事を書かせていただきました。何が楽になるのでしょう？それは、ソースコードを読むこと、です。「クラスを増やすと、ソースコードを読むのが楽になる？
2021年の「オブジェクト指向」を考える
きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」
オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena
定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代
2000年代オブジェクト指向は絶対の正義だった。つまり僕は洗脳を経験している - レベルエンター山本大のブログ
私がIT業界の片隅に所属をし始めた2000年ごろ、Javaエンジニアはスーパースターだった。Javaエンジニアを名乗るということは、秘奥義オブジェクト指向を習得していることに他ならないからだ。 「オブジェクト指向こそ正義」だった。 Javaとオブジェクト指向を身につければ、20年は食っていけると言われたものだった。 あれから20年。たしかにJavaとオブジェクト指向で20年は食えた。が、もはやオブジェクト指向は絶対でも正義でもない。 僕は、IT講師として新入社員にJavaを教える仕事もしているが「オブジェクト指向こそ正義」と無垢な生徒達に教えなければならない時に、苦痛を覚えるようにすらなってしまった。 2000年代から、新人教育のテキストは変わっていない。継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている。Strutsだけ
PHPによるデザインパターン入門 - 目次 - Do You PHP はてブロ
このエントリは、Do You PHP?(www.doyouphp.jp)で公開していたコンテンツを移行/加筆/修正したものです。公開の経緯はこちらをどうぞ。 2006/11/23に株式会社秀和システムさんから発売された「PHPによるデザインパターン入門」（ISBN4-7980-1516-4)を執筆しました。 また、2009/09/14付けの絶版に伴い、Do You PHP?にて校正前の原稿テキストを公開していました。が、この度、Do You PHP?の閉鎖に伴い、はてダに移行しました。今回の移行で、校正完了間際の原稿に差し替えましたが、まだ誤字/脱字、説明不足の箇所もあるかも知れません。ご了承ください。 1章 デザインパターンの世界へようこそ デザインパターンって何？ デザインパターンとは？ オブジェクト指向 GoFパターン デザインパターンのメリット・デメリット デザインパターンを使うメ
SwiftとKotlinの構文比較 (2) 〜クラス、列挙体、構造体、プロトコル、拡張 - Qiita
class NamedShape { var numberOfSides: Int = 0 var name: String init(name: String) { self.name = name } func simpleDescription() -> String { return "A shape with \(numberOfSides) sides." } } class NamedShape(name: String) { var numberOfSides: Int = 0 var name: String = "" init { this.name = name } fun simpleDescription() : String { return "A shape with ${numberOfSides} sides." } } class Square: Nam
オブジェクト指向設計原則とは - Qiita
はじめに オブジェクト指向の設計原則を説明します 勉強内容のアウトプットです 単一責任の原則 単一責任の原則は非常にシンプルな内容で、「1つのクラスに1つの役割(機能)」と言うものです。 これはカプセル化で強く言われる「小さなカプセル」ということに通じます。 ただ、この「1つのクラスに1つの役割」という考え方は正しいのですが、コレを正確に運用するのは非常に難しいです。運用が難しいというのは「1つのクラスに1つの役割」という言葉を指針としてしまうと思わぬ間違いを生むということです（言葉自体は正しいが、人間はアホなので間違っちゃうのです） そこで、クラスの妥当性をチェックするために別の角度から眺める必要が出てきます。この時の言葉が 「クラスを変更する理由が2つ以上存在してはならない」 という言葉です。この言葉は単一責任の原則の話で重要となる言葉ですので、覚えておいてください。 さて、あなたはあ
オブジェクト指向エクササイズのススメ
3. ThoughtWorksアンソロジー ThoughtWorks社コンサルタント ● の 骨太なエッセイ集 様々な ジャンルを収録 ● DSL、プログラミング、設計、 マネジメント、ビルド、デプロイ、テス ト．．． オライリーさんブースで ● 絶賛販売中！ 3
オブジェクト指向設計 getter, setterを使うなとはどういうことか - Qiita
趣旨 今回は、とかく誤解されたままになりがちなこのテーマについて自分の中での整理も兼ねて書いていきます 内容は特定の言語に限定されるものではありませんが、コード例はJavaで書いています。他の言語をお使いの方は適宜読み替えながら読んでいただければ幸いです 入門書は間違ったことを教えている？ 皆さんはどのような本でオブジェクト指向プログラミング言語を勉強しましたか？多くの方は例えば「やさしい～」や「たのしい～」のような入門書から入ったのではないでしょうか（中にはいきなり分厚い言語仕様から入る剛の者も居るようですが） その中で必ずと言っていいほど書かれているワードがあります フィールドはprivateにし、その値の書き換えや読み取りにはgetterやsetterを用意しましょう。これによってカプセル化が維持されます さて一方でコミュニティなどでは次のように言われることがあります getterや
Kotlinまとめ - 文法詳解 - インタフェース - Qiita
インタフェースの定義と実装 実装するオブジェクトの協会におけるプロトコル(規約、取り決め)を表現するもの インタフェースのメンバは基本抽象メンバ(abstructを書かないのが普通) 直接インスタンス化できない interface Greeter { val language: String fun sayHello(target: String) } class EnglishGreeter: Greeter { override val language: String = "English" override fun sayHello(target: String) { println("Hello, $target") } } 抽象クラスとの違い インタフェースにはコンストラクタがない 継承可能なクラスは1つ。準拠可能なインタフェースは1つ以上 複数のインタフェースを実装する場合は
オブジェクト指向歴25年のオブジェクト指向おじさんが語るオブジェクト指向設計の処方箋 - Qiita
この記事のターゲット この記事は以下の人々を対象としています。 オブジェクト指向を一通りわかっている人。 オブジェクト指向の設計力を高めたい人。 オブジェクト指向を使っているのに、設計が綺麗にならず悩んでいる人。 プログラムが大きくなるとオブジェクト指向設計が破綻する人。 オブジェクト指向に限界を感じている人。 共同開発メンバーの設計力に差があって困っている人。 以下の人は対象外です。 オブジェクト指向が何なのかわからない人。 オブジェクト指向を極めている人。 関数型など別のパラダイムに活路を既に見いだしている人。 オブジェクトは責任ベースで考える オブジェクト指向といえば、やれインターフェイスだメッセージだ隠蔽だカプセル化だ、みたいな用語がたくさん出て来て、どれも関連があるようでないようで意味が分からないですよね。気取ったこと言ってんじゃねぇよと。 日本で社会人経験があれば、こんなものは
オブジェクト指向設計（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（条件分岐
大規模開発でオブジェクト指向は本当に変更に強いのか？
オブジェクト指向（OOP）は変更に強い、と一般に言われます。 カプセル化とかいろいろな機能のおかげで、あとから仕様変更する場合などに他に影響が及びにくい、と。 しかし実際には銀行や官公庁の大規模プロジェクトで、システム開発の失敗や遅延、頓挫などをしばしば見聞きします。 それらはおそらくJavaでOOPで開発されているはずです。 失敗や遅延などする理由は、発注元の曖昧な要求や後出しの仕様変更の多発などが想像されます。 でもOOPであれば、少なくとも仕様変更には強いはず。 なのに、なぜ失敗しまくるのでしょうか？ なぜ仕様変更のたびに膨大な影響範囲の調査・テストが必要なのか？ ある一部分の機能を変更するだけなら、そのクラスの単体テストだけでいいんじゃないの？ 「OOPは設計が大事。最初の設計がダメだった」という意見が想定されます。 しかし数百億円・数千億円規模のプロジェクトに関わるレベルの人です
オブジェクト指向の法則集 - Qiita
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します
PHP5.4 で実装された trait のまとめと実際の利用例｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
PHP5.4 で実装された trait のまとめと実際の利用例 弊社技術ブログへお越しのみなさま、こんにちは。今年度入社の新人、 YamaYuski です。 先日、社内勉強会にて「traitを使って楽したい話」という演目で簡単に trait について発表しました。 trait が実装された PHP5.4 は2年も前にリリースされたものなので、何故今更、という話になると思います。 しかし、ネット上(特に日本語圏)においての trait の記事はまだまだ少なく、具体例を探すのも大変だったので、「もしかして trait はあまり浸透していないんじゃないか？」と考え、 trait の有用性を世に広めるためにこの記事を作り始めました。 今回は、初心者ながら個人的に調べたり考えたりしたことを、 trait とはなにか trait の実装方法と利用方法 どのようなケースで実装するか 実装時の小ネタ の4
「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い - Qiita
はじめに 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考えるという記事がkenokabeさんという方が挙げていて、拙著の 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡について言及があったので、補考として挙げておく。 暗黙的状態と明示的状態 これまで、関数を「わかりやすくきれいに書く方法」とオブジェクト指向が「どのようにして生まれてきたか」について話してきた。 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 一見、それぞれ関係ないように思うかもしれないが、実は大きなテーマでつながっている。 『それは「状態」をどのように取り扱い単純化するか。』ということだ。そして、これがいわゆる関数型プログラミングとオブジェクト指
リーダブルコード、あるいはコードコンプリートについて - mizchi's blog
リーダブルコードから学べるのは嘘メソッド名と嘘コメントが最大の罪ってことだよ— 片手間以上 (@mizchi) 2014, 7月 5 コードコンプリート、個人的にそんな有益な話はなかったという記憶なんだけど単に趣味のドメインが違うだけかもしれない可能性はある— 片手間以上 (@mizchi) 2014, 7月 5 コードコンプリート、作者が一生懸命になってる主張の部分が全然共感できないのがあった— 片手間以上 (@mizchi) 2014, 7月 5 僕はGoFはむしろ初心者に絶対に読ませてはいけない本だと認識していて、グローバル変数をファサードとか言い出したり、これはシングルトンなんです！と言い出す— 片手間以上 (@mizchi) 2014, 7月 5 本読んでコード書けるようになるとか幻想だと思ってるので、基礎文法覚えたあたりでコードコンプリート読んで、その後はいろんなパラダイムのフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインパターン[モデリング] -TECHSCORE-
オブジェクト指向できていますか？
