継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
デザインパターン〜とかアーキテクチャ〜〜とか・・・に行く途中の話
こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい
オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が
オブジェクト指向プログラミングは終わった カプセル化が悪い(感想戦) - Qiita
が(良くも悪くも)注目頂き、その観測で思ったことのメモです。1年後の自分用です！ もっかい言いたいこと再考のポエムです。 概要 関数型には意図的に触れたくなかった 継承や再利用性への懐疑の共通認識 抽象化戦略開発戦略で補う話 タイトルは釣り 抽象化という言葉のふわっと感 カプセル化が問題 関数型言語には意図的に触れたくなかった ポリモーフィズムのくだりで、関数型のご指摘が多かったのですが、あえて直接は触れたくありませんでした。これは、オブジェクト指向 vs 関数型にしたくなかったからです。(結果、Rust/Goに被弾させました) なぜかと言えば、オブジェクト指向を(結果として)衰退させたのは、あくまでも 開発手法の変化 や設計論の精錬が主軸だと認識しています。 不確実性に適応する上で、継承やカプセル化による状態隠匿という戦略が、良い筋に動かず、オブジェクト指向なりに変化を遂げた結果だと考え
やはり「オブジェクト指向」のオブジェクトを「モノ」とかって訳すのは間違っている。 - Qiita
はじめに すみません。ごめんなさい。 別に間違ってるわけじゃないです。「モノ」でもいいと思います。 ただ、「『オブジェクト指向』って何?」っていう状態の人に、「全てを『モノ』と考える」とか言ったら余計混乱するだろうなーと思ってます。皆さんそうですよね。 TL;DR オブジェクト指向では、操作対象を重視する。 手続き型プログラムでは、操作対象はコマンドの引数とされる。目的語の扱い。 オブジェクト指向プログラムでは、操作対象が文の先頭にくる。主語の扱い。 「オブジェクト指向」とは 「オブジェクト指向」は、「object-oriented」の日本語訳です。 「oriented」が「指向」と訳されているわけですが、名詞ではなく本来は形容詞です。 また、「指向」という単語も意味がよく分からないので、別の訳語「○○を重視する」をあてましょう。 「オブジェクト指向」が意味するのは、「オブジェクト重視の○
オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena
定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代
まんが 「オブジェクト指向ユーザーインターフェース」
表紙 The Art of User Interface Design ジ・アート・オブ ユーザーインターフェースデザイン 藤井 幸多 少年と博士が並んでいる 扉絵 オブジェクト指向ユーザーインターフェース 健太が思考の中からオブジェクトを手で取り出し、アプリのデザインへ埋め込んでいる それを見守る博士と母親 橘 健太（以下 健太）「決めた！アプリを作る！！」 健太の母「え？アプリ？」 健太「うん！毎日いろんなものを見つけるんだけど図鑑に載ってないものが多くて」 健太「だから見つけたものを記録するアプリを作りたいんだ」 健太の母「それはいいアイデアね！！でも困ったわ。お母さんそういうこと全然詳しくないのよ。あ！イリュウ博士に聞いてみたらどうかしら？」 健太「手品師のジョンおじさん？」 健太の母「そうよ。確かコンピュータに詳しかったはずよ」 射留（いりゅう）研究所 ジョン・イリュウ博士（以下
OOPに対する問題は誇張されている
Young Coderより(M)。 50年経った今でも、私たちはプログラミングの支配的なパラダイムについて混乱しています。 マシュー・マクドナルド 何人かの敵を引き付けなければ、開発世界を何十年も支配することはできません。そして、オブジェクト指向プログラミングは、新旧数十種類の言語の概念的基盤を提供していますが、確かに敵もいます。 そのためか、私たちはOOPについての終わりのない一連のホットテイクに苦しんでいる理由です。彼らはOOPを、生産性を破壊する災厄であるとか、一連のごまかしのプログラミング・パターンであるとか、貧しいプログラマが無能さを隠すために設計された平凡なツールであるとか説明してきました。OOPは死んだとさえ宣言されたことがありました(14年前ですので、割り引いて下さい)。 OOPの4つの柱 これらすべての暴言に共通しているのは、現代のソフトウェア設計の落とし穴のいくつかを(
7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
オブジェクト指向のハードコア
オブジェクト指向のハードコアは2019年5月25日にゼロベースサロンで行われたイベントです。「オブジェクト指向」というキーワードについて、プログラミング、デザイン、哲学などの分野を横断しつつ知的な議論ができました。記録映像は必見。 企画意図／招待状 この研究会の企画意図については、私が送った招待状を見ていただくのが早いでしょう： いくつか異なる分野で「オブジェクト指向」がキーワードとして注目されています。昨年からGUIデザインの分野では「オブジェクト指向ユーザーインターフェイス」(OOUI)の議論がホットです。ソフトウェア開発の分野では、数年前からオブジェクト指向の見直しとしての「ドメイン駆動設計」(DDD)が広まっています（※原著である英語版から日本語への翻訳は数年遅れています）。さらには「オブジェクト指向存在論」(OOO)も思想業界でブームになっています。 これはもうオブジェクト指向の
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
PHP:手軽なのに型安全。多重度[1..*]の制約を実装する裏ワザ - Qiita
オブジェクト指向するとき、「多重度が1以上」の制約を設計で想定することがある。例えば、「メッセージ」には「受信者」がいるが、「受信者は最低1名」という制約をクラス設計(UMLのクラス図)で表現すると次にのようになる。recipientsはMessageクラスのメンバで、1..*が多重度1以上を意味する。 本稿では、こうした多重度が1以上のモデルを、PHPでいかに型安全1にコードに落とし込んだらいいか、その裏ワザを紹介する。 なお、本稿で提示するPHPのサンプルコードの完全版はGitHubで公開しているので、必要があれば参照していただきたい。 オーソドックスな多重度制約の表現方法 今回紹介したい内容に行く前に、多重度制約を表現するオーソドックスな実装方法を見ておこう。 final class Message { /** * @var Recipient[] */ private $recip
![PHP:手軽なのに型安全。多重度[1..*]の制約を実装する裏ワザ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/30495a4c437df70e15dff755b10a51ab03f6a0e0/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9UEhQJTNBJUU2JTg5JThCJUU4JUJCJUJEJUUzJTgxJUFBJUUzJTgxJUFFJUUzJTgxJUFCJUU1JTlFJThCJUU1JUFFJTg5JUU1JTg1JUE4JUUzJTgwJTgyJUU1JUE0JTlBJUU5JTg3JThEJUU1JUJBJUE2JTVCMS4uJTJBJTVEJUUzJTgxJUFFJUU1JTg4JUI2JUU3JUI0JTg0JUUzJTgyJTkyJUU1JUFFJTlGJUU4JUEzJTg1JUUzJTgxJTk5JUUzJTgyJThCJUU4JUEzJThGJUUzJTgzJUFGJUUzJTgyJUI2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1kZmU4YWEzY2JmODFlM2YyZDhiZDZhOGMwYTJmYTg0ZA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc3VpbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NGFlNjk2NWUyOWFiNjg4MmRlNmViY2E4NDc2NWMxMjA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D60b23b31fd0aa6daa1a85793d41476d0)
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
staticおじさんの逆襲 - Qiita
実はオブジェクト指向ってしっくりこないんです! 私はJavaでキャリアを始めたので、当然、オブジェクト指向を前提としてプログラミングを学んでいきました。オブジェクト指向の概念を聞いたとき、なるほどこれはよくできているなと思ったのを覚えています。オブジェクト指向では、現実世界の「もの」をそのままオブジェクトに表現します。なるほど、合理的でプログラミングが簡単になるように感じます。ちょうど現実のものを操作するようにプログラミングができるのですね。 実際にオブジェクト指向でプログラムを書こうとして分かったのは、私が作っているのはコンピューターのコードであって、現実のものではなかったということです。ArrayListって現実の何に対応するんでしょうか? 本棚? 「プログラミングはデータの入出力と、その変形のことだ」というデータ指向プログラミングの考えを知ったことが、決定的にオブジェクト指向への興味
もっと早くオブジェクト指向設計実践ガイド読んどけばよかった - razokulover publog
@joker1007さんが激推ししてたのでオブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方を読んだ。 なんかすんませんw Sandi Metz本はここ数年でトップクラスに良い本だったのでオススメです。 #railsdm— ジョーカー (onkさんに返済完了) (@joker1007) 2017年12月9日 内容としては、オブジェクト指向設計の核となるものを初めての人でもわかりやすく理解できるように書かれた本という感じ。 この手の本は静的型付け言語でかかれたものが多いがRubyで書かれてるのでゆるふわなwebエンジニアにも読みやすそう。 流行りのDDDをやるにもまずオブジェクト指向がしっかり理解できてないと厳しいし、まずはしっかり土台を固めようぜみたいな。 オブジェクト指向を理解した気になっている人とか、新卒で入社してきたwebエンジニア諸氏に
書評『現場で役立つシステム設計の原則』 - まっつんの日記
下記の本のレビュー記事。 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨 出版社/メーカー: 技術評論社 発売日: 2017/07/05 メディア: 単行本（ソフトカバー） この商品を含むブログを見る 内容 特定の理論や手法を説明したものではなく、それらをどのように組み合わせていけば、変更が楽で品質の高いシステムを開発できるのか、って問いに答えるオブジェクト指向アプリケーション開発の秘伝の書。 基盤となっているのは ドメイン駆動設計 Thoutworks流のオブジェクト指向開発（マイクロサービスアーキテクチャ含む） XP（エクストリームプログラミング） データモデリング（リレーショナルモデル） あたり 感想 最初の雑感 とにかく様々なことを勉強した上で、現場の実践で考え抜かれ、蒸留されたノウハウが詰め込まれている。ありがとうございます、とし
『オブジェクト指向設計実践ガイド』を読もう（2016/12/16 社内勉強会）
『オブジェクト指向設計実践ガイド 〜Rubyでわかる進化しつづける柔軟なアプリケーションの育て方』を読んで「みんな読めばいいのに！」という強い思いを発表しました。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
契約による設計事始め
オブジェクト指向が0.005%理解できる記事 - Qiita
一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？
