独習Javaサーバサイド編第２版 第1章まとめ
山田祥寛さんの独習Javaサーバサイド編第2版
今回から新しい本まとめていきます
1章はまだわかりやすい感じ
サーバサイドJava
Webアプリケーションを開発するための技術
Webアプリケーション
検索エンジンやネットショッピングサイト、SNSなどのインターネットを経由してアクセスすることができるアプリケーション
クライアント
顧客、依頼人という意味で、コンピュータの世界では
ほかのコンピューターに対してなんらかの依頼（要求）を行い、その結果として情報を受け取るコンピュータ
のことをいう
Webアプリケーションの場合、InternetExplorerやGoogle Chromeなどのインターネットブラウザのこと
サーバ
給仕人、奉仕者という意味で、コンピュータの世界では
ほかのコンピュータに対して、情報やサービスを提供するコンピュータ
のことをいう
日常的に一般ユーザの目に触れることはなく、ネットワークのどこかにいつも待機している存在
メールを送受信するメールサーバや、データ管理のデータベースサーバなどさまざまなサーバがある
Webアプリケーションで直接クライアントにサービス（情報）を提供するのが
Webサーバ
と呼ばれるもの。
クライアント/サーバ間の通信
サーバにはいくつかの役割があり、重要な一つは
クライアントから要求されたファイル（Webページ）をクライアントに送信すること
である
URL(Uniform Resource Locator)
クライアントが見たいページを指定するためのもの
クライアントからサーバに対して
HTTP(HyperText Transfer Protocol)
という
プロトコル(コンピュータ同士がデータをやり取りするための約束事)
に従って送信される
プロトコルにはさまざまな種類があり、Webサーバとインターネットブラウザとが会話するとき使用するのがHTTPである
HTTPはクライアントからの要求（リクエスト）に対して、サーバが応答（レスポンス）するという単純な手続きを規定している
静的なページ
サーバ側であらかじめ用意されたファイルをそのままなんの加工もせずに返すページ
この場合、サーバは要求を受け、要求通りのページを返すだけ
コンテンツそのものを用意する
動的なページ
クライアントに応じて異なる結果を返したいときのためのページ
コンテンツを生成するための仕組みを用意する
クライアントサイドスクリプト
JavaScriptなどで記述するようなもの
クライアント側にスクリプト（人間がコンパイルを意識しなくていい、書いてすぐ実行できるプログラム）とデータをダウンロードし、クライアント上で実行する仕組みのこと
メニューをクリックするとサブメニューが展開されるといった効果は基本的にクライアントサイドスクリプトを利用して実現している
サーバサイドJava
サーバ側で動作する
サーバサイドであらかじめ決められた処理を行い、その結果を一般的にはHTMLとしてクライアントに送信する
２つの技術の違い
クライアントサイド技術とサーバサイド技術は
ユーザの操作や与えられた値、条件に応じて動的にコンテンツを生成する
という点ではよく似た技術である
だが、実行する場所が違うだけではない！！
●クライアントサイド技術
原則としてデータ保存の手段がない
コンテンツ提供者があらかじめ用意したコンテンツを、手を変え品を変え見せ方を変えているだけ
コンテンツそのものは不変（静的である）といえる
すべてのデータ、プログラムをクライアント側にいったんダウンロードしなければならないため次のような短所がある
・パスワードなどユーザの目から隠したい情報を扱いにくい
・トラフィック量が増大しやすい
・クライアントのマシンスペックやブラウザの種類、バージョンなどに依存しやすい
●サーバサイド技術
サーバ側に用意されたファイルシステムやデータベースといった保存手段を自由に利用できる
コンテンツ提供者が用意したコンテンツはもちろん、クライアントから入力した情報をもとにコンテンツを成長させていくことができる（ブログなどのアプリケーションなどを実現できる）
すべての処理をサーバ側でおこなうので次のようなメリットがある
・機密情報も管理しやすい
・処理結果は最終的な結果であるHTMLなのでトラフィックを最低限に抑えられる
・クライアント環境に依存しにくい
*すべてをサーバサイド技術で実現すればいいのではない
すべての処理をサーバ側でおこなうので処理要求のたびにクライアント/サーバ間でトラフィックが発生するという短所もある
適材適所で使い分けるべき
サーバサイド技術の中のサーバサイドJava
サーバサイドJavaは代表的なサーバサイド技術だが、唯一の技術ではない
PHPやASP.NET,CGI&Perlのようなサーバサイド技術もある
サーバサイドJavaの特徴
利用実績の高さとそれによるノウハウの多さ
10年以上企業における基幹系システムの基盤技術として数多く
利用されてきた枯れている技術である
サーバサイドJavaとJSP&サーブレット
Java技術は利用目的から3つのエディションに大別できる
●JavaSE(Java Platform, Standard Edition)
Javaアプリケーションを動作するために最低限必要な基本的な実行/開発環境を提供するもの
通常JDKといった場合JavaSEのことを指す
デスクトップアプリケーションを開発するための機能も含まれる
●JavaEE(Java Platform, Enterprise Edition)
JavaSEの上で動作するサーバサイドアプリケーション開発のためのライブラリ群（アプリケーションフレームワーク）
主に企業向けのアプリケーション開発を想定した機能が取り揃えられている
サーバサイドJavaといった場合まずはこれを指していると考えて良い（JavaEEがすべてというわけではない）
●JavaME(Java Platform, Micro Edition)
携帯端末や家電製品への組み込み用途を想定した開発/実行環境
JavaSE/JavaEEが互いに密接に関連しているのに対して、JavaMEは独立したエディションである
JavaEEを構成するライブラリのなかでも特にサーバサイドアプリケーションを開発する上で欠かせないJSP(JavaServerPages)とサーブレットは、主にプレゼンテーション層（画面の生成や制御）を担う
JSPとサーブレットの使い分け
JSPで記述できることは必ずサーブレットで実現できる
サーブレットで記述できることの大部分はJSPで実現できる
同一のJava言語をベースとし、担う部分も同じ技術をなぜ使い分けるのか？
サーブレットはあくまでもJavaプログラミングの一部としてHTMLを出力する
JSPはHTMLのなかに断片的なJavaプログラムを埋め込む形式をとる
この書き方の違いから用途によって使い分けをする必要がでてくる
●サーブレット
ロジックの記述は得意だが静的なHTMLを大量出力するには記述が冗長になる
処理中心の機能を担う
●JSP
レイアウトとは関係ないロジックを大量に埋め込むとページの構造が見えにくくなる
表示中心の機能を担う
JSPはコンパイルを必要としない
●サーブレット
開発者自らコンパイル作業を行い、できた実行ファイルを配置する作業が必要
●JSP
事前のコンパイル不要
書いたソースコードをそのままサーバ上に配置さえすれば動作させることができる
JSPは最初に呼び出されたタイミングでいったんサーブレットに変換/コンパイルされた後、コンパイルされた状態のものがメモリ上に常駐するので、1度目の要求では遅さを感じるが2回目以降はサーブレットと同等のパフォーマンスを発揮する
環境構築の部分は省いてます。
別上げするかは未定。たぶんするかも。
明解Java入門編 振り返り
この本は15章までで終了。
最後の方は文章の説明が多いので読んでもほ〜んという感じ。
評価は結構分かれてるみたいだけど、最初の方はわかりやすいのかなあと個人的には思う。
問題に対して、実現の仕方はいろいろあるがその章で学んだことをつかって解いて欲しいのではないかと意図を汲み取りながらやった時もあった（ちゃんと汲み取れてるか定かではない）。
章を重ねるごとに、文章を読んで練習問題に取り組んでも全く解けないことが増えてくる。ちなみに答えは載っていない。
正解を載せてもらいたいと最初は思ったけど、実際に働いてる人たちはたぶん答えがわからないものを一から作るので、新しいものを出したあとはバグが多かったりメンテナンスが頻繁に入るのかなあとなんとなく思えたのでそれはよかったかも。（勉強する前はなぜアプリなどでバグがでるのかとかなぜしょっちゅうメンテナンスしてるのかとか全くわかってなかった。）
一見できたと思っても、ここがこうだと求めてる反応返ってこないじゃん！みたいなこともあって、テストの重要性とか、誰かに見てもらって指摘してもらう大切さを知った。
初心者なので、正直この一冊だけではわからないことが多く（当たり前か）、様々なサイトやネットで学習できるサービスなどを利用しまくっている。
わからなすぎるところは飛ばしまくっているのでもう一周する。
この本やって、自分の頭の悪さに不安しか感じてないしきついけど、逃げちゃダメだ精神で頑張ろうと思う。Javaともう少し、せめて今よりもお近づきになりたい気持ち。
明解Java入門編 第15章まとめ
文字
文字は整数値のコードで表され識別される。
文字コードには種類があり、Javaが採用しているのはUnicodeである。
Unicode
・全ての文字に固有の番号を与える
・プラットフォームに依存しない
・プログラムに依存しない
・言語に依存しない
char型
文字を表す。
中身が空である""が許される文字列リテラルとは異なり、中身が空である文字リテラル''はコンパイルエラーになる。
文字列と文字列リテラル
文字列リテラルはString型インスタンスへの参照である。
文字列はString型である。
文字列の代入は文字列のコピーでなく参照のコピーである。
Stringクラスは文字列を格納するためのchar型の配列などのフィールドと数多くのコンストラクタおよびメソッドを有している。
キーボードからの読み込み
Scannerクラスのnextメソッドとnextlineメソッドは、キーボードから読み込んだ文字列を内部に持つString型インスタンスを生成してそのインスタンスへの参照を返却する。
コマンドライン引数
プログラム起動時にコマンドラインから与えられた文字列の配列はmainメソッドの引数として受け取ることができる。
明解Java入門編 第14章まとめ
インターフェース
インターフェースのメソッドはpublicかつabstractである。それを実装するクラスではメソッドにpublic修飾子を与えて実装する。
インターフェース型のインスタンスを生成することはできない。
インターフェース型の変数は実装クラスのインスタンスを参照できる。
実装するインターフェースの全メソッドを実装しないクラスは、抽象クラスとして宣言する必要が有る。
メンバとして定数を持つことができるが定数でないフィールドを持つことはできない。
インターフェースで宣言されたフィールドは、public static finalとなり、値を書き換えることのできないクラス変数になる。
インターフェースの名前は原則として名詞。振る舞いを表現する形容詞としてもよい。
インターフェース宣言
先頭のキーワードがclassではなくinterfaceとなる。
メソッド本体{...}の代わりに;をつけて宣言する。
インターフェース実装
インターフェース内で宣言された抽象メソッドの実体はインターフェースを実装するクラスの中で定義する。用いるキーワードはimplements。
インターフェースのメソッドはpublicかつabstractである。それを実装するクラスではメソッドにpublic修飾子を与えて実装する。
クラス派生とインターフェースの実装
extendsとimplementsの両方がある場合、必ずextendsを先にかかなければならない。
複数インターフェースの実装
クラスは複数のインターフェースを同時に実装できる。
明解Java入門編 第13章まとめ
抽象クラス
インスタンスを生成できない、またはすべきでない。
メソッドの本体が定義できない。その内容はサブクラスで具体化すべきであるという性質を持ったクラスを表す。
抽象メソッドを一個でも有するクラスは必ず抽象クラスとして宣言しなければならない。
下位クラスをグループ化して多相性を有効活用するためのクラスに具体的な実体がなければ抽象クラスとして定義すると良い。
抽象クラスから派生したサブクラスで抽象メソッドを実装しなければ抽象メソッドのまま継承される。
抽象メソッド
メソッドの前にabstractをつける。
ここではメソッドの実体を定義できないから私から派生したクラスで定義してというニュアンスを持つ。
抽象メソッドには本体がないのでその宣言では{}の代わりにたとえ空であっても;を置く。
スーパークラスの抽象メソッドをオーバーライドしてメソッド本体の定義を宣言することをメソッドを実装するという。
抽象性をもつ非抽象メソッドの設計
スーパークラスの非抽象像メソッドを抽象メソッドとしてオーバーライドできる。
文書化コメント
形式：/**...*/
javadocツールによって、マニュアルともいうべきドキュメントを生成できる。
文書化コメントの対象は、クラス・インターフェース・コンストラクタ・メソッド・フィールドである。
HTMLタグを挿入できる。
明解Java入門編 第12章まとめ
派生と継承
あるクラスをコピーして、部分的な追加・修正を施すプログラミングを続けていくと、互換性のないクラスが溢れかえってしまうため、プログラムの開発効率・拡張性・保守性が低下することになる。そのためソースプログラムの安易な切り貼りによって新しいクラスを作るべきではない。
このような問題を解決するのがクラスの派生である。
派生とは
既存クラスのフィールドやメソッドなどの資産を継承した新しいクラスを作り出すこと。
フィールドやメソッドを追加したり上書きすることもできる。
派生元のクラス（呼び方）
親クラス/上位クラス/基底クラス/スーパークラス
派生したクラス（呼び方）
子クラス/下位クラス/派生クラス/サブクラス
サブクラスはスーパークラスのフィールドやメソッドなどの資産を継承するとともに、それを部分として含むクラスである。
派生とコンストラクタ
クラスの派生においてコンストラクタは継承されない。
コンストラクタの先頭でsuper(...)を実行することによって、スーパークラスのコンストラクタを呼び出せる。
明示的にsuper(...)を呼び出さないコンストラクタの先頭行には、スーパークラスに所属する「引数を受け取らないコンストラクタ」を呼び出すsuper();が挿入される。
コンストラクタを一個も定義しないクラスには、x(){super();}という形式のデフォルトコンストラクタが自動的に定義される。
クラスにコンストラクタを定義しない場合、そのスーパークラスが「引数を受け取らないコンストラクタ」を持っていなければならない。
「super.メンバ名」によって、スーパークラスのメンバをアクセスできる
Objectクラス（親玉クラス）
明示的な派生の宣言をしないクラスはObjectクラスのサブクラスとなる。
javaのすべてのクラスはObjectクラスの下位クラスである。
差分プログラム
継承のメリットの一つに「既存プログラムに対する必要最低限の追加・修正だけで新しいプログラムが完成する」という差分プログラムが行えるということがあげられる。プログラム開発時の効率アップや保守性の向上が図れる。
is-Aの関係
スーパークラス型の変数はサブクラスのインスタンスを参照できるが、サブクラス型の変数はスーパークラスのインスタンスは参照できない。（明示的なキャスト演算子を適用しなければならない）
メソッドのクラス型引数に対しては、そのクラス型のインスタンスへの参照だけでなく、そのクラスの下位クラス型のインスタンスへの参照を渡すことができる。
メソッドのオーバーライド
スーパークラスのメソッドと同形式のメソッドに、サブクラスで別の定義を与えることをオーバーライドすると表現する。
@Overridアナテイション
コメントより高度な注釈で、人間だけでなくコンパイラにも読ませる注釈。
スーパークラスのメソッドをオーバーライドするメソッドには@Overrideアナテイションをつけて宣言すると良い。
メンバ
クラスの派生で継承されるのはクラスのメンバに限られることになっている。
・フィールド
・メソッド
・クラス
・インターフェース
スーパークラスのメンバは原則としてそのまま継承される。
ただし、非公開アクセス性を持つメンバ（private宣言されたメンバ）は継承されない。
メンバではないクラスの資産
・インスタンス初期化子
・静的初期化子
・コンストラクタ
これらの資産は継承されない。
finalなクラスとメソッド
finalクラスのメソッドはすべてfinalメソッドとなる。
finalクラス
final付きで宣言されたクラスやメンバは派生において特別な扱いを受ける。
finalクラスから派生を行うことはできない。拡張すべきでないクラスは（勝手にサブクラスを作られると困る）finalクラスとして宣言すること。
finalメソッド
finalメソッドはサブクラスでオーバーライドすることができない。サブクラスでオーバーライドされるべきではないメソッドはfinalメソッドとして宣言すること。
明解Java入門編 第11章まとめ
パッケージ
主な役割は3つ
1.名前の衝突回避
2.カテゴリによる分類
3.カプセル化（アクセス制御）
同一名のクラスは異なるパッケージに属していれば使い分けられる。
階層化できる。例）Scannerクラスはjavaパッケージの中のutilパッケージに属す。
階層的なパッケージの名前は各パッケージ名を.で区切って表現することになっている。例）java.util
完全限定名
例）java.util.Scanner
単純名
例）Scanner
型インポート宣言
パッケージ名を省略した単純名だけで型を利用可能にする。2種類ある。
単一型インポート宣言
import 完全限定名;
この形式でインポートされた型名はそのソースプログラム内で単純名だけで利用できる。
オンデマンド型インポート宣言
ソースファイル中で利用する全クラスに対して単一型インポート宣言を行うのは大変。そのための簡略的なインポート方法。
import パッケージ名.*;
パッケージ名で指定されたパッケージに所属する型名を、単純名だけで利用できる。
オンデマンドは「必要に応じて」という意味なので使われていない型名はインポートされない。
オンデマンド型インポートするパッケージに同一名のクラスが存在するとそのクラスを単純名で利用しようとしたときエラーが生じるのでオンデマンド型インポート宣言は多用すべきではない。
異なる階層のパッケージ中の型名はインポートできない。
java.langパッケージの自動インポート
java言語に密接に関連したクラスが集められているので、自動的にインポートされることになっている。
静的インポート宣言
・クラス変数（静的フィールド）
・クラスメソッド（静的メソッド）
の2つのインポートを行う。
単一静的インポート宣言
import static 型名.識別子名;
オンデマンド静的インポート宣言
import static 型名.*;
特定のクラスに所属するクラス変数またはクラスメソッドを多用するプログラムでは、オンデマンド静的インポート宣言をするとよい。
パッケージ宣言
package パッケージ名;
・パッケージ宣言はなくてもよい
・パッケージ宣言を2個以上置くことはできない
同一のパッケージ内に所属するクラスは、単純名でアクセスできる。
無名パッケージ
ソースファイルにパッケージ宣言がない場合、そのソースファイル中で定義したクラスは無名パッケージに所属することになっている。無名パッケージに所属するクラスの完全限定名は、単純名と一致する。テスト的な使い捨てのものでない限り、クラスはパッケージに所属させるべきである。
パッケージとクラスの命名での注意
一つのパッケージ中に同一名のパッケージとクラスが存在することは許されない。
パッケージ名はすべて小文字とする。
パッケージとディレクトリ
パッケージを作成する場合は、パッケージ名と同一のディレクトリの中にソースファイルとクラスファイルを置くのが基本的構成である。
一意なパッケージ名
パッケージには一意な名前を与える必要がある。
推奨されているのはインターネットのアドレスを逆順に並べるという方法。識別子として許されていないハイフンなどの特殊文字は下線文字に置き換える。キーワードと一致する単語にはその後ろに下線文字を付加する。先頭文字が識別子の開始文字として許されていない場合はその単語の前に下線文字を付加する。
クラスのアクセス制御
クラスのアクセス性はパッケージという観点から2種類に分けられる。
publicクラス
キーワードpublic付きで宣言されたクラス
パッケージとは無関係に利用できる。
クラスのアクセス性は公開アクセスになる。
publicクラスの名前とソースプログラムのファイルの名は一致していなければならない。
1個のソースプログラムにはpublicなクラスを0個または1個しか定義できない。
非publicクラス
キーワードpublicを付けずに宣言されたクラス
そのクラスが所属するパッケージ内からは利用できるが、他のパッケージからは利用できない。
クラスのアクセス性はパッケージアクセスとなる。（デフォルトアクセスとも呼ばれる）
メンバのアクセス制御
あるクラスに所属するクラス変数・インスタンス変数・メソッドなどをまとめてクラスのメンバと呼ぶ。
メンバのアクセス性には4種類ある。
公開（public）アクセス
パッケージの中からも外からも利用できる
限定公開アクセス
パッケージの中からのみ利用できる
パッケージアクセスと違い、パッケージの内部からだけでなく、そのクラスから派生した異なるパッケージに属するサブクラスからも利用できる
パッケージアクセス
同じパッケージの中からのみ利用できる
非公開（private）アクセス
クラスの内部でのみ利用できる
同じパッケージに所属するクラスからは利用できない
