C# Tips: interface を 抽象クラス (abstract class) とどう使い分けるか (プログラミング C# - 翔ソフトウェア (Sho's))
# 久々に技術ネタを書いてみる。 # と言っても、某掲示板で使ったネタの使い回し。 C++ にはなかった新しいキーワードとして、C# では interface というものが出てくる。 interface は、Java ではおなじみのキーワードだ。 例． interface ICloneable { object Clone(); } interface では公開されているメソッドとプロパティの外見 (名前、パラメータ、戻り値) だけが宣言されていて、実装部分が定義されていない。実装部分は、その interface を実装するクラスによって定義される。 例． class Employee : ICloneable { private string name; public string Name { get { return name; } set { name = value; } } p
業務系のクラスでインタフェイスの実装クラス名に「インタフェイス名+Impl」って名前をつけるのはダサいよね。 - wildcatsの日記
実装に特性があるからインタフェイスと実装を分離するわけで*1 インタフェイスに対して実装が1クラスになる場合にはインタフェイスと実装を分離する必要が無いとボクは思うね。 追記：特定のDIコンテナの話はこのエントリと無関係です。 追追記：他所での議論の延長でボクの考えをここに書いただけなので、特定のDIコンテナとか特定の設計手法とかは何も関係ない（というか意識もしていなかった）話ですけど。 上にも例外として書いたしコメントにも書いたんだけど、たとえばトランザクション自動制御とかでFacadeに対してAspectをかけたい場合の設計手法の一つとしてインタフェイスと実装を強制的に分離（インタフェイスと実装が1対1)してDynamic Proxyを使う設計手法を用いても構わないのではないでしょうか？最近のプロジェクトでDIコンテナは使ってないけどHibernateのセッションとかの管理をFacad
『インターフェイス指向設計』読了
最初にオススメポイントだけ書いておく。この本には テスト容易性の確保複雑性保存の法則への対処へのヒントが詰まっている。 kakutani.com にアサマシセンターがあるのかと思ったけどなかったので自分ので貼っちゃうよ。献本なのに自分のアサマシ貼ってるなんてふてぇやつだよ、オレ。 読み手に推奨される準備まずはじめに「本書の読者対象」を挙げておくと、 本書は、ある程度のプログラミング経験と、オブジェクト指向設計の基本的な知識を持つ開発者を対象にしています。オブジェクト指向に深い造詣がある読者でも、インターフェイス指向のアプローチを学ぶことで、これまでにはなかった設計の概念を得ることができるようになるでしょう。また、インターフェイスを理解することは、SOA（サービス指向アーキテクチャ）の設計においても有用です。 と書かれている。 正直に告白すると自分はこれをなめていた。普通に UML もデザイ
業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
