はじめに
手続き型プログラミングの説明ですが、私が手続き型言語を触ったことがないため、この記事で話される手続き型プログラミングはオブジェクト指向言語でのものです。オブジェクト指向言語だけど、実際手続き的に書いているというケースは多いと思っています。なので、両者の違いを理解し、オブジェクト指向言語を利用する利点を享受しようというのがこの記事の目的です。
※いまいち自分の中でこれという結論が出なかったので、疑問を投げかけるような内容になってしまいました。コメントで皆さんの考えをお聞きできると嬉しいです。
手続き型プログラミングにおける問題点
まず１ファイルで手続き的にプログラムを書く際に発生する問題点について考えてみました。
- クラスの肥大化
- 似た処理（考え）が色々な場所に散乱する（DRY原則）
この辺りは説明せずともプログラムを書いたことがある人なら直感的に感じられるところかと思います。
上記の問題点は手続き型プログラミングではUtilクラスを使って解消することが一般的です。Utilを利用すれば、似た処理（考え）は***Utilクラスに集約され、手続きを行う側のクラスも幾ばくかスッキリします。
ただUtilクラスも完璧ではなく、以下の問題点が上げられます。
- データと処理が同じ場所にないので、処理（考え）がどういう使われ方をされるか分からない
- データと処理が同じ場所にないので、ロジックの切り分けの基準がなく、メソッドのスコープは肥大化したり、一つのUtilクラスに大量のメソッドが生まれるなどの悪い凝集に陥る
- 振る舞いの抽象化が出来ないため、ポリモーフィズムが実現できない
ポリモーフィズムは置いておいて、1，2点目に関しては、手続き型言語でいう構造体、所謂データ型を利用すれば解決する気がします。引数は必ずデータ型を利用するとして、一つのUtilは一つのデータ型しか利用できないというルールを設けるという考えです。
もちろんオブジェクト指向言語を利用しているのであれば、わざわざデータ型とロジックを分けて書かなくてもいいし、どうせデータ型を使わずにプリミティブな型で書いている場合がほとんどなのは理解していますが、両者が出来ることを考えた場合、手続き型プログラミングとオブジェクト指向プログラミングの違いは振る舞いの抽象化（ポリモーフィズム）くらいなのかなと思います。
ポリモーフィズムを利用して拡張性に富んだソフトウェアを作ることの利点は理解しますが、これだけで手続き型プログラミングがアンチパターンとされ、オブジェクト指向プログラミングがあらゆる場面で優れていると言うのは自分の中で疑問符が残ります。
上記以外にも抽象クラスを使い、依存関係をコントロールしたり、疎結合を図ったり、ユースケースのみに注目して手続き的に分析するのではなく、ドメインに注目してモデリングを行い、価値のあるソフトウェアを作ろうという考えもあると思いますが、このあたりの話はクリーンアーキテクチャであったりDDDの話なので、オブジェクト指向プログラミングの説明としては正しくないような・・
自転車置き場の議論かもしれませんが、自分が誤った理解をしているような気がしてもやもやします・・
良く分からん！！
どなたか教えてください
手続き型とオブジェクト指向の違いはポリモーフィズムで良い気がしてきました。
ポリモーフィズムを使い拡張性の高いソフトウェアを作る。ある程度作りきりのようなシステムは手続き型でも良いのかなというのが個人的な見解です。