サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
www.itsenka.com
Adapter パターン 「Adapter」という英単語は、「適合させるもの」という意味です。 互換性のないインタフェースを持つメソッド間の相違を、埋めるような(適合させる)パターンが、「Adapter パターン」です。つまり、「Adapter パターン」は、ある任意の機能のインタフェースを変更することなく、他クラスが提供している新しい機能を使用できるようにするパターンです。 このパターンには、以下の2つの実装方法があります。 継承(is a 関係)を利用した方法 委譲(has a 関係)を利用した方法 役割り 1. Client(利用者) 「Target」のメソッドを利用して処理を行います。 2. Target(対象) 要求されているメソッド(インタフェース)を定めます。 3. Adaptee(適合される側) 既存のメソッドを提供します。このメソッドの機能を「Target」のインタフェー
Chain of Responsibility パターン 「Chain of Responsibility」という英単語は、「責任の連鎖」を意味します。 このパターンは、ある要求の受取り対象となる複数のオブジェクトに鎖状の関係を構築し、要求を処理する事が可能なオブジェクトに渡るまで、順次、構築した鎖状の関係に沿って要求を受流していくパターンです。 このパターンを適用すると、「この要求はこのオブジェクトが処理する」などという司令塔的な役割り(結び付き)を利用者側が意識しなくて良くなり、利用者側は「連鎖関係にある任意のオブジェクトに要求を投げるだけ」、処理側は「流れてきた要求が自身で処理できる場合は処理し、できない場合は、その要求を次のオブジェクトに渡すだけ」という役割分担が明確となります。(利用者側は、処理の詳細まで意識する必要はない) ※ 連鎖構造が深いと、実際どのオブジェクトが処理してい
抽象クラス(Abstract Class) 抽象クラスは文字通り抽象的存在のクラスであり具体的な処理はこれを継承したクラスに記述させます。抽象クラスの存在意義は複数のクラスに対して共通性を持たせることであり、クラス設計においてとても重要な役割を担っています。 抽象クラスの特徴 抽象クラスの特徴として、具象クラス(通常のクラス)との違いを挙げます。 1. 抽象メソッドを定義する事ができる。 抽象メソッドとは、実際の処理を自身にではなく子クラスに記述させるためのメソッドです。この抽象メソッドを記述できることが、抽象クラスの最大の特徴です。抽象クラスを継承したクラスは、この抽象メソッドを必ず「オーバーライド」しなければなりません。(オーバーライドしないとコンパイルエラーとなります。) 2. 抽象クラス単体でインスタンスを生成する事はできません。 抽象メソッドを定義している。つまり、実際の処理を記
ユースケース図(Use Case Diagram) ユースケース図とは、ユーザ(外部システムも含む)の要求に対するシステムの振る舞いを表現する図です。ユースケース図はシステムの要件定義についての俯瞰的情報を提供します。したがってユースケース図を描くことは、同時に要件定義の分析の機会になります。 記述例 例えば、次のような仕様の「受験管理システム」があるとします。 【要件定義】 ユーザ(受験者)は「受験申し込み」、「受験料振込み」、「テストを受ける」という処理を行っています。 このとき、ユースケース図では次のように表現できます。 ユーザ(受験者)が何を行うのかを書き出すことによって、より具体的な要件定義の視覚的な理解深まると同時に、不足している要件や修正するべき要件を洗い出す事が出来ます。 ▲PageTop 構成要素 ユースケース図は次の要素で構成されます。 構成要素一覧
ファイル入出力についてみていきます。ファイルへのアクセス方法は対象となるファイルによりバイトストリーム(バイナリファイル)と文字ストリーム(テキストファイル)に大別されます。「ストリーム」とは「データの流れ」を表現する用語です。 ファイルオブジェクト ファイル入出力の前に、まずファイルやディレクトリの取り扱いをみていきます。Javaでは「java.io.File」クラスによってファイルやディレクトリを1つのオブジェクトとして取り扱っています。「java.io.File」の詳細についてはJDK API仕様に譲るとして、ここでは簡単な使用例で確認してみます。 Fileオブジェクトの使用例 ・サンプルソース(Sample1601.java) import java.io.File; import java.io.IOException; public class Sample1601 { pub
コンポジット構造図(Composite Structure Diagram) コンポジット構造図とは複数のクラスを包括するようなクラスやコンポーネントにおいて、その内部要素の構造や相互作用を表現するための図です。UML2.0で追加されました。
▲PageTop 実行例 複数のパスワード更新(ユーザ:「sampleuser01」、「sampleuser02」、「sampleuser03」が存在するものとします。)を一括処理します。 パスワード更新用のバッチファイル「passwordupdate.bat」を作成します。 一括更新処理を行います。 実行結果 ■更新用バッチファイルの作成 # vi chpasswd.bat [Enter] ■更新用バッチファイルの内容(書式は、[ユーザ名]:[パスワード]となります) sampleuser01:password01 sampleuser02:password02 sampleuser03:password03 ←改行しないように注意してください。 ~ ~ ~ 4,0-1 全て ■一括更新処理 # chpasswd < chpasswd.bat [Enter] ▲PageTop ▲
Observer パターン 「Observer」という英単語は、「観察者」を意味します。 このパターンは、観察者となるオブジェクトが、観察対象となるオブジェクトからの状態変化の通知を受けそれに対する処理を行うパターンです。 役割り 1. Subject(観察対象者) 「Observer」の観察対象となるオブジェクトのインタフェースを定義します。観察者を保持するメソッド、観察者への通知メソッド(状態が変化した際に「Observer」に通知)等を定義します。 ※ 保持する観察者は複数でも可能 2. ConcreteSubjectA・B(具体的な観察対象者) 「Subject」で定義したインタフェースを実装します。「Observer」への通知は、自身に保持している「Observer」オブジェクトの通知受信用メソッドを呼出すことにより実現します。 3. Observer(観察者) 「Subject
7. デッドロックについて 7-1. デッドロック デッドロックとは、2つのスレッドが2つのロックを取り合い、互いに相手のスレッドがロックを解放するのを待つ状態のことを言います。 具体例で説明します。 例えば、AさんとBさんがコンビニ弁当を1つ買って、一緒に仲良く食べることになったとします。 しかし、袋を開けるとお箸が1セット(左右の2本)しか入っていませんでした。 2本の内の1本(左)のお箸をAさんが手にとりました。すかさずBさんも片方(右)のお箸を手にとりました。 2人とも不器用なので2本(左右)のお箸がないと弁当を食べることができません。 Aさんは、仕方なくBさんがお箸を置くのを待ちます。 Bさんも同じくAさんがお箸を置くのを待ちます。 ・・・・ 結局、2人とも決して自分の持っているお箸を譲らなかったので餓死してしまいました。・・・・ めでたし!めでたし!・・・ってめでたくないわー!
State パターン 「State」という英単語は、「状態」を意味します。 このパターンでは、ある物についての各状態をそれに対応した各クラスで表現します。(つまり、状態1つにつき、クラス1つで表現します。) 通常、条件(状態)に一致するか否かの処理は、if文を使用し、コーディングしますが、その条件分岐数が多い場合、1つの条件で処理するコード量が多い場合、また同じ条件分岐が複数の箇所に点在する場合等、メンテナンスし辛いものとなってしまいます。しかし、このパターンを適用すると、その状態状態を個々のクラスで表現するため、単純明快となります。 役割り 1. State(状態) 状態を表すクラスです。 状態毎に振舞いが異なるメソッドのインタフェースを定義します。 2. ConcreteStateA・B(具体的な状態) 「State」のインタフェースを実装し、具体的な状態を、「1クラス」 = 「1状態
UTF8コード(BOMを記述しません。UTF8の場合、BOMはファイルがUTFで記述されていることを明確にするために使用されます。)で出力します
処理をバックグラウンドで行います。-oオプションの指定がない場合処理結果はwget-logに書き込みます。
デザインパターンとは、オブジェクト設計において、定石となる手法をパターン化したものです。 ここでは、有名な「GOFの23パターン」についてみていきます。 ちなみに、この23パターンは「オブジェクト指向における再利用のためのデザインパターン」という本の中で紹介されたもので、GOFとはこの本の著者である4人組(Erich Gamma、Ralph Johnson、Richard Helm、John Vlissides)を指しています。 生成に関するパターン ・Factory Method パターン 実際に生成するオブジェクトに依存しない、オブジェクト生成のインタフェースを提供します。 ・Abstract Factory パターン 互いに関連する一連のオブジェクト郡を、その具象クラスに依存しないで生成するためのインタフェースを提供します。 ・Builder パターン 複合化されたオブジェクトについ
状態マシン図(State Machine Diagram) 状態マシン図とは、オブジェクトの状態遷移を表現する為の図です。各状態の内容および、状態遷移の条件等を記述します。 記述例 下の図は、中学校を卒業した状態から大学生の状態になるまでを表した例です。 【要件定義】 「大学生」になるためには、高校を卒業、もしくは大学入学資格の取得を経て、大学受験で合格する必要があります。 高校を卒業するためには、「一年生」、「二年生」、「三年生」と各学年に進級する必要があり、高校に進学せず大学入学資格を取得するには、大学入学資格検定に合格する必要があります。 遷移を表す矢印に、記述されている「受験[合格]/入学」は、「契機[条件]/効果」の書式で記述されています。つまり、大学生になるには、受験で合格して大学に入学するという意味になります。 このように、状態マシン図を記述することによって、実体の状態変化を
スレッドとは1つの処理の流れを示す単位です。ちなみに「thread」を翻訳すると「糸や筋」といった意味になります。「1つの話の流れ」と言う意味で掲示板などで話題のことをスレッドと読んだりしています。 javaは複数のスレッドを同時実行させて並列処理(マルチスレッド)を可能にしています。 よく似た処理単位として「プロセス(並列処理をさせることで「マルチプロセス」)」がありますが、プロセスはOSにインストールされたソフトウェア(プログラム)の実行単位であり、スレッドはそのプログラム中の一連の処理のような感じになります。その他、プロセスは固有のメモリ空間を持ちますが、スレッドはメモリ空間を共有するという違いがあります。したがって「マルチスレッド」は「マルチプロセス」に比べ並列処理を制御する負荷は軽くなりますが、メモリ内の変数などに対して排他制御等の考慮が必要になってきます。 スレッドのライフサイ
Lemple-Ziv法で圧縮されたファイル(拡張子は「.gz」、gzip等で作成可能です。)を解凍します。
シーケンス図(Sequence Diagram) シーケンス図とは、クラスやオブジェクト間のやりとりを時間軸に沿って表現する図です。機能ごとに相互作用(Interaction)と呼ばれる下記のようなフレーム内に処理内容を記述します。 記述例 下の図は、在庫管理システムの一機能を表したものです。 【要件定義】 店員は在庫管理画面から在庫一覧を確認できる。 この機能は、「店員オブジェクト」、「管理画面オブジェクト」、「倉庫オブジェクト」、「商品オブジェクト」から構成されている。 メッセージと呼ばれる矢印で各オブジェクト間の応答を表し、縦軸(上から下)を時系列として応答の順序を表現しています。 これにより、ある機能(例では在庫一覧)を実現する各オブジェクトが時間に沿ってどのように相互作用しているかがわかります。 ▲PageTop 構成要素 シーケンス図は次の要素で構成されます。 構成要素一覧
参照型とプリミティブ型 インスタンス変数の型は参照型(オブジェクト型)となります。プリミティブ型とはJVMでの管理方法が違いますので注意が必要です。 参照型とプリミティブ型の違い JVMには「スタック領域」と「ヒープ領域」という仮想メモリ領域があり、この中で変数を処理しています。参照型変数とプリミティブ型変数では、この仮想メモリ領域での管理方法が異なります。 「スタック領域」は「ローカル変数領域」とも呼ばれ、主にメソッド処理などで一時的な値保持に使用されますが、プリミティブ型変数(変数で保持している値を含む)はこの「スタック領域」で処理されます。これに対し、参照型変数の場合、保持する値(インスタンス)はヒープ領域に作成して「スタック領域」には、その保持したインスタンスへのアドレスが格納されます。 例えば、次のような変数宣言があるとします。 int a = 1; Integer i = ne
コンポーネント図(Component Diagram) コンポーネントとは複数のクラスで構成される処理に対して1つ以上のインターフェースを用意し、あたかも1つのクラスのように取り扱ったものであり、コンポーネント図とはその内部構造やコンポーネント間の相互作用を表現するための図です。 同じくコンポーネントの内部構造を表現する「コンポジット構造図」の拡張版といえます。 コンポーネントの表現 コンポーネント図は次の要素で構成されます。 または 表記例 ■内部構造を表現 ※コンポーネント内の記述方法は「コンポジット構造図」(パート、ポート、インターフェースなど)と同じです。 ▲PageTop サブシステム コンポーネントの相互作用により実現する処理をサブシステムという、より大きなコンポーネントのように表現する事が出来ます。 サブシステムの要素は次のようになります。 表記例 ▲PageTop ▲
クラス図(Class Diagram) クラス図はUMLの基本となる図のひとつで、システムを構成するクラスとそれらの関係を表現します。また、各クラスが保持する属性(プロパティ)や操作(メソッド)も表現します。 クラスの表現 クラス図は次の要素で構成されます。 ■クラス名称 クラス名を記述します。抽象クラスの場合はイタリックで記述します。 パッケージ:クラス名 ※パッケージは省略可能 また、クラス種別(ステレオタイプ)を表示するには、<<ステレオタイプ>>の形式でクラス名の上部に記述します。 例 : <<interface>> ■属性 属性は次の形式で記述します。 可視性 名前 : 型 = 初期値 { 制約条件 } ※名前以外は省略可能
UML(Unified Modeling Language)とは、様々な開発現場で使用されている設計書の書式を統一する目的で規定された言語で、1997年にOMG ( Object Management Group ) により標準化されました。 但し、UMLによる標準化はあくまで表記方法であって、開発手法の方法論ではありません。 UML2.0では表記方法を以下のように分類しています。 構造に関する表記 振る舞いに関する表記 構造に関する表記 ・クラス図(Class Diagram) クラス構造を表現します。 ・オブジェクト図(Object Diagram) クラスをより具体化したオブジェクトで表現します。 ・パッケージ図(Package Diagram) クラスなどをグループ化し整理された関係を表現します。 ・コンポジット構造図(Composite Structure Diagram) クラ
アクティビティ図(Activity Diagram) アクティビティ図とは、連続する「実行」の遷移、つまり一連の「手続き」を表現するための図です。ある事象の開始から終了までの機能を実行される順序にしたがって記述します。 状態マシン図が実体の状態遷移を表すのに対し、アクティビティ図では実体の制御の流れを描写します。 記述例 アクティビティ図は必ず開始状態から何らかの終了状態へ、矢印で示された手順に従って実行を行います。 下の図はある会社社員が起床して出社するまでの手続きを示した例です。 【要件定義】 まず朝起きて顔を洗います。健康ならば新聞を読みながら朝食を食べ、歯を磨き、そのあと服を着替えて出社します。もし体調が悪ければ「病気である」と会社に連絡して処理終了です。 ひし形で表される条件分岐は排他的で、両方の制御の流れを同時に行うことはありません。 歯を磨くという制御と新聞を読むという二つの
ドメインウェブの設定が見つかりません 考えられる原因 ドメインウェブの設定がまだ行われていない。 ドメインウェブの設定がまだ反映されていない。(反映には数時間~24時間かかることがあります) ドメインウェブ・DNSの設定が誤っている。 アカウントが存在しない、契約が終了している、削除されている。
次のページ
このページを最初にブックマークしてみませんか?
『IT専科 - ITエンジニアのための技術支援サイト』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く