.NET のクラスライブラリ設計 - ぐるぐる～
.NETのクラスライブラリ設計 開発チーム直伝の設計原則、コーディング標準、パターン (Microsoft.net Development Series) 作者: Krzysztof Cwalina,Bard Abrams,藤原雄介出版社/メーカー: 日経BPソフトプレス発売日: 2009/12/24メディア: 大型本購入: 9人 クリック: 543回この商品を含むブログ (32件) を見る とっくに読み終わっていたんだけど、まとめる時間がなかったのでかなり時間が空いてしまった・・・ ということで基本的には「・・・ん？」って思ったところとかのまとめです。 アセンブリと名前空間 よく Java の package と C# の namespace を同じようなものとして扱っている人はいるけど、この本では、 アセンブリ パッケージング及び配置の境界 名前空間 開発者に対する論理的なグループ と
フレームワーク デザインのガイドライン | Microsoft Docs
このセクションでは、.NET Framework を拡張および操作するライブラリをデザインするためのガイドラインを示します。 目標は、開発に使用されるプログラミング言語に依存しない統合プログラミング モデルを提供することにより、ライブラリ デザイナーが API の一貫性と使いやすさを確保できるようにすることです。 .NET Framework を拡張するクラスやコンポーネントを開発する場合は、これらのデザイン ガイドラインに従うことをお勧めします。 一貫性のないライブラリ デザインは、開発者の生産性に悪影響を及ぼし、採用を妨げます。 ガイドラインは、Do、Consider、Avoid、Do not という言葉から始まる単純な推奨事項として編成されています。 これらのガイドラインは、クラス ライブラリ デザイナーがさまざまなソリューション間のトレードオフを理解できるようにすることを目的として
S2AbstractServiceを用いたAction-Service-Logicパターン - 出羽ブログ
以前に「1.5階層のAction-Service-Logicパターン」を紹介させて頂きました。今回は、このアーキテクチャにS2AbstractService を導入した場合のアーキテクチャについて検討してみました。 主な変更点として、S2AbstractService を導入する場合は、アクションやロジックから直接JdbcManagerを使うこと得策ではないと考え、データアクセスロジックは全てサービスを経由するようになった点です。 まずは、アーキテクチャを図示したものをご覧ください。細かい解説は別エントリにて書かせて頂きますが、エンティティ単位のサービスを採用しつつも、ユースケース固有のロジックはアクションに記述する方法を提示したいと思います。 アーキテクチャ（レイヤ構成図） アーキテクチャ（モジュール相関図）
1.5階層のAction-Service-Logicパターン - 出羽ブログ
趣旨とあんまり関係ないですが、Service・Logicをとりまぜた3階層にするならば、エンティティによったものをService、アクションによったものはLogicと呼んだ方が、フレームワーク側の呼び方との親和性は高いように思います。 ちなみに、今はこんな感じの設計はどうかと思っています。 Serviceクラス：エンティティと対につくる。ドメインモデル的な考え方がプロジェクト内でついていけないならばいっそのこと導入しない。 Logicクラス ・ユースケースを跨がる画面まわりの制御処理や、ユースケースをまたがるビジネスロジック特有の処理を書く。いわゆる、サブシステム間共通関数のイメージ。たとえば複数ユースケースであるケースでは沢山の表にインサートするが、あるケースではアップデートのみするようなものを使う。 ・ただし、Serviceクラス的設計が難しい場合には、画面制御的なクラス Servic
Action-Service-Logic の3階層は冗長か？ - 出羽ブログ
エンティティ固有のドメインロジックは別出しにします。 ひがさんが最近呼んでる「Service」に近いです。 でも、みなさん Action-Service-Logic の3階層は冗長ってお考えなんですね。 そうでもないですよ。今、私が携わらせて頂いている案件では、 Action ： コントローラ Service： ユースケース単位のロジック + データアクセス Logic ： エンティティ単位のロジック + データアクセス ※ LogicはActionとServiceの両方から呼び出し可能とする。の方式に数人の中核のメンバーから納得感を得ています。 無難な選択肢だと思います。 一見冗長に思えますが、「ユースケース単位のロジック」と「エンティティ単位のロジック」を１種類のクラスに寄せる方式はどこかで無理が生じてしまいます。そう考えると、この方式は自然な発想ではないでしょうか。 この方式のポイン
フォームクラスをアクションとは別にする 5 つの理由 - cypher256's blog
セッションに格納したい場合は作る、っていうのがあれな気がします Struts に慣れている人に違和感がない気がします 最近よくあるフレームワークはプロパティも一緒に持ってるけど、あれはページ単位です サンプルでは小さいけど、実システムでは一緒にすると間違いなくでかくなります 誤解をおそれず古い言葉で言えば、トランザクションスクリプト最強です
どのクラスに処理を記述すべきか？ 〜 Part2 - 出羽ブログ
SAStrutsのアーキテクチャにおいて、それぞれの処理をどのクラスに 記述するのが良いかの検討を引き続き行う。 下図はブラッシュアップした現時点での判断チャート。 順を追って説明してみる。 ユーティリィティ的な処理か？ 何を持ってユーティリィティ的な処理とみなすかは以外に難しい。 しかし、どのクラスに記述すべきかの見極め以前に、そもそも、 そのソースコードを書く必要があるかを疑ったほうがいい。 Apache CommonsやSeasar2のutilパッケージなど第三者が 作成したユーティリィティクラスでかなりの代替が利くはず。 プログラマ全員がプロジェクトの最初の段階で、 役立つ3rdパーティのユーティリィティ情報を共有しておくべし。 あとは、ユーティリィティ的な処理かどうかの見極めに 自信がない人は、センスのよさそうに相談するのが良い。 画面周りの処理か？ 画面周りのロジックの代表的な
複数種類のエンティティを扱うロジックをどこに書くのか - ひがやすを技術ブログ
「複数種類のエンティティを扱うロジックをどこに書くのか」、これは、非常に難しい問題です。エンティティに持たせると、どこのエンティティに持たせるのかを判断するのが難しい。 だから、アクションにもたせるのが良いと書いてきました。 でも、売上金額 = 売上明細.商品.単価 * 売上明細.数量みたいなロジックがあって、JSPに売上金額を表示する場合に、このロジックをアクションにもたせるかというと微妙ですね。 売上金額が1つしかないなら、それでもいいけど、複数あった場合は、うまくいかない。コメントで答えたように、これくらいの計算なら、ELでやっても全然いいんだけど、複雑な計算だとどうするのか。 売上明細エンティティが複数あって、複数の売上金額を表示するなら、売上エンティティで計算したほうが全然楽です。 <c:forEach var="e" items="salesDetailItems"> ${e.
どのクラスに処理を記述すべきか？ - 出羽ブログ
1つユースケースに閉じていることは、すべてActionに記述し、複数のユースケースで使われるものをLogicに分割するのがシンプルでわかりやすいのではないかと、そう思ったわけです。 ＜＜中略＞＞ 追記2:コメントへの回答ですが、ユーティリティは、staticメソッドで構成されるやつは、utilのパッケージ。ActionにDIするやつは、logicパッケージでいいと思います。どっちでもないユーティリティもutilパッケージですね。 Entityについては、SAStrutsのドキュメントにもこのblogでも書いていますが、1つのEntityに閉じたロジックならEntityに記述するということでいいと思います。複数のユースケースで使うからこそ、Entityに書く意味がありますね。個別のユースケースでしか使わないなら、Actionに書いたほうがいいと思います。 上記のひがさんのエントリーを元に「ど
クラスに原則として、CRUDのメソッドがないとこまる - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） きのうの、要件を出すところから運用まで、一気に書いてみるで、 （４）機能要件の抽出（クラス図のメソッド部分） のところで、 ・（２）の名詞、つまり、主語か、目的語のクラスのメソッドに、 開発システムのアクティビティ図のアクティビティを埋める と書いたところがありますが、メソッドを、主語と目的語のどちらに入れるかについての話。 ■まず、原則、そのクラスのCRUDは、メソッドにある これは原則論ですが、あるクラスの ・作成または追加（C:Create） ・検索（一覧）読み込みなど（R:Read) ・編集、更新、変更など（U:Update) ・削除（D:Delete） を意味するようなメソッドは、そのクラスのメソッドとします。 たとえば、「申請書を作成する」というような場合、 申請書ク
要件を出すところから運用まで、一気に書いてみる - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） いままで、 ・要件から、クラス図までに落とし込む流れ ・MVCで要件→モデルのクラス図から、コントローラーに落とし込む ・MVCで要件→画面に落とし込むまで とまとめてきたので、それから先のプログラミングやテストまでも含めて、全部 一気に開発の最初から最後まで、書いてみました。 ■要件から要求仕様まで （１）要件の動詞部分に着目し、抜き出す （２）動詞の主語、目的語を取り出し、 「何々が、何々を、なんとかする」という単文の形にする →もし～ならば、「何々が、何々を、なんとかする」と、 条件がつく場合もある （３）データ分析（クラス図の属性部分） ・（２）の名詞、目的語は、「モノ」なので、これをエンティティとする ・使っている帳票などを、 ・第一正規形 ・第二正規形（トップダウン方
やさしいクラス設計「活きのいいクラス見つけます」by Java and C#
1日目 --- クラス設計とは ここではクラスとその設計について書いていきます。 オブジェクト指向プログラミング言語の一つであるクラスベースの言語において、クラスの設計はプログラム設計の重要なものの一つです。 例えば、Java や C# はクラスベースのオブジェクト指向言語であり、そのクラス設計は重要です。 クラスとは？ まず、クラスとは何でしょう。 クラスとは、具体化されたインスタンスオブジェクトの一部を抽象化してカテゴライズしたオブジェクトです。 例えば、数値の 1や 2 のようなオブジェクトを考えます。このオブジェクトは + や - に反応するオブジェクトです。 これらのオブジェクトで値を抽象化したオブジェクトを考えます。これを integer オブジェクトと呼んでみます。この integer は + や - に反応するオブジェクトで値が抽象化されている オブジェクトの総称になりま
C＋＋クラス設計に関するノート
C++が他のオブジェクト指向言語と比べて難しいのは、やはりメモリ管理をプログラマが自分でしなければいけない点だと思います。よくよく注意しないと、削除し忘れたり、同じオブジェクトを2度削除してしまうというエラーが発生します。このノートでは、オブジェクトを「値オブジェクト」と「参照オブジェクト」というカテゴリに分け、詳細設計の段階で注意すべき点を整理しておきたいと思います。 0. はじめに 私自身今までいくつかのプログラミング言語を使ってきましたが、C++ が他のオブジェクト指向言語と比べて難しいのは、やはりメモリ管理をプログラマが自分でしなければいけない点だと思います。例えば、 Person* person = new Person(); と生成したオブジェクトは、使い終わったら次のように削除しなければなりません。 delete person; 生成してすぐ削除するなら簡単なのですが、実際に
クラス設計に関するメモ
経験的にこのようにした方がよいと思った点についての記録です。 仕事で大規模(2000クラス超)かつ製品寿命がながいパッケージソフトを作っていた関係で、 ちょっとした設計の間違いが、 あとあとで大変な苦労する羽目になったりすることを経験してきました。 このような規模が大きいアプリケーションを作ることはなかなかないかもしれませんが、 なにかの参考になれば、と思います。 継承する前に委譲を検討する Singleton パターンを使うときの注意 Template Method パターンを使うときの注意 クラス間の依存に関する注意 クラスの粒度 Singleton の問題を回避できるか？ 継承する前に委譲を検討する 継承はスーパークラスの仕様をよく理解しておかないと、 バグを作りこみやすいので十分注意する必要があります。 メソッドのオーバーライドをするときも、 public void foo(){
ハタさんのブログ : 第2回設計勉強会に参加してきた
第2回設計勉強会に参加してきました。 まず、こういった機会を提供してくれた id:shimookaさん、ありがとうございます。株式会社ディノさんも会場の提供ありがとうございます。LINDさんも毎度ありがとうです。 とりあえず、資料を置いておきます。 Event Php Study Design 2 View SlideShare presentation or Upload your own. (tags: php design) ちなみに、Teedaのレイヤーは Teeda Extension featuring Goya 〜アーキテクチャ【レイヤー構成】〜 - たかのり日記 さんのを、チョーそのまま使ってます Hermit は http://svn.coderepos.org/share/lang/php/misc/Hermit/ 今回の発表は、すいません。あまりまとめきれていなく
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
- デザインパターンによる進化的設計
このプログラムでは全体の処理の流れが決まっています． その中で，youGotMailPopup()の部分のみの動作が変更できることが望まれています． ここで利用できるパターンを考えてみます．振舞に分類されるパターンのなか で，TemplateMethod と呼ばれるパターンがあります．GoFを参照すると， TemplateMethod 目的: 1つのオペレーションにアルゴリズムのスケルトンを定義しておき，そ の中のいくつかのステップについてはサブクラスでの定義に任せることにする． TemplateMethodパターンでは，アルゴリズムの構造を変えずに，アルゴリズ ムの中のあるステップをサブクラスで再定義する． とあります．今回の例では，全体の処理の流れを規定するrun()メソッドが上 記の「スケルトン」に当たります．また，youGotMailPopup()が「いくつかの ステップ」に当ては
ドメイン駆動設計 - Wikipedia
ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）とは、ドメインの専門家からの入力に従ってドメインに一致するようにソフトウェアをモデル化することに焦点を当てるソフトウェア設計手法である[1][2]。オブジェクト指向プログラミングに関しては、ソースコード（クラス名・クラスメソッド・クラス変数）の構造と名称がビジネスドメインと一致させる必要があることを意味する。例えばローンの申し込みを処理するソフトウェアには、LoanApplicationやCustomerなどのクラスと、AcceptOfferやWithdrawどのメソッドが含まれることになる。ドメイン駆動設計は次の目標に基づいている。 プロジェクトの主な焦点をコアドメインとドメインロジックに置く。 ドメインのモデルに基づく複雑な設計。 特定のドメインの問題に対処する概念モデルを繰り返し改良す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web API Design - 開発者が愛するインターフェイスを作る
Amazon.co.jp: 言語設計者たちが考えること (THEORY/IN/PRACTICE): Federico Biancuzzi (編集), Shane Warden (編集), 伊藤真浩 (翻訳), 頃末和義 (翻訳), 佐藤嘉一 (翻訳), 鈴木幸敏 (翻訳), 村上雅章 (翻訳): 本
