はじめまして。
>いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は
> ・大規模なプログラムの開発でないと効果を発揮しない
> ・プログラムを分割することが大切
> ・デザインパターン（設計）を知らないといけない（？
>という特徴を持っているのではないかと思っています。
デザインパターンはOOPの応用例であって、デザインパターンのためには
OOPを知らないといけないけど、逆は真ではないのではないでしょうか。
GoFのパターンにはある意味マニアックなものもありますし。
>では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で
>（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を
>実践する方法はないだろうか、ということです。
「小規模すぎる」というのがどの程度かわかりませんが、先に例に出した
オセロや、以下のページにおいてあるドローツールなどは、趣味でも
十分作成可能な規模だと思いますがどうでしょうか。
ドローツール「X-Draw」のJavaアプレットによる実行例:
http://kmaebashi.com/nazojava/xdraw/index.html
サンプルソースはこちら:
http://kmaebashi.com/nazojava/index.html
>今自分が目をつけているのが、
> ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」
>というもので、これにのっとって実践を進めれば今ある機能を追加していくと
>いうことでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを
>大きくしていけるのではないかと考えています。
OCPというと、最近Matzにっき経由でこんなページを見つけましたが
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp-2.html
ここの例だと音符クラスを使っていますね。
元祖MayerさんのOOSC(第1版)だと出版物(PUBLICIATION)クラスです。
上に挙げたX-Drawでは、Shape(図形)にdraw()メソッドを付けることで、
プログラムのあちこちにShapeの種類による分岐(Cならswitch case, Pascalなら
case of文ですか)を書くことを避けることができ、図形の追加が容易にできるので、
これはまさに上のページやOOSCで挙げている例と合致していると思うのですが…
ただ、ドローツール程度ではこれでよくても、実際大規模なCADなどでこういう
方法が使えるかといえば、
・draw()といっても、ウインドウシステム等の違いにより描画方法は異なる。
ディスプレイリストを保持するシステムを使うなら、そもそも描画はdraw()じゃないぞ。
・Shapeだからといってdraw()するとは限らない。データをファイルから
読み込んで解析だけして結果をテキストファイルに吐くようなツールだってあるぞ。
という問題もあるわけでして(あっちこっちに書いてるネタですが)。
結局設計に万能の「正解」はなく、たとえば拡張に備えるにしても「どんな拡張が
ありそうか」ということをある程度予測してからでないと設計方針は選べないんじゃ
ないかなあ、と思います。つまらない結論かもしれませんけど。
>ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、
>という理由付けになりオブジェクト指向と呼べるのでは？と思っています。
そうですよね。実のところ私はconcrete classなんざ継承できなくても
よいのでは、と思っていますが、上で出ている例(Note, PUBLICICATION, Shape)は
どれも抽象クラスですし、使用範囲を間違えなければ、有効に使えると思います。