7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
Let's make a contract: the art of designing a Java API
Let's make a contract: the art of designing a Java API 1. Let's make a contract: the art of designing a Java API by Mario Fusco mario.fusco@gmail.com @mariofusco 2. What is an API? 3. What is an API? 4. An API is what a developer uses to achieve some task What is an API? 5. What is an API? An API is a contract between its implementors and its users 6. And why should I care? We are all API designer
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
ショッピングサイトで見かけるダークパターンのまとめ | コリス
たくさんのショッピングサイト、オンラインショップがあります。良心的なサイトもたくさんありますが、意図しない購入や申込に誘導・欺くサイトもあります。利用者として、そして制作者として、気をつけたいダークパターンを紹介します。 料金に手数料が加えられていたり、メール配信が知らない間に申し込まれていたり、登録は簡単なのに退会が難しかったり、キャンセルがクリックできないみたいに表示されてたり、さまざまなダークパターンが存在します。 Dark Patterns at Scale by プリンストン大学とシカゴ大学の研究者によるレポート 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに Sneaking -スニーキング Urgency -アージェンシー Misdirection -ミスディレクション Social proof -ソーシ
高木浩光＠自宅の日記 - 天動説設計から地動説設計へ：7payアプリのパスワードリマインダはなぜ壊れていたのか（序章）
■ 天動説設計から地動説設計へ：7payアプリのパスワードリマインダはなぜ壊れていたのか（序章） 7payの方式はなぜ許されないのか、なぜあんな設計になってしまったのか、どう設計するのが正しいのか、急ぎ書かなくてはいけないのだが、前置きが長くなっていつ完成するかも見えない。取り急ぎ以下のツイートでエッセンスを示しておいた*1が、すでにわかりかけている人達にしか刺さらなそうだ。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) July 8, 2019 同様のことは4年前にNISCのコラムに書いたが、消えてしまっているので、ひとまず、その原稿を以下に再掲しておく。 スマホ時代の「パスワード」のあり方を再考しよう 高木浩光 2015年2
共通化という考え方はアンチパターンを生み出すだけ説 - タオルケット体操
共通化を指針にするのはおすすめできない 「共通化」というワードはプログラマーであれば誰しもが一度は聞いたことがあるだろう。そしてもうひとつ、それと対称であるかのように語られるのが「コピペは悪」だ。 ここで僕が異議を唱えたいのは共通化を善とする教義についてだ。世間的に共通化を良いものだとする風潮があるようなので石を投げるために書き殴ろうとおもう。 さて、ぶっちゃけた話、共通化なんてものを念頭にしてコードを書いてはいけない。そんなことをしたら見通しの悪いクソの山が世の中に一つ増えるだけである。 じゃあコピペしろというのかというとそういう話をしているわけではない。僕が言いたいのはコードを設計*1する際に、共通化なんていうゴミみたいな方針を用いるのはやめろということだ。 ならどうすればいいのかというのを頑張って言語化してみると、「抽象化」するというのが僕の語彙の中では正しい。 なぜ共通化するのか
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
早すぎる抽象化の危険性(その抽象化、今のタイミングで大丈夫ですか？) - Qiita
※ 色々と誤解を招くというご指摘を受けたためタイトルを変更しました 早すぎる抽象化の危険性 ↓ 早すぎる抽象化の危険性(その抽象化、今のタイミングで大丈夫ですか？) 元の記事の趣旨としては、 抽象化をするな という訳ではなく、 その抽象化は本当に今すべきなのか一歩立ち止まって考えろ ということだと思っております。 何か不適切な点などございましたらご指摘頂けますと幸いですm(_ _)m ~~ 以下本文 ~~ ちょっと前の記事なのですが とても印象深く 今後も気をつけていきたいと思い 自分なりにまとめてみました。 早すぎる抽象化とは？ 問題になっていることを十分に理解する前に 可能性のあるすべてのパターンを把握しきる前に 抽象化をしてしまうこと ※コメントでのご指摘がありましたように 「早すぎる抽象化」はの結果として 「誤った抽象化」に陥ってしまうことが問題であり、 定義を下記のように修正しま
REST APIとは？ - API設計のポイント
最近は様々なサービスでWebAPIが提供されています。普段の開発をする中でもシステム連携などでAPIを作る機会が出てくるのではないでしょうか。 WebAPIの中でもREST APIなんてものもよく聞くのかなぁと思います。REST APIの設計は色々と奥が深く、なかなかおもしろい技術です。 今回はそんなREST APIを設計する上でのポイントをご紹介していきます。この記事では実装よりも設計思想的な部分を書いています。次回以降にもう少し実装に近いレベル記事を書いきます！ REST APIは、「Representational State Transfer（表現状態の転送）」というアーキテクチャスタイルに従って設計されたAPIのことです。RESTの概念は2000年にRoy Fieldingによって提唱され、Webアーキテクチャにおける一つの重要な原則として広く認識されています。 じゃあ、REST
DDDとコードとしての正しさ - pospomeのプログラミング日記
ドメイン駆動設計 #1 Advent Calendar 2018の14日目を担当する@pospomeです。 今回はDDDとコードとしての正しさについて書いてみようと思います。 DDDは設計手法である コードとしての正しさ コードとしての正しさを見失う ユースケースの日本語を"そのまま"コードに落とし込もうとする 無駄にオブジェクト同士の結合度を上げる RubyのActiveRecordの正しさ コードとしてのメリット、デメリットを具体的に考えて解決する まとめ DDDは設計手法である DDD = ドメイン駆動設計 ですよね。 "設計"という単語が付いていることから分かる通り、DDDはあくまでソフトウェアにおける設計手法です。 そのためDDDの成果物は"コード"であり、DDDの目的は"コードの可読性を上げること"であると自分は考えています。 DDDが持つ"ビジネスを理解する", "ドメインを
500日のトライエラーから生まれた大規模設計ノウハウ / Frontend Conference Fukuoka 2018 - Speaker Deck
2018/12/8 Frontend Conference Fukuoka 2018にて発表した資料です。
技術者よ、設計しよう、仕様書を書こう | 宇宙科学研究所
私は、昨年度、工業標準化事業に対する貢献により経済産業大臣から表彰を受けました。編集委員会から私に与えられたテーマは、それについて解説せよというものです。しかし、その技術的な内容については既に本ニュースの2004年6月号において「宇宙開発における標準化と情報化」という題名で執筆しています。そこで、今回は、私が標準規格などの文書の作成に力を入れている理由についてお話ししたいと思います。なぜならば、その理由をお話しすることは、「人工衛星のような複雑なシステムをいかに効率的に開発するか」という私のシステム工学的な研究の成果を解説することになるからです。 人工衛星のような複雑なシステムの開発は、必然的に大人数のチームで行うことになるのですが、効率的に開発を行うための一つの原則は、「チーム構成員の誰もが何かしら具体的な作業を担当し、その作業結果を文書などにまとめ、プロジェクトの中で機能させること」だ
設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜(まとめ版) - Speaker Deck
「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
センター試験のリスニングプレイヤーはデザイン性は無いが誤操作が起きないよう徹底的に設計されている「ダサ美しい」