OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
オブジェクト指向宗教史
OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
マリオで学ぶSOLID原則
はじめに 最近オブジェクト指向とデザインパターンについて学び始めたので、勉強しつつ記事にまとめていきたいと思います。 初回はSOLID原則についてです。SOLID原則はオブジェクト指向プログラミングにおいて、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくするために考えられたルールです。 この記事では、オブジェクト指向プログラミングの重要な開発原則であるSOLID原則について皆さんが想像しやすいマリオのクラス実装を例に解説していきます。 1. S (Single Responsibility)：単一責任の原則 クラスは単一の責任を持つべきと言う原則です。 ここでの責任というのは、オブジェクトが持っている機能のことです。 一つのクラスができる機能（責任）が複数あると、クラス内部の関数が強い結合を起こす可能性が高ま理望ましくありません。 次のマリオクラスを見てみましょう。
Table of Contents · Game Programming Patterns
Table of Contents Game Programming Patterns Acknowledgements Introduction Architecture, Performance, and Games Design Patterns Revisited Command Flyweight Observer Prototype Singleton State Sequencing Patterns Double Buffer Game Loop Update Method Behavioral Patterns Bytecode Subclass Sandbox Type Object Decoupling Patterns Component Event Queue Service Locator Optimization Patterns Data Locality
本当のオブジェクト指向の話をしよう - Qiita
この記事はC#アドベントカレンダー5日目の記事です。 2時間くらい間に合いませんでした はじめに 今年もアドカレの季節がやってきましたので、今年もさっそく記事を書いていきます。 ずっといつか書こうと思っていた、「オブジェクト指向って何？」に対する自分なりの答えです。 多分かなり長くなる気がするので、気長に読んでいただけると幸いです。 オブジェクト指向って何？ よくある説明 さっそくですが、「オブジェクト指向」とは何か。ひとまず既存の説明を検索してみましょう。 「ある役割を持ったモノ」ごとにクラス（プログラム全体の設計図）を分割し、モノとモノとの関係性を定義していくことでシステムを作り上げようとするシステム構成の考え方のこと。 オブジェクト指向とは、コンピュータプログラムの設計や実装についての考え方の一つで、互いに密接に関連するデータと手続き（処理手順）を「オブジェクト」（object）と呼
「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
値オブジェクト（Value Object）は3種類ある - パンダのプログラミングブログ
Value Object（値オブジェクト）は3種類あった Value Object（値オブジェクト） の意義と使い所がわからなかった。そこで調べてみたらなんと3種類あった。面白かったのでその調査過程を紹介する。 なお、現在では DDD の意味での Value Object がメインであること、またこれは自転車置き場の議論であり、DDD Quickly の Value Object の章を読む方が有意義であることを先に記しておく。 1. Data Transfer Object 1つ目は、Data Transfer Object（DTO）の意味だ。これは PoEAA に少しだけだけ出てくる。かつてのJava界隈の一部では（？）DTOのことを Value Object と呼んでいた。だが、現代では Value Object と DTO は別物として定着している。PoEAA は2000年代前半に
オブジェクト指向プログラミングは終わった カプセル化が悪い(感想戦) - Qiita
が(良くも悪くも)注目頂き、その観測で思ったことのメモです。1年後の自分用です！ もっかい言いたいこと再考のポエムです。 概要 関数型には意図的に触れたくなかった 継承や再利用性への懐疑の共通認識 抽象化戦略開発戦略で補う話 タイトルは釣り 抽象化という言葉のふわっと感 カプセル化が問題 関数型言語には意図的に触れたくなかった ポリモーフィズムのくだりで、関数型のご指摘が多かったのですが、あえて直接は触れたくありませんでした。これは、オブジェクト指向 vs 関数型にしたくなかったからです。(結果、Rust/Goに被弾させました) なぜかと言えば、オブジェクト指向を(結果として)衰退させたのは、あくまでも 開発手法の変化 や設計論の精錬が主軸だと認識しています。 不確実性に適応する上で、継承やカプセル化による状態隠匿という戦略が、良い筋に動かず、オブジェクト指向なりに変化を遂げた結果だと考え
Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
継承は禁止するべき
キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。 オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。 そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。 また、凡庸なプログラマが継承で実現したい
なぜ昨今のJavaScriptではイミュータブルであるべきと言えるのか歴史的背景を踏まえて言語化する - Qiita
先日JavaScriptに慣れていない人のコードをレビューする機会があり、constで宣言されたオブジェクト内部に副作用を与えている記述がありました。 その時に「今の動作に問題ないけど、今風のJSならイミュータブルの方が良いかも」と指摘したものの、JSに疎い人からすれば背景が分からないはずで、理由を自分なりに説明したものの案外言語化が難しかったことがありました。 難しい理由として、イミュータブルであることは実利面と同時に、Facebook発祥のトレンドという側面も多分に含んでおり、JavaScript自体の潮流も踏まえておく必要があるからです。 今回は実利面に加えてトレンド面も交えて、なぜイミュータブル性がJavaScriptで重宝されるのかを見ていきましょう。 フロントエンドの世界では状態を持ち、時間やインタラクションと共に変化するから サーバーサイドの世界から見た場合、HTTPはステー
Object-Oriented Programming — The Trillion Dollar Disaster
OOP is considered by many to be the crown jewel of computer science. The ultimate solution to code organization. The end to all our problems. The only true way to write our programs. Bestowed upon us by the one true God of programming himself…
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
Design Patterns and Refactoring
Abstract Factory The purpose of the Abstract Factory is to provide an interface for creating families of related objects, without specifying concrete classes (more...) Builder The Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations (more...)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Utility and helper classes - a code smell? — John Mikael Lindbakk
Redirecting
Ralph Johnson, Joe Armstrong on the State of OOP
OOP Overkill
今あえてDRY原則に向き合う
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
