きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
2017年10月18日、James Coplienさんとその奥様であるGertrud Bjørnvigさんをお招きして、「Lean Architecture / DCI Evening 」というイベントを開催しました。日本ではソフトウェアパターンやアジャイルのリーダーとして知られるJames Coplienさんは、『 マルチパラダイムデザイン 』（1998年）でドメインとドメイン間の関係を中心に据えた設計パラダイムを提唱していました。Coplienさんは2009年、MVCアーキテクチャの考案者である Trygve Reenskaug さんと共に「DCIアーキテクチャ」を発表しました。2010年、CoplienさんはGertrudさんとともに書籍『 Lean Architecture 』を上梓、トヨタ生産方式をソフトウェアアーキテクチャに適用するリーンアーキテクチャについて、DCIアーキテク
This website uses cookies for account and order processing. By using this site you understand and agree to our use of cookies, our Terms Of Use, and Privacy Policy Alec Sharp, in the recent book Smalltalk by Example [SHARP], points up a very valuable lesson in few words: Procedural code gets information then makes decisions. Object-oriented code tells objects to do things. — Alec Sharp That is, yo
Tell-Don't-Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do. This encourages to move behavior into an object to go with the data. Let's clarify with an example. Let's imagine we need t
This blog post is outdated. Please read chapter “New OOP features besides classes” in “Exploring ES6”. Classes [1] are the major new OOP feature in ECMAScript 6 [2]. However, it also includes new features for object literals and new utility methods in Object. This blog post describes them. New features of object literals # Method definitions # In ECMAScript 5, methods are properties whose values
拙著「コーディングを支える技術」のp.216では、リスコフの置換原則について説明しています。しかし、p.217の「条件qを満たさないTが発生する」という表現はわかりにくいようですので、ここでストーリー仕立てにして補足説明をします 今日 まず、現時点でT型の値はすべて条件qを満たしているとします。 あなたはT型の引数をとる関数fを実装したいとします。あなたはきっと「T型の値はすべて条件qを満たしている」ということを前提としてコードを書くことでしょう。 1ヶ月後 あなたはSを作ろうと考えます。S型の値の中には条件qを満たさないものもありますが、あなたはあまり意識していません。 あなたは「SはTを継承して作ると楽だな」と思ったので、そうしました。 Javaなどの言語処理系では、SがTを継承すると、T型の変数にS型の値を入れることができるようになります。つまりこの時点でT型の引数を取る関数fにS型
オブジェクト指向でソフトウェアを実装していると、オブジェクトの生成に一連の手続きが必要なものがでてきます。このような生成に関する手続きがあちこちのソースコードへ散在すると、望ましくない状況になることは想像に難くないでしょう。この問題に対処するために、Simple FactoryやFactory Methodといったデザインパターンがあり、オブジェクトの生成に関する手続きや関連オブジェクトも含めたオブジェクトの構成（オブジェクトコンストラクション）に関する知識は1箇所にまとめるということが定石となっています。 しかし、単にファクトリーを導入するだけだと、オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります。このような試行錯誤の歴史から登場したのがDependency Injection(依存性の注入)パターンです。Dependency
prototype-based object oriented 。 オブジェクトがスロット（クラスのインスタンスならインスタンス変数やメソッドに相当）の追加をクラスに依存せずに自由にできることを前提としたオブジェクト指向。あるいはそうしたオブジェクトを用いたプログラミングや、それをサポートする機構。 「インスタンスベース」、「オブジェクトベース」とも。 これらへの言い換えは「プロトタイプベース」という言葉が持つ限定的なニュアンスを払拭するのにおおいに役立つ。しかし同時に、前者の「インスタンスベース」において特に、“プロトタイプベースにはクラスがない”あるいは“プロトタイプベースはクラスベースの対極にある（あるいはアンチテーゼである）”といったような教科書的記述に惑わされている人をひどく混乱させるらしく、極端な拒絶反応を示す人もいるので注意。また、後者においては、オブジェクトオリエンテッド＝
The Closure Library makes use of the pseudoclassical inheritance pattern, which is particularly compelling when used with the Closure Compiler. Those of you who have read JavaScript: The Good Parts by Douglas Crockford may use the functional pattern for inheritance that he espouses. Crockford appears to object to the pseudoclassical pattern because: "There is no privacy; all properties are public.
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く