プログラミングの設計が分からない
テーマ、知りたいこと 設計は何に着目すればいいのでしょうか。 オブジェクト指向などの本も読んでみましたがよくわからないです。 vendingMachine (自動販売機) を例にとると ① 仕様に着目 (動詞 メソッド風?) (1) storeJuice ジュースを保管する (2) coolJuice ジュースを冷やす (3) checkPayment 支払いを確認する (4) outputJuice ジュースを排出する ② 場所に着目 (名詞 クラス風?) (1) juiceStore ジュースの保管場所 (2) cooler ジュースの冷却器 (3) moneyBox 金銭管理箱 (4) vent ジュースの排出口 ③ 目的物に着目 (名詞 データが主役のクラス風?) (1) storedJuice 保管されたジュース (2) coolingJuice 冷やされたジュース (3) bo
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
クリーンアーキテクチャ(The Clean Architecture翻訳)
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
データベース論理設計のアンチパターン - 夜は寝る
おはこんばんちは。 がんばってブログを書きたいので、ちょうどいま読んでいるSQLアンチパターンという本を、噛み砕いて離乳食くらいの柔らかさにして晒してみます。すでに読んだ人はいますぐそっ閉じ、まだ読んでない人は、こちらも同様にそっ閉じしてお風呂に入ってすぐ寝ましょう。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (45件) を見る かなり圧倒的に当たり前のことしか書いてないんですけど、そういう本こそが良書だっておじいちゃんの息子の息子が言ってた気がします。 アンチパターンが全部で25個、ｶｯﾁｮｲｲタイトルとともに紹介されています。「目的」「アンチパターン」「解決策」をそれぞれ示します。本書だと、「アンとパターンを
Rubyデザインパターンまとめ
GoFのデザインパターンとは、「プログラミングのベストプラクティスを体系化したもの」です。このベスト・プラクティスをしっかりと理解して設計すれば、ソフトウェア設計の効率を高めることができます。またデザインパターンが「プログラミングの思想」の共有をよりスムーズにしてくれます。先人たちの試行錯誤の結果を効果的に利用して、プログラミングをもっと楽しんでしまいましょう！ 🐯 デザインパターンのポイントGoFのデザインパターンには下のプリンシパルがあります。 変わるものを変わらないものから分離する インタフェースに対してプログラミングし、実装に対して行わない 継承より集約 委譲、委譲、委譲 必要になるまで作るな(You Ain’t Gonna Need It./YAGNI) 🏀 デザインパターン一覧 アブストラクトファクトリ ビルダ ファクトリメソッド シングルトンパターン アダプタ コンポジッ
設計の原則：モジュール化 | システム設計日記
ソフトウェア設計には、パターン理解が大切。 でも、その前に、設計の基本原則（設計の基本テクニック）を、押さえておきたい。 いろいろな設計パターンに共通する、その根っこにある設計原則を会得すれば、パターンの理解や実践が、もっと楽に楽しくなる。 設計原則の会得は、ソフトウェア設計の免許皆伝、達人への道であり、ここぞという時の、銀の弾丸になる。 モジュール化 たぶん、これが、いちばん基本の設計原則。 デザインパターンも、アナリシスパターンも、アーキテクチャパターンも、モジュール化原則の適用例になっていると思う。 モジュール化の原則違反の典型例は、一枚岩（モノシリック）で巨大なソフトウェア。 別名、密結合、スパゲティコード。 こういうソフトウェアは、理解しがたく、変更が恐ろしく難しい。 バグがあちこちに隠れていて、副作用が怖く、とてもじゃないが、コードを変更する勇気（度胸？）はない。 「一枚岩」は
サルでもわかる 逆引きデザインパターン
デザインパターンは「良い設計の虎の巻」 デザインパターンとは簡単に言うと「良い設計の虎の巻」です。 プログラミングや設計をしていると、以前経験したことがある、 似たような問題に出くわすことがよくありますよね。 そのような問題の解決法にわかりやすい名前を付けて、 カタログ化（虎の巻化）したものがデザインパターンです。 デザインパターンは虎の巻ですので、 知っているのと知らないのでは設計や効率に大きく差がついてきます。 先人たちの「設計に関する試行錯誤の結果」であるデザインパターンを、 効果的に再利用しない手はありません。 デザインパターンにはいくつか種類があります。 表１ デザインパターンの種類 カタログ名 説明
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
