53402


### はじめに

設計初心者です。

### 分かっていないこと

下記「参考」内の例における「シングルトン」をはじめとする、デザインパターンの適用範囲がわかりません。

「参考」のページには図書館の貸出名簿の話が掲載されています。この話自体はなんとなく理解できたのかなと思います。

では、ここをシングルトンで設計したらほかもシングルトンで統一する必要があるのか、それともデザインパターンはオブジェクトごと（もしくは他のなにかごと）に適用するものであって、アプリ内で統一する必要はないものなのか。これが分かりません。

### 不明ながらも現状で想像していること

現状の想像では、貸出名簿はシングルトン、ほかは○○といったようにオブジェクトごとにデザインパターンを適用でき、アプリ内にそれぞれ適材適所の形でデザインパターンが混在できるのでは？という想定をしています。（貸出名簿が１つしか生成できないからといって、貸出名簿のルールに縛られて他のオブジェクトが１つしか生成できなくなるなんてことはかなり不都合なので。例えばユーザーインスタンスの生成など…）だからアプリ全体として○○で作られているという言い方はあまりされず、この部分は○○パターンを利用、この部分は…という言い方になる。

### 教えていただきたいこと

まとめると、教えていただきたいことは以下になります。

  1. シングルトンを含むデザインパターンの適用範囲(区切り)はどこか。
  2. （１.を元に）アプリケーション内にデザインパターンが混在することは悪い設計にはならないのか。
  3. 主要なオブジェクト指向言語（JavaScriptやJava、C#等、GitHubのリポジトリ内の使用率10〜20位に入る程度を想定しています。）は上記 1. 2.におおよそ共通していると言えそうか

### 参考

[デザインパターン 5章 Singleton
パターン](https://www.techscore.com/tech/DesignPattern/Singleton.html/)

以上です。  
よろしくお願い致します。


CC BY-SA 4.0
2019-03-13T08:03:46.510
53399
2019-03-14T02:15:11.970
2019-03-14T02:15:11.970
32521
32521
question
デザインパターン
デザインパターン（シングルトン）の適用範囲　同一のアプリケーション内で統一する必要があるのか


オブジェクト指向プログラミングを行う場合、オブジェクトは自身の内部にオブジェクトを持つことになり、つまりオブジェクトは再帰的な構造を持ちます。

デザインパターンは、あるやりたいことがあったときに、それをオブジェクト構造においてどのような形で実装するとうまくいくかの経験則的なパターンを集めたものです。

最初に述べた通り、オブジェクトは再帰的な構造を持つので、現実的なプログラムは例えば、あるトップのクラスは主にイテレーターパターンで処理を行なっていて、イテレーターパターンによって取得されるオブジェクトは内部的にストラテジーパターンを採用していて、、、などといったようなことになると思います。

ディレクトリとファイルで例えると、例えば社内共有フォルダがあって、それはトップでは部署ごとフォルダによって整理されている。各部署ごとフォルダはチームフォルダによって整理されている。特定のチームのフォルダは、四半期ごとのフォルダによって整理されている。。。。といったような形であったときに、デザインパターンのアナロジーでいうならば、トップディレクトリは「組織構造による分割パターン」を採用している。各部署ディレクトリも同様である。その特定のチームディレクトリは「時系列分割パターン」を採用している。などといった表現になるかと思います。

>   1. シングルトンを含むデザインパターンの適用範囲は区切りはどこか。
>

フォルダの整理術１０パターンがあったときに、その適用範囲は何かといわれれば、「適切に整理できるような範囲が適用範囲である」という答えになると思います。もう少し言うと、各デザインパターンは何かの問題を解決しようとしているので、その問題を正しく解決する形で最終的にプログラムを組めるならば、それは適用範囲だった、といえそうです。

>   2. （１.を元に）アプリケーション内にデザインパターンが混在することは悪い設計にはならないのか。
>

デザインパターンはそれぞれが何かの問題を解決していて、その問題解決を組み合わせることが、デザインパターンに従ったプログラム記述である、と言えます。混在、というより、「適切に組み合わせる」ことこそがプログラムの設計・実装である、と認証するのが正しいと思います。

>   3.
> 主要なオブジェクト指向言語（JavaScriptやJava、C#等、GitHubのリポジトリ内の使用率10〜20位に入る程度を想定しています。）は上記
> 1. 2.におおよそ共通していると言えそうか
>

1 や 2 の話は、オブジェクト指向がどうであるか、という話であって、言語の話とはレイヤーが違う認識です。

オブジェクト指向のデザインパターンとは、究極的には、抽象的なオブジェクトというものたちのみがあるような世界において、（そしてそれしかなかった場合）どのようにオブジェクトを組み合わせていくと現実の問題に対応できるようになるのかのパターン集です。

またもし聞きたいのが、各プログラミング言語において、どの程度までのオブジェクト指向して実装をするのが効果的か、特にいろいろ controversial
なシングルトンパターンはどうなのか、という旨の質問であるとしたら、それは各言語の言語設計に依存していて、一概に答えは出せない(すごく出しにくい)のではないか、と個人的には思います。


CC BY-SA 4.0
2019-03-13T10:12:34.027
53402
2019-03-13T10:12:34.027
754
53399
answer


まず、ソフトウエアのデザインパターンとは  
「アプリケーション設計のあるある」と言い換えても良いかもしれません。  
これは、このパターンだなといえる雛型で、  
例えば等質なオブジェクトの配列も一種のデザインパターンです。  
もっともむしろ有名なのは「(完全には)等質でない」物の配列を  
どのように設計実装すべきかというパターンで大変有用です。  
さて、概ね全てのデザインパターンに言えるのですが、

(1)「デザインパターンP」を適用すべきクラスは  
「その設計であるべき、と考えられるクラス」に限られます。

つまり設計上、そうあってほしいクラスに対して、  
あるべき振る舞いを与えるという手順になります。  
従って、図書館を設計することを想像すると、

(2)「貸出名簿」は「図書館」の所有物で、唯一の実体であるべき。

という考えから、図書館インスタンスに対するシングルトン的な扱いは  
妥当な設計であると考えられます。一方、

(3)「司書係」は複数の人員が必要で、唯一の「貸出名簿」を排他共有するため、  
場合によっては処理待ちになるかもしれない。  
(4)「返本箱」はまったく同一の機能で良く、1つ以上必要で、かつ複数存在してよい。  
(5)「蔵書一覧表」は複数の種類の書籍の複数の実体を管理しなければならないので  
単純な配列パターンでは無い可能性もある。

などと設計するかもしれません。  
ご質問への明確な回答は、デザインパターンの機能と役割がわかれば  
自然に理解できるものと考え、明示しませんでした。  
この様な回答で少しは訳に立つでしょうか。

以下蛇足です。

「デザインパターン」は元々建物の建築設計に関連したアイデアだったようです。  
具体的な建物としては個々に異なりますが、その建物の使用目的によって、  
ある主の「建築設計上の典型的な雛型」が見つかったわけですね。  
例えば、

「集合住宅パターン」・・・入口のロビーにセキュリティがあって、二階以上が居住区画のなど。  
「商店パターン」・・・・・広い入口を道路側に持ち、裏に倉庫があるなど。  
「工場パターン」・・・・・できたら平屋でトラックの駐車場、資材置き場、工場建屋、  
事務所食堂等が必要など。  
「役所パターン」・・・・・役目は雑多で外形に特定パターンは無いが、  
その市に一つで良いという特徴を持つ物など。

建物あるあるですね。設計時にその雛形が使えて省力化できるわけです。

さて、アプリケーションではその目的によって幾つかの設計パターンがあることに気づきます。  
簡単に思いつくのは、画面の様子で、「ワープロ型」は如何にも文字入力に適した設計です。  
他にも「表計算型」「線画編集型」「写真編集型」などが思いつきますが、建築設計と同じく、  
その目的が似かよればそれらの面構えも似てくるわけです。


CC BY-SA 4.0
2019-03-13T10:19:24.663
53403
2019-03-13T10:19:24.663
3793
53399
answer