タグ

OOPとinterfaceに関するkiyo_hikoのブックマーク (4)

  • 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

    kiyo_hiko
    kiyo_hiko 2012/04/17
    「実際の設計では、State/Strategyパターンを使おう→じゃinterface を使おうとはならない」 / ConcreteStrategyに状態を持たせるならAbstractStrategy書いて共通のフィールドは書いてしまうかな。それが設計としていいのかダメかは謎い
  • 業務系のクラスでインタフェイスの実装クラス名に「インタフェイス名+Impl」って名前をつけるのはダサいよね。 - wildcatsの日記

    実装に特性があるからインタフェイスと実装を分離するわけで*1 インタフェイスに対して実装が1クラスになる場合にはインタフェイスと実装を分離する必要が無いとボクは思うね。 追記:特定のDIコンテナの話はこのエントリと無関係です。 追追記:他所での議論の延長でボクの考えをここに書いただけなので、特定のDIコンテナとか特定の設計手法とかは何も関係ない(というか意識もしていなかった)話ですけど。 上にも例外として書いたしコメントにも書いたんだけど、たとえばトランザクション自動制御とかでFacadeに対してAspectをかけたい場合の設計手法の一つとしてインタフェイスと実装を強制的に分離(インタフェイスと実装が1対1)してDynamic Proxyを使う設計手法を用いても構わないのではないでしょうか?最近のプロジェクトでDIコンテナは使ってないけどHibernateのセッションとかの管理をFacad

    業務系のクラスでインタフェイスの実装クラス名に「インタフェイス名+Impl」って名前をつけるのはダサいよね。 - wildcatsの日記
    kiyo_hiko
    kiyo_hiko 2012/04/11
    コメ欄より「interfaceImplではなくinterface_v101みたいな表記」なるほど / 追記先も見てみた。固有クラスでは多分アリだけど広く利用される予感ならI/FのJavadocにセマンティックス書く所かなあ
  • 『インターフェイス指向設計』読了

    最初にオススメポイントだけ書いておく。このには テスト容易性の確保複雑性保存の法則への対処へのヒントが詰まっている。 kakutani.com にアサマシセンターがあるのかと思ったけどなかったので自分ので貼っちゃうよ。献なのに自分のアサマシ貼ってるなんてふてぇやつだよ、オレ。 読み手に推奨される準備まずはじめに「書の読者対象」を挙げておくと、 書は、ある程度のプログラミング経験と、オブジェクト指向設計の基的な知識を持つ開発者を対象にしています。オブジェクト指向に深い造詣がある読者でも、インターフェイス指向のアプローチを学ぶことで、これまでにはなかった設計の概念を得ることができるようになるでしょう。また、インターフェイスを理解することは、SOA(サービス指向アーキテクチャ)の設計においても有用です。 と書かれている。 正直に告白すると自分はこれをなめていた。普通に UML もデザイ

    kiyo_hiko
    kiyo_hiko 2011/05/26
    読書中・・・「継承の問題について自覚的であった方がよい。継承がいかに扱いにくいかを普段感じていないと、サンプルのコードだけではいたずらに複雑になっただけに感じられてしまう」
  • 業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して

    Java: The Good Partsののタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は当にGood Partなのか? - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす

    業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
    kiyo_hiko
    kiyo_hiko 2011/03/02
    Javaは強固な言語設計をバックに現在の地位を得た印象があるけど、強固に具象化されたものは互換性の維持と相入れにくいんだと思う。古い皮袋的印象がある。Groovyの記事読むと、新しい皮袋としては中々よさそう。
  • 1