SOLID原則のSについて、設計素人なりに考えてみた

こんにちは。

最近、C#の言語仕様(浅く広く)については理解が深まってきたので、設計について学んでいます。

以前、オブジェクト指向とは概念である、という感じの記事を書いたのですが、その概念の理解をより深めるために勉強し始めました。

オブジェクト指向を勉強したいのであれば、良い設計でのPrismを用いた実装を読ませてはどうか
こんにちは。 最近までC#はLivet+ReactivePropertyで開発をしていたのですが、全社的に使用しているフレームワークがPrismという事でPrismの勉強をしています。 余談ですが社内でReactivePropertyを知っ...

良い設計と呼ばれる物を可視化するためにPrismを用いると良く、じゃあ何が良いのか?と理解するためにはSOLID原則等の設計技術を知る必要があります(勉強していてわかりました)。

C#でよく「インターフェースとは~」と書かれていますが、C#と言わず、プログラミングにおけるインターフェースを理解するにはSOLID原則を知らないと無理だろうなぁ、と個人的には思っています(思い始めました)。

言語の勉強していて「インターフェースとはこういう物か…」と頭でわかっていても、それが何の役に立つかはおそらく理解できません。

話は逸れましたが、現在SOLID原則について勉強しているのですが、OLIDについては割と理解できました。

が、Sについては抽象的な話が多く、中々自分の中で落としどころが見つかりませんでした。

SはSingle Responsibility Principleの頭文字を表していて、簡単に言うと「1つのクラスで、色々な事をするな」という事です。

これは不正確で、「あるクラスを修正するときには、必ずそのクラスを修正する理由は1つにしなさい」の方が確かです。

例えばデータ保存を担うクラスがあったとき、データ保存の仕組みを変えるときはそのクラスだけを変更するようにしておけ、という事です。

また保存するデータの種類が変わった場合、そのクラスを変更することは許されない(できればやるな)という事も含んでいます。

こういう設計にしておけば、プログラミングとして良しとされる疎結合が自動的に実現されている、という事です。

後者のデータの種類が変わった場合に対応するためには、インターフェースを用いて実装します。

そうすればインターフェースでのメソッド定義だけ使えばいいので、データ構造がどうなっていようとインターフェースが実装されていれば問題なくなります。

前者ですが、私は「単一クラスで公開するpublicメソッドは常に1つにしておけばいい」と考えたのですが、これは間違いでしょうか?

1つにしろ、は極論ですが、基本的に公開するメソッドの名前はほぼ一意にしておくべき、と考えて良いのではないでしょうか。

色々なサイトを見たのですが、そこに書かれている例文は大体publicで、どう見てもクラス分けは別だろ…というものしかありませんでした。

「どう見てもクラス分けは別だろ…」という感覚がSingleResponsibiliryPrincipleだ!と言われればそれまでなのですが。

あるクラスで、publicをいくつも実装しなくてはならない時点で、SingleResponsibiliryとは言えない気がします。

せいぜい2つか3つが良い所でしょう。

何が言いたかったというと、設計時に公開するメソッドをまず考え「このクラスはこれで閉じる!」と考える癖をつけるところからでしょう。

後で実装してて「これどこでやろう…」「とりあえずこのクラスに持たせておこう…」となった場合、自分をビンタして、1食抜くことにします。

で、最初にインターフェースの話題を出したのですが、SOLID原則をC#で実現する場合、インターフェースの知識が無いと何もできないです。

実際に動くだけのものを作るのであれば、インターフェースなんて不要だと思います。

実装が増えるだけですので。

ただ、規模が大きくなったり、複雑な構成のプログラムであれば必須であり、SOLID原則を知らなくてはまともに設計なんてできないと思います。

設計は学べば学ぶほど奥が深いですね。

ただ、使用する言語で「この設計を実現するためにはどうやればいいのだろう」等、実現可能性を知らないといけない点が難しいです。

設計手法が先か、言語仕様が先か、私の中では課題でした。

私の場合、完全に放置で設計に関しても、言語に関しても、一切教育を受けていません。

言語に関しては本を読んだり、手を動かせばだれでも理解できるかと思います(経験談)。

ただし、設計に関しては良い設計を目にしたり、どういう構造にすれば綺麗になるだろう、保守しやすいだろう、という向上心的なものが無いと身につかないと考えています。

まだ後輩はいないのですが、後輩ができた際には私の様にならないように教えてあげたいですね。

私はとりあえず言語仕様について勉強してもらい、手を動かしてそこそこ書けるようになったらすぐにSOLID原則について勉強させてみたいと思います。

で、SOLID原則にのっとって設計したソフトを1つ作ってもらいたいと思います。

最後に、SOLID原則という考え方が面白いですね。

S,O,L,I,Dがそれぞれ強力な考え方なのですが、SOLIDとカプセル化する事で何倍にも強力になっている感じがします。

どれか1つを意識して使うだけでも全然異なる設計になりそうですが、他に1つ取り入れるだけでも各段に設計が良くなりそうな気がしています。

コメント

タイトルとURLをコピーしました