Q&A
すいません「関数」は「命令文みたいなもの」の感じでいいのでしょうか？
JAVAのオブジェクト指向を勉強・練習している者です。
説明が下手ですいませんが、「スッキリわかるJava入門 第2版 (スッキリシリーズ) 」の（P281）「手続き型プログラミングとの違い」のところを復習を兼ねて読み直しているのですが、「手続き型プログラミング」とは
コンピュータがどのように動けばよいかという手順を考え、プログラムの先頭から順番に命令として記述していく方法です。
と書かれているのですが、JAVAも、同じようにプログラムの先頭から順番に命令として記述していき、実行していくと私は思うんですが、（違っていたらすいません）オブジェクト型プログラミングと手続き型プログラミングは厳密には何がどう違うのでしょうか？
又、オブジェクト型と手続き型ではコンピュータ上ではどう動くのですか？
例えばオブジェクト型はコンピュータ上ではクラスのソースコードをコンピュータのメモリ上に展開するのですが、手続き型はコンピュータ上ではどう動くのでしょうか？
わかりやすく教えてくれませんか？
よろしくお願いします。
回答6件
0
「オブジェクト指向型言語」と「手続き型言語」の区分は、論者によっても違ってきます。
- 言語として「メソッド」が登場しない、C言語のような言語だけが手続き型言語
- メソッド以外の関数・コードが書ける、PHPやC++のような言語も手続き型言語に含まれる
- Javaのような、「メソッドの中身を手続き型で書いていく」言語も手続き型言語に区分する
Javaの場合、すべてのコードは何かしらのメソッドとしてオブジェクトに属させるしかありませんが、メソッド内部では実行することを順に書いていくという、手続き型の概念で成立しています。
一方で、「手続き型でない」プログラミングパラダイムとしては、以下のようなものがあります。
- 副作用のない関数を組み合わせてプログラムを構築する「関数型言語」
- 解が満たすべき条件だけを与えて、実際の算出はエンジンに任せる、「制約型言語」（SQLもこの部類です）
（たまに特殊なCPUがありますが）ふつうのコンピュータは「オブジェクトは何か」ということを認識できません。実際に実行する命令は「このアドレスに何を書き込む」とか「このメモリに入っているコードに飛ぶ」といった、ごく簡単な機能のものばかりです（C++のコンパイラは、オブジェクト指向で書かれたコードを、このような形に変換します）。アセンブラといって、実際の機械語を人間が読み書きしやすい形にもできますが、大きなプログラムをアセンブラで直接書くのは現実的ではありません。
一方、Javaのコードは直接マシンで実行するのではなく、Java仮想マシンの上で動きます。この仮想マシンはオブジェクトの概念を理解して動作します。
投稿2017/04/15 08:33
総合スコア146598
0
こんにちは。
Javaのクラスはメソッド（関数の一種）を持っています。
そして、関数は「その関数がどのように動けばよいかという手順を考え、関数の先頭から順番に命令として記述していく方法です。」
つまり、関数＝手続き型プログラミングと言っても良いです。
一般に関数は何らかのデータを取り扱います。そして、複数の関数が１つのデータの塊を操作することにより、何らかの機能を実現することは多いです。（良く出てくる例では、線形リストやソートなどなど）
それらをひとかたまりとしてプログラミングすることが「オブジェクト指向型プログラミング」の本質と思います。関数＝手続きだけでなくデータ構造もセットにするという考え方です。（人によって捉え方は異なります。もう少し様々な機能を使わないとオフジェクト指向とは言えないと言う人もいるかも知れません。）
そして、C言語のような手続き型言語でも、データ領域の獲得と初期化、その領域の解放、それぞれのデータを使って駆動する関数群を定義することはできますし、やっている人は多いです。メジャーなものではlinuxのカーネルなど。
しかし、それらをまとめるための統一的な方法がなく、プリフィックス等の付け方を決めてプログラマが個別に用意します。その実現方法も様々な方法があるので、様々な仕組みが存在しメンテナンスする人はたいへんです。
これに対して、データ構造と関数をまとめてクラスとして定義し、一貫した方法で記述できるような支援のある言語がオブジェクト指向型言語です。そして、現代の多くのオブジェクト指向型言語の考え方はかなり似通っているので、１つのオブジェクト指向型言語を学べば、その知識を他の同様な言語に活かしやすいです。
投稿2017/04/15 08:43
総合スコア23274
0
ベストアンサー
オブジェクト指向と手続き型は相反するものではありません。大雑把に述べれば、オブジェクト指向プログラミングはマクロな考え方、手続き型はミクロな考え方のプログラミングです。
javaでもすべての処理をMainメソッド内に記述しても文法上の誤りはないです。ただし、こうなるともうオブジェクト志向と呼ぶより手続き型に近いものになってしまします。そもそも、オブジェクト指向言語であっても、ソースを書き下す過程は手続き型の考え方が必要です。
逆にC言語(C++やObjective Cは含まない)の中でも、構造体とポインタを駆使し、独自ルールをチーム内で作っていけばオブジェクト指向に相当するプログラミングもできるはずです。
投稿2017/04/15 11:23
総合スコア4853
すいません。「オブジェクト指向プログラミングはマクロな考え方、手続き型はミクロな考え方」とはどういうことでしょうか？
横から失礼します。
マクロ：巨視的、ミクロ：微視的というのはわかりますでしょうか。
砕いていうなら、マクロ：全体的に見た感じ、ミクロ：細部を見た感じ です。
オブジェクト指向は全体で見たときにオブジェクトというデータと処理をまとめた大きな括りを使って、その関わり合いでプログラミングするという、全体視点からの考え方です。
その細部を見ていくと、質問者様の言う通り、上から下に順に処理する手続き型となっています。
はい。大体そんな感じです。
オブジェクト指向プログラミングでは「処理の単位をオブジェクトと呼ばれる単位レベルで考える」ことをベースとしています。ただし、これも突き詰めればjavaVM上での処理レベルの集まりですので、ソースを書き下す段階では手続き型でもあるということになります。
0
他の方も述べられているように別物って訳じゃないですね。
ある時、手続型hogehoge があらわれた。
いま、オブジェクト指向hogehoge に進化した。
って感じでしょか。
要するにできることが増えたってことスな。
個人的には間に 構造化hogehoge を入れたいところ。
こういう連綿と連なっている変化をながめると
なぜそのような形で現在に至るかが分かりやすいと思ってます。
投稿2017/04/15 14:46
総合スコア7468
0
１．オブジェクト型プログラミングと手続き型プログラミングは厳密には何がどう違うのでしょうか？
Java という言語を、すこし厳密に分類すると、「クラスベース・オブジェクト指向を言語仕様レベルで採り入れたプログラミング言語」となります。
同じくクラスベースオブジェクト指向プログラミングが出来る、Java より古い言語に C++ がありますが、これは「クラスベース・オブジェクト指向を言語仕様レベルで採り入れ、手続き指向でも書けるマルチパラダイム・プログラミング言語」となります。
クラスベースのオブジェクト指向プログラミングでは、ソースコード上で、クラスという「手続きと、必要なデータをまとめた入れ物」を定義します。 実行時には、クラスを元にしてメモリー上にインスタンスを生成し、その中の手続きを実行します。
手続き型プログラミングでは、ソースコード上で、データと手続きをそれぞれ定義します。 実行時には、データと手続きをメモリー上に展開し、その手続きを実行します。
1970年代以降、プログラミングに求められる仕事は複雑化・大規模化してきました。 それまで手続き型プログラミングでなんとかやってきましたが、手続きとデータの区別をプログラマー側で気を付けてソースコードを書かねばならないので、「手続きＡでしか触っちゃいけないデータαを、手続きＢで触ってしまう」という事が頻繁に起こってしまいました。
そのため、変数名の命名規則を考えたり、関数名の命名規則を考えたり、人間側でなんとかしようとして色々なコーディング・ルールを作ってきたのですが、所詮は人間のする事ですから、どうしても間違いはあります。
しかもプログラムが大規模であれば、間違いの絶対数も増え、それを探すのも大変です。
プログラムが小規模で、単純なものだけであるなら、手続き型でも問題は起こりにくいのですが、大規模化して、数百人～数千人でひとつのプロジェクト開発をする、という時代になると、もはや「人間側が手続きとデータの分離ルールを作って守る」という方法では追いつかなくなってきたのです。
問題はそれだけではありませんでした。
プログラムが大規模化して、多数の人間が開発に携わると、「同じような手続き」があっちにもこっちにもある、という事が、どうしても発生します。 大規模なプログラムのあちこちで「車輪の再発明」が起こるのです。
「この動作を実現したいんだけど、手続きＡを呼ぶべきか、手続きＢを呼ぶべきか」という迷いも生じますし、機能のアップデートをする際にも、「すべて」を本当に網羅して変更したのか、という疑念も生じます。
それを解決するために、「すべて」を文書化して、全員の間で共有するというルールも必要になってきました。
ものすごく大変な作業ですが、手続き型の世界において、ドキュメンテーションは避けて通れない大きな課題でした。
「同じ事は２度書きたくない」というのはプログラマーの美徳のひとつとされていますが、手続き型プログラミングでそれを守ろうとすると、結局は人間の目でソースコードすべてを追う必要があったのです。
もう「無理ゲー」です。
そこで頭の良い人達は、「手続きＡでしか触っちゃいけないデータαは、『本当に』手続きＡでしか触れないように、プログラミング言語にルールを実装してしまえば良いのではないか」と考えました。
クラスという構造体に、手続きＡとデータαを入れてしまい、その中のデータαは他の手続きからは一切触れないようにする……こういう言語を作れば、プログラマー側でルールを守る必要は無くなるわけです。
実は、かつての大規模開発においては、命名規則や人的ルールの徹底によって、それを実現しようとしていました。 つまり、クラスベースオブジェクト指向という言葉が出来るより以前に、それに近い事を人力でやっていたのです。
クラスベースオブジェクト指向を言語仕様に採り入れた最初の実用的言語は C++ でした。
そのため、C++ は大規模開発の現場から熱烈に歓迎されました。
人間が必死になってルールを守ろうとしなくても、「触っちゃいけないデータをうっかり触る」と、コンパイラーがエラーを出してくれるのですから。
C++ がさらに素晴らしかったのは、クラスに「継承」という機能を持たせた事でした。
クラスベースオブジェクト指向以前の手続き型プログラミングにおいては、複数の手続きで共通の機能があれば、それを別の手続き（関数）として括り出していました。 そのような括り出しを極限まで繰り返せば、プログラムの中で「同じ事を２度書かない」が実現できます。
しかし、括り出した関数「の中で使われるデータ」は、その関数を呼び出す複数の手続きの間で、どう扱えば良いのか、という問題が生じます。 手続きＡが呼び出す関数Ｃと、手続きＢが呼び出す関数Ｃは、同じ関数ですから、関数Ｃではローカルデータを全く持たないようにしないと、動作が保証できなくなります。
ところが、手続きＡの持つデータを関数Ｃで加工したい、手続きＢの持つデータを関数Ｃで加工したい、という要求は、普通によくある話です。
そこでクラスベースオブジェクト指向では、複数の機能で共通する手続きとデータをクラスＣとして定義したあとに、クラスＣを継承するクラスＡと、クラスＣを継承するクラスＢを、独立して定義できるようにしました。
ソースコード上では、それぞれのクラスはただ１度書くだけですが、実行時には、クラスＡを元に生成されたインスタンスＡの中にＣがあり、クラスＢを元に生成されたインスタンスＢの中にもＣがある、という形になります。
クラスは１度書くだけで済むが、必要なインタスンスは実行時に「その時の要請に応じていくらでも生成され、互いの中身には干渉しない」、という仕組みが出来たのです。
いったんこういう仕組みが出来ると、多くのプログラムにおいて、「共通する手続きとデータ」が、どんどん括り出されていって、「このクラスは、こういうクラスから継承されるようにした方が良い」というのが出てきます。
その繰り返しの結果、「もうこれ以上は、『元のクラス』には遡及できない」ような、基底となるクラスが作られ、そしてまた、「基底のクラスから継承したクラス」が再整理されていき、膨大なプログラム機能が、クラスという形で分類されていきました。
その成果のひとつが、Java のクラスライブラリーです。
数多くの手続きやデータが再整理され、基底クラスから継承された様々なクラスが用意されたので、我々は、それらのクラスを「ちょいと借りて」自分の継承クラスを作り、複雑で大規模なプログラムを省力的に作る事ができるようになりました。
「巨人の肩に乗る」を実現した……これもクラスベースオブジェクト指向の大きな功績です。
手続き型プログラミングにおいても、ソースコード・ライブラリーや、オブジェクト・ライブラリーは有ったのですが、「括り出した関数のローカルデータ」問題や、命名の問題が有ったので、クラスライブラリーのような「統一され、一貫性のある『借り物』の仕組み」が実現できませんでした。
上記を端的に言うと、「オブジェクト（クラス、およびクラスから生成されるインスタンス）という概念を採り入れる事によって、大規模な開発を迅速かつ、少ない間違いで出来るようにした」……これが手続き型との違いです。
ぶっちゃけ、おおむね 1K行以下の小規模開発なら、オブジェクト指向は要らない、と言っても良いでしょう。
C++ は「マルチパラダイム言語」なので、手続き型でもプログラムが書けて、クラスベースオブジェクト指向でもプログラムが書けます。 クラスの無いプログラムも書けるし（手続き型指向）、クラス有りきのプログラムも書けるので、小規模開発でも大規模開発でも対応できるわけです。
Java は「クラスベースオブジェクト指向言語」なので、クラス有りきのプログラムしか書けません。 小さな関数ひとつで済むようなプログラムでも、必ずそれをクラスに入れなければコンパイル出来ません。
C++ に比べれば不自由ですが、「間違う自由」を捨て去った、とも言えます。
２．オブジェクト型はコンピュータ上ではクラスのソースコードをコンピュータのメモリ上に展開するのですが、手続き型はコンピュータ上ではどう動くのでしょうか？
手続き型では、ソースコードに書かれた手続きとデータをコンパイルして、メモリー上にバイナリー・データの形で展開し、それを CPU が読み取って実行します。 手続きは「上から下へ」と流れるのですが、「括り出した関数」や、「手続きＡが手続きＢを呼び出す」などのように「プログラムの中でジャンプ」するという事がしばしばあります。
（クラスベースオブジェクト指向においても、クラスの中に書かれた手続きにおいては、手続き型と同じ様な動作をします）
クラスベースオブジェクト指向では、ソースコードに書かれたクラス（手続きとデータが書かれている）をコンパイルして、メモリー上にバイナリー・データの形で展開し（これを特にインスタンスと呼ぶ）、それを CPU が読み取って実行する、という点は手続き型と変わりませんが、
クラスＡをメモリー上に展開したインスタンスＡの中には、「クラスＣを展開したインスタンス」も含まれていますし、
クラスＢをメモリー上に展開したインスタンスＢの中には、「クラスＣを展開したインスタンス」も含まれています。
手続き型においては、すべての関数は「それひとつ」しか無いのですが、継承したクラスが有るオブジェクト指向プログラムを実行する時においては、上記のように「クラスＣが持つ手続きとデータ」は、継承先のクラスの分だけ、複数独立して存在します。
さらに、クラスＡやクラスＢが、さらに別のクラスに継承されて、実行時に動的生成される（Java では new する事）ようなものなら、メモリーのあちこちに独立したインスタンスＡとインスタンスＢが存在し、それぞれバラバラに実行される事になります（もちろんそれらの中にはこれまた独立した「クラスＣを展開したインスタンス」もある）。
すでにお分かりと思いますが、クラスベースオブジェクト指向においては、手続き方と比べて、ソースコードを書く手数は減るのですが、メモリーの消費量はバンバン増えます。
使えるメモリー量が今より少なかった昔の時代においては、クラスベースオブジェクト指向は「富豪的なプログラミング技術」でしたが、今はメモリーが大量に使えるので、この点はほとんど問題にならなくなりました。
コンピューターやメモリーの負荷が多少増えたところで、人間側の手数が減るメリットの方がはるかに大きい、と考えられる時代になったのです。
とは言え、節約できるメモリーが有るなら節約した方が良いのは当然で、そのために静的オブジェクトというものも考え出されました。
これは、メモリー上にただひとつしか展開されないインスタンスです。
もし、クラスＣが、「いつでもどこからでも呼び出せるような、手続きしかない内容」であったなら、クラスＣを静的オブジェクトとする事で、プログラム実行時の全体メモリー量を節約できます。
（了）
投稿2025/05/30 23:36
総合スコア90
0
オブジェクト指向型プログラミングと、手続き型プログラミングの厳密な違いについては、「オブジェクト指向プログラミングとは～」といった結論の出ない問いを土台にしており、回答することは難しいです。
せいぜい、Javaはオブジェクト指向型、Cは手続き型、のようにプログラミング言語で「やんわり」理解するのがよいでしょう。
オブジェクト型と手続き型ではコンピュータ上ではどう動くのですか？
この問いに対しての直接的な回答は「コンピュータ上での動きに違いはない」です。
現行のコンピュータはすべてノイマン型コンピュータであり、その動作はプログラム言語の違いによってなんら影響を受けません。
オブジェクト型はコンピュータ上ではクラスのソースコードをコンピュータのメモリ上に展開する
コンピュータのメモリ上にどのようにプログラムを展開するかは各言語のコンパイラなりに依存しており、オブジェクト指向型だから～といった決まりはありません。
オブジェクト指向型とか手続き型とは、プログラムを作る上での方法論のことです。
なので、最初のステップとしては Java 言語でプログラミングをしているのであれば(とりあえず)オブジェクト指向型でプログラムを組んでいると考えて先に進めばよいでしょう。
投稿2017/04/15 09:59
総合スコア938
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。