【オブジェクト指向】【アーキテクチャ】違いって？

Question

【デザインパターン/設計パターン】
【ソフトウェアアーキテクチャ】
【オブジェクト指向】
【SOLID原則】

大雑把にまとめると、これらは全て、
「守って設計すると、コードの再利用がしやすい/コード変更の際、お手軽」
みたいなことだと認識しているのですが、それぞれ違いはあるのでしょうか。

または、認識が間違っていますでしょうか。

Comments

[Zuishin]

間違っています。

[dodox86]

> みたいなことだと認識しているのですが、それぞれ違いはあるのでしょうか。

言葉が違うということは指し示しているものやその領域が違うことがほとんどですが、なぜ違いが無いと思えるのでしょう。質問の気軽さに比してちゃんと答えようとすることの費用対効果を考えてみませんか。

[m.ts10806]

カテゴリや領域、階層が違うものを比べるのは間違っています。
「スポーツと野球の違い」を聞いてるようなものです。

Answer 1

「ダイコン」
「ニンジン」
「ハクサイ」
「ホーレンソウ」
大雑把にまとめると、これらは全て、「野菜」というものですが、違いはあるのでしょうか。

と聞かれてるのと同じで、意味不明ですよ.

それぞれ説明することはできるでしょうけど（ぐぐれ、ってはなしですわな）
それがあなたの求めてることなんでしょうか。

Answer 2

検索すればわかるはずなんだが…(ざっくりとしたものであれば趣味&独学の私ですらわかっているのに)

「守って設計すると、コードの再利用がしやすい/コード変更の際、お手軽」

ある意味、正しい。ただし、後半部分の『お手軽』はまったくの間違い。
(自分で考えるよりは楽だが)

ただ、それぞれ方向性が違うのです。

まずデザインパターン。
これはGoFだったかな。とある方々が考えた手法です。
データ構造とアルゴリズムとかのように、先人たちの知恵です。

『俺はこういう局面ではこういう風に切り抜けたぜ』という情報です。
これを学んで、発想力というかそういうのを学ぶのです。
だから、常に使えるわけではありません。
実際、(初期の?)デザインパターンではSingletonパターンがありますね。
でもこれを多用しすぎると、ある意味C言語よりも使いづらい状態になります。
1クラス で 1オブジェクト しか作れません。もしWindows APIとかみたいなのをラップしてボタンクラスとかを作ると考えてみてください。
普通、市販のソフトとかにはボタンがいくつもありますよね。ボタンだけじゃないですが。そうなると、ボタンの数だけクラスを組まないといけないです。

なので今ではアンチパターンとなっているようです。
このように、必ずしも使い勝手がいいとは言えません。

ただし、オブジェクトの運用方法は学べますよ。

ソフトウェアアーキテクチャ… あまり詳しくありませんが、ざっと調べると、MVCパターンとかのようなやつのようですね。

これはある意味、設計におけるデザインパターンのような感じでしょうか。
デザインパターンはオブジェクトの運用方法(どのようにオブジェクトを生成し管理するか)で、ソフトウェアアーキテクチャはUIとビジネスロジックの分離等のような設計におけるものっぽいです。

オブジェクト指向(OOP)はあくまで発想法です。

プログラミングの歴史を考えるとわかりますよ。

まず、プログラミングは最初、軍事利用でした。弾道計算や暗号解読とかです。
でも機械は0と1からなる機械語しか認識できません。でも人間にはきつい。ってことで、アセンブラのような言語が作られました。でも、似たような処理も今で言うコピペやgotoの乱用でいわゆるスパゲティコードになっていることが多かったようです。

そこで、手続き型プログラミングと呼ばれる手法、つまり関数にまとめたりして考える方法が生まれました。C言語とかがそうです。でも、これにもデータと処理(関数)は別々で、たまたまそれを処理するだけでした。プログラマがデータの状態を完全に意識しないといけません。

そこでオブジェクト指向プログラミングというのも考えだされました。
手続き型で問題となっていた『データと処理が別物』の部分を解決しました。

データ(= フィールド)と処理(= メソッド)をひとまとめにしたオブジェクトなるものを中心に見る発想法です。これにより、『データと処理方法はオブジェクトが知っている』という状態になりますね。それは言い換えると『オブジェクトだけが対象データと処理方法を知っている』という状態です。つまり『オブジェクトに処理や管理を任せる』のです。

でもOOPにも問題があったので…という風に試行錯誤しながらできた手法です。

確かに自分一人で開発する場合はあまり旨みが感じられないかもしれません。
ですが、C++でいうBoostやQt、JavaでいえばPOIのような外部ライブラリを使うと考えてみてください。ファイルの読み込みを考えても、『今ファイルのどこを指し示しているか』とかのような部分は意識しないはずです。(バイナリファイルとかだと意識する必要がある場合が多いが)

SOLID原則…DRYの原則とかもあった気がしますが。これらは上記OOPを実現する上での指標です。
従わなくても実装自体は可能です。ですが、それならいっそ手続き型のほうがましっていう状態になりやすいからです。

たとえばメソッドをやたらstaticにしたりとか、いわゆる神クラスっていうやつになったりとか。

単一責任の原則は『1クラスにつきひとつの責務だけ与えよ』的なやつですね。
従わない場合、例えばファイルの読み書きをする『FileManager』なるクラスを作ったとします。
でも一ヶ月後の自分は覚えていません。
それで『これもファイル操作だから』と削除系やコピー系の処理も加える。
そうするとクラスが肥大しますね。

で、なにかファイル関連があったらFileManagerへ。
という風になってしまう。
そうすると、OOPの基本概念である『オブジェクトに管理や処理を任せる』ということができなくなってしまいます。

これではダメだということで、単一責任の原則とかを課しているのです。

他の原則も似たような感じです。
『同じような処理を書くな』→クラスなり関数なりで切り出して使え
的な。

よってそれぞれ方向性が違います。