Python滅ぼす協会に入会したい
なぜ令和にもなって動的型付け言語を使うのか シフトレフトという概念が生まれたのは二十年以上も前のはずだ。 それにもかかわらず動かしてみるまで答え合わせもできない言語で開発をするという発想自体がどうかしている。 同じ動的型付けといってもJavaScriptはブラウザという事情があるし、型の表現力に優れたTypeScriptがあるからまだよい。 しかし、Pythonはどうだ。他にいくらでも選択肢があるなかで、サーバーサイドにわざわざ選定する言語ではなかろう。 貧弱な型ヒント、しかも書いたところで大した効用もない。 使っている外部ライブラリにひとつでも型ヒントがクソなものがあれば即座に破綻する。 型というガードレールもシートベルトもなしで糞を撒き散らしながらする開発にはうんざりだ。 シンタックスもキモい 動的型付けもさることながら、シンタックスもキモい。とにかく思考を妨げる語順になっている。 m
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
継承は禁止するべき
キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。 オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。 そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。 また、凡庸なプログラマが継承で実現したい
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
社内LTにて、ドメイン駆動設計と依存性逆転の原則を布教しましたʕ◔ϖ◔ʔ はてなブックマークのコメントもどうぞ！ なお、ドメイン駆動設計を理解するためには、依存についても知る必要があります。 是非、依存関係と依存オブジェクト注入もご参照ください👍🏻
SOLID原則完全に理解した！になるための本
SOLID原則を学び、完全に理解した！になるための本
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。本連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理
今回の記事はオブジェクト指向プログラミングにおける設計の基本、「SOLID原則」について。 ある程度プログラミングの文法を知っていれば、動作するコードを書くことは可能です。しかし、より良いコードを書きたいのであれば、文法の知識だけではなく、設計に関する知識も必要になってきます。 特にUnityでは、適当にコードを書いていくと目も当てられないようなスパゲッティーコードが容易に出来上がります。「とりあえずシングルトンにすりゃいいや！」みたいなノリで「何とかManager」クラスを作りまくった結果、「あれ？この処理どこに書いたんだっけ？」という状況になったこと、誰しも一度はありますよね…？ 今回は、そんなクソk…良くないコードを書かないための設計原則である「SOLID原則」について紹介します。記事内のコードはC#で記述しますが、言語に関わらずSOLID原則は広く応用の効く考え方なので、是非とも覚
当初はちょっとしたSOLID批判のつもりが、「藪を突ついて蛇を出して」しまったのですが、物事はそこから具体的で目に見えるものへと発展しました。仮に、近頃はSOLID原則が役に立たなくなっているのだとしたら、何に置き換えればよいのでしょう？ あらゆるソフトウェアに通用する原則はあるのでしょうか？ そもそも「原則」とは何を意味するのでしょう？ 私は「仕事がたのしくなるソフトウェアならではの特性や性質がある」ということを確信しています。コードでそのような質が高まれば高まるほど、仕事もどんどんたのしくなります。しかし、何事もトレードオフですから、自分の置かれている状況をつねに考慮する必要があります。 そうした特性はたくさん存在しており、互いに重なりや関連がありますし、説明の仕方もさまざまです。ここでは私がコードで気にかけている要素を強く支えていると思える5つを選びました。選ぶ数はこれぐらいが丁度良
マリオで学ぶSOLID原則
はじめに 最近オブジェクト指向とデザインパターンについて学び始めたので、勉強しつつ記事にまとめていきたいと思います。 初回はSOLID原則についてです。SOLID原則はオブジェクト指向プログラミングにおいて、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくするために考えられたルールです。 この記事では、オブジェクト指向プログラミングの重要な開発原則であるSOLID原則について皆さんが想像しやすいマリオのクラス実装を例に解説していきます。 1. S (Single Responsibility)：単一責任の原則 クラスは単一の責任を持つべきと言う原則です。 ここでの責任というのは、オブジェクトが持っている機能のことです。 一つのクラスができる機能（責任）が複数あると、クラス内部の関数が強い結合を起こす可能性が高ま理望ましくありません。 次のマリオクラスを見てみましょう。
TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
React大好き侍が、「もうSolidJSでいいじゃん...//」ってなったワケ。 - Qiita
Reactが好きです。 Reactが好きです。コンポーネントを関数として扱うのが好きです。 SolidJSはReactそっくりの書き心地(DX)を保ちつつ、Reactに足りない要素を兼ね備えた期待の新人です。 コードの比較 React const Counter = () => { const [count, setCount] = useState(0) useEffect(() => { console.log(`Count: ${count}`) }, [count]) return ( <div> <div>{count}</div> <button onClick={() => setCount(prev => prev + 1)}>Add</button> </div> ) } const Counter = () => { const [count, setCount] =
最近、小〜中規模のプログラムを保守性高く記述するにはどうすればよいかが気になっていて、 ソフトウェアのアーキテクチャについて調べていました。 本を読んでみる 以下の本を浅めに読み通してみました。どの本もそれぞれ学ぶべき点があって興味深かったです。 .NETのエンタープライズアプリケーションアーキテクチャ第2版 https://www.amazon.co.jp/dp/B00ZQZ8JNE C#での設計の話。ドメイン駆動設計など、設計に関わるトピックが広く触れられていて良い。 Adaptive Code C#実践開発手法 第2版 https://www.amazon.co.jp/dp/B07DJ2BL4Y C#での実装の話。SOLID原則を中心に、実装に関わるトピックが広く触れられていて良い。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://www.a
この記事は、Merpay Advent Calendar 2022 の21日目の記事です。 こんにちは。メルペイBackendエンジニアのfivestar（@fivestr）です。 本記事では「SOLID原則」と呼ばれる設計原則に沿って実際に行ったリファクタリングについて、メルペイの「あと払い」サービスの開発現場事情を踏まえながらご紹介していきます。 あと払いの歴史とコード負債 私が所属するCredit Designチームではメルペイの「あと払い」や「メルペイスマートマネー」といった与信サービスの開発を行っています。中でも「あと払い」はメルカリが2017年にリリースした「メルカリ月イチ払い」を前身とする歴史の長いプロダクトであり、単純な機能追加だけでなく、設計上大掛かりな変更を伴う修正を繰り返しながら今日まで成長してきました。 例えば、あと払いをメルカードの決済・清算のバックエンドとして統
shiodaifuku.io
Webエンジニアのブログです。
失敗例から学ぶSOLID原則
PHPカンファレンス北海道2024 https://fortee.jp/phpcon-hokkaido-2024/proposal/7d223fcd-ecc8-4cfb-92b2-4987749463d8 Lについての補足記事 https://asumikam.com/entry/2024/01/12/144338 Sについての補足記事 https://asumikam.com/entry/2024/01/13/152513
SOLID原則を理解し、JavaScriptで実践するためのガイド - deve.K's Programming Primer - プログラミング初心者のための入門ブログ
ソフトウェア開発者にとって、堅牢でテスト可能で拡張性があり、保守性の高いオブジェクト指向のソフトウェアシステムを設計することは重要です。 そこで登場するのがSOLID原則です。 SOLIDは、ソフトウェア開発中に生じるかもしれない特定の問題を解決するために5つの設計原則が組み合わさったセットです。 この記事では、SOLID設計の原則について詳しく学んでいきます。 具体的には、SOLID原則が何を意味しているのか、各部分がそれぞれ何を表しているのか、また実際のプログラム例を挙げながら現役のプログラマーが説明します。 さらに、JavaScriptを使ってこれらの原則を実装する方法も紹介します。 SOLID設計原則とは？ 単一責任原則 (SRP) Open/Closed原則 リスコフ置換原理 (LSP) インターフェース分離原則 (ISP) 依存関係逆転の原則 最後に SOLID設計原則とは？
現実世界の事象から学ぶSOLID原則
# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお
オブジェクト指向プログラミング言語の経験がある方なら、SOLID の原則や、MVP、シングルトン、ファクトリ、オブザーバーなどのパターンについて聞いたことがあると思います。今回新しく公開する e ブックでは、これらの原則やパターンを使って皆さんが Unity プロジェクトでスケーラブルなゲームコードのアーキテクチャを構築するためのベストプラクティスを紹介しています。 皆さんが遭遇するソフトウェア設計の問題は、1000 人の開発者がかつて遭遇した問題です。その開発者たちに直接アドバイスを求めることはできませんが、デザインパターンを通じて、そうした開発者がどのような決断を下したのかを学ぶことができます。 Unity プロジェクトで一般的なゲームプログラミングにおけるデザインパターンを実装することで、クリーンで整理された読みやすいコードベースを効率的に構築および維持することができ、ゲームそのもの
DIP(依存性逆転の原則)を守っていない話
一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか？」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat
SOLID原則をまとめてみた Part1 ～SOLID原則とはなんぞや編～ - ecbeing labs（イーシービーイング・ラボ）
はじめに SOLID原則とは どうしてSOLID原則が生まれたのか ダメなソフトウェア設計の4つの原因 Rigidity-剛性 Fragility-脆弱性 Immobility-不動性 Viscosity-粘性 本当の原因 どんな変更が設計をダメにするのか おわりに&次回記事に続く… はじめに はじめましてorこんにちは！ ecbeing2年目、R&D部門所属のいかちゃんです。 これまでは、Dockerの記事やスクラムに関する所感記事、JavaScriptライブラリに関する記事を書きました。 blog.ecbeing.tech そして今回…というより本シリーズでは、泣く子も黙る『Clean Architecture』本を参考に…。 https://www.amazon.co.jp/dp/B07FSBHS2Vwww.amazon.co.jp ソフトウェア設計の5つの原則として名高い「SOLI
https://www.solidjs.com/
How New CSS Is Changing Everything About Graphic Design on the Web
solid+cqs+dry
監視とオブザーバビリティ 〜 悩む前に確認しておくべきこと / 20230926-ssmjp-monitoring-and-observability
ReactからSolidに変えました
趣味でプログラミングをしていて、ライブラリをReactからSolidに変えたので、変えるときに気をつけたことを書きます。 クラスコンポーネントを関数コンポーネントにする Solidにはクラスコンポーネントがないので、関数コンポーネントに書きなおします。 フック関数を変える ReactとSolidはフック関数が違うので、書きなおします。 useState → createSignal 戻り値の一つ目が関数になっているので、気をつけます。 // React function useState(initialState: T): [T, (state: T) => void]; const [state, setState] = useState(initial); // Solid function createSignal(value: T): [() => T, (state: T) =>
SOLID原則は、オブジェクト指向プログラミングにおける基本的な5つの原則です。 S — 単一責任の原則 (Single Responsibility Principle) O — 開放/閉鎖原則 (Open/Closed Principle) L — リスコフの置換原則 (Liskov Substitution Principle) I — インタフェース分離の原則 (Interface Segregation Principle) D — 依存関係逆転の原則 (Dependency Inversion Principle) コーディングにおいて、言語化できない不吉なにおい（Code Smell）を感じたときには、これらの原則に照らし合わせることで設計の間違いを言語化し、修正の手がかりを掴むことができます。 SOLID原則はもちろん、ソフトウェア設計のための原則です。 しかしオブジェクト
class DiscountManager { static int getDiscountPrice(int price, boolean isSummer) { if (isSummer) { int discountPrice = price - 300; if (discountPrice < 0) { discountPrice = 0; } return discountPrice; } return (int)(price * (1.00 - 0.04)); } } class DiscountManager { static int getDiscountPrice(int price, boolean isSummer) { if (isSummer) { return getSummerDiscount(price) } return getRegularDiscoun
GitHub - solidjs/solid: A declarative, efficient, and flexible JavaScript library for building user interfaces.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
SOLID原則で考えるReact設計
こんにちは、株式会社スタメンでオンラインサロンFANTSのフロントエンドエンジニアをしている@0906kokiです。 今回はSOLID原則の5つの設計原則を、Reactのコードをベースにして解説できればと思います。 SOLID原則とは？ SOLID原則とは、ソフトウェアを柔軟に、メンテナンス性を高く設計するための5つの原則となります。 Robert C. Martinによって、5つの原則の頭文字をとってSOLIDという名前が付けられました。5つの原則とは以下の通りです。 SRP: 単一責任の原則 OCP: 開放閉鎖の原則 LSP: リスコフの置換原則 ISP: インタフェース分離の原則 DIP: 依存性逆転の原則 元々、SOLID原則はJavaなどのオブジェクト指向プログラミングに対して、メンテナンス性の向上や分かりやすいプログラムを担保するために提唱された原則ありますが、オブジェクト指向
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: SOLID Principles #5 - Dependency Inversion Principle | Netguru Blog on Ruby/Ruby on Rails 原文公開日: 2018/04/26 著者: Marcin Jakubowski 「SOLIDの原則シリーズ」へようこそ。このシリーズ記事では、SOLIDの原則をひとつずつ詳しく説明し、分析します。シリーズの最後にはいくつかのヒントや考察を含む総括記事をお送りしますのでどうぞご期待ください。 それでは始めましょう。「SOLIDの原則」とはそもそも何なのでしょうか？SOLIDとは、オブジェクト指向プログラミング設計における一般的な原則であり、ソフトウェアをより理解しやすくし、拡張性やメンテナンス性やテストのしやすさを向上させることを目的としています。 単一責
ソフトウェアエンジニアが知っているべきSOLID原則についての記事です。SOLID原則は、5つの原則の頭文字を並べた言葉で、S・O・L・I・Dそれぞれの原則について、5回に分けて説明します。 1) Single Responsibility Principle：単一責任の原則 2) Open/closed principle：オープン/クロースドの原則 3) Liskov substitution principle：リスコフの置換原則 4) Interface segregation principle：インターフェース分離の原則 5) Dependency inversion principle：依存性逆転の原則 今回はSingle Responsibility Principle（単一責任の原則 / SRP）についてです。 なぜSOLID原則が必要なのか？初回なので、なぜソフトウェア
本記事は、掲載元で31K「いいね」を獲得したUgonna Thelma氏による「The S.O.L.I.D Principles in Pictures」（2020年5月18日公開）の和訳を、著者の許可を得て掲載しているものです。 本記事に掲載されているイラストは、すべて原著者Ugonna Thelmaによるものです。 はじめに オブジェクト指向プログラミングに精通している方なら、SOLID原則について聞いたことがあるでしょう。 この5つのソフトウェア開発原則は、ソフトウェア構築時に従うべきガイドラインで、ソフトウェアの拡張性や保守性を高めるためのものです。これは、ソフトウェアエンジニアのRobert C. Martinが提唱したものです。 SOLIDに関する素晴らしい記事はネット上に数多くありますが、イラスト付きの例は滅多に見ません。そのため、私のような視覚的学習者には、飽きずに学習する
Applying SOLID principles in ReactPublished on July 12, 2022 Photo by Jeff Nissen on Unsplash As the software industry grows and makes mistakes, the best practices and good software design principles emerge and conceptualize to avoid repeating the same mistakes in the future. The world of object-oriented programming (OOP) in particular is a goldmine of such best practices, and SOLID is unquestiona
SOLID原則を勉強中です。 TypeScriptでOCPを説明している記事があまりなかったので、自分なりにまとめてみました。 オープン・クローズドの原則（OCP）とは？ software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification クラス・モジュール・関数は「拡張」に対して開いていて、「修正」に対して閉じていなければならない という原則です。 これだけ読んでも「拡張に対して開いて、修正に対して閉じている？ 何も分からん🤔」という感じですが、 自分の中では機能の拡張の際、既存コード修正せず、新しくコードを追加するだけで対応できる設計にすることだと解釈しています。 以下の仕様でプログラムを書くと仮定して、OCPに違反したコード・遵
CA.unityはサイバーエージェントが運営するUnityをテーマにした勉強会です。サイバーエージェントのサービス開発者と社外の開発者を交えて、Unityに関する知見を共有します。とりすーぷ氏からは、設計とアーキテクチャについて発表がありました。 アーキテクチャの目的はコストの最小化 とりすーぷ氏：「Unityにおける設計パターン」というタイトルで発表します。よろしくお願いします。 私は、とりすーぷという名前でいろいろと活動をしています。Microsoft MVPを2018年から継続で受賞しています。ありがとうございます。最近『UniRx/UniTask完全理解』という本を出したので、もしよければ手に取ってみてください。 今回は、設計とアーキテクチャに触れたいと思っています。10分の発表に対して、調子に乗って100枚を超えるスライドを作っちゃって、絶対に10分では終わらないので、発表はだい
オブジェクト指向プログラミングにある程度精通していれば、この開発スタイルが、特定の言語やフレームワークの選択よりも、基礎となる設計手法に深く関わっていることを知っているだろう。オブジェクト指向の適切な設計については数多くの主張や見解があるが、「SOLID原則」は、オブジェクト指向設計に携わる全ての開発者が従うべきルールとして、その権威を確立している。 SOLIDの原則を真に理解するには、この原則が推奨する個々の設計プラクティスについて学び、「各原則を並べて議論する必要性」を理解しなければならない。そこで本稿では、SOLIDが表すオブジェクト指向設計の5つの原則をそれぞれ確認する。「各原則がどう違うか」ではなく「各原則を相互に結び付ける根本的な概念とは何か」について説明する。 オブジェクト指向設計のSOLID原則とは オブジェクト指向プログラミングには特有の5つの原則がある。この5つの原則は
ソフトウェアエンジニアが知っているべきSOLID原則についての記事です。SOLID原則は、5つの原則の頭文字を並べた言葉で、S・O・L・I・Dそれぞれの原則について、5回に分けて説明する記事です。 1) Single Responsibility Principle：単一責任の原則 2) Open/closed principle：オープン/クロースドの原則 3) Liskov substitution principle：リスコフの置換原則 4) Interface segregation principle：インターフェース分離の原則 5) Dependency inversion principle：依存性逆転の原則 今回は5番目の依存性逆転の原則です。 なぜソフトウェアエンジニアがSOLID原則について知っていなければいけないかは最初の記事をご覧ください。 依存性逆転の原則ものすご
Home · Solid
Solid: Your data, your choice. Advancing Web standards to empower individuals and groups. Solid is a specification that lets individuals and groups store their data securely in decentralized data stores called Pods. Pods are like secure web servers for data. When data is stored in a Pod, its owners control which people and applications can access it. Your Pod: All your data, under your control Any
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロサービス設計原則: SOLIDではなくIDEALS
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
🏗️ ドメイン駆動設計と依存性逆転の原則
どうしてあなたの共通化は間違っているのか：目次 - Qiita
【C#】SOLID原則を学ぼう - Annulus Games
たのしいコーディングのための「CUPID」特性 - iki-iki
ソフトウェアのアーキテクチャについて - threecourse’s blog
SOLID原則に従って行うリファクタリング実践 | メルカリエンジニアリング
ゲームプログラミングパターンでコードをレベルアップさせよう | Unity Blog
ガチャを1から作り直した話 ─規模の拡大につれて開発速度を落とさないための取り組みについて─
iOSDC 2019「SOLID原則を生活に適用する」全文以上書き起こし
どうしてあなたの共通化は間違っているのか：第1章「単一責任原則の有用性」 - Qiita
Railsで学ぶSOLID（5）依存関係逆転の原則（翻訳）｜TechRacho by BPS株式会社
よくわかるSOLID原則1: S（単一責任の原則）｜erukiti
イラストで理解するSOLID原則 - Qiita
Applying SOLID principles in React
オープン・クローズドの原則 - TypeScriptで学ぶSOLID原則 part 1 - Qiita
万能なアーキテクチャは存在しない Unityのプロジェクトにあわせたアーキテクチャの“育て方”
オブジェクト指向設計の5つの原則「SOLID」を解説
よくわかるSOLID原則5: D（依存性逆転の原則）｜erukiti
natalie.mu
www.nikkei.com
www.koto6.com
blog1.shima-coffee.com
nlab.itmedia.co.jp
nordot.app