デザインパターン カテゴリーの記事一覧 - 銀行員からのRailsエンジニア
銀行員からのRailsエンジニア 銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。
銀行員からのRailsエンジニア 銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。
デザインパターンはJavaなどのオブジェクト指向言語で使われる設計パターンのことです。特に有名なGoFのパターンでは、数々のエンジニアが工夫を重ねてきた設計が23種類にパターン分けされまとめられています。
コンテナを使ったシステムのアーキテクチャパターンが掲載されている、分散システムデザインパターンという良書に出会ったので、Kubernetesの勉強を兼ねて各デザインパターンを実装してみましたので、ご紹介です。 この本は執筆者の論文が元になっており、そちらの翻訳記事もあるので、一読することをおすすめします。 Qiita | コンテナ・デザイン・パターンの論文要約 本記事で扱うデザインパターンとその例 分散システムデザインパターン中では、大別して2種のデザインパターンが紹介されています。 1台のノード上で複数のコンテナが動作するシングルノードパターン 複数のノード上で実現されるマルチノードパターン 本記事では、シングルノードパターンから以下のデザインパターンとその例を、Kubernetesでの実装例とともに解説します。 サイドカーパターン ex1. git-sync ex2. topz アンバ
Why solve a problem twice? Design patterns let you apply existing solutions to your code - Stack Overflow
The most satisfying problems in software engineering are those that no one has solved before. Cracking a unique problem is something that you can use in job interviews and talk about in conferences. But the reality is that the majority of challenges you face will have already been solved. You can use those solutions to better your own software. Software design patterns are typical solutions for th
オブジェクト指向設計とデザインパターンの基礎 / Basics of object oriented design and design pattern
2017/07/04 新卒エンジニア向け座学の資料
デザインパターン・カタログ
生成関連パターン これらのデザインパターンは、 柔軟性を増しコードの再利用を促すようなオブジェクト生成の仕組みを提供します。
I was recently asked by a developer friend of mine what design patterns I use in my job. The question threw me off a bit because I didn't actually know the answer, even though I know that there are definitely patterns that I've used. Do those patterns have names? And why are the patterns I have been using better than others? For today's post, I will be writing down my notes and thoughts as I learn
trait は当初 2008 年に PHP の言語開発者コミュニティへ提案され、長い議論期間を経て 2012 年リリースの PHP 5.4 で導入された機能です。 それから 10 年がたち、trait は「ちょっと試しに使ってみよう」というものから、各開発現場において使われる中で少しずつその立場を変えてきました。 さて、実際どのように変わったのでしょうか？ 先日、今年に出る PHP 8.2 へ向けて言語機能追加の RFC を提出しました。PHP の trait で定数を定義できるようにするというものです。 静かな議論期間を経ての RFC の投票開始後、PHP の開発者向けメーリングリストから最初に得られたのは驚くべきリアクションで、要約すると次のようになります。 「trait は言語にとってまったく不要なものであり、使われるべきでないものを改善すべきではない」 続々と RFC に No の
When I was at SoundCloud, being transparent about our architecture evolution was part of our technology strategy. Something we’ve talked about on countless occasions but never really described in detail was our application of the Back-end for Front-end architecture pattern, or BFF. This post documents my understanding of how we developed and applied this technique. My understanding of the evolutio
【DDD】ドメイン駆動開発のメリットと始め方 codezineを読んでみる - See the Elephant
【DDD】ドメイン駆動開発のメリットと始め方 codezineを読んでみる codezine.jp 2ページまでよんだ。DDDってなんのために使うんだっけー？という話 DDDにおける2つの設計 戦略的設計と戦術的設計 whatとhowみたいな感じだな 戦略的: 何を設計し実装するのか 戦術的: どのように設計し実装するのか 「戦略的設計」を実施せず、エンジニアが取り組みやすい「戦術的設計」にだけ注力すると、「軽量DDD」と呼ばれる事業価値を発揮できない貧弱なDDDになってしまう 気をつけよ。ちゃんと要件を確認してモデリングしてからやりましょってことね DDDの概略 DDDは「高品質」のソフトウェアを設計する手法です。ここでの高品質はバグのないという意味ではなく、ビジネス的にも成功していることを指します 顧客と開発者が共通言語(ユビキタス言語)で会話して、一体感あるチームとして、事業価値の高
DI とは何か DI を利用するメリット・デメリット Autofacを利用した例 Autofacのさらなる機能 その他 DI とは何か Wikipediaでは以下のように説明されている。 コンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである。 言い換えると あるコンポーネントAが利用している別のコンポーネントBを外部から注入することにより、コンポーネントAがコンポーネントBの実装との依存関係を排除するデザインパターン。 となる。 例 まずは DIを使わない場合 ///<summary>メインプログラム</summary> class Program{ public void Main(){ var client = new FooClient(); client.Execute(); } } ///<summ
You must know the power of Object-oriented programming if you have ever worked with object-oriented languages like Java, C#, and much more. Python also supports object-oriented programming, and we can define a class in Python. Let’s explore more about how to achieve this in Python. In the post Getting Started with Python, I have covered the essentials required before becoming a data scientist. In
先日某所で「最近プログラミングを始めた入門者（だったかな？）に勧められるオブジェクト指向の本を教えてほしい」みたいな質問をいただいたのですが（うろ覚えなのでちょっと違っているかも）、その場で即答できず考え込んでしまいました。ですが、遅ればせながら選書してみたので、その内容をここに書いておきます。 とはいえ、改めて考えてみても、2023年に入門者向けのオブジェクト指向の本を探すのはなかなか難しいですよね…。もちろんオブジェクト指向じゃなければ簡単かと言われるとそういう訳でもないですが。とりわけオブジェクト指向に関する書籍の場合、海外のよく知られている書籍は少し前に翻訳されたものが多くて、最近はこれというのがなかなか思いつきません。また日本でも良書がばんばん出てるわけでもなさそうです。 この辺りは、オブジェクト指向に関する技術はもはや当たり前のものとなってしまっていて、今さら旬のトピックでもな
Modern MVVM iOS App Architecture with Combine and SwiftUI
The iOS Developer Community Survey shows that Model-View-ViewModel (MVVM) is the second most popular architectural pattern for designing iOS apps. It makes a good reason to study the state of modern MVVM with SwiftUI and Combine. In this article we’ll cover: The purpose of MVVM. The components of the MVVM pattern. The flow of data and dependencies in MVVM. Why should we use unidirectional data flo
【TS】今さら聞けないストラテジパターン
はじめに 今回はストラテジパターン(Strategy Pattern)について解説します。 ポリモフィズム(多態性)を利用して、種別ごとに異なる挙動をさせたい時に便利なデザインパターンです。 ストラテジパターンとは？ 有名どころでTECHSCOREさんの解説があります。 参考：TECHSCORE | 10. Strategy パターン 以下、引用です。 普通にプログラミングしていると、メソッドの中に溶け込んだ形でアルゴリズムを実装してしまうことがよくあります。if 文などで分岐させることでアルゴリズムを変更するような方法です。Strategy パターンでは、戦略の部分を意識して別クラスとして作成するようにしています。戦略x部分を別クラスとして作成しておき、戦略を変更したい場合には、利用する戦略クラスを変更するという方法で対応します。Strategy パターンを利用することで、メソッドの中に
ICONIX を使ったオブジェクトモデリング
OOC = Object-Oriented Conference でお世話になった hiro さん(@hirodragon112)の、#astah セミナーシリーズに参加してきました。 hiroさん（イメージ） ICONIX プロセス 最近アジャイルばかりの話題を書いていて、ソフトウェアデザインの話題は久しぶりです。当日のスライドはこちら。 hiro さんはゆっくり「オブジェクト指向」という言葉の意味や捉え方かたはじめ、 「外部知識が捕捉される」モデルの重要性 を前半で、後半でユースケース分析、ロバストネス分析、を通じてドメインモデルが洗練されていく様子を解説していただきました。(Akaponさんのマインドマップによるレポート) 【メモ】ICONIXプロセスから学ぶオブジェクト指向モデリング ドメインモデルの構築（ドメインモデルが、ユースケースモデリング、ロバストネス分析を通して、どんどん
Design Patterns in Swift
Lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code.
この記事は Mobility Technologies Advent Calendar 2021 の17日目です。 タクシーアプリ「GO」の iOS アプリを開発している今入です。日々複雑化するアプリをどのように設計して開発しているかについて紹介します。 はじめにタクシーアプリ「GO」の iOS アプリでは RIBs アーキテクチャを採用しています。RIBs アーキテクチャは「RIB」と呼ばれるコンポーネントを組み合わせることで、木構造で iOS アプリを構築させることができます。「RIB」同士の依存関係をどのように組み立てていくかがアプリの設計の肝となります。 タクシーアプリ「GO」および「JapanTaxi」アプリに RIBs アーキテクチャを採用し 3 年が経ちました。様々な機能開発を通し RIBs アーキテクチャにおける iOS アプリの設計を行ってきました。振り返ってみるとその設
オブジェクト指向 導入 / OOP1
勉強会での登壇用資料です。 オブジェクト指向についての解説の導入です。 オブジェクト指向とは何であるのかについて定義していきます。 https://nrslib.com
2023年度リクルート エンジニアコース新人研修の講義資料です
デザインパターンを Python で
複雑なオブジェクトを段階的に構築できます。 このパターンを使用すると、 同じ構築コードを使用して異なる型と表現のオブジェクトを生成することが可能です。
特定のフロント エンド アプリケーションやインターフェイスによって使用される個別のバックエンド サービスを作成します。 このパターンは、複数のインターフェイスのために 1 つのバックエンドをカスタマイズすることが非効率な場合に役立ちます。 このパターンは、Sam Newman が初めて説明しました。 コンテキストと問題 アプリケーションは、当初デスクトップの Web UI 用に導入される場合があります。 通常、バックエンド サービスは、その UI に必要な機能を提供するために、並行して開発されます。 アプリケーションのユーザー ベースが増えてくると、同じバックエンドとやりとりする、モバイル アプリケーションが開発されます。 その結果、バックエンド サービスは、デスクトップとモバイルの両方のインターフェイスの要件に対応する、汎用的なバックエンドになります。 しかし、モバイル デバイスの機能は
Rustのイディオム - Qiita
この記事について Rust Design Patternsで紹介されているRustでのプログラミングにおけるイディオムをまとめました。 format!マクロを使用したstringの結合 所有権の制約によりRustでのstringの結合はとてもめんどくさいです。 let mut result = "Hello".to_owned(); let mut name = "World".to_owned(); result.push_str(name); result.push('!');
Repository Pattern
It’s time to make good on our promise to use the dependency inversion principle as a way of decoupling our core logic from infrastructural concerns. We’ll introduce the Repository pattern, a simplifying abstraction over data storage, allowing us to decouple our model layer from the data layer. We’ll present a concrete example of how this simplifying abstraction makes our system more testable by hi
iOS Interview Questions and Answers for Senior Developers Part 1 - Swift
iOS Interview Questions and Answers for Senior Developers Part 1 - Swift I recently got into the position of leading the technical interview when my client was searching for a new senior iOS developer. It's a challenging task to evaluate the skills and knowledge of another developer. So in this post, I want to share my results of the most useful iOS and Swift questions and answers with you. I cate
SE Radio 393: Jay Kreps on Enterprise Integration Architecture with a Kafka Event Log – Software Engineering Radio
SE Radio 393: Jay Kreps on Enterprise Integration Architecture with a Kafka Event Log Jay Kreps, CEO of Confluent discusses an enterprise integration architecture organized around an event log. Robert Blumen spoke with Jay about the N-squared problem of data integration; how LinkedIn tried and failed to solve the integration problem; the nature of events; the enterprise event schema; schema defin
AにBを持たせる class A { private B b; // 実装 } AをラップしてBと共通のインタフェースを実装する interface IB { // Bのメソッド } class AWrapper implements IB { private A a; // 実装 } class B implements IB { // 実装 }
デザインパターンを Go で
複雑なオブジェクトを段階的に構築できます。 このパターンを使用すると、 同じ構築コードを使用して異なる型と表現のオブジェクトを生成することが可能です。
チームメンバーみんなで協働してハイレベルの設計をすることができるテクニックがあります。CRCカードを使った設計モデリング。UMLモデリング推進協議会(UMTP)主催のセミナーで開かれたCRCカードのワークショップで学んできました。講師はオブジェクトの広場の編集員でもある藤井拓です。本記事では、セミナーで行われたワークショップの様子をお伝えしつつ、CRCカードを使った設計の概要を紹介します。 UMTPのCRCカードワークショップ 2018年2月に、UMLモデリング推進協議会(UMTP)主催の技術セミナーがありました。今回は「CRCカード ワークショップ～賢いクラスとそれらのコラボレーションをモデリングしよう」という内容で、オブジェクトの広場の編集員でもある藤井拓が講師をしました。 ワークで配られたもの：CRCカードの進め方と、ユースケース、講義スライドを印刷したもの。 CRCカードは、198
Send feedback Common design patterns Stay organized with collections Save and categorize content based on your preferences. Empty Responses The standard Delete method should return google.protobuf.Empty, unless it is performing a "soft" delete, in which case the method should return the resource with its state updated to indicate the deletion in progress. For custom methods, they should have their
今回の話 「Visitorパターン」を使ってswitch文やif文での型分岐を置き換えてみよう、という話です。C#で書いてます。 （サンプルコードはだいぶ端折ってるのであまり突っつかないで下さい） switchやif文のどこが良くないのか 「型の判定によって処理を分岐する」という実装をswitchやifで作ってしまうと、後から構造を変更した際などに問題が起きる可能性があります。 （そもそもオープンクローズド原則違反になってしまう） たとえば「型をみてデータ構造を変換する」といった場合はこの問題を踏みやすいです。 例：データ構造を1:1変換する 「RPGのキャラクター（ジョブ）」という概念があったとしましょう。 これは基底クラスであり、派生先にいくつかのジョブがあってそれぞれで独自のパラメータを保持しています。 /// キャラクターの抽象クラス public abstract class C
本題に入る前に、値オブジェクトの表明を使って検証を実装する方法に、必要な検証(バリデーション)と表明(アサーション)の違いについて以下にまとめる。 検証(バリデーション) 以下のブログ記事によると、3種類のバリデーションがあるようです バリデーションには3種類のバリデーションがある 〜 セキュアなアプリケーションの構造 〜 が、日常的にはこのあたりは区別せずに「入力値の確認」と認識していると思います。厳密に表現すると「入力値が要件を満たしているか妥当性を確認すること」になります。Error, Defect, Fault, Failureの定義と解釈のエラー(Error)のカテゴリ。 以下は、バリデーションロジックの一例。値が満たすべき要件を確認するロジックを記述しますが、場合によっては複数の検証を組み合わせて一つの検証を行うことがあります。 object Validators { type
はじめに 本記事では、初学者向けにオブジェクト指向について簡単に解説します。 細かい文法部分については省略していますが、イメージを掴んでもらえたら嬉しいです。 また、本記事ではGoFのデザインパターンについても簡単に紹介します。 今回は、Singleton、Factory、Strategy、Observer、Adaptorパターンについて取り上げます。 初学者の方は、今回紹介するデザインパターンをなんとなくでも理解できたらバッチリです。 前提知識 デザインパターンを学ぶにあたって、オブジェクト指向についての理解は必須になります。 ここでは前提知識として、クラスとインスタンスの関係、オブジェクト指向の3大要素について簡単に解説をしておきます。 不要な方はそもそもデザインパターンとは？から読み進めてください。 クラス と インスタンス クラス クラスのイメージは"設計図"です。 例として、家を
多くの企業が今、DXに取り組んでいる。その際に課題になるのが、レガシーアプリケーションのモダナイズだ。だが、巨大であればあるほど、立ちはだかる壁が多数あり、なかなか手をつけられず悩んでいる企業も多い。そんな企業に対して、レッドハットは、段階的にモダナイズへ移行することを提案。どんなテクノロジーやデザインパターンを使って、段階的移行を行っていくのか。レッドハットのソリューションアーキテクトである森和哉氏が解説した。 レッドハット株式会社 テクニカルセールス本部 ミドルウェアソリューションアーキテクト部／ソリューションアーキテクト 森 和哉氏 段階的移行に必要なテクノロジーとデザインパターン 「今、アプリケーションモダナイズへの関心は非常に高まっている」 こう語り、森氏のセッションは始まった。アプリモダナイズへの関心が高まっている背景には、「データ量や利用者の増加に対応したい」「大幅に増えた保
はじめに 自分が書いてないコードで色々辛い思いをしてきたので、どういう場合に継承が破綻するのか調べてみました。 この記事でわかるであろうこと * 継承を（破綻しないように）ちゃんと用いるにはリスコフの置換原則と契約による設計の理解が必要なこと リスコフの置換原則とは リスコフの置換原則とは、一言でいうと「派生型（サブクラス）はその基底型（スーパークラス）と置換可能でなければならない」という原則です。 ＊ リスコフの置換原則を守らないと必然的に開放/閉鎖原則に違反するため、リスコフの置換原則を守ることは重要です。 下記のコードはSquare（正方形）がRectangle（長方形）を継承しています。つまり、派生型がSquare、基底型がRectangleです。 正方形は長方形を特化したもの（見た感じではis-a関係が成立している）と言えるので継承を使うことは一見正しそうに見えます。 「派生型は
90年代のオブジェクト指向開発諸手法
2021/11/24の『オブジェクト指向LT会 vol.3』というイベントで発表したスライドです。
The VIPER architectural pattern is an alternative to MVC or MVVM. And while the SwiftUI and Combine frameworks create a powerful combination that makes quick work of building complex UIs and moving data around an app, they also come with their own challenges and opinions about architecture. It’s a common belief that all of the app logic should now go into a SwiftUI view, but that’s not the case. V
Design Patterns
Design patterns are typical solutions to common problems in software design. Each pattern is like a blueprint that you can customize to solve a particular design problem in your code.
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Javaデザインパターン全23種の特長をスッキリ解説 | 侍エンジニアブログ
Kubernetesで学ぶ分散システムデザインパターン - Qiita
Design Patterns In JavaScript
導入から 10 年、PHP の trait は滅びるべきなのか ーーその適切な使いどころと弱点、将来について
The Back-end for Front-end Pattern (BFF)
DI(Dependency Injection) の解説 - Qiita
Object-oriented Programming in Python
西暦2023年、オブジェクト指向に興味を持った入門者にお勧めする日本語書籍を考える
iOS アプリを木構造で組み立てるための 7 つのデザインパターン
実践オブジェクト指向設計
フロント エンド用バックエンドのパターン - Azure Architecture Center
AにBを持たせる class A { private B b; // 実装} AをラップしてBと共通のイン..
レポート：CRCカードでチームが協働して設計する | オブジェクトの広場
Common design patterns | Cloud APIs | Google Cloud
Visitorパターンで型によるswitchやif判定を消す - Qiita
値オブジェクトの表明を使って検証を実装する方法 - Qiita
猿でもわかるオブジェクト指向とデザインパターン - Qiita
レガシーアプリケーションの段階的モダナイズに必要なテクノロジーとデザインパターン【デブサミ2022】
リスコフの置換原則（LSP）と契約による設計（DbC）の関連について - Qiita
Getting Started with the VIPER Architecture Pattern
news.yahoo.co.jp
www.bunkeiplc.com
bookplus.nikkei.com
momouy.livedoor.blog
www.asahi.com
news.yahoo.co.jp