オブジェクト指向でないプログラムってどんなのですか

オブジェクト指向はそれぞれのインスタンスに属性とオペレーションがあるのがわかりましたが、そうでないプログラムの仕組みなんてありえるんですか？
Aを動かす為にBを押したらCがAを動かしてくれたって物を作ろうとしたときにそれぞれをオブジェクトとする以外に方法は無いような気がしますが。
ものを作るときって部品を組み立てたり作用させたりすると思うので、それ以外の組み立て方法ってどうやるのでしょうか？

No.4 ベストアンサー 回答者： jjon-com 回答日時： 2011/04/13 01:23

> それぞれをオブジェクトとする以外に方法は無いような気がしますが。

オブジェクト指向における「オブジェクト」って，自律的なモノであって，単なる他動的なモノではありません。
ですから，前者以外に方法は無いような気がします，という問いに対しては，後者の方法があります，と回答できます。

----------------
例えば，次のようなコードが書けるオブジェクト指向言語があるとします。
（相当いいかげんです。プログラムに詳しい方，ご容赦ください）

　　A = new クラス(リスナーC)
　　A.動け(イベントB)

このオブジェクト指向言語では，次のように機能することを想定しています。

・インスタンスAには，イベントを感知する機能Cが組み込まれた。
・リスナーCは受け取ったイベントBを解釈して適切な動きのパターンを決める。
　他の知らないイベントに対しても適切な動きのパターンを決められる。
・Aは自分に対する「動け」というメッセージとそのパターンに対して
　自分がどうすればよいのか知っている。
・（例えば）Aが動くことによって盤上から外れてしまったり，
　Aが動く先に敵がいたりしても，Aは自分がどうすればよいのか知っている。

質問者自身がおっしゃっているとおり，インスタンスAは自身についての属性と操作をともに内蔵しており，それ自身が独立したインテリジェンスを持つ擬人化されたモノ，すなわちオブジェクトなわけです。

----------------
それに対して，非オブジェクト指向な言語ですと，こんなコード例が想定できます。

　　動け(A, リスナーC, イベントB)

このコードのポイントは，
Aが自律性を持つオブジェクトではないため，すべてを単なる「操作対象」として他動的に扱うしかないということ。

変数とリスナーの組合せは適切か？　リスナーとイベントの組合せは適切か？　変数とイベントの組合せは適切か？　各組合せのパターンに対応してそれぞれどう動けばよいのか？　自身の盤上の位置や敵の位置によって動きはどう変わるのか？　等々…

これらをすべて「動け」プログラムの中に記述することで，前者と同等の機能を持つシステムを作ることができます。

----------------
単純なイメージで説明するならば。

ひとかたまりのシステムを実現するのに，
「この機能はすべて○○に任せる。俺は○○に指示するだけ。あとは○○が責任を持って立派にやってくれるようにしておいた」というスタンスなのがオブジェクト指向。

「このシステムの機能はすべて俺が管理する。モジュール分割などして管理しやすい工夫はするけれど，システム要素のすべてを把握しておりそれに指示できるのは俺一人」というスタンスなのが「手続き型」という非オブジェクト指向の代表例になります。

No.3 回答者： red-signal 回答日時： 2011/04/13 00:30

文面から想像しますと「オブジェクト指向」を理解されてない気がします。

オブジェクト指向の「オブジェクト」とは、あえて簡単に言うと、関数やサブルーチンです。
関数やサブルーチンは、必要な時に何度でも繰り返し使えます。
また、これをベースに新機能を追加して拡張することが出来ます。
つまり「オブジェクト指向」とは、関数やサブルーチンを使い回すことです。

と前置きしまして、質問の「オブジェクト指向でないプログラム」にお答えします。
オブジェクト指向でないプログラムとは、関数やサブルーチンを一切使わずに、同じ処理（コード）をその都度書くプログラムです。


続いて・・
　　>それ以外の組み立て方法ってどうやるのでしょうか？
にお答えします。

例えば、
プログラムの中に、消費税を計算する工程が沢山ある場合、
オブジェクト指向ではこの計算式を自作の関数に置き換えます。
プログラムが短くスッキリします。
また税率が変更した時には関数を修正するだけで簡単です。

一方、オブジェクト指向でないプログラムは
消費税の計算式を毎回書いて、税率が変われば全部の計算式を修正するのです。


※やや強引な説明ではありますが、分かり易く言うとこんな感じです。

No.2 回答者： axel_eye 回答日時： 2011/04/11 10:40

ソフト屋さんではないので、厳密な事は言えませんが、

オブジェクト指向とは、そもそもプログラムではなく、設計手法などの方法論ではないでしょうか？
方法論ですので、その作法に習って設計すれば、どのような言語を用いてもオブジェクト指向っぽく記述する事は可能かと思います。

オブジェクト指向っぽく、記述できると言うだけで、オブジェクト指向を適用しやすいと言われるC++であってもオブジェクト指向でないような記述も出来ると思います。

では、どこまでがオブジェクトか？
と、言われると定義の中に粒度は含まれていないような気がします。

ある人がこれは、オブジェクトだと言っても、他の人が違うと言うような事も起こり得ると思います。
と、なると、結局の所、何かを作る際に、チームやグループでその粒度と言うものを定義する必要が出てくるように思います。

しかし、粒度を決める作業にいちいち時間をかけていたら、それこそ生産性が下がりますし、合理的ではないことが多いと思われますので、各人にオブジェクトの粒度自体の定義は任されているように思います。

さらに言えば、オブジェクト指向では設計が難しい物もあると思います。例えば、同じ属性が複数のクラスにまたがる場合などです。複数のクラスにまたがる属性をわざわざ複数のクラスで記述していたら、それこそ合理的ではありません。そのような状況を回避するために、アスペクト指向などと言う方法論もあったりします。

個人的な認識では、オブジェクト指向という考えが主流になってきたのは1990年代後半かと思います。それ以前にも確かにオブジェクト指向という考えはあり、具体的な言語として個人的に知ってるのはEiffelという手続き型言語ですが、余りもてはやされてなかったようにも思います。

これらの時代背景を捉えると、オブジェクト指向と言う考えが主流でなかった時代からあった言語はオブジェクト指向では無いとも言えますし、どのような言語でもアスペクト指向で記述できると思いますから、オブジェクト指向ではなくアスペクト指向だと言う事も可能かもしれません。

しかし、やはり、オブジェクト指向という言葉は、設計手法などの方法論の一つだと思いますから具体的レベルに落ち込む物では無いように思います。

No.1 回答者： ID10T5 回答日時： 2011/04/11 08:19

アセンブラ。

レジスタやメモリにデータを転送したり、割り込み入れたり、サブルーチンコールする前にレジスタの値をスタックに飛ばしたり。