K.Maebashi's BBS 投稿フォーム

ハンドル名
件名
Link

>こんにちは。
>
>>いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は
>>  ・大規模なプログラムの開発でないと効果を発揮しない
>>  ・プログラムを分割することが大切
>>  ・デザインパターン（設計）を知らないといけない（？
>>という特徴を持っているのではないかと思っています。
>
>私は、上記のどれもオブジェクト指向の特徴を表していないと
>思います。
>以前ここの掲示板でオブジェクト指向のポイントは、以下の
>２点であるという結論になっていたと思います。
>1. データの抽象化
>2. マルチプルインスタンス
>何ができれば、オブジェクト指向になるのかは難しいと思いますが、
>上記の２点はオブジェクト指向を語る上で重要だと思います。
>あと、データのアクセス制御(制限？)なども重要だと思っています。
>
>
>>では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を実践する方法はないだろうか、ということです。
>>
>>今自分が目をつけているのが、
>>  ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」
>>というもので、これにのっとって実践を進めれば今ある機能を追加していくということでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを大きくしていけるのではないかと考えています。ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、という理由付けになりオブジェクト指向と呼べるのでは？と思っています。
>>
>>しかしそのためには手続きを分節化し、プログラムを設計する能力がいるだろう、と思っています。
>>このような場合に、デザインパターンが有効なのだと思いますが、具体的にどうプログラムを組むのか、というところで自分は躓いている状況です。
>
>私は普段オブジェクト指向言語を使用していないのですが、
>オブジェクト指向を意識したプログラミングをしています。
>小規模であっても、手続き型言語であってもオブジェクト指向的
>発想は可能です。
>例えば、GUIのいくつかのパーツがあって、これらが互いに依存しあう
>場合、これら同士でお互いを直接呼び出さないようにします。
>必ず親(Mediator)を作って、間接的に制御します。
>こうすることで、依存関係を親側に集中化でき、単純化できます。
>これの本質部分は、全くオブジェクト指向は関係ありません。
>GUIパーツ自身は、本来自分がやるべきことのみ
>やらせるようにします(単一責任の原則)。
>
>あと、OCPにより、小さなプログラムを大きくしていける
>(コードを再利用する)というのは、私はそんなに単純ではない
>と思います。
>OCPとは、つまり、上側のコードの再利用であり、下側の
>コード(処理やデータなど)を追加のみするということですが、
>それが、そんな単純にうまくいくなら、トップダウンの
>開発が重要ということになります。
>仕様変更によるプログラムへの影響は多くが、より上側の処理
>であり、より下側の処理の方が再利用の確率は高いと
>思います。
>プログラムを大きくしていく秘訣はいかにプリミティブな
>関数など(より下側の処理)を充実していくかとか、
>いかにモジュール化により、プログラムを分割していくかに
>よると思います。
>
>そもそもOCPは、オブジェクト指向言語だけでは不十分で、
>例えば、ログの処理やエラー処理が入ると
>それだけで処理の「汎用性」が失われ、OCPが成立しません
>(例えば、エラーを出すタイミングを変えるなど)。
>アスペクト指向言語があれば十分かは分かりませんが、
>あらかじめ仕様変更を予想してOCPが成立するように
>再利用可能なコードを組むのは現実的には不可能だと思います。
>但し、局所的に(場合によって)は、うまくいく時ももちろんあります。
>

spamよけのため、ここに「ほげぴよ」と入力してください。

削除パスワード : クリック！