あなたのコードを[賢く]する デザインパターンJavaプログラミング

概 要

ワンランク上のJavaコードを書く上で、見通しのよい、再利用性の高いコーディングに不可欠なのが「デザインパターン」です。本書はデザインパターンを用いたJavaプログラミングの実際を「どのようなパターンを」「どのようなシチュエーションで」「どのように用いるか」まで、著者の豊富なプログラミングノウハウをもとに詳細に解説しました。添付CD-ROMには各種サンプル・ツール付き。

著者 杉浦K.
価格 本体2800円(税別)
ISBN 4-7980-1106-1
発売日 2005/07/09
判型 B5変
色数 1色
ページ数 400
CD/DVD Windows
対象読者 中級
シリーズ
表紙イメージ
購入 アマゾンで購入する

※リンク先によっては、販売ページが用意されていないことがあります。 あらかじめご了承ください。

新しいウィンドウで開く 書籍購入のご案内

サポート

現在サポート情報はありません

目次

Chapter1 デザインパターンって一体何?

1.1 そもそもデザインパターンって?

1.2 オブジェクト指向設計

 ~あれ、これって意外に難しい!?

1.2.1 「クラス」って難しい??

1.2.2 オブジェクト指向設計とは

1.2.3 「継承」を活用する

1.3 柔軟性のあるソフトを目指して

 ~再利用:ソフトウェアってホントに「柔らかい」?

1.3.1 たとえばソートだと?

1.3.2 インターフェイスを活用する

1.3.3 結合度を下げる

1.3.4 クラスの「粒度」に気を配る

1.3.5 抽象 vs 具体

1.4 こんなにある! デザインパターンを学ぶメリット

Chapter2 デザインパターンのメリットを味わおう

2.1 たかがソートだって奥深い...

2.2 パターンを使わない力任せの悪いコードから...

2.3 まずは「Command」パターンによる改良

2.4 こんなによくなる! パターンを使った改良

 ~Factory Method

2.5 Javaの特徴を生かす

 ~動的ローディングによるSimple Factory(Builder)

2.6 抽象基底クラス=Template Method

2.7 結果の取得はIteratorで

2.8 まとめ:デザインパターンって面白い!

Chapter3 いろいろなデザインパターン

3.1 デザインパターンにはいろいろある!

3.2 GoFのデザインパターン

3.2.1 生成に関するパターン(Abstract Factory、Builder、

Factory Method、Prototype、Singleton)

3.2.2 構造に関するパターン(Adaptor、Bridge、Composite、Decorator、Facade、Flyweight、Proxy)

3.2.3 振る舞いに関するパターン(Chain of Responsibility、

Command、Intepreter、Iterator、Mediator、Memento、Observer、State、Startegy、Template Method、Visitor)

3.3 GoF以外の有名なデザインパターン

3.3.1 MVC(Model-View-Contoller)

3.3.2 スレッドデザインパターン

3.3.3 J2EEデザインパターン

3.3.4 ロギングデザインパターン(N.Harrison

「Patterns for Logging Diagnostic Message」)

Chapter4 本書で扱うサンプルの説明

 ~対戦型五目並べ

4.1 対戦型五目並べについて

 ~具体的サンプルで、デザインパターンのメリットを体感!

4.2 対戦型五目並べの概要

4.3 対戦型五目並べの遊び方

4.4 対戦型五目並べの発展型の紹介

4.5 仕様とゲームのルール

4.6 開発プロセス

4.7 ディレクトリ構造の概略

Chapter5 まずは部品づくり~汎用ライブラリで使えるデザインパターン

5.1 プログラム全体でリソースを共有する

 ~汎用プロパティクラス(Singleton/Adaptor)

5.1.1 アプリケーションでのリソースの共有の問題

5.1.2 Singletonとは?

5.1.3 仕様の検討

5.1.4 JUnitによる単体テスト

5.1.5 便利な仕様の追加~プロパティの取得

5.1.6 便利な仕様の追加~プロパティのセット

5.1.7 Singletonの体質強化作戦~まずsynchronized

5.1.8 Singletonの体質強化作戦~アプリ≠JVM

5.2 データ保存方法をいろいろと差し替える

 ~JDBC、XML、EJBでも自由自在(Strategy/Singleton)

5.2.1 これからの時代は「戦略」がなくっちゃね!

5.2.2 Strategyの検討

5.2.3 Singletonと派生クラスの問題

5.2.4 Persistenterのクラス構成

5.2.5 ひな形~FakePersistenter、GomokuFakePersistenter

5.2.6 データベースによる永続化~JDBCPersistenter、GomokuJDBCPersistenter

5.2.7 XMLファイルによる永続化~XMLPersistenter、GomokuXMLPersistenter

5.2.8 JUnitによるテスト

5.2.9 まとめ:Singletonのメリット・デメリット

5.3 行列に並ぶより宅配便で

 ~汎用タイマライブラリ(Observer)

5.3.1 AWT(Swing)とObserver

5.3.2 Observerパターンの要素

5.3.3 汎用タイマ・ライブラリ~仕様の検討

5.3.4 テスト・プログラム

5.3.5 TimerEventの実装

5.3.6 Timerクラスの検討~マルチキャスト・コールバック

5.3.7 TimerCallbackクラスの実装

5.3.8 Timerクラスの実装

5.3.9 まとめ:タイマの性能チェック

5.4 一緒に使うものは一緒にしておこう

 ~ソケットライブラリ(Facade/Decorator)

5.4.1 前提知識:サーバ・クライアントモデルのプログラミング

5.4.2 ソケット利用の問題点~Facadeパターンによる解決

5.4.3 読み書きロギング~Decorator

5.4.4 「合わせ技」を可能にするアイデア~ヒントはjava.ioに?

5.4.5 まず「Decorator」の動作を理解する

5.4.6 Decoratorの実装

5.5 難しければコピーせよ

 ~アプレットでも強いログユーティリティ(Bridge/Prototype)

5.5.1 いろいろなロギング・ライブラリ

5.5.2 橋がかかって便利になる~Bridge

5.5.3 「ログレベル」を理解しよう!

5.5.4 Log4j用の「橋」はLog4jLog

5.5.5 JDK 1.4用のJDK14LogとビルトインのSimpleLog

5.5.6 基底クラスLoggerにすべてお任せ

5.5.7 Prototypeはこう使え!

5.5.8 利用例~sug.util.socketIO.LogBridgeIOSocket

Chapter6 クラス分割にデザインパターンを使う

 ~メインプログラムではこう使え!

6.1 AWTだろうがSwingだろうがSWTだろうが...(Abstract Factory)

6.1.1 起動のしかたは1つじゃない!

  ~メインプログラムのいろいろな種類

6.1.2 クライアント起動方法

6.1.3 必要なウィジットをまず確認

6.1.4 インターフェイスを定義しよう

6.1.5 部品工場~Abstract Factory

6.1.6 アプレット版のメインクラス

6.1.7 スタンドアロン版のメインクラス

6.1.8 SWTだとさらに違いが...

6.1.9 まとめ:メインプログラム関連クラス図

6.2 いちばんよく知っているのはやはり本人

 ~GUI部品クラス(Observer再び/Command)

6.2.1 GUI部品とカプセル化

6.2.2 Controls派生クラス

6.2.3 スレッド・ポリシー

6.2.4 スレッドポリシーの解決~無名内部クラスで

6.2.5 スレッドポリシーの真の解決~Command風のObserver

6.2.6 SafeInvokerの構造

6.2.7 カスタム・ウィジットBoardImage派生クラス

6.2.8 ダイアログJumpDialog派生クラス

6.3 Mediatorはチームの司令塔(Mediator)

6.3.1 Mediatorとは?

6.3.2 「対戦型五目並べ」のMediator

6.3.3 sug.gomoku.client.Mediator~クラス宣言部分

6.3.4 sug.gomoku.client.Mediator~コンストラクタ

6.3.5 sug.gomoku.client.Mediator

  ~Mediatorとしての中継インターフェイス

6.3.6 sug.gomoku.client.Mediator~コールバック

6.3.7 sug.gomoku.client.Mediator~終了関連

6.3.8 SWT版Mediator~継承による作成

6.4 「昼の顔」と「夜の顔」の違う人

 ~状態遷移機械(State)

6.4.1 状態遷移機械とは

6.4.2 「対戦型五目並べ」の状態遷移機械

6.4.3 「状態遷移図」を「状態オブジェクト」に渡す

6.4.4 基底クラス兼終了状態~sug.gomoku.client.Status

6.4.5 「自分の番」の状態~sug.gomoku.client.SelfStatus

6.4.6 「相手の番」の状態~sug.gomoku.client.PartnerStatus

6.5 正しい責任転嫁のしかた

 ~細かいことは派生クラスに聞いてね(Visitor/Immutable)

6.5.1 通信関連クラスの相互関係

6.5.2 通信スレッド~sug.gomoku.client.CommThread

6.5.3 Visitorデザインパターンを導入すべき理由

6.5.4 Visitorによる「責任転嫁」

6.5.5 通信オブジェクト基底クラス

  ~sug.gomoku.comm.CommItem

6.5.6 CommItem派生クラスたち

6.5.7 Immutableなクラス

6.6 ケチケチ生活

 ~インスタンス生成を節約!(Builder/Flyweight)

6.6.1 わざわざ「クラスを作るだけのクラス」を作るの!?

6.6.2 CommItemBuilderの出発点~継承を可能にする

6.6.3 面倒な生成プロセス~生成すべきクラスに任せよう

6.6.4 以前作成したインスタンスを再利用する~Poolモデル

6.6.5 Immutable性と「Flyweightパターン」

6.6.6 リフレクション機能

6.6.7 CommItemBuilder完成版

6.7 縦横無尽! 

 ~ルール判定クラス(二次元Iterator)

6.7.1 ルール判定クラスの概要

6.7.2 「盤面のスキャン」を抽象化するRuleIterator

6.7.3 RuleIteratorの実装

6.7.4 マルチスレッド環境とIterator

6.7.5 Iterator側でマルチスレッドに対応する

  ~バージョン付きIterator

6.7.6 Iterator側でマルチスレッドに対応する

  ~スナップショットIterator

Chapter7 再利用の実例~たとえばゲームがオセロだったら?

7.1 主要な変更点

7.2 変更ソース一覧

7.3 遊びかた

コラム デザインパターンって難しい…

コラム 「Commandオブジェクト」を作る

コラム テスト文化とデザインパターン

コラム クラスの共有範囲

コラム クラスメソッドと継承

コラム Chain of Responsibilityでもある!?

コラム サーバの起動方法とプロパティ

コラム アプレット固有の問題

コラム 実験してみよう!

コラム JDK 5.0で追加されたGenericsの機能

PR

秀和システム