手続き型コードベースの複雑さを管理することを念頭に置いて作成された

• しかし、手続き型より優れている証拠はない

オブジェクト指向が解決しようとした問題

• 階層構造を持ったオブジェクトを作り、管理する
  • 現実では「動物→犬、人間」のようなきれいな階層構造を持つ
  • （複雑な）アプリケーションでは必ずしもそうではない

デザインパターンが同時にもてはやされた

• メリット
  • 共通認識が作られる
• デメリット
  • 複雑なオブジェクト間の関係を持つ
    • 一連のまとまった処理だったはずが、オブジェクト指向によってプログラム中に散らばってしまった
  • 単なる経験則であり一般化された数学的論拠がない
  • デザインパターンを学習しなければ理解できない構造はそもそも良くない

人間の思考は「関数」ベースである

• 〇〇をする
  • 散歩に行く
  • 友達と話す
  • ピザを食べる

世界を抽象オブジェクトの複雑な階層に組織化はしない

オブジェクト指向は冪等性がない

• 同じ入力に対して同じ出力が得られることは保証されていない
  • オブジェクト内部の値（時間）によってそれらは変化する

使い所を間違えなければ未だに良い考え

• 状態の変更はオブジェクトへの依頼という方法のみで行う、強い制約をつけたモデル
  • 単純なオブジェクトであればこれによって扱いやすいことは多々ある

参考

• 現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
• オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある
• 関数型プログラミングはオブジェクト指向プログラミングに変わるパラダイムになると思いますか？
• 一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？