意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
「現場で役立つシステム設計の原則」批判 (2) ～ポリモーフィズムは何のために？～
増田亨氏の「現場で役立つシステム設計の原則]」批判の第２編です。 （２）ポリモーフィズムは何のために？オブジェクト指向の要件本書には「変更を楽で安全にするオブジェクト指向の実践技法」というサブタイトルが付与されています。オブジェクト指向が何かという点については、論者によって違いはあるものの、以下の３つが要件とされることには、多くの人が合意するでしょう。 カプセル化インヘリタンス（継承）ポリモーフィズム（多態）前回で明らかになったように、カプセル化は、オブジェクト指向とは独立にモジュール分割の指導原理としてデイビッド・パーナスにより提唱された「情報隠蔽」を敷衍したものです。オブジェクト指向の要件ではありますが、オブジェクト指向固有のアイデアではありません。 インヘリタンスは便利な機能ですが、コンポジションや移譲により代替できるので、オブジェクト指向の本質的な要件とは見做されなくなってきたかと
Design Patterns and Refactoring
Hello, world! I'm SourceMaking. I will tell you a lot of stories about good software architecture and teach you how to create it with design patterns. I will guide you through anti-patterns, common pitfalls and mistakes that people make when they plan, create, and manage software projects. In the end, I will teach you how to smell a bad code and improve it with refactoring. We can start from the v
オブジェクト指向エクササイズのススメ
3. ThoughtWorksアンソロジー ThoughtWorks社コンサルタント ● の 骨太なエッセイ集 様々な ジャンルを収録 ● DSL、プログラミング、設計、 マネジメント、ビルド、デプロイ、テス ト．．． オライリーさんブースで ● 絶賛販売中！ 3
Syn の独り言 : 継承か委譲か、それが問題だ - livedoor Blog（ブログ）
April 01, 201323:55 カテゴリプログラム 継承か委譲か、それが問題だ この記事は新ブログに引っ越しました。 Where is the mate to the Sock! 「プログラム」カテゴリの最新記事 タグ ：#委譲#継承#delegate#inheritance#多重継承#菱形継承#オブジェクト指向
置き場所に困るドメインロジック | システム設計日記
このロジックは、このデータといっしょにいるべき 前の記事で取り上げた date.isSummer() platform.isMacOS() に至るリファクタリングでは、ビジネスルールの置き場所は、わりと簡単に見つかりました。 ケント・ベックの「オブジェクトとは何か」のシンプルな説明、 "This data goes together and this logic goes with it" をそのまま実践しただけです。 既存オブジェクトへロジックを移動する date オブジェクトは最初からドメインモデル上に存在していた。 isSummer() 判定ロジックに必要なデータは、 date オブジェクトが持っている。 そのデータのそばに、ロジック（メソッド）を移動する。 簡単だけど、しぶいリファクタリングネタですね。 変数をオブジェクトに昇格してからロジックを移動する platform は、元々
ビジネスロジックの置き場所の改善 | システム設計日記
前の記事で、コードの中に埋もれていたビジネスのロジックを、 ・変数名 ・メソッド名 で具体的に表現するコードの改善について書きました。 ドメイン（問題領域）の知識を、コードでうまく表現する、というドメイン駆動設計の基本プラクティスです。 とても、大切な習慣だけど、メインイベントはこれから。 パラメータ渡しは、リファクタリングのヒント 前の記事の例だと、if( isSummer( date ) ) は、たぶん、予約サービスクラスでトランザクションスクリプトとして書かれている。 予約サービスクラスには、こういう判定や、夏季特別料金を計算する summerCharge() メソッドなどが、いろいろ記述されているはず。 isSummer( date ) のように、パラメータ付きの判定メソッドは、ドメインロジックの置き場所を議論する格好のネタです。 条件判断メソッドにパラメータを渡す場合、機械的に、
コードの中のビジネスルール | システム設計日記
ビジネスルールの大半は「制約」とか「不変条件」である。 ビジネスアプリケーション開発では、このビジネスルール(制約）のモデリングと設計・実装が重要な関心事のひとつ。 モデルに記述する？ 制約をモデルで表現する手段に、OCL ( Object Constraint Language )がある。 詳細に知らなくても、 { quantity > 0 } (数量は１以上） というような、波括弧 ( ブレース ) での表記は、UML 図で時々みかける。 でも、クラス図とかでは、あまり使わない。 OCL を書くより、Java とかプログラミング言語で、直接 if 文を書いちゃうほうが、二度手間にならないから。 モデル駆動設計といっても、業務アプリのこういう細かな制約ルールとかを、クラス図に詳細に書き込むメリットは、ないと思います。 コードの中に埋もれたビジネスルール 単純化すれば ・ if ○○ th
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Head First Object-Oriented Analysis and Design