オブジェクト指向設計の原則 - パッケージ設計の原則 - brfrn169の日記
少し勉強したんで、メモ。 たぶん、今後更新していきます。 まず、パッケージとは、機能のグループ単位、サブシステムのこと。 Javaだと、パッケージの概念はあるけど、もっと広い意味でJarもパッケージに含まれる。 パッケージ内部の凝集度に関する原則 再利用・リリース等価の原則（REP:Reuse-Release Equivalency Principle） 再利用の単位とリリースの単位は等価になる。 パッケージに含まれるクラスは、すべてが再利用されるか、すべてが再利用できないかのどちらかにすべきだ。 リリースの単位はパッケージ毎に行う。 再利用できるパッケージは別に切り出しといて、再利用できないパッケージでそれを使うイメージ。 全再利用の原則（CRP:Common Reuse Principle） パッケージに含まれるクラスは、すべて一緒に再利用される。 つまり、パッケージに含まれるいずれか
Javaパッケージの分割、命名についてのまとめ。 - be a ninja engineer
Java: The Good Parts 作者: Jim Waldo,矢野勉（監訳）,笹井崇司出版社/メーカー: オライリージャパン発売日: 2011/02/24メディア: 大型本購入: 3人 クリック: 148回この商品を含むブログ (37件) を見る JavaTheGoodPartsを読み終わったので、良いタイミングと思い、パッケージの分割、命名に付いてまとめてみました。 パッケージとは Javaのパッケージとは、名前空間を作成するものである。 クラス名に一意な名前を指定する必要があるので、重ならないドメインを使用してパッケージ名を決定するのは基本だと思います。 パッケージ分割指針 レイヤでの分割 私は通常、Webアプリケーションを4層構造(view, controller, service, model)で作成し、クライアント側とサーバ側はJSONでやり取りすることが多いため、以下の
Javaにおける分散処理の通信実現手段 - torutkのブログ
システム設計においては、ネットワークは常に信頼できず、また、通信には時間がかかるということを念頭に分散処理を設計することが肝要です。 ここで、信頼性のある通信を実現するには、どのような実現手段をとればよいかを考えてみます。 Javaでアプリケーションを記述する場合、アプリケーションから通信手段を利用することになるので、Javaから利用しやすい通信手段として候補に思いつくのは、 (1) UDPデータグラム (2) TCPソケット (3) SCTP (4) RMI (5) CORBA (6) HTTP (7) XML-RPC (8) Java Messaging Service (メッセージング・ミドルウェア） (9) Enterprise Service Bus があります。（レイヤーの低位から並べた） ※ FTP,E-mail等のデータ転送プロトコル、SSL等のセキュリティ付加プロトコル、
Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
いまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味について - 達人プログラマーを目指して
正しく意味を理解している方にとっては、まったく常識レベルの話であり、何をいまさらと思われる方々も多いかと思いますが、大規模案件のレガシーコードなど、私が仕事で見かけるJavaのコードを読むと、「このコードを書いたSEやPGの方々は、はたして継承の意味を正しく理解していないのではないか」と思われる設計のコードに出会うことが少なからずあります。現在では改良されましたが（Javaプログラミング能力認定試験の問題がかなり改善されていました - 達人プログラマーを目指して）、以前のJavaプログラム認定試験の問題は、そうした不適切な設計がされている典型的な例となっていたのですが、実際、SI業界ではあのような品質のコードのシステムが今でも現役で多数稼動しているというだけでなく、現在でも新たに生み出されているというのは残念ながら紛れもない事実のようなのです。 確かに新人研修で「哺乳類を継承して犬クラスと
どう共通化する？しない？ - Mitsuyuki.Shiiba
コードを書いてると「これ、同じようなコードあるから共通化した方がいいな」ということがよくある。 共通化する？ （僕はJava好きなのでJavaを思い浮かべながら書くけど）親クラスにくくりだしたり、ユーティリティクラスをつくったり。 そうすることで、ロジックをひとつの場所にまとめることができて、仕様が変わったときにはそこだけ修正すれば大丈夫。平和。 コードレビューで気づくのも伝えるのもそんなに難しくないし、伝えられた側も「確かに」って対応しやすい。 どう共通化する？ ちょっと難しいなと思うのは「同じような処理だけど意味が違う」場合。 例えば、消費税計算で価格の8％を計算して返す処理と、8％の割引をするときに計算して返す処理とは、同じ「8％を計算する」という処理だけど、どう共通化するかはちょっと考えたい。 消費税が10％になったときに、割引も10％にはなって欲しくない（あ、いや、買う方としては
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
