オブジェクト指向は業務システムで本当に不要なのか？ - Qiita
主旨 以前はシステムの状態をオブジェクト指向でカプセル化し、オブジェクト同士の通信でシステムの制御をしようとしていた しかし、Webアプリケーションのように状態をメモリ上に保持し続けるのが難しい環境が増えると、上記のことがやりにくくなった（ORMのインピーダンスミスマッチの影響が大きくなった） 現在では、システム全体の状態を管理するためにオブジェクト指向を用いるシーンは減っているが、要所要所でシステムを抽象化する道具の一つとして用いるシーンはあり、適材適所で使い続ければ良い はじめに 一時期あれだけもてはやされた「オブジェクト指向」ですが、現在では「業務システム開発においてオブジェクト指向で作るとろくなことがない」、とか、いっそ「不要である」、という意見もよく見かけます。 オブジェクト指向、この記事では特に「オブジェクト指向プログラミング」を対象として話をしますが、その利点は以下の３点に集
オブジェクト指向プログラミングは終わった - Qiita
追記: 振り返りを書いてみました～ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性／可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性／可変性分析 共通性／可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題領域にある概念を見つける（共通性の分析） その流動的要素を洗い出す（可変性の分析） 流動的要素を見ながら、その概念が持つ責務を果たすための抽象的側面（≒インタフェース）を導く 各流動的要素の実装上の観点から、インタフェースが適切かどうかを見極め、補正する オ
staticメソッドの使いみちがイマイチわからないのでまとめてみた - Qiita
※ 本記事は未完成 です。 まだ自分の中に落とし込めていないのですが、他の人の役に立つこともあるかと思い、投稿します。 誤っている箇所がありましたら、遠慮なくマサカリを投げてください。 「staticメソッド」とは？ 直訳すると「静的メソッド」です。「クラスメソッド」ともいいます。 対義語は「インスタンスメソッド」です。 staticメソッドのメリット ①インスタンスを生成せずに呼び出せる インスタンスを生成せずに呼び出せるのが一番のメリットです。インスタンス生成にかかるオーバーヘッドがなくなるので、 インスタンス生成に時間がかかるクラスに有効 です。 そのため、頻繁に呼び出されるユーティリティメソッドはよくstaticメソッドとして実装されます。 また、自クラスのファクトリメソッドのように、 インスタンスの生成前に実行すべきメソッド はstaticにするしかありません。 ②インスタンスご
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
君の継承の使い方は間違っている - Qiita
オブジェクト指向はプログラミングの基本です。そして、継承はオブジェクト指向の基本的な操作ですから、プログラマーは呼吸をするように継承をできなくてはならないはずです1。 しかしその割に、ダメな継承の使い方をして、スパゲッティコードになるのを実務でしばしば見かけます。 これは、継承の「良い使い方」はデザインパターンとしてリストアップされているのに、「悪い使い方」はまとまっていないせいかもしれません。そこで、自分だったらコードレビューで をつけるような「悪い継承の例」を挙げてみました2。 （この記事は個人的な経験によるもので、理論的な裏付けがあるものではありません。ご意見やオススメ本があれば、コメントをお願いします。また、この記事は随時細かい表現の修正をしています。） TL;DR 継承を使ってはならない Mix-inを使ってはならない super は不吉な兆候 例外条項 インターフェースの実装（
DI はなんのためにあるのか - Qiita
この記事について DI (Dependency Injection: 依存性注入）とはなにか、という解説はよく見るんですが、なぜ DI か、という解説はあまり見ない気がするので、自分の考えを文書化しておこう、という試みです。 DI（依存性注入）とはなにか Wikipedia にある説明を載せるのに留めます。 コンポーネント間の関係はインタフェースを用いて記述し、具体的なコンポーネントを指定しない。具体的にどのコンポーネントを利用するかは別のコンポーネントや外部ファイル等を利用すること https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E3%81%AE%E6%B3%A8%E5%85%A5 Laravel での使用例です。Laravel においては、インタフェースを介さず、キーとなる文字列（クラス名、コンテナを用いる場合は任意の
PUT か POST か PATCH か？ - Qiita
CRUDの操作をRESTで表現すると一対一で対応していないことに気づきます。RはGET、DはDELETEと考えておいて良さそうですが、CとUはPUT、POST、PATCHの3つの選択肢があり、APIを設計していると迷います。整理するためにまとめておきたいと思います。 下記の資料を参考にしました。 http - PUT vs POST in REST - Stack Overflow When to use PUT or POST | - The RESTful cookbook GitHub API v3 基本的な考え方 PUT: リソースの作成、リソースの置換 POST: リソースの作成 PATCH: リソースの部分置換 PUTはPOSTと違い、リソース名を指定して作成または更新をかけるメソッドです。PUT /articles/3421は新規作成かもしれませんし、更新かもしれません。PU
コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可
Serviceクラスの意義と勘所 - Qiita
今回はRails界隈でもいくつかの議論がある「Serviceクラス」について 一つの考え方を書いていこうと思います Serviceクラスとは MVCやDDDにおいて分離させているレイヤーの責務が大きくなった際に活躍の場がある概念です DDDでは「ドメインサービス」と「アプリケーションサービス」とそれぞれのレイヤーで定義されていますが MVCにおいても「モデルサービス」「ビューサービス」「コントローラーサービス」みたいな考え方ができますね ただし、「ビューサービス」ではなく「ビューヘルパー」だったり、別に置き換えられたりします それ故、世間一般にいうServiceクラスは「ドメイン知識を持った手続きクラス」を指すことが多いです 意義 MVCなど完成された概念になぜServiceクラスが必要なのか？ その答えは肥大化したクラスを整理することにあります 処理系をまとめて、カプセル化し、責務を分け
オワコン大手SIerに学ぶアンチパターン - Qiita
軽い読み物としておもしろおかしく読んでください。 はじめて社外の人の仕事を見た 今まで社内の成果物しか目にしてこなかったのですが、ふとしたきっかけで外部ベンダーが作ったシステムを移行することになりました。 会社名を見て、よく知った会社でちょっと安心しました。 「ここなら設計書とかもきちんとしてるだろう、多少古臭くても堅実にやってるんじゃないかな」って思ってました。ええ。 実態は全然違った とんでもない量のExcelが設計書として渡されました。 さすがに設計が専門だけあって設計書の量はすごいなぁ。と思って読んでいるといろいろ察してきました。 正直、「オワコン大手SIer」と呼ぶしかありません。設計しかできないと思っていたのに、何もできないなんて・・・ 実際に自分が見た「オワコン大手SIer」のアンチパターンをご紹介していきます。 自分が多く当てはまっている場合は今すぐ直してください。移行する
GoF デザインパターン チートシート - Qiita
ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね! (注: ここからはあとがきポエムです) ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。 実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。 あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のす
SQLアンチパターンもりもりDBを設計しよう！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 名著SQLアンチパターンを読み終えたので、それの復習のために悍ましいデータベースを作ろうと思った。 まず前半では、SQLアンチパターンを意図的に盛り込み、目も当てられない酷い設計をします。 そのあとリファクタリングを行なったER図に書き直していきます。 なお、真面目に書くと参考書の丸写しになってしまうので、この記事は アンチパターンもりもりのER図を見て嫌悪感を学習し、設計に役立てようという趣向のもと、詳しい説明は省きます。 とても良い本なので読んでください。 想定するシステムの概要と状況 目的において適切かはわかりませんが、とり
ドメイン駆動設計を勉強するときのオススメ資料 - Qiita
この記事は、ドメイン駆動設計 #1 Advent Calendar 2018の9日目です。 明日は@kmdsbngさんです。 今回は、ドメイン駆動設計（以下DDD）を学ぼうとする人に対して参考になる資料をまとめます。 DDD関連資料のオススメ まずはDDDの青い本、エリック・エヴァンスのドメイン駆動設計から手を出したいところですが、500ページ超えで分厚く、初学者の人とっては解説される内容が抽象度が高く、理解するのに苦労すると思います。 ですのでこれから紹介するSTEPの順番から読んでいくのことをオススメします。 STEP1 まずはDDDの概念から理解していくことから始めましょう。下記の本がオススメです。 わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～ https://booth.pm/en/items/392260 この本はストーリー形式でDDDを解説されていますので比較的理解しやす
業務でWebサービス開発をする際に気をつけたいこと（新卒向け） - Qiita
趣味でも業務でも日々Webサービスを開発しているzaruです。こんにちは。ついにアドベントカレンダーも最終日です。まだサンタとしての仕事が残っています。さて今回は仕事としてWebサービスを開発するときに気をつけたいポイントを紹介します。まぁ仕事に限った話じゃないですが…参考になれば幸いです。特に新卒プログラマあたりに読んでもらえればと思います😀 なお僕の業務上インフラ周りはAWSが多いです。 RASISという指標 RASISという指標があります。コンピュータシステムの評価指標5つの頭文字を取ったものです。 Reliability（信頼性） Availability（可用性） Serviceability（保守性） Integrity（保全性） Security（機密性） 今回はこの5つの指標に沿ってポイントを紹介していきます。RASIS自体については色々なところで解説されていると思うので
ログ設計指針
概要 このドキュメントは、効率的かつ安定した、システム開発/運用をするためのログ設計指針です。 的確かつ無駄のない、ログ出力を目指します。 ログレベル ログの緊急度や用途により、以下のようにログレベルを設定する。 Log4j のログレベルを踏襲しているため、運用の状況によっては Critical などのレベルを適宜追加すると良い。 PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっている。 「出力先」「運用時の対応」は、各プロジェクトのポリシーに準じてください。 レベル 概要 説明 出力先 運用時の対応
翻訳: WebAPI 設計のベストプラクティス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「設計」で大事なのはこれだった！半年間で40本レビューして分かった 5つのポイント - Qiita
Not Found