オブジェクト指向プログラミングにおいてユーティリティクラスに代わるもの | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、OOP Alternative to Utility Classesを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 ユーティリティクラス(またはヘルパークラス)は、スタティックメソッドだけを持っていて、状態を内包しない「構造体」だ。 Apache CommonsのStringUtils、IOUtils、FileUtilsや、GuavaのIterables、Iterators、またJDK7のFilesはユーティリティクラスのいい例だ。 ユーティリティクラスはよく使われる共通機能を提供するので、この設計手法はJava(やC#、Rubyなど)の世界でとても人気だ。 要するに我々は、DRY原則に従い、重
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い - Qiita
はじめに 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考えるという記事がkenokabeさんという方が挙げていて、拙著の 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡について言及があったので、補考として挙げておく。 暗黙的状態と明示的状態 これまで、関数を「わかりやすくきれいに書く方法」とオブジェクト指向が「どのようにして生まれてきたか」について話してきた。 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 一見、それぞれ関係ないように思うかもしれないが、実は大きなテーマでつながっている。 『それは「状態」をどのように取り扱い単純化するか。』ということだ。そして、これがいわゆる関数型プログラミングとオブジェクト指
共通関数継承のデメリットを説明せよ - @katzchang.contexts
共通関数継承とは、あるクラスで共通的に使うだろう関数やメンバを、親クラスのメソッドやメンバとして定義するパターンだ。Constant interfaceパターンやimport staticあたりが関係するアンチパターンとされるモノの一つで、神様ルートクラスを嫌い、POJOを好むのあたりの、ごく初歩な議論になるだろうと思う。 package spike; public abstract class SuperUtil { /** * 時刻形式の文字列から、日付部分を抜き出す */ protected String timestamp2Date(String timestamp) { if (validTimestamp(timestamp)) return timestamp.substring(0, 10); return ""; } /** * 時刻形式の文字列から、時間部分を抜き出す
『インターフェイス指向設計』読了
最初にオススメポイントだけ書いておく。この本には テスト容易性の確保複雑性保存の法則への対処へのヒントが詰まっている。 kakutani.com にアサマシセンターがあるのかと思ったけどなかったので自分ので貼っちゃうよ。献本なのに自分のアサマシ貼ってるなんてふてぇやつだよ、オレ。 読み手に推奨される準備まずはじめに「本書の読者対象」を挙げておくと、 本書は、ある程度のプログラミング経験と、オブジェクト指向設計の基本的な知識を持つ開発者を対象にしています。オブジェクト指向に深い造詣がある読者でも、インターフェイス指向のアプローチを学ぶことで、これまでにはなかった設計の概念を得ることができるようになるでしょう。また、インターフェイスを理解することは、SOA（サービス指向アーキテクチャ）の設計においても有用です。 と書かれている。 正直に告白すると自分はこれをなめていた。普通に UML もデザイ
オブジェクト指向プログラムでgetter/setterメソッドを使わなければならない10の理由
オブジェクト指向プログラムで getter/setterメソッドを使わなければならない 10の理由 福盛 秀雄 fukumori at m.ieice.org JavaやC++などのオブジェクト指向言語でプログラムを書いているときに、単純なメンバ変数を参照したり操作するために anObject.getX() [以後これをgetterメソッドと呼ぶ] とか anotherObject.setY(y) [以後これをsetterメソッドと呼ぶ] と書くのはなぜだろうと思ったことはないだろうか? int型の変数ひとつを操作するのになぜわざわざメソッドを定義するのだろう? 単純に代入を使えばいいじゃないか? この文章はそんなあなた(かつての僕も含む)が、getter/setterメソッドを使うべきである理由についてまとめたものである。 ということで早速本論へ。 1. クラス内部のデータ表現を変えた場
)
Coupling (computer programming) - Wikipedia
In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are;[1] the strength of the relationships between modules.[2] Coupling isn't binary but it's multi-dimensional. [3] Coupling and cohesion Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa
オブジェクト指向についてまとめたもの - だるまのエクセルVBA
オブジェクト指向についてまとめたもの このコンテンツの開設理由 オブジェクト指向で設計する際に頭に入れた方が良いと思ったこと（基礎的な内容） クラスとオブジェクト インスタンススコープの属性とクラススコープの属性 インスタンススコープの操作とクラススコープの操作 オブジェクト指向とモジュールの凝集度、モジュールの結合度 クラス図とER図とクラスの抽出 クラスの正規化 関連 POA、DOAとオブジェクト指向 カプセル化と属性と操作 ←サンプルがバグっていました。大変申し訳ございません。（2007/11/7） 多態性 継承 依存 オブジェクト指向とUML オブジェクト指向の限界 オブジェクト指向で設計する際に頭に入れた方が良いと思ったこと（より良い設計をするための内容） オブジェクト指向設計とGRASPパターン エンティティクラス、バウンダリクラス、コントロールクラス、その他のクラス
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
「オブジェクト技術導入の落とし穴」実施報告 (前編)
[ObjectDayパネルディスカッション] 「オブジェクト技術導入の落とし穴」実施報告 (前編) オブジェクト第1事業部技術コンサルティング室 羽生田栄一 はじめに 先日行われたObjectDayの最後を飾る形で（などというと並行セッションの方々に申し訳ないですね。あくまでもその場で司会を務めた私の主観でそう感じたということでお許しあれ）パネルディスカッションが開かれました。普通このような１私企業主催のパネルということになると、あたりさわりのない事勿れ的なテーマが選ばれるのが常ですが、そこは大阪商人の伝統？と大衆芸能のセンスを分かち持つオージス総研ですから、お客さんがここが聞きたい、と思っていてしかも面白い、議論が白熱するテーマでやれ、というありがたいお達し(*)で、敢えてこのようなテーマが選ばれたわけです。 オブジェクト指向がどんなに優れているか今さら議論するのも興ざめだし、かといって
Martin Fowler's Bliki in Japanese - CallSuper
http://martinfowler.com/bliki/CallSuper.html 親メソッド呼び出しは、オブジェクト指向フレームワークのなかで 不吉な匂い(アンチパターンと言っても良いでしょう)を出しています。 その症状は簡単に見つけることができます。 フレームワークを使うために、スーパークラスを継承しているとしましょう。 ドキュメントには、おそらくこのようなことが書かれているでしょう。 「サブクラスを作成して処理メソッドをオーバーライドしてください。 ただし、メソッドの先頭でスーパークラスの呼び出しを行ってください。」 例えばこんな感じです。 public class EventHandler ... public void handle (BankingEvent e) { housekeeping(e); } public class TransferEventHandler
オブジェクト指向設計入門 品質を追及する設計
2006.4.28 2 � � � � 1. 2. 3. 4. 5. 6. 4 � � � � � � � � � � � � � � 5 � � � � � � � � � 6 � � � � � � 7 � � � � � � 8 � � � � � � � � � � 9 � � � � � � � � � � � � � � � 10 � � � � � � � � � � � � � � � 11 � � � � � � � – – � � � � 12 � � � � � � � � � � � 13 � � � � � API � � � � � 14 � � � � � � � � � � 15 � � � � � � � � 16 � � � � � � � � � 17 � � � � � � � � � � � 18 � � � � � � � � 19 � � �
- 不吉な匂い
不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。 ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。 匂いとして示されているのは、次の２２のケースです。ひとつずつ見ていきましょう。 また、解決法に添えられている数字は、参考書籍「リファクタリング」の何ページに記されているかを示しています。
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
OOコード養成ギブス - rants
Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/kenokabe/items/13ea8d2da6adce1b3b9a
デザインパターン[モデリング] -TECHSCORE-