More on getters and setters
More on getters and setters Build user interfaces without getters and setters It's a 25-year-old principle of object-oriented (OO) design that you shouldn't expose an object's implementation to any other classes in the program. The program is unnecessarily difficult to maintain when you expose implementation, primarily because changing an object that exposes its implementation mandates changes to
Why getter and setter methods are evil
Why getter and setter methods are evil Make your code more maintainable by avoiding accessors I didn't intend to start an "is evil" series, but several readers asked me to explain why I mentioned that you should avoid get/set methods in last month's column, "Why extends Is Evil." Though getter/setter methods are commonplace in Java, they are not particularly object oriented (OO). In fact, they can
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
実はオブジェクト指向ってしっくりこないんです。 - 無料でプログラミングを教えます日記
まえがき 1. 広く認知されているオブジェクト指向の一般論は存在しない。 2. ここでいうオブジェクト指向は、オブジェクト指向 2.0である。これはオブジェクト指向の歴史や世間一般で言われるオブジェクト指向完全無視のオブジェクト指向である。 オブジェクト指向の歴史 そんなものは後で学べばいい。 objectってどういう意味？ 対象という意味である。 じゃあ対象ってなによっていう話だが、 関数 f: A -> B であれば、dom(f) である A が対象（圏論で言われる対象とは別）、つまり object の集合 Object なのである。 いうまでもなく、A は 直積集合 であっても構わないし もっというなら集合である必要もない。 抽象データ型ってなに？ 抽象データ型とは dom(f) が Object の関数型の直和である。 Haskellであれば型クラスで表現できる。 たとえば Sta
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行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
モジュラリティを考える - Fly me to the Luna
ソースコードの分かりやすさは、「単一責務の原則」と「関心毎の分離」により適切に構造を分割した、バランスのいいところにあると前のエントリに書いた。では、そこにモジュラリティが加わるとどうなるだろうか。 モジュラリティとは、システムを幾つかのモジュール*1に分離し、さらに分離したモジュールを組み合わせて新しいシステムを組むソフトウェア開発法、とここでは定義する。分かりやすい例はEclipseだ。例えばPyDevを導入すればPythonの開発環境が手に入る。このように言語環境ごとに作られたプラグインを導入すれば、それぞれの言語で開発ができるIDEが構築できる。EclipseはIDEとして必要な機能の全てをプラグインという形のモジュールに分離し、組み合わせる事でモジュラリティを実現している。*2 モジュラリティの利点と欠点を上げてみよう。 利点 モジュール毎に独立して開発できる モジュールに分割で
クラスがメソッドの実行に必要なインスタンスを手に入れる方法色々 - 都元ダイスケ IT-PRESS
あるクラスが、メソッドによってある役割を果たすためには、別のインスタンスが必要なことが多い。ここでは、具体的にそのクラスを考え、そのインスタンスのを手に入れる方法を比較していこう。 ここでは、あるクラスをSqlExecutorとしよう。SQL文を受け取って、データベースのConnectionを使って実行するクラスだ。そして、SQL実行結果(ResultSet)をResultHandlerに渡して処理をする。さて、このクラスが責務を果たすためには「SQL文」「データベースConnection」「ハンドラ」の3つのインスタンスが必要だ。このクラスをいくつか書いて、比較してみよう。 どのインスタンスを、どのように受け取るかの違いだ。各インスタンスに対して、「setterで受け取る方法」「コンストラクタで受け取る方法」「メソッド引数で受け取る方法」がある。 A.全てsetterで受け取る方法 im
Concepts Principles - プログラミングの原則 - Concepts Principles - Top
ここはプログラミングの原則を集める Wiki です。巨人の肩に乗って、ふつうの人がよいプログラムを書くための指針を集めたいなと思ってます。 目次 よいデザインのための Concepts + Principles DRY (Don'tRepeatYourself) 名前重要 直交性 トラッシュではなくクラッシュ DuckTyping よいルーチンを書く 凝集性 結合性 契約による設計 (DesignByContract) ルーチンを作る正当な理由 よいモジュールを書く 適切なモジュール性を確保するために守らなければならない5つの原則 開放/閉鎖原則 (OpenClosedPrinciple) よいアプローチのための Concepts + Principles 曳光弾 可逆性
オブジェクト指向分析/設計概論
1 はじめに Javaプログラミングを行っていくうえで、大きな関門となるのはオブジェクト指向分析/設計でしょう。「クラスとオブジェクトの違いは」といった初歩的なものから、「再利用性を高めるためのフレームワークとコンポーネントの責任の配分の度合」といった高度なものまで、Javaプログラミングの要諦(ようてい)はオブジェクト指向分析/設計との関係の中にあるに違いありません。 Javaプログラマという立場からオブジェクト指向分析/設計を取り巻く状況を整理してみるのが本稿の目的です。 業界標準のオブジェクト指向モデリング言語であるUMLと、代表的なオブジェクト指向分析/設計プロセスであるユニファイドプロセス、そして最近発展が著しいパターン技術をベースにJavaプログラマに取ってのオブジェクト指向分析・設計の枠組みを総括してみました。 2 オブジェクト指向とは何か オブジェクト指向といえばクラスやイ
Rees Re: OO
著者: Jonathan Rees 原文: http://www.paulgraham.com/reesoo.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) これを翻訳したのは2004年7月頃だったのだが、 このメッセージについてRees氏に訳文公開の許可を求めたところ、 「あれは急いで書いたemailなので、きちんとした論になっていない。 できれば書き直したいと思っている。ただいつ出来るかわからないので、 私からのメイルがしばらく無かったら公開してもらって構わない」 との返事をもらった。それからもう半年経つので、公開することにした。 ただ、読む場合は著者本人が上記のように思っていることを留意して頂きたい。 また、原文が書かれたのは2002年であることにも注意。 いくつかの事実は古くなっているかもしれない。 2005/01/23 翻訳公開 「なぜAr
デザインパターンを読み解く
ポリモーフィズム（サブクラスによる切り替え、抽象化） ここに分類されるのは、オブジェクト指向の第３原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。＜参照＞ 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
Matzにっき(2003-07-29)
<< 2003/07/ 1 1. 星村麻衣 2. [生活]散財 2 1. [NTT]ADSL申し込み 2. [Ruby]1.8.0リリース前の作業 3. [OSCON]プレゼン準備 3 1. [OSCON]プレゼン準備 2. [Ruby]RCR 4 1. [OSCON]まだプレゼン準備 2. [本]Perl 6 Essentials 3. [Ruby]移植性 5 1. [OSS]「知的財産戦略」は、インターネット時代には似合わない 2. [生活]お風呂のお湯 6 1. [教会]ホームティーチング 2. [生活]デフレ 7 1. [OSCON]発表資料 2. [OSCON]資料間違い 3. [OSS]オープンソースには法的問題あり 8 1. [OSCON]旅立 2. [OSCON]プレゼン資料改善 3. [本]『4488663052』 4. [OSCON]到着 9 1. [OSCON]The
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Getters and setters: evil or necessary evil? — Berry Langerak
bliki: Getter Eradicator
継承にかかわる諸問題
オブジェクト指向と非オブジェクト指向の境界 - DoMshi