読者です 読者をやめる 読者になる 読者になる

kyosho5’s blog

貧乏で数学があまり得意ではない理系出身のエンジニアのブログ

デザインパターン勉強メモ⑨

第17章 Observerパターン

観察対象の状態が変化したときに、観察者に通知され、状態変化に応じた処理を記述する。

・Subject役
→観察される側。観察者であるObserver役を登録するメソッドと削除するメソッドを持つ。
また、現在の状態を取得するメソッドを持つ。

・ConcreteSubject役
→具体的な観察される役。状態の変化を登録されているObserver役に伝える。


第18章 Mementoパターン

インスタンスの状態を表す役割を導入して、カプセル化の破壊に陥ることなく保存と復元を行うパターン
インスタンスへ不用意にアクセスを許してしまい、そのクラスの内部構造に依存したコードがプログラムのあちこちに分散してしま
クラスの修正がしにくくなることをカプセル化の破壊という。

Mementoパターンを用いて、プログラムに対して
undo、redo、history、snapshotを行うことができる。

・Originator役
→自分の現在の状態を保存したいときにMemento役を作る。
以前のMemento役を渡されると、そのMemento役を作ったときの状態に戻る処理を行う。

・Memento役
→Originatorの内部情報をまとめる。その情報は誰にでも公開するわけではない。Memento役は以下のインタフェース(API)を持っている。
wide interface
→オブジェクトをもとの状態に戻すために必要な情報がすべて得られるメソッドの集合。Memento役の内部情報をすべてさらけ出してしまうため、Oiriginator役のみが扱える。

narrow interface役
→外部のCaretaker役に見せる。できることに限りがあり、内部状態が外部に公開されるのを防ぐ。
できることが少ない=narrow

以上の使い分けによって、オブジェクトのカプセル化の破壊を防ぐことができる。

・Caretaker役
→現在のOriginator役の状態を保存したいときに。そのことをOriginator役に伝える。Originator役はそれを受けてMemento役を作り、Caretaker役に渡す。
Caretakerは将来の必要に備えて、そのMemento役を保存しておく。
narrow interfaceしか使えないので、Mementoの内部情報にアクセスすることはできない。作成されたMementoをブラックボックスとして保存しておくことのみができる。(Memento役はCaretaker役に対して情報隠ぺいを行っている。)

Mementoをメモリ上だけでなくファイルとして保存しておく際には、将来の改修やバージョンアップの際に整合性が取れなくなる可能性があるので賞味期限を考慮する必要がある。

CaretakerとOriginatorを分けることで役割分担が実現できる。
OriginatorはMementoの作成と、与えられたMementoを使って自分の状態を元に戻すということのみに限っているため、
undoの方法などを変更するときに変更の影響を受けない。

デザインパターン勉強メモ⑧

第15章 Facadeパターン

複雑に絡み合っている詳細をまとめ、高レベルのインタフェース(API)を提供する。

・Facade役
→システムを構成しているその他大勢の役のシンプルな窓口となる。高レベルなインタフェース(API)をシステム外部に提供する。

・その他大勢の役
→それぞれ自身の仕事をするが、Facade役のことは意識しない。
Facade役から呼び出されて仕事をするが、その逆は起こらない。

・Client役
→Facadeパターンを利用する役


システムが大きくなるにつれてその複雑さは増大していくが、裏方のクラスの関係やその使い方などを意識しないで済むようこのパターンを使う。
インタフェース(API)を少なくすることが大事。(外部との結合が疎になる→パッケージを部品として再利用しやすくする。)
Facade役をもったクラスが複数個ある場合に、それらをまとめたFacade役を導入することも可能。

第16章 Mediatorパターン

処理内で全体に波及する出来事が起こった場合は相談役を介して大局的な判断を仰ぎ、相談役からの指示を受けて処理を実施する。
多数のオブジェクトの間の調整を行う必要があるときにはこのパターンを使う。
個々のオブジェクトが互いに通信しあうのではなく、相談役をとのみ通信を行う。
実際のロジックは相談役の中にのみ記述する。

・Mediator役
→Colleague役と通信を行い、調整を行うためのインタフェース(API)を定める。

・ConcreteMediator役
→Mediator役のインタフェース(API)を実装し、実際の調整を行う。・
アプリケーションへの依存度が高いロジックを実装したコードが集中しているためため再利用しにくい。

・Colleague役
→Mediator役と通信を行うためのインタフェース(API)を定める。

・ConcreteColleague役
→Colleague役のインタフェース(API)を実装する。
アプリケーションへの依存度が高いコードがないため再利用しやすい。

本来オブジェクト指向では処理を分散させるように実装することが多いが、今回のような場合は処理を各クラスに分散させると
デバッグや修正、機能追加などが大変になる。
各クラスに分散させるものと1クラスに集中させるものをうまく分ける必要がある。

デザインパターン勉強メモ⑦

第13章 Visitorパターン

データ構造と処理を分離し、データ構造の中を巡り歩く主体である訪問者をあらわすクラスを用意し、
そのクラスに処理を任せる。

・Visitor役
→データ構造の具体的な要素(ConcreteElement役)ごとに「XXXXを訪問した」というvisit(XXXX)メソッドを宣言する。
実際のコードはConcreteVisitor役の中に書かれる。

・ConcreteVisitor役
→ Visitor役のインタフェース(API)を実装する。
visit(XXXX)という形のメソッドを実装し、個々のConcreteElement役ごとの処理を記述する。
具体的な処理はすべて個々に記述できてしまうので、新しいConcreteVisitor役を追加するのは容易である。
(ConcreteElement役を修正する必要がない)

・Element役
→Visitorの訪問先を表す役。訪問者を受け入れるacceptメソッドを宣言する。引数はVisitor役。

・ConcreteElement役
→Element役のインタフェース(API)を実装する役
新しいElement役を追加するときにVisitorクラスのサブクラスすべてに新たなvisit()メソッドを
追加しなければならないため追加が難しい。

・ObjectStructure役
→Element役の集合を扱う役。
ConcreteVisitor役が個々のElement役を使えるようなメソッドを備えている。


データ構造の中に処理を記述せずに分離させるのがVisitorパターンの狙いである。
FileクラスやDirectoryクラスの部品としての独立性を高めることができる。

OCP(Open-Closed-Principle)
→既存のクラスを修正することなく拡張できるようにせよ。

第14章 Chain of Responsibilityパターン

複数のオブジェクトを鎖のようにつないでおき、順次渡り歩いて要求を処理するオブジェクトを決定する

・Handler役
→要求を処理するインタフェース(API)を定める役
たらいまわし先のオブジェクトを保持しておき、自分で処理できない要求が来たらそのオブジェクトにたらいまわしする。
次のオブジェクトもHandler役である。

・ConcreteHandler役
→要求を処理する具体的な役

・Client役
→最初のConcreteHandler役に要求を出す役

要求を出す人と処理するひとを緩やかに結びつける。特定のクラスなどに処理を担当する条件やその知識を中央集権的に
持たせないような構造になっている。
要求を出す人が処理者たちの役割分担の詳細を知らないことで、部品としての独立性が高まる。

委譲を用いることでたらいまわしを行っていれば、要求を処理するConcreteHandler役のオブジェクトの関係が動的に変化しても
その役そのものを組み替えることができる。

自分で処理するか、できなければ次の人に回してしまうというスタンスによって、仕事の振り分け自体をConcreteHandlerに
負わせないで済む。

要求を処理する役が決まっている、処理速度の優先順位が高い場合などはこのパターンをもちいないという判断も必要。

デザインパターン勉強メモ⑥

第11章 Compositeパターン

容器と中身を同一視し、再帰的な構造を作る。

Leaf
→中身を表す役。この役の中には他の物を入れることはできない。

・Composite役
→容器を表す役。中にLeaf役や他のComposite役を入れることができる。

・Component約
Leaf役とComposite役を同一視するための役。それぞれのスーパークラス

・Client役
→Compositeパターンの利用者。

サブクラスでしか使わないメソッドをインタフェース(API)で規定するときには、
API側では例外処理のみを書く、実装はするが処理は何もしないなどの方法がある。

引数の数が異なる同名のメソッドを書いておくと、呼び出されたときに引数の形態から自動的にどのメソッドが実行されるかが決まる。
オーバーロード(多重定義)

第12章 Decoratorパターン

あるオブジェクトに、あとから機能を追加していくことでより目的に近いオブジェクトを作る。

・Component役
→機能を追加するときの核になる役。インタフェース(API)のみを定める。

・ConcreteComponent役
→Component役のインタフェース(API)を実装しているクラス。

・Decorator約
→Componentと同じインタフェース(API)を持つ。さらに、このDecorator役が装飾する対象となる
Component役を持っている。(自分が装飾するクラスを知っている)

・ConcreteDecorator役
→具体的なDecoratorの役。

Decoratorパターンでは中身と飾り枠を同一視している。
(サンプルではBorderとそのサブクラス、そしてDisplayクラス)
→つまり同じインタフェースを持っている。→飾り枠が増えてもインタフェースは隠されない
→インタフェースが透過的であるという。

新社会人の皆様へ(主に仕事への準備の話)

あと1週間ちょっともすればまた新社会人の皆さんが誕生するんですね



皆さんよりも先に社会人になった身として、タメになるアドバイスでもできればとは思うのですが、
まだ2年しか社会人やってないし自分自身もわかんないことだらけなので…



あまり背伸びをしない助言みたいなことができれば。



まず。スキルや習慣として、各職種共通でいえるのは、



①「エクセルとワードは使えるようにしておこう」

②基本的な敬語は復習しておこう

③本を読もう

④タイピングを鍛えておこう



パッと思いつくのはこれくらいでしょうか?



では、各項目に簡単に肉付けを。



①「エクセルとワードは使えるようにしておこう」
特にエクセルは頻度高く使うことになるのではないでしょうか。


私はITの業界で1年営業、もう1年エンジニアとして仕事をしてきましたが、どちらもエクセルの出番は多かったです。


表計算ソフト、なんていうくらいなので見積書・発注書などの数字の絡む各書面をこれで書くことがほとんどです。営業職や管理系のお仕事をされる方は特に。
数字の計算だけでなく、エクセルが思うように使えないのは相当ストレスになってしまうので、早い段階での習得をおすすめします。

行・列の概念から、数値の計算、そもそものエクセルの操作性、簡単な関数を使ってみるなどして慣れておくと慌てずに済みます。
また、どの機能がどの部分についているのかを早いうちに把握できると尚よし。(セル結合を行う方法、そらで言えますか?)


エンジニアになってからも、システムなどの設計書とかでほぼ必ずエクセルが絡みます。
こういう場面でエクセルを利用することの是非についてはかねてより様々議論がありますが、それはまた別の機会でお話ししましょう。
とにかく、使えて損はありません。

私は嫌いですが。



②基本的な敬語は復習しておこう

尊敬・ていねい・謙譲語の基本は押さえておきましょう。自分を下げる?相手を上げる?どれがどれ?

ら抜き言葉にならないように気を付けましょう。

※全部当てはまるかはわかりませんが、「動詞を命令形にしたときに末尾がオ段の音になるものの不可能表現」でははよくあてはまるので
特に気を付けましょう。

×食べれない ○食べられない
×起きれない ○起きられない ←これはなかなか気づかなかった


いわゆる「バイト敬語」にならないように気を付けましょう。
「こちら○○になります」


※「させていただきます」という表現、特に日常でとがめられることはないかもしれませんが、もともと正しい表現とはいいがたい。
私もうっかりやらかしますが、自分でもイライラします。あと、Facebookでコンサル名乗ってる人は死ぬほど乱用するので距離を置くと吉。


「そんなもん、意味が相手に伝われば問題ない」「言葉とはそもそも時代の流れの中で変わっていくものだ」なんて言い分もありますが、
義務教育時代の国語の勉強をさぼった言い訳をそれっぽくされてもねぇ?


③本を読もう
個人的にはなんでもいいです。とにかく何か1冊買って読んでみましょう。
仕事に使う本、自己啓発本、技術書(最近こればっか読んでる)、小説。なんでも。

仕事で必要な本はその道の先達に良書を聞くのがよいでしょう。技術書もしかり。
おすすめ本をまとめた記事とかもあるのでうまく使いましょう。

自己啓発本は、それ自身はいい本も多くあるのですが、自己啓発本大好きクラブ会員みたいな人がたまにいるので気を付けましょう。

個人的に抱えている課題(仕事をさばくのが人より遅い、メンタル的によく落ちこんでしまうとかとか)をはっきりさせてからどういう本を読むのか決めるのが
無駄がなくていいのではないかと思います。

特に課題が思いつかないのなら、たまのジャケ買いをしてみるのもいいと思います。表紙とパラ読みの印象で買ってみる。

読んでて著者と自分の意見が合わなくても、「著者のように考えるとどういうメリットがあるんだろう」とか考えてみると収穫は大きい。







人に強制される読書ほどクソの役にも立たないものはないので、自分からいろいろ手を出してみるといいですね。



④タイピングを鍛えておこう

これを一番最後に持ってきたのは、まさに一番強調して言いたいことだからです。

メールを打つ、エクセルに入力する、チャットで情報共有する、プログラミングをする…

あらゆる場所でPCのキーを叩く場面は出てきます。
思っていることを文字に起こすのに手間取ってしまうと、自分はいらいらするし仕事進まないし上司はせっついてくるしでなにもいいことありません。

春休み中に、1日10分だけタイピングを鍛えておきましょう。
大学のレポートとかを書いてる段階でタイピングに習熟した方は間違いなく1歩リードしていると思っていいでしょう。

おすすめは寿司打という練習サイトです。
1万円コースで元が取れるレベルになればだいぶストレスも少なくなると思います。基本配置を頭に入れたら、あとはひたすらに打つべし。






こんな感じでしょうか?
もっと社会人経験を積んでいけばもっと実のある内容が書けるのかもしれないですが、まぁ勘弁してやってください。

気負わず、春休みを楽しみつくしてください。やり残したことのないようにね。







気が向いたら心構え的な記事も書きたいなぁと思ってます
そっちはだいぶ考え方が偏っている部分もあるので、暇をつぶす程度に読んでください。(政治思想がどうこういう話じゃないよ)


それでは。

デザインパターン勉強メモ⑤

第9章 Bridgeパターン

機能のクラス階層と実装のクラス階層を橋渡しする。

・機能のクラス階層
スーパークラスは基本的な機能を持っている
②サブクラスでは新しい機能を追加する

・実装のクラス階層
スーパークラスでは抽象メソッドによってインタフェース(API)を規定している
②サブクラスは具象メソッドによってそのインタフェース(API)を実装する

上記2つの考え方が混在してしまうととても複雑なクラス階層になってしまうため、
設計の段階でどちらの意図で階層を作ろうとしているのかを考える必要がある。

Bridgeパターンを用いて異なるクラス階層にしてしまうことで上記のわずらわしさをなくす。

・Abstruction役
→機能のクラス階層の最上位クラス。Implementor役のメソッドを使って基本的な機能だけが
記述されている。
このクラスはImplementor役を保持する。

・RefinedAbstruction役
→Abstruction役に対して機能を追加した役

・Implementor役
実装のクラス階層の最上位クラス。Abstruction役のインタフェース(API)を実装するための
メソッドを規定する役。

・ConcreteImplementor役
→具体的にImplementor役のインタフェース(API)を実装する役

2つのクラス階層に分割したことで、それぞれのクラス階層を独立に拡張することができる。
(もう片方のクラス階層は一切手を加える必要がない。)

継承はクラス拡張の際に便利だが、結びつきが硬くなってしまう(変更の際にはソース自体を変更する必要がある)
サンプルではMainクラスの中で各実装クラスのインスタンスを作って引数として渡しているため(継承ではなく委譲)、
Mainクラスのみの変更で実装を切り替えることができる。

継承は固い結びつきであり、委譲はゆるい結びつきである。


第10章 Strategyパターン

問題を解くためのアルゴリズムが実装されている部分がごっそり交換できるような仕組み。
アルゴリズムを切り替え、同じ問題を別の方法で解くことを容易にするパターン。

・Strategy役
→戦略を利用するためのインタフェース(API)を定める。

・ConcreteStrategy役
→Strategy役のインタフェース(API)を実際に実装する役。
ここで具体的な戦略(作戦・方策・方法・アルゴリズム)を実際にプログラミングする。

・Context役
→Strategy役を利用する役。ConcreteStrategyのインスタンスを持っていて、必要に応じてそれを利用する。
あくまで呼び出すのはStrategyクラスのインタフェースである。


Strategyパターンではアルゴリズムの部分をほかの部分と意識的に分離し、インタフェース(API)の部分のみを規定する。
→プログラムから委譲によってアルゴリズムを利用する。
また、動的にアルゴリズムを切り替えが可能になる。

デザインパターン勉強メモ④

第7章 Builderパターン

構造を持ったインスタンスを積み上げていくという考え方。

・Builder役
インスタンスを作成するためのインタフェース(API)を定める。
インスタンスの各部分を作るためのメソッドが用意される。

・ConcreteBuilder役
→Builder役のインタフェース(API)を実装しているクラス。
実際のインスタンス作成で呼び出されるメソッドが定義される。また、最終的にできた結果を得るためのメソッドも定義される。

・Director役
→Builde役のインタフェース(API)を使ってインスタンスを生成する。
ConcreteBulder役の種類に関係なく動作するようにBuilder役のメソッドのみを使う。

・Client役
→Builderパターンを利用する役。

オブジェクト指向プログラミングでは、どのクラスがどのメソッドを使えるかを意識することが重要。
DirectorクラスがBuilderクラスしか知らないような形にする(ConcreteBuilderクラスの種類に関しては何も知らないようにする)ことで
交換可能性が高まる。

つまり、Builderクラスはそのサブクラスたちが将来必要とするであろう必要十分なメソッドを宣言していなければならない。
設計者は、すべてを見通せないまでも近い将来必要となりそうな変化には耐えうるような設計を意識する必要がある。

既存のソースを読むときは、抽象クラスばかりを眺めるのではなく
Directorクラスを読みこんでBuilderクラスのメソッドの使われ方を理解し、最後にConcreteBuilderクラスを読むことで
Builderクラスにどういう動作が期待されているのかをチェックする。
変更すべきクラスとそうでないクラスのみきわめが大事。

第8章 Abstract Factoryパターン

抽象的な工場が登場し、抽象的な部品を使って抽象的な製品を作る。
部品の具体的な実装には注目せず、インタフェース(API)に注目し、それだけを使って
部品を組み立てて製品にまとめる。
Template MethodパターンやBuilderパターンと同様にサブクラスのレベルで具体的な実装をおこなう。

・AbstractProductの役
AbstractFactory役によって作り出される抽象的な部品や製品のインタフェース(API)を定める。

AbstractFactoryの役
→AbstractProduct役のインスタンスを作るためのインタフェース(API)を定める。

・Client役
→AbstractProducとtAbstractFactoryのインタフェース(API)だけを使って仕事をする役
具体的な製品や工場については知らない。

・ConcreteProduct役
→AbstractProduct役のインタフェース(API)を実装する。

・ConcreteFactory約
AbstractFactoryのインタフェース(API)を実装する。

AbstractFactoryパターンではクラスの構造やどのようなメソッドを実装すべきかがはっきりしているため、
ConcreteFactoryを新たに追加するのが簡単になる。

AbstractFactoryに新しい部品を追加すると、それを実装しているすべてのConcreteFactoryに対応する修正を加えなければならないため大変。

工場を新たに追加するのは簡単だが、新たな部品を追加するのは困難である。

インスタンスの作り方
①Something obj = new Something();

②Prototypeパターンで登場するclone()メソッド
→すでに存在するインスタンスをもとに新しいインスタンスを生成できる。
(コンストラクタは呼ばれない)

③newInstance
java.lang.ClassクラスのnewInstanceメソッドを使う。
例外が発生するメソッドなのでtry-catchでくくるかthrowsの宣言が必要。

ここまでの感想

著者もいうように8章は自分にとってかなり難しいというか複雑というか
週末の時間を使ってソースを写経することにする。