オブジェクト指向 の検索結果 - きしだのHatena
オブジェクト指向言語の話をするときに便利なように、Javaを中心にプログラミング言語をまとめてみました。 Javaに影響与えるか、Javaから影響を受けるか、という感じですね。 Simula オブジェクト指向はここから始まったと言われています。 クラス、オブジェクト、継承、仮想関数(多態)といった、オブジェクト指向の基本要素が備わっていました。 ただし、「オブジェクト指向」という言葉は生まれていません。 Smalltalk Simulaから発想を得て「オブジェクト指向」という… …ろいろ分類した本で、オブジェクト指向言語とはどういう位置づけになるのかという話をするときに確認してもらいたいんだけど、いま中古で4万円。 「アルゴリズムデザイン」も一時絶版状態で、12万とかで売られてるのを見た。 いまは在庫復活して17,000+税になっているけど、買ったときは15,000+税だったな。Amazo
Table of Contents · Game Programming Patterns
Table of Contents Game Programming Patterns Acknowledgements Introduction Architecture, Performance, and Games Design Patterns Revisited Command Flyweight Observer Prototype Singleton State Sequencing Patterns Double Buffer Game Loop Update Method Behavioral Patterns Bytecode Subclass Sandbox Type Object Decoupling Patterns Component Event Queue Service Locator Optimization Patterns Data Locality
コードの臭い - リファクタリングの必要性を示す兆候
重複したコード (Duplicate Code) 同じようなコードの並びが、複数の場所で見られる。 長すぎるメソッド (Long Method) メソッドが長くて理解しづらい。 巨大なクラス (Large Class) インスタンス変数を持ちすぎている。コード量が多すぎる。 多すぎる引数 (Long Parameter List) 引数が多くて、それらの意味がわかりにくくなっている。 変更の発散 (Divergent Change) 1つのクラスがさまざまな変更要求の影響を被る。 変更の分散 (Shotgun Surgery) 1つの変更がさまざまなクラスの変更を引き起こす。 属性・操作の横恋慕 (Feature Envy) 他のクラスの属性やメソッドを使いすぎる。 (これは他のクラスに強く関連していることを意味します) データの群れ (Data Clumps) いつも一緒に使われるデータ
猫型プログラミング言語史観(2) 〜あるいは実行コンテキストにどう立ち向かうのか〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
前回のおさらいと今回の話 前回は手続き型パラダイムとオブジェクト指向パラダイムを見比べたときに、「ひとかたまりのデータとそれを操作する手続きを一カ所にまとめて守る」という方向に言語が進化していったというひとつの史観を示しました。その中で返答として「構造化プログラミング」の時点でその視点はすでにあるという指摘を頂いたりもしました。ただ、「ひとかたまりのデータとそれを操作する手続きを一カ所にまとめる」という発想もオブジェクト指向の「ひとつの側面としては」たしかにありますし、その側面を見ると、オブジェクト指向言語に「言語デザインでもってプログラマーがそれを行いやすくした」という面を見いだすことができそうです。そして、その視点に立ったときに「臭ってくる」ヤバい設計として、「データが露出してる」「別のクラスのデータいじってる」「複数の異なるデータに関心をもってしまっている」というものを挙げてみました
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
教える側が知らないプログラミングの３つのこと
一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？
Head First Object-Oriented Analysis and Design