オブジェクト指向できていますか？3. 自己紹介 1992年～1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在 日本工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。
非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS
まず、以下に持論を展開するにあたって、自分の立ち位置を明確にしよう。自分は「Webアプリケーション開発者」としてではなく「JavaによるWebアプリではない（デスクトップアプリ,コマンドラインアプリ,ライブラリ）アプリの開発者」として語る。まぁ、自分に一番馴染みの深いプロダクトとしてJiemamyが挙げられるわけだが、こいつはWebアプリじゃない。Eclipse上で動くアプリケーションであり、そしてMaven2によって呼ばれるCLIアプリでもあり、また、クラスライブラリである。 この視点からJavaにおけるチェック例外と非チェック例外の話を再び。 Javaにおけるthrows句は、メソッドシグネチャの一部であり、インターフェイスにも現れる情報である。今まで「Javadocは仕様だ」と言い続けて来たが、正確にはインターフェイス（シグネチャ＋Javadoc）が仕様だ。*1 検査例外が使いにくい
第4回 JavaScriptでオブジェクト指向プログラミング
（2）プロトタイプ・オブジェクトの変更はリアルタイムに認識 プロトタイプ・オブジェクト配下のメンバが（インスタンスにコピーされるわけではなく）暗黙的な参照を通じて、必要都度にアクセスされるという事実には、もう1つ大きなメリットがある。それは、インスタンスを生成した「後」に、基となるプロトタイプ・オブジェクトにメンバを追加した場合にも、これを認識できるという点である。 例えば、以下のような例を見てみよう。 var Animal = function() {}; Animal.prototype.name = "サチ"; var anim = new Animal(); Animal.prototype.sex = "メス"; // インスタンスの生成後にメンバを追加 window.alert(anim.sex); // 「メス」 もっとも、この性質は、先ほどの「暗黙的な参照」を理解していれば
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
いまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味について - 達人プログラマーを目指して
正しく意味を理解している方にとっては、まったく常識レベルの話であり、何をいまさらと思われる方々も多いかと思いますが、大規模案件のレガシーコードなど、私が仕事で見かけるJavaのコードを読むと、「このコードを書いたSEやPGの方々は、はたして継承の意味を正しく理解していないのではないか」と思われる設計のコードに出会うことが少なからずあります。現在では改良されましたが（Javaプログラミング能力認定試験の問題がかなり改善されていました - 達人プログラマーを目指して）、以前のJavaプログラム認定試験の問題は、そうした不適切な設計がされている典型的な例となっていたのですが、実際、SI業界ではあのような品質のコードのシステムが今でも現役で多数稼動しているというだけでなく、現在でも新たに生み出されているというのは残念ながら紛れもない事実のようなのです。 確かに新人研修で「哺乳類を継承して犬クラスと
ドメイン駆動設計・俯瞰編 - Strategic Choice
書籍「エリック・エヴァンスのドメイン駆動設計」にある全パターンを、３枚の俯瞰図にまとめます。ボリューミーなこの本を攻略するのに、この本自身にある「大規模な構造（第16章）」という戦略に倣おうと考えたからです。巨大なシステムに包括的な原則がなく、そのせいで各要素を解釈する際に、設計全体にまたがるパターンにおいてどのような役割を果たすかという観点から考えることができなければ、開発者は「木を見て森を見ず」になってしまう。全体の詳細を徹底的に調べなくても、全体の中で個々の部分が果たす役割を理解できる必要があるのだ。「大規模な構造」は、システムをおおよその構造から議論し、理解できるようにするための言語である。第16章 大規模な構造 P447-448「パターン」の仔細を見る前に、各々の「コンテキスト」の中での「立ち位置」をわかっておいたほうが、理解が「速い」し「深まる」と思います。まず「全体における部
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
[ 技術講座 ] Domain-Driven Designのエッセンス -目次-｜オブジェクトの広場
［技術講座］ DDD難民に捧げる Domain-Driven Designのエッセンス 第 1 回 ドメイン駆動設計とは 第 2 回 DDDの基礎と実践 第 3 回 大規模なプロジェクトへの適用 DDDパターンカタログ パターン名 参考訳 I. Putting the Domain Model to Work Ubiquitous Language ユビキタス言語 Model-Driven Design モデル駆動設計 Hands-On Modeler 実践的モデラー II. Building Blocks of a Model-Driven Design Layered Architecture 層状アーキテクチャ Smart UI （アンチパターン） 利口なUI Entities エンティティ Value Objects 値オブジェクト Services サービス Modules モジ
- 不吉な匂い
不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。 ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。 匂いとして示されているのは、次の２２のケースです。ひとつずつ見ていきましょう。 また、解決法に添えられている数字は、参考書籍「リファクタリング」の何ページに記されているかを示しています。
アジャイルモデルのエッセンス: アジャイルに作れる成果物
by Scott W. Ambler, Copyright 2003 効果的にアジャイルモデリングを行うには、さまざまな種類のモデリング手法を知っておく必要があります。残念ながら、これは口で言うほど簡単なことではありません。このページはまだ作成中ですが、さまざまなモデリング成果物の概要へリンクしています。各ページには、その成果物についの解説と、1、2の例、推奨文献へのリンクが含まれています。 モデリング成果物 ビジネスルール ビジネス/本質ユースケース 変更案 CRC(Class Responsibility Collaborator)モデル 制約事項 取り決めモデル データフロー図(DFD) 本質/ビジネスユースケース 本質ユーザインターフェースプロトタイプ ユーザ機能 自由形式の図 フローチャート 用語集 Logical Data Model (LDM) ネットワーク図 オブジェクトロ
憂鬱本を買ってみました - みねこあ
javablack さんが最近とりあげ、 ちょっとだけ話題再燃したの憂鬱本 こと「憂鬱なプログラマのためのオブジェクト指向開発講座」。以前借りて読んだことがあるのですが、「酷いわ」と思ったこと以外具体的なことは何も覚えていません(^^; で、具体的になにが酷かったのかのかな？とザザッとWebを流してみたのですが、見つからない。というか「これはいい本だー」という感想ばっかりで、予想以上に「酷い」というレビューがないのに改めてビックリです。 むー、これはネチっこいレビューの需要があるかな？とスケベ心をだして買ってしまいましたョ。 憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) 作者: Tucker出版社/メーカー: 翔泳社発売日: 1998/05/31メディア: 大型本購入: 10人 クリック: 508回この商品を含むブログ (78件) を見る で、改めて読み
『オブジェクト指向講座 スタック領域とヒープ領域』
令和からの働き方について -TownSoft- 元「傲慢SE日記」で、しばらく放置していました。 2020年からはこれからの働き方などについて書いて行こうかと思います。 本カテゴリーは手続き型言語になれている人がどうやったらオブジェクト指向を理解できるのかを考えて書いている記事です。 多少の言語知識があることを前提に進めます。 C#やJava等の言語では肝となる部分です。 この概念が分からないとガベージコレクションの概念が分かりません。 そして、この概念を持っているとオブジェクト指向の理解が早まります。 さて、スタック領域は皆さん知っているはずです。 特にC言語を使っている方はお手の物のはずです。 なぜなら、 普段使っている領域 ですから。 まぁ、順を追って一つずつ解決していきましょう。 まず。ポインタの概念からゆっくりと解決していきましょう。 int i = 0; この書式はint型のi
派遣PG時代の思い出
@vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。 2010-05-11 12:42:06
今からでも遅くない これから始めるScala（前編）
なぜ、いまScalaなのか？ TwitterがScalaを利用しているのは有名ですが、他にも位置情報を利用したfoursquareはScalaで構築されたLiftというWebフレームワークを利用していますし、GTDツールとして有名なRemember The MilkもScalaの利用を検討しているようです。 Scalaは、Java Virtual Machine（以下JVM）上で動くオブジェクト指向＋関数型言語です。簡潔で柔軟な記述が可能であり、マルチコアを意識したライブラリがあり、JVMでのスケールメリットを享受できることが、これらの企業で採用に踏み切った理由であると考えられます。 Scalaは、非常にバランスの取れたプログラミング言語です。本連載では、Scalaの基本的な文法を解説しながら、オブジェクト指向と関数型言語を組み合わせたプログラミングスタイルについて、解説したいと思います。
ソフトウェア工学 (吉田誠一のホームページ)
Abstract Factoryパターン Adapterパターン Bridgeパターン Builderパターン Chain of Responsibilityパターン Commandパターン Compositeパターン Decoratorパターン Facadeパターン Factory Methodパターン Flyweightパターン Interpreterパターン Iteratorパターン Mediatorパターン Mementoパターン Observerパターン Prototypeパターン Proxyパターン Singletonパターン Stateパターン Strategyパターン Template Methodパターン Visitorパターン
翔ソフトウェア (Sho's) - オブジェクト指向 - 書籍/雑誌
書籍 オブジェクト指向全般 開発プロセス UML ソフトウェア パターン オブジェクト指向全般 ■ 憂鬱なプログラマの為のオブジェクト指向開発講座 C++ による実践的ソフトウェア構築入門 翔泳社 Tucker! 著 定価(本体 ¥3,200【税別】) ・入門用に是非読んでおきたい． 抽象的に成り勝ちなオブジェクト指向開発技法の説明を C++ を使って具体的に解説． ■ オブジェクト指向方法論OMT トッパン ランボー，J. 著/羽生田 栄一 監訳 B5変型判 544頁 本体価格(税別):¥6,214 ISBN: 4-8101-8527-3 ・OOA/OOD 技法 OMT の教科書 ■ オブジェクト指向がわかる本 Ohmsha オーム社 東京国際大学 教授 佐藤 英人 A5判 136頁 定価(本体 ¥1,600【税別】) 1998/04 ISBN: 4-274-07858-2 ■ まるごと
POA、DOAとオブジェクト指向 - だるまのエクセルVBA
オブジェクト指向を勉強している人は、POA(プロセス中心アプローチ)やDOA(データ中心アプローチ)（※１）という言葉を聞いたことってある？ オブジェクト指向関連の本を見てもPOAやDOAについてはあまり書かれていないみたい。 でも、オブジェクト指向を勉強するときはPOAとDOAについて多少理解（最低でもPOA、DOAの特徴と欠点）していないとまずいです（※２）。 ということで、ここではPOAとDOAについて、いい加減に説明し、その後、それらとオブジェクト指向の関連について適当に説明します（※３）。 ※１：POA、DOAは情報処理技術者試験のソフトウエア開発技術者の試験範囲なので合格を目指している人は勉強した方が良いです。 （実はオブジェクト指向も試験範囲だったりする。） ※２：特にPOAやDOAの欠点を理解することは大事です。 欠点を理解していないとオブジェクト指向で開発し
Strategic Choice
Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき？「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする？「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン
DOAの新刊2冊紹介：An Agile Way：オルタナティブ・ブログ
今日は、DOA(データ中心アプローチ) の新刊を2冊紹介します。 まず、株式会社データアーキテクト、真野正さんの、 『独習データベース設計』 真野さんはこれまでも『実践的データモデリング』など、良質で、現場で使えるDOAの本を書かれています。今回は、DOAの初歩から分かりやすく解説された本で、まさに、「独習」できる。 DFDや、ERDとDFDのCRUDのところで、astah* が紹介、使われています。また、こっそり、マインドマップも使われています。 （※ところで、先日セミナーにて、DFDを多様するのだが、外部エンティティとストアを、直接結びたいケースがあって、でも、astah* だと、間にプロセスを挟まないと書けない。簡略記法を許してくれてもいいのに、というご意見を頂いた。なぜ外部エンティティとストアを直接結んではいけない、というDFDの仕様になっているのか、もしご存知の方は教えてください
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Press Enter■