が(良くも悪くも)注目頂き、その観測で思ったことのメモです。1年後の自分用です！ もっかい言いたいこと再考のポエムです。 概要 関数型には意図的に触れたくなかった 継承や再利用性への懐疑の共通認識 抽象化戦略開発戦略で補う話 タイトルは釣り 抽象化という言葉のふわっと感 カプセル化が問題 関数型言語には意図的に触れたくなかった ポリモーフィズムのくだりで、関数型のご指摘が多かったのですが、あえて直接は触れたくありませんでした。これは、オブジェクト指向 vs 関数型にしたくなかったからです。(結果、Rust/Goに被弾させました) なぜかと言えば、オブジェクト指向を(結果として)衰退させたのは、あくまでも 開発手法の変化 や設計論の精錬が主軸だと認識しています。 不確実性に適応する上で、継承やカプセル化による状態隠匿という戦略が、良い筋に動かず、オブジェクト指向なりに変化を遂げた結果だと考え
宣言的UI
宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql
大規模システムにおける5つのログ転送パターン
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
こんにちは。 最近、こんなツイートしたのですが、ドメインオブジェクトではなくアプリケーションサービス1などにドメインロジックが書かれてしまうことがあります。 アプリケーションサービスはドメインロジックを配置する場所ではない、それはドメインオブジェクトの役割。アプリケーションサービスは進行役。ここを間違うから簡単にドメインモデル貧血症になってしまうんだと思います。 — かとじゅん (@j5ik2o) August 18, 2019 最近、以下の書籍(以下 増田本)をマジメに読み直しました(笑)。ドメインモデル貧血症2を回避して、ドメインロジックをドメインオブジェクトに凝集させる方法に関して、増田本にいろいろ書いてあったので、そのエッセンスと僕の考察を交えて解説したいと思います3。 詳しい内容は以下の増田本を読んでください！ コード例はScalaですが難しい表現がないので、Scalaが分からな
Photo by charlesdeluvio on UnsplashWhy Should We Care About Design PatternsSimply put, design patterns help us solve problems by creating a reusable solution that we can use as a template for our software. That being said, design patterns aren't algorithms and you can't paste them into the code base. They give you a template of sorts, but if misused some patterns may cause additional complexity an
Laravel大規模開発入門！MVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Laravel大規模開発入門！MVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について ナイル株式会社メディアテクノロジー事業本部の工藤さんにMVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について解説いただきました。 こんにちは、ナイル株式会社メディアテクノロジー事業本部で開発マネージャをしています工藤@ta99toです。 今回は大規模で複雑度の高い開発をMVCフレームワークベースで構築する際に僕が課題と捉えているポイントやその具体的な解決手法について解説させていただきたいと思います。 「MVC以上の責任分離イメージがつかないよ！」 「DDDとかクリーンとかオニオンとかあのへんの設計パターンの導入モチベーションが不明」 「どうやっても最終的には複雑になって追加開発や修正開発が怖い状態になっちゃう」 ↑このような悩みを持った方に対して
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
PHPで学ぶオブジェクト指向プログラミング入門 / Introduction to OOP with PHP
PHP Conference Japan 2021 で発表した「PHPで学ぶオブジェクト指向プログラミング入門」のスライドです。 # URL PHP Conference Japan 2021: https://phpcon.php.gr.jp/2021/ CfP: https://fortee.jp/phpcon-2021/proposal/868cc3d1-114d-4543-a59f-e068b0fb8fa5 YouTube: https://www.youtube.com/c/narusemi HomePage: https://nrslib.com Twitter: https://twitter.com/nrslib
イベントの動画 : https://www.youtube.com/watch?v=2Z1CJhPk-f8 オブジェクト指向プログラミングはクラス設計。 クラス設計はプログラムの分割。 クラス設計の焦点は、ビジネスルールを表現するクラスと、ビジネスアクションを表現するクラス。 クラス設計やパッケージ設計の実証済の形を覚えると、出発地点の設計が楽になる。 リファクタリングを積み重ねて設計を改善していく。
（修正）機械学習デザインパターン（ML Design Patterns）の解説
鷲崎弘宜, "機械学習デザインパターン（ML Design Patterns）の解説", スマートエスイー ＆ JST未来社会 eAIセミナー: 機械学習デザインパターン, 2021年3月30日Read less
契約による設計事始め
Object-Oriented Conferenceの発表資料です。 https://fortee.jp/object-oriented-conference-2020/proposal/1224f293-8624-4448-866f-5d1b991d377f カンファレンスの感想はこちら。 https://dnskimox.hateblo.jp/entry/2020/02/22/104342
Patterns.dev
Improve how you architect webappsPatterns.dev is a free online resource on design, rendering, and performance patterns for building powerful web apps with vanilla JavaScript or modern frameworks.
DIP(依存性逆転の原則)を守っていない話
一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか？」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat
SES 企業のソフトウェアエンジニア -> ソシャゲ会社のテックリード兼スクラムマスター -> 日系 SIer の社内アジャイルコミュニティオーナー 発言や記載した内容は個人のものであり、所属団体とは関係ございません
話したネタ デザインパターンとは？ ソフトウェアパターン 書籍: オブジェクト指向における再利用のためのデザインパターン Gang of Four 進研ゼミみたいなもの Composite パターン デザインパターン以外のソフトウェアパターンとは？ アーキテクチャパターン、アンチパターン、コンカレンシーパターン AWSクラウドデザインパターン パターンにはフォーマットがある GoFのデザインパターンはいつ頃生まれたもの？ GoFのデザインパターン登場時に、ソフトウェア業界では何が起きていたのか？ Ruby 20 周年記念パーティーレポート ―― プログラミング初心者の運営スタッフが見た Ruby コミュニティ C、C++、Perl、Smalltalk、Visual Basic の時代 デザインパターンには、どういうカテゴリがある？ 生成・構造・振る舞い Javaのクラスライブラリにおけるデ
社内勉強会でOOPとCleanArchitectureとDDDを勉強し始めたというお話
BASE, Inc. で社内勉強会を開くときに考えた、僕らの学習アプローチと勉強会設計について話しました。
オブジェクト指向プログラミングとドメイン駆動設計を学ぶのに適切な書籍とおすすめの読む順番 - Qiita
オブジェクト指向プログラミングが学べる書籍たち もし私が今から最初から学ぶならこの順番でこの本読むだろうという紹介です。 新人プログラマの方々は右も左も分からないというところからスタートとなるため、オブジェクト指向プログラミングを学ぶときに何から学べば良いか全くわからないという状況かと思います。 オブジェクト指向プログラミングを学んでいると自然と出会うドメイン駆動設計についても同様です。 そうした方々が書籍から学ぼうとした場合に、少しでも効率良く進められる順番を示してあげられれば良いなと思って紹介します。ただし、各書籍についての詳細な説明は書いていません（というか結構忘れててかけない）…。 なお、前提言語はJavaで言語構文にも十分詳しいことが大前提です。 以降、オブジェクト指向プログラミングはOOPと略します。 現場で役立つシステム設計の原則 OOPらしさの雰囲気がわかります 入り口に最
アンドキュメンテッド ちょうぜつソフトウェア 設計入門 「オブジェクト指向に定義はない」のか？
PHPerKaigi 2023 前夜祭の資料です
モダン PHP テクニック 12 選 ―PsalmとPHP 8.1で今はこんなこともできる！―
2021/12/21 PHPerKaigi petit - PHP8.1リリース祝賀会 でのトーク「モダンPHPテクニック 12選 ―PsalmとPHP 8.1で今はこんなこともできる！―」のスライドです。発表時点からごくわずかに加筆修正した部分があります。 https://phperkaigi.connpass.com/event/233022/Read less
オブジェクト指向カンファレンス2020での登壇資料です。 https://fortee.jp/object-oriented-conference-2020/proposal/b2dcff77-08af-4561-bcda-fc86e553ccec
Laravel を使った開発でも、ドメインロジックと RDBMS などの永続化層へのアクセスを分離するためにリポジトリパターンを採用するケースが増えてきました。 ただ、Laravel には Eloquent という Active Record タイプの ORM があるので、これとリポジトリをどのように組み合わせるかで悩んでいる人が多いようで、これまで開発現場や勉強会などで質問を受けることがありました。 本エントリでは、リポジトリを実装してきた経験を元に、私が考える実装のポイントをご紹介します。 1. ドメインデータの入出力にリポジトリパターンを使う 2. メソッドの型宣言にドメインデータを指定する 3. 機械的に CRUD メソッドを実装しない 4. Eloquent を利用したリポジトリクラスの実装 5. 複数テーブルを扱うリポジトリ 6. Paginator との連携 さいごに 1.
アーキテクチャ大全 - kawasima
お気に入り / ページネーション / 検討リスト / カテゴリ毎の件数表示 / Conversation threading / オートログイン / 途中保存 / 予約 / 未読管理 / アンケート
きしださんの以下のツイート オブジェクト指向はこの20年だれも再定義せずみんな自分の思うオブジェクト指向を暗黙に仮定して適当に話してるだけなので、技術的な共通認識のもとの議論はほとんどできないんですよ。という話を「オブジェクト指向をきちんと使いたいあなたへ」の記事に書いたのだけど、そろそろ公開するか— きしだൠ(K8S(Kishidades)) (@kis) July 29, 2019 を読んで、そういえば、私が思うオブジェクト指向の定義、についてツイッター以外ではあまり語ったことがなかったなと思い返し、ちょっと記事にしてみることにしました。まず、結論からいうと、私はオブジェクト指向プログラミングとは サブタイピングを活用したプログラミング手法の総称 と考えています。ここで、クラス継承とかインタフェース継承とかダックタイピングとかではなく、単にサブタイピングであるのがポイントです。なお、型
1995年まで：イノベータとアーリーアダプターの時代； 1995-2005 ： オブジェクト指向ブームと混乱の始まり； 2005-2015 ： さらなる混乱と収束の兆し； 2015- ; 現在の状況とこれからの２０年Read less
なぜ昨今のJavaScriptではイミュータブルであるべきと言えるのか歴史的背景を踏まえて言語化する - Qiita
先日JavaScriptに慣れていない人のコードをレビューする機会があり、constで宣言されたオブジェクト内部に副作用を与えている記述がありました。 その時に「今の動作に問題ないけど、今風のJSならイミュータブルの方が良いかも」と指摘したものの、JSに疎い人からすれば背景が分からないはずで、理由を自分なりに説明したものの案外言語化が難しかったことがありました。 難しい理由として、イミュータブルであることは実利面と同時に、Facebook発祥のトレンドという側面も多分に含んでおり、JavaScript自体の潮流も踏まえておく必要があるからです。 今回は実利面に加えてトレンド面も交えて、なぜイミュータブル性がJavaScriptで重宝されるのかを見ていきましょう。 フロントエンドの世界では状態を持ち、時間やインタラクションと共に変化するから サーバーサイドの世界から見た場合、HTTPはステー
前回記事で、一般的な業務システムの開発において、DDD（ドメイン駆動設計）が提唱する「ユビキタス言語」の実践は難しいと説明した。そもそもDDDを含むオブジェクト指向プログラミング(OOP)は、一般的な業務システムの開発には向いていない。とはいえ、企業がOOPで内製することが合理的なものは存在する。企業に売上をもたらす製品（プロダクト）系のソフトウエアだ。典型的な例が「自社サービス」の運用を支える「サービス支援システム」である。これと業務システムとの関係を見よう。 自社サービスと業務システムの関係 自社サービス、つまり、WEB上で提供される有償サービスで稼いでいる企業があるとして、そのシステム構成はどのような形になるだろう。まずは、企業システム全体の一般形について確認しておこう（図１上 参考記事）。 図１．企業システムの一般形とサービス支援システムの位置づけ この中のａがいわゆる業務システム
商品リンクはこちら https://little-hands.booth.pm/items/1835632 DDDはドメインモデリングを通じてソフトウェアの価値を高めようとする設計・開発手法です。 新しく得られたモデルに関する知見を頻繁にコードに落とし込む必要があるのですが、 それはソフトウェアにとっては非常に高い要求をしていることになります。 そこでDDDでは、オブジェクト指向の手法を利用して、メンテナブルで、拡張性の高いコードを書くことを目指しています。 このセッションでは、DDDではモデリング結果をどのようにコードに落とし、どのような利益を得られるのかを、具体的なコードを交えながら解説します。Read less
オブジェクト指向設計実践ガイドを読んだので基本部分をPythonでも書いてみた - サーバーワークスエンジニアブログ
オブジェクト指向設計実践ガイド is https://www.amazon.co.jp/dp/477418361X その名の通りオブジェクト指向の原則に沿った設計を実践しながら学ぶという内容です。 私は今年の3月からCloud Automatorを開発するサービス開発課に配属になりましたが、これまでのプログラミング経験が乏しいこともあり、 オブジェクト指向というものがいまいち掴みきれませんでした。 そこで夏頃からこの書籍を読み始めたのですが、これまで頭の中でぼんやりしていた概念が丁寧に論理立てて整理できた感覚があり、とても勉強になりました。 オススメの書籍ですので、今回はこの書籍の基礎部分をPythonでご紹介したいと思います。 なぜPython? 私自身、普段の業務では主にRubyを利用していますが、 社内の他部署ではPythonが主に使われていて、新人研修で初めて学んだプログラミング言
1. はじめに JavaScriptデザインパターンは、JavaScriptを使ってプログラムを書くときによく出くわす問題を解決するためのガイドです。これらのパターンの背後にある考え方を理解することで、自分の問題に適用することができます。また、これらのパターンが自分のコードに役立つ場合を見つけることもできます。 2. モジュールパターン モジュールパターンは、JavaScriptのモジュールシステムの一部で、データを保護する方法を提供します。これは、モジュール内のプライベートなデータと動作を保護し、一方で公開APIを提供する方法です。これにより、プライベートとパブリックのアクセスレベルを持つ自己完結型のモジュールオブジェクトを作成することができます。 これは、JavaやC++のような言語でクラスにアクセス修飾子を使用するのに似ています。 JavaScriptでは、クロージャを使用してモジュ
2023年 研究開発部 新卒技術研修 ~ 実践編 ~ - Sansan Tech Blog
こんにちは、研究開発部 Architectグループの藤岡です。 4/26（水）〜 4/28（金）で研究開発部内の技術研修を行ったので、その内容を公開します。 目次 目次 研修の目的 研修の概要 実践編の概要 アプリケーションを作成 バッチを作成 gokartとは パイプラインを実装 APIを作成 FastAPI とは APIを実装 ディレクトリ構成 実行 Webアプリを作成 Streamlitとは Webアプリを実装 Docker化 デプロイ ECRにイメージをプッシュ アプリケーション基盤 Circuitについて アプリのマニフェストを作成 研修終了後 終わりに 研修の目的 この研修の主な目的は、新卒社員がスムーズに業務に入れるようにすることです。 研究開発部にはさまざまなバックグラウンドを持つ研究員が入社するため、チーム開発の経験がない方もいます。 そのため、Gitの操作やプルリクエス
デザインパターンを出自から深く理解する / understanding design pattern from the origin
PHPカンファレンス沖縄 2019 前夜祭 で発表したデザインパターンの出自から特性を理解しようという内容です
マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ
インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF（Backend For Frontend）導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。 BFF とは？ BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API
オブジェクト指向プログラミング入門
きしだൠ(K1S) @kis オブジェクト指向について、技術的には「オブジェクト指向は差分プログラミングとデータ分類をまぜて考えてややこしくなる。分離せよ。そして差分プログラミングにはラムダを使え。データ分類のときはオブジェクト指向じゃなく型を考えろ」っていう主張になった。 2022-02-28 12:22:33 きしだൠ(K1S) @kis 「オブジェクト指向は差分プログラミングとデータ分類を同時に行う手法」という見方。 もっといえば、継承の用途を差分プログラミングとデータ分類の2種類にわけた。その上でそれぞれについてのオブジェクト指向離れを考えた。 2022-02-28 12:25:12 きしだൠ(K1S) @kis ここから考えると、オブジェクト指向の技術的欠点は差分プログラミングとデータ分類を不可分に考えてしまったところか。 継承を使うと差分プログラミングとデータ分類が同時にできて
デザインパターンの使い方を パタン・ランゲージとの比較から考える / design-pattern-usage-inspired-by-pattern-language
Object Oriented Conference 2020 にて発表した内容です。
はじめに Java の enum は大変便利で非常多くのシーンで活用されています。例えば区分を表すようなオブジェクトを表現したい際にもよく使われていますね。 Java 14 で正式機能となった switch式にて網羅性検査が行えるようになり、それまで以前ではどうしても抽象メソッド等を活用する必要があった処理についても、switch式を利用する事で簡潔に表現することができるようになりました。 また、Java 17 で正式機能となった sealed classes/interfaces と Java 21 で正式機能になった Record Patterns によって、これまで必要だった区分値のような enum を必ずしも定義しなくて良い場合も出てきました。 この記事では、今まで enum を使っていたコードがこれらの機能によってどのように変わるのかを紹介し、盲目的に enum を定義するのでは
Rustでの 抽象化 3パターンについて
※この記事は全然入門記事ではないです。Javaなどのオブジェクト指向言語とRustをある程度理解している前提での記事です。あと、メモ程度に雑に書いています。 今回は抽象化がテーマです。オブジェクト指向の多態相当のことをRustでどうのように解決すればいいのでしょうか。個々の実装型の都合によらず、呼び出し側は統一的なインターフェイスで操作するケースはRustでもあるはずです。 オブジェクト指向言語の設計に慣れていると、Rustで設計するときにどうしたらいいかわからないことがあります。なぜならRustには継承がないからです…。まぁJavaと比べるとだいぶ違うので頭を切り替える必要があります。今回はそういう感じの記事です。 では、早速デザインパターンを題材にして考えてみましょう。 抽象化について 簡単なコマンドパターンから考えます。 ここでは単純に渡した文字列を標準出力するコマンドを考えます。以
CQRSはなぜEvent Sourcingになってしまうのか、まとめてみたいと思います。 なぜまとめるか、それはCQRSにとってEvent Sourcingはオプションだと誤解されている方が多いからです。この記事を書いてる本人も最初はそう思っていましたが、実際に開発・運用を経験してみるとCQRSにとってEvent Sourcingはほぼ必須で、認識を改めるべきだと気づきました。なので、原義に基づいたうえで、Event SourcingではないCQRSがなぜよくない設計になるのか解説します。 その前に松岡さんの記事について。 CQRSの領域ではモデルを完全に分ける 松岡さんの記事には”CQRSはモデルを完全に分ける必要はない”と書かれていますが、知識がないと誤解しがちですが文字のまま意味を取るといけません。こちらの言及は、システムのうち、モデルをC/Qに分割するCQRS領域とモデルを分割しな
オブジェクト指向歴25年のオブジェクト指向おじさんが語るオブジェクト指向設計の処方箋 - Qiita
この記事のターゲット この記事は以下の人々を対象としています。 オブジェクト指向を一通りわかっている人。 オブジェクト指向の設計力を高めたい人。 オブジェクト指向を使っているのに、設計が綺麗にならず悩んでいる人。 プログラムが大きくなるとオブジェクト指向設計が破綻する人。 オブジェクト指向に限界を感じている人。 共同開発メンバーの設計力に差があって困っている人。 以下の人は対象外です。 オブジェクト指向が何なのかわからない人。 オブジェクト指向を極めている人。 関数型など別のパラダイムに活路を既に見いだしている人。 オブジェクトは責任ベースで考える オブジェクト指向といえば、やれインターフェイスだメッセージだ隠蔽だカプセル化だ、みたいな用語がたくさん出て来て、どれも関連があるようでないようで意味が分からないですよね。気取ったこと言ってんじゃねぇよと。 日本で社会人経験があれば、こんなものは
The Amazon Builders' Library
Amazon is an Equal Opportunity Employer: Minority / Women / Disability / Veteran / Gender Identity / Sexual Orientation / Age.
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向プログラミングは終わった カプセル化が悪い(感想戦) - Qiita
ドメインロジックはドメインオブジェクトに凝集させる - Qiita
7 Must Know Software Design Patterns
ちょうぜつのカレンダー | Advent Calendar 2019 - Qiita
クラス設計本格入門 JJUGナイトセミナー 2021-6-16
if しか知らないあなたのためのポリモーフィズム入門
48. GoFデザインパターンとDI (前編) w/ twada | fukabori.fm
クソコード動画「switch文」解説
Laravel におけるリポジトリ実装のポイント - Shin x Blog
私なりのオブジェクト指向プログラミングの定義 - kmizuの日記
オブジェクト指向プログラミングの現在・過去・未来
自社サービスはOOP、業務システムはDOAで作ろう - 設計者の発言
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
JavaScriptデザインパターン入門 - Qiita
流行りのBFFアーキテクチャとは？｜Offers Tech Blog
Java の enum を使いこなせるあなたに sealed interface
CQRSはなぜEvent Sourcingになってしまうのか - かとじゅんの技術日誌
mei1.ht.gob.jp
w.atwiki.jp
note.com/kuranuki
www.asahi.com
ufit.co.jp
x.com