オブジェクト指向プログラミングを学ぶ オブジェクト指向プログラミングという言葉は、広い意味で使われている。 オブジェクト指向プログラミングをキーワードにすべての情報をかき集めて理解するというアプローチは現実には無理。 目に付いた重要そうなところを見繕って集めてみても、たぶん混乱するだけ。 この記事では、オブジェクト指向プログラミングのいろいろなアプローチの中で、 クラスを使って独自の「型」を定義するプログラミングスタイル 関連するデータとロジックをまとめて、小さな入れ物に格納する「カプセル化」を重視するプログラミングスタイル を学ぶための参考図書を紹介したい。 型とカプセル化に重点を置く設計スタイルがわかってくると、それとは異なるスタイル、異なる力点を置くアプローチとの違いが具体的にわかるようになってくる。*1 *2 まずは、オブジェクト指向プログラミングの中で、型・クラス・カプセル化に力
「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
社内LTにて、ドメイン駆動設計と依存性逆転の原則を布教しましたʕ◔ϖ◔ʔ はてなブックマークのコメントもどうぞ！ なお、ドメイン駆動設計を理解するためには、依存についても知る必要があります。 是非、依存関係と依存オブジェクト注入もご参照ください👍🏻
すえなみチャンス暑気払い 2019夏で話した、設計要素を分解して理解してみようという話です。 Simplicity makes easy to understand.
とある休日 娘「ねぇ、パパ！」 娘「switchやろ〜！」 ワイ「おお、ええで！娘ちゃん！」 ワイ「Switchやろう！」 ワイ「ほな、テレビをつけて・・・」 娘「テレビ？」 娘「何を言っているの、パパ？」 娘「TypeScriptのswitch文のことだよ？」 ワイ「ファッ！？」 switch文で何をしたいのか 娘「今ね、ショッピングサイトを構築してるところなの」 ワイ「ほうほう」 娘「それでね、手広く儲けようと思って」 ワイ「おお、ええやんか」 娘「個人ユーザーだけじゃなく、法人ユーザーも登録できるようにしようと思うの」 ワイ「なるほどな」 娘「言語はTypeScriptを使っているんだけど」 娘「ちょっと聞きたいことがあるの」 ワイ「おう、なんでも聞いてや」 あいさつ関数を作っている 娘「ショッピングサイトにログインしたときに・・・」 個人の場合 → 「無職 やめ太郎さん、こんにちは
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
ミラティブのサーバサイドをGo + Clean Architectureに再設計した話 - Mirrativ Tech Blog
こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ
こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい
今回の記事はオブジェクト指向プログラミングにおける設計の基本、「SOLID原則」について。 ある程度プログラミングの文法を知っていれば、動作するコードを書くことは可能です。しかし、より良いコードを書きたいのであれば、文法の知識だけではなく、設計に関する知識も必要になってきます。 特にUnityでは、適当にコードを書いていくと目も当てられないようなスパゲッティーコードが容易に出来上がります。「とりあえずシングルトンにすりゃいいや！」みたいなノリで「何とかManager」クラスを作りまくった結果、「あれ？この処理どこに書いたんだっけ？」という状況になったこと、誰しも一度はありますよね…？ 今回は、そんなクソk…良くないコードを書かないための設計原則である「SOLID原則」について紹介します。記事内のコードはC#で記述しますが、言語に関わらずSOLID原則は広く応用の効く考え方なので、是非とも覚
はじめに 私自身は今年の 7 月にドメイン駆動設計（DDD）を実践する企業に転職したばかりで DDD 実践歴は浅いのだが、最近は開発業務の他にも中途採用者の DDD 教育や 現場で DDD！2nd のドライバー役をする機会を頂くなど、DDD の布教活動にも少し関わっている。 その中で「DDD ムズイ」という言葉をよく聞いたので、DDD の実践に悩んでいる人向けにサンプル問題の解説を通して、実は DDD 自体は難しくないんだよってことを教える目的で本記事を書いた。 TL;DR（最初に結論） DDD 自体はドメインを中心にモデリングと実装をイテレーティブに繰り返す設計プロセスであり、モデリングと OOP の理解があれば誰でもできる。 難しいのは DDD 自体ではなくて、モデリングまたは OOP である。特に「良いモデル」を得ることは非常に難しい。 なので「DDD ムズイ」と感じる人はモデリング
『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』は、現代ソフトウェア開発の”知の高速道路” - Magnolia Tech
ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用 作者:田中 ひさてる技術評論社Amazon 予約してまで買ったものの、なかなか時間が取れず、読めていなかった『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』をようやく読み終わりました。 筆者である田中ひさてるさん自身で描かれた表紙の可愛らしさからは想像もできないハードな内容なので、一気に読もうとすると「分かった気」になるだけで全然理解していなかった、ということになりがちなので、3回くらいぐるぐる読むといいと思います（そうです、この本は本文もイラストも丸っと同じ人が書いているのです！！）。 目次 第1章 クリーンアーキテクチャ 第2章 パッケージ原則 第3章 オブジェクト指向 第4章 UML（統一モデリング言語） 第5章 オブジェクト指向原則 SOLID 第6章 テスト駆動開発 第7章 依存
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。 本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。 型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。 さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。 関数型の考えをいれるといってもただ単にHaskellなどに代表される関
第0章. なぜ Scala を使うのか？ はじめに 本稿は、John C. Mitchell 氏らによる Concepts in Programming Languages を基に自身の見解を交え、私がなぜ Scala を好んで使うのかを論じた記事になります。 プログラミング言語の歴史 本題に入る前に、プログラミング言語の歴史について紹介します。 年代 言語・イノベーション 1950 Fortran and Cobol 1960 Lisp and Algol 1970 Abstract data types (Simula, C, SQL) 1980 Objects (Smalltalk, C++) 1990 Java, JavaScript, Python, Ruby これは、年代ごとに開発された言語およびイノベーションを表にまとめたものになります。ただし、この表には欠けている事柄があり
この文章みてください。 オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな…… 「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年
2000年代オブジェクト指向は絶対の正義だった。つまり僕は洗脳を経験している - レベルエンター山本大のブログ
私がIT業界の片隅に所属をし始めた2000年ごろ、Javaエンジニアはスーパースターだった。Javaエンジニアを名乗るということは、秘奥義オブジェクト指向を習得していることに他ならないからだ。 「オブジェクト指向こそ正義」だった。 Javaとオブジェクト指向を身につければ、20年は食っていけると言われたものだった。 あれから20年。たしかにJavaとオブジェクト指向で20年は食えた。が、もはやオブジェクト指向は絶対でも正義でもない。 僕は、IT講師として新入社員にJavaを教える仕事もしているが「オブジェクト指向こそ正義」と無垢な生徒達に教えなければならない時に、苦痛を覚えるようにすらなってしまった。 2000年代から、新人教育のテキストは変わっていない。継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている。Strutsだけ
ありがちな仕様とコードを題材に、よくないコードに立ち向かうための整理術を紹介します。 この Book にはデザインパターンや DDD やオニオンアーキテクチャや関数型プログラミングなどは一切登場しませんが、それらのエッセンスと日常のコーディングにおいて求められる基礎的な考え方の説明が含まれています。 この Book の内容は、特定の業務領域やプログラミング言語・フレームワークには限定されません。 Laravel でも RoR でも Spring でも React でも Nuxt.js でも、きっと役に立つはずです。 逆にこの本にはクラス設計のべき論や OOP vs FP のような議論は含まれません。 画一的なコードの良し悪しの定義は難しいですが、何かしら得るものがあったと感じてもらえたらうれしいです。
マリオで学ぶSOLID原則
はじめに 最近オブジェクト指向とデザインパターンについて学び始めたので、勉強しつつ記事にまとめていきたいと思います。 初回はSOLID原則についてです。SOLID原則はオブジェクト指向プログラミングにおいて、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくするために考えられたルールです。 この記事では、オブジェクト指向プログラミングの重要な開発原則であるSOLID原則について皆さんが想像しやすいマリオのクラス実装を例に解説していきます。 1. S (Single Responsibility)：単一責任の原則 クラスは単一の責任を持つべきと言う原則です。 ここでの責任というのは、オブジェクトが持っている機能のことです。 一つのクラスができる機能（責任）が複数あると、クラス内部の関数が強い結合を起こす可能性が高ま理望ましくありません。 次のマリオクラスを見てみましょう。
それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた 多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの？という人たちと、まさにブレークスルーだ世界が変わるとエキサイトした人たちだろう。 色々あったが、人にも読めるソースをアセンブリ言語に変換してくれるCが出来た。 多分このときも単なるアセンブリのスーパーセットだろ？なんか意味あんのか？っていう人たちと、やばいレベルでプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。 その後Javaが登場してオブジェクト指向が花開いた。 このときも、構造化プログラミングに毛が生えた程度のもんだろ？何が嬉しいんだ？という人と、オブジェクト指向なら何でもできる！とエキサイトした人たちで溢れかえったことだろう。 Java以降のIT界隈ではもはやオ
2022/5/14に開催されたTechFeed Conference 2022の5分LTでの登壇資料です
追記: 振り返りを書いてみました～ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性／可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性／可変性分析 共通性／可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題領域にある概念を見つける（共通性の分析） その流動的要素を洗い出す（可変性の分析） 流動的要素を見ながら、その概念が持つ責務を果たすための抽象的側面（≒インタフェース）を導く 各流動的要素の実装上の観点から、インタフェースが適切かどうかを見極め、補正する オ
画像をウェブページの作成や資料作成用に編集する際は、「画像をリサイズ」「名前を変更」「フォルダを移動」などの複数の処理を行う必要があります。無料で公開されているソフトウェア「chaiNNer」を使えば、複数の処理内容を数珠つなぎにしてワンクリックで実行できるとのこと。日々の繰り返し作業が楽になりそうだったので、実際に使い方を確かめてみました。 GitHub - chaiNNer-org/chaiNNer https://github.com/chaiNNer-org/chaiNNer まずは、リリースページにアクセスしてchaiNNerのインストーラーをダウンロードします。今回はWindowsで使いたいので、「chaiNNer-0.14.2-x64-windows-setup.exe」をダウンロードしました。ファイルサイズは90.7MBです。 ダウンロードしたインストーラーをダブルクリック
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年代前半に
列挙型、JavaでいうならEnum型、使っていますか。使わないわけにいきませんよね。 でも、Enumを使っていたせいで辛い目にあったことありませんか。ないですか。それならきっともうすぐに辛い目にあうと思います。 Enumはすべてのプログラマに等しく辛みを与えてくれるからです。そんな辛みについて、ちょっと一緒に直視してみましょう。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の6日目です。 アプリケーションプログラミング上の辛み 1. 既存のif文が偶発的に意図しない方に倒れる 2. switch文に至っては「どちらでもない」で処理不発に アプリケーションプログラミング上の対策 1. 分岐条件をEnumに持たせる 2. swi
Java 20, 21, オブジェクト指向からデータ指向へ / Java20, 21, Object Oriented to Data Oriented
2023/5/10(水)に開催されたTechFeed Experts Night#18での登壇資料です。 https://techfeed.io/events/techfeed-experts-night-18
主旨 以前はシステムの状態をオブジェクト指向でカプセル化し、オブジェクト同士の通信でシステムの制御をしようとしていた しかし、Webアプリケーションのように状態をメモリ上に保持し続けるのが難しい環境が増えると、上記のことがやりにくくなった（ORMのインピーダンスミスマッチの影響が大きくなった） 現在では、システム全体の状態を管理するためにオブジェクト指向を用いるシーンは減っているが、要所要所でシステムを抽象化する道具の一つとして用いるシーンはあり、適材適所で使い続ければ良い はじめに 一時期あれだけもてはやされた「オブジェクト指向」ですが、現在では「業務システム開発においてオブジェクト指向で作るとろくなことがない」、とか、いっそ「不要である」、という意見もよく見かけます。 オブジェクト指向、この記事では特に「オブジェクト指向プログラミング」を対象として話をしますが、その利点は以下の３点に集
ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね! (注: ここからはあとがきポエムです) ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。 実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。 あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のす
GraphQL と Prisma から考える次のN年を見据えた技術選定 / Architecture decision for the next N years at StudySapuri
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-the-next-10-years-at-pixta) [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-pract
インスタンスとオブジェクトは混同しがちで区別がようわからんになりがちです。 とりあえず某所で説明したものを再構成します。 ※2022/12/10追記: クラスに対するのはインスタンスになるべき(たとえばクラス変数とインスタンス変数)なので、ちょっと修正するべきですが、このエントリはそのまま残してます。 クラス・インスタンス・オブジェクト クラスをインスタンス化(実体化)したものがオブジェクト(物)です。 実際に在るものはクラスとオブジェクトで、インスタンスはそれらの関係です。colorsやsportsが並んでるツリーが「オブジェクト」で、右のパレットに並んでるTreeが「クラス」、Treeからみたときのツリーが「インスタンス」ということになります。 ここでツリーはオブジェクトでもインスタンスでもあります。 このように、同じものをオブジェクトともインスタンスともいうことができるので混同してし
「DIは必ずしも善ではない」| Dependency injection is not a virtue by DHH
DHHの Dependency injection is not a virtue(2013) という記事は有名ですが、ちゃんとした日本語訳が意外とないようなので、書き出してみて思ったことを要約してみた。[1] Rubyのエンジニアの中には、何も考えずに他のモデルのnewを書いてる人の割合が多いという（コードレビュー時のヒアリングによる）体感があり、また8年前の記事なので経験の浅い人は読んだことがない人もいると思う。該当する方は是非読んでほしい。 全部読む時間が無い人は要約へ. 原文と訳文 In languages less open than Ruby, hard-coded class references can make testing tough. If your Java code has Date date = new Date(); buried in its guts,
DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と
![DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/cf7c2977c5538fe370d1ff60a78958464a9e1f3f/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20220125%2F20220125074432.png)
2020/5/13追記 オブジェクト指向と哲学の関係について書いた記事ではないです。せっかくだしQiitaっぽいタイトルつけようと思ったら結果的に釣りっぽくなってしまった 概要 オブジェクト指向とは何か？ということを真面目に調べていくと、オブジェクト指向には二種類ある、という話に突き当たる。sumim氏のQuora回答などを参照。 Smalltalkの設計者アラン・ケイによる、メッセージング重視のオブジェクト指向 C++の設計者ストラウストラップによる、クラス重視のオブジェクト指向 今回はこの前者のオブジェクト指向について、アラン・ケイの書きものを読んで調べた結果をまとめ、コメントを付す。 参考文献は最後にまとめて出す。参照元は「（AOO）」のように略記で示す。 アラン・ケイのオブジェクト指向 OOPは私にとって、メッセージング、状態処理の局所的な保持・保護と隠蔽、そしてあらゆる事象の徹底
オブジェクト指向のハードコア
オブジェクト指向のハードコアは2019年5月25日にゼロベースサロンで行われたイベントです。「オブジェクト指向」というキーワードについて、プログラミング、デザイン、哲学などの分野を横断しつつ知的な議論ができました。記録映像は必見。 ティザー（予告編、8分51秒） 企画意図／招待状 この研究会の企画意図については、私が送った招待状を見ていただくのが早いでしょう： いくつか異なる分野で「オブジェクト指向」がキーワードとして注目されています。昨年からGUIデザインの分野では「オブジェクト指向ユーザーインターフェイス」(OOUI)の議論がホットです。ソフトウェア開発の分野では、数年前からオブジェクト指向の見直しとしての「ドメイン駆動設計」(DDD)が広まっています（※原著である英語版から日本語への翻訳は数年遅れています）。さらには「オブジェクト指向存在論」(OOO)も思想業界でブームになっています
SOLID原則を理解し、JavaScriptで実践するためのガイド - deve.K's Programming Primer - プログラミング初心者のための入門ブログ
ソフトウェア開発者にとって、堅牢でテスト可能で拡張性があり、保守性の高いオブジェクト指向のソフトウェアシステムを設計することは重要です。 そこで登場するのがSOLID原則です。 SOLIDは、ソフトウェア開発中に生じるかもしれない特定の問題を解決するために5つの設計原則が組み合わさったセットです。 この記事では、SOLID設計の原則について詳しく学んでいきます。 具体的には、SOLID原則が何を意味しているのか、各部分がそれぞれ何を表しているのか、また実際のプログラム例を挙げながら現役のプログラマーが説明します。 さらに、JavaScriptを使ってこれらの原則を実装する方法も紹介します。 SOLID設計原則とは？ 単一責任原則 (SRP) Open/Closed原則 リスコフ置換原理 (LSP) インターフェース分離原則 (ISP) 依存関係逆転の原則 最後に SOLID設計原則とは？
思った以上に反響をいただき嬉しく思っています。SNSやコメントで言及していただいている構造化プログラミングとの比較や現代的なOOP開発への適応記事を執筆予定です。記事が完成しましたら自分のSNSで共有いたしますので、もし良ければフォローしてお待ちいただけますと幸いです。（記事を書くのは思考が整理されて良いものですね。） TL;DR データ指向プログラミング(DOP) とは、データとコードを分割してアプリケーションを設計・実装するプログラミングパラダイムのこと。 DOPの実装は、以下の原則に従う。 コードとデータを分離する 汎用的なデータ構造でデータを表現する データをイミュータブルなものとして扱う データスキーマとデータ表現を分離する 個人的にDOPは、バックエンドを宣言的プログラミングっぽく書くための現実的な解だと捉えています。実装の詳細は翔泳社より出版されている「データ指向プログラミン
Unityにおける設計パターン
CA.unity #1 2021/02/19 https://meetup.unity3d.jp/jp/events/1271
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。
現実世界の事象から学ぶSOLID原則
# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向プログラミングを学ぶための推薦図書 - ソフトウェア設計を考える
🏗️ ドメイン駆動設計と依存性逆転の原則
Atomic Architecture
6歳娘「パパ、型による条件分岐はできないの？」 - Qiita
技術的負債は開発者体験を悪化させる - mtx2s’s blog
オブジェクト指向は必要なのか / Is object-oriented needed?
なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
デザインパターン〜とかアーキテクチャ〜〜とか・・・に行く途中の話
【C#】SOLID原則を学ぼう - Annulus Games
DDD くらいできるようになりたいよねって話 - Qiita
プログラミング言語論入門 - riswu’s blog
時代がstaticおじさんに追いついてきた(追記あり) - きしだのHatena
実践 よくないコードに立ち向かう整理術 〜あなたのコードはどんな色？〜
かつて人類は1と0を打ち込んでプログラムを書いていたらしい
脱オブジェクト指向講座(5分LT資料)
オブジェクト指向プログラミングは終わった - Qiita
画像の処理内容を数珠つなぎに設定して複雑な処理を一発実行できる無料ツール「chaiNNer」を使ってみたよレビュー
値オブジェクト（Value Object）は3種類ある - パンダのプログラミングブログ
Enumとてもつらい、でも負けない - エムスリーテックブログ
オブジェクト指向は業務システムで本当に不要なのか？ - Qiita
GoF デザインパターン チートシート - Qiita
インスタンスとオブジェクトの違い - きしだのHatena
「アラン・ケイの」オブジェクト指向とは何だったか？元哲学者のエンジニアがまとめてみた - Qiita
オブジェクト指向の複雑性を軽減する、データ指向プログラミング入門
関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita