手続き型プログラミング言語とは

手続き型プログラミング言語とは?その特徴やオブジェクト指向言語との違いを分かりやすく解説

どーもー、現在某IT系の会社でjavaエンジニアとして働ている者です。(当ブログの管理人です)

現在、エンジニアやプログラマーとして働いている方や、PHPやRuby、Java等、何かしらのプログラミングを学んでいる方であれば、一度は「オブジェクト指向」や「手続き型言語」といったキーワードを聞いたことがあると思います。

プログラミング言語というのは、大きくこの2つに切り分けることができます。

・手続き型言語 : C言語、COBOLなど

・オブジェクト指向言語 : Java、PHP、Rubyなど

とはいえ、これらに対して、明確に理解している方は意外と少なかったりするのではないでしょうか。

「何となく、イメージできる」程度の人も、かなり多いかと思います。

というわけで、今回のこの「手続き型言語」について、基本概念やメリット・デメリットについて。

また、代表的な手続き型のプログラミング言語についても、まとめてみました。

ちなみに、オブジェクト指向については、以下にて詳細にまとめているので、こちらもぜひ参考にしていただければと思います。

→ オブジェクト指向とは?プログラミングする上でのメリットや、java言語での例題を交えて分かりやすく解説

以下、目次です。

  1. 手続き型言語の概念について
  2. 手続き型プログラミングの特徴 ~オブジェクト指向言語と比較したメリット・デメリット
  3. 手続き型言語の、代表的なプログラム言語:5選

手続き型プログラミング言語とは何?基本概念について分かりやすく解説します

手続き型プログラミング言語の基本概念-1

手続き型言語とは、上図のように、プログラムが動作する内容を、一から順々に(左から右へ流れるように)構成していく事を特徴としたプログラミング言語となり、C言語をはじめ、多数のプログラミング言語の特徴となっています。

処理の1まとまりのことを、「手続き、関数、サブルーチン」などと呼び、多数の「手続き(関数)」の集まりによって、システムが構成されています。

一つ、例を出します。

例えば、「会社員が朝起きて、会社に行くまでの流れ」を、手続き型言語で表現すると、

  1. 朝起きる
  2. 朝食を食べる
  3. 家を出る
  4. 電車に乗って、通勤する
  5. 会社に出社する

上記のような流れになり、一つ一つの項目が、「手続き、関数、サブルーチン」となります。

何となくイメージできたかと思います。

このように、1まとまりの処理を、順番に実行していくのが、手続き型プログラミング言語の特徴となります。

手続き型プログラミング言語の特徴 ~オブジェクト指向言語と比較したメリット・デメリットのまとめ

手続き型プログラミング言語のメリット・デメリット-1

続いて、手続き型言語のメリット・デメリットについて、オブジェクト指向言語と比較したうえで、まとめていきたいと思います。

まずは、メリットから。

  1. 「プログラムが理解しやすい(学習コストが低い)」

    上述の通り、手続き型言語は、一から順々に処理が流れていくようにプログラムが構成されているので、その順番通りにプログラムを確認していけば、理解できるようになっています。

    なので、何かしらのシステムのプログラムを理解しようと思ったときに、理解しやすいのが特徴となっています。

    逆に、オブジェクト指向言語は、プログラムが各部品(オブジェクト)ごとに構成されており、大規模なシステムだと、数万・数十万といった部品で構成されることになります。

    そして、部品同士での複雑な関係性もあったりするので、プログラムの全体像を把握するのに、かなり時間が掛かってしまうのが、オブジェクト指向言語の特徴となります。

  2. 「小規模なシステム開発に向いている」

    例えば、プロジェクトのメンバーが自分1人とか、簡単に開発できそうな小規模なシステムとかであれば、手続き型言語が向いているでしょう。

    上述の通り、順番通りに動作する関数を、一つ一つ順に作成していけば良いだけなので、開発作業としても、単純に進めていくことができます。

    逆に、オブジェクト指向言語の場合は、開発作業に入る前に、以下のような事を決める、設計作業がどうしても必要になってきます。

    ・システムを構成する上で、どのような部品(オブジェクト)が必要となり、部品同士の関係性をどのように定義するか。

    ・データや機能が被っている部品が無いか。

    ・また、各部品が共通で利用できそうなデータや機能は無いか。そして、共通で利用する部品を作成した時に、再利用やカスタマイズはしやすくなるのか。

    オブジェクト指向では、この設計作業がめちゃくちゃ重要になってきます。

    一方、単純なプログラム構成を特徴とした手続き型言語の場合は、このような設計作業をしなくても、開発を進めていけるメリットがあります。

    ※ただし、大規模なシステムとなると、プログラムの再利用性やカスタマイズ性が高い、オブジェクト指向言語の方が向いてきます。

以上、手続き型言語のメリットでした。



続いて、(オブジェクト指向言語と比較した)デメリットについても、解説していきます。

  1. 「プログラムの再利用性やカスタマイズ性が低い」

    手続き型言語でも、システム内で、同じことをする処理(関数)があれば、それを「共通処理」として、再利用することは可能です。

    例えば、上述の例に出した「会社員が朝起きて、会社に出社する」というプログラムであれば、

    会社員一人ではなく、全員分のプログラムを作成する場合、「朝、起きる」とかは、共通で利用できますよね。

    ただ、次のステップの「朝食を食べる」を、以下の選択肢に変更する場合

    ・パンを食べる
    ・米を食べる
    ・そもそも朝食を食べない
    ・それ以外

    この場合、会社員の一人一人、全員分のプログラムを修正する必要があります。

    また、朝食を食べた後に、「歯磨きをする」というステップを追加したい場合だったり、

    「朝起きてから、出社するまでに出会った人間の数」をカウントしたい場合・・・同じように全員分のプログラムの修正が必要となります。

    ※オブジェクト指向言語でも、全員分のプログラムを修正する必要はありますが、手続き型言語と比較すると、修正する手間をだいぶ減らせる事が可能です。

    詳細は以下にまとめていますが、専門的な話になるので飛ばしてもらっても良いです。

    手続き型言語とオブジェクト指向言語の違いで最も重要なポイントは、

    「データの保持を、どこでするのか」といった点です。

    ※関数については、どちらも共通化できるから、ほぼ差異はありません。

    オブジェクト指向言語の場合は、New(インスタンス化)すれば、インスタンスごとにデータ(「状態」とも呼ぶ)を保持することが可能ですが、手続き型言語では、それができません。

    手続き型言語では、関数内のローカル変数か、関数の外のグローバル変数でしか、データを管理することができないのです。

    上述の例で言うと、

    1、「朝食を食べる」 → 「パンを食べる・米を食べる・それ以外・そもそも朝食を食べない」という選択肢に修正

    オブジェクト指向プログラミングの場合・・・New時の引数に選択値を追加するだけで、関数呼び出し時のパラメーターはそのままで良いです。(呼び出し先のクラスにて、選択値のデータ(フィールド)を一つ追加して、そのデータを元に、関数内で分岐させれば良い)

    手続き型プログラミングの場合・・・関数の呼び出し時のパラメーターに、選択値のデータを一つ追加する必要が出てきます。

    また、呼び出し先のクラスにてデータ保持ができないため、呼び出し元で、選択値の設定をしなければいけません。。

    2、「歯磨きをする」というステップを追加

    関数の追加に関しては、基本的に、どちらでも修正する手間は変わりません。

    3、「朝起きてから、出社するまでに出会った人間の数」をカウントしたい

    オブジェクト指向プログラミングの場合・・・呼び出し先のクラスにて、カウント値のフィールドを追加して、そのインクリメント関数を追加するだけで。(呼び出し元では、関数の呼び出しだけで良い)

    また、シングルトンで実装すれば、別スレッドにも、カウント値を引き継ぐ事が可能です(マルチスレッド環境の場合)

    一方、手続き型プログラミングの場合・・・カウント値は、呼び出し元で管理しないといけません。そして、引数を介して、インクリメント関数に、値を渡す必要があります。

    また、別スレッドに、カウント値を引き継ぐ事は不可能なので(オブジェクト指向のように、メモリでインスタンスの状態(フィールド)を保持できないので)、ファイルやDBを介する必要が出てきます。

    ※C言語であれば、(ポインタ操作により)メモリに直接カウント値をセットすればいけるかも。。

  2. 「システムの保守やカスタマイズが大変」

    こちらも、上記に関係してくるポイントになりますが、

    手続き型言語によって構築されたシステムに対して、何かしらの修正(カスタマイズ)が必要になったり、何かしらのエラーが起きた際、その原因の追究や対応が必要になった時に、

    オブジェクト指向言語と比較すると、手間がかかる傾向にあります。

    それは、手続き型プログラミングの場合、データ(変数)のスコープが、ローカル or グローバルの2通りしか無いからです。

    そのため、「カスタマイズ」が必要になった場合に、修正箇所や影響箇所が非常に多くなったり、エラーが起きた場合にも、同じことが言えます。

    特にスコープがグローバルのデータを修正したり追加したりする場合、プログラム全体に影響することになり、どうしてもコストが掛かってしまう傾向にあります。

    逆に、オブジェクト指向の場合は、インスタンス(クラス)ごとに、データを保持することが可能なため、手続き型言語と比較すると、影響範囲を小さく抑えることが可能となります。

    (専門的な話になるので、よく分からない人は、「カスタマイズや保守が大変なんだな、、」という理解で、ココでは大丈夫です。)
  3. 「多くのメンバーが関わる大規模なシステム開発には向いていない」

    こちらも、上述の内容と関係してくる部分となりますが、

    手続き型言語は、オブジェクト指向と比較すると、どうしてもプログラムの「まとまり」が薄くなってしまうため、

    その分、チーム内での共有・連携がしにくかったり、分担作業がやりにくくなってしまいます。

    オブジェクト指向プログラミングの場合、データ(状態)も含めて、関数とともに、部品(まとまり)化することが可能となるため、

    再利用性が高い共通部品を誰かが作成しておけば、他のメンバーは、それを利用すれば良いだけになるので、チーム全体の開発の効率化に繋がります。

    一方で、ちょっとした処理を実行するだけの簡単なプログラム開発であれば、手続き型プログラミングの方が向いています。(開発に入る前の、設計作業(クラス設計など)が必要ないため)

以上、手続き型プログラミング言語のデメリットまとめでした。

※オブジェクト指向プログラミングについては、以下でも詳細にまとめているので、ぜひ参考にしてください。

→ オブジェクト指向とは?プログラミングする上でのメリットや、java言語での例題を交えて分かりやすく解説

手続き型言語の、代表的なプログラム言語:4選

手続き型のプログラミング言語まとめ-1

最後に、手続き型言語の代表的なものを以下にまとめてみました。

  1. 「C言語」

    こちら、手続き型言語の中では、最も有名な言語となります。

    歴史も古く、様々なプログラミング言語が、この「C言語」を参考にして作られています。(Javaや、C++、C# など)

    非常に有名な言語なので、聞いたことがある方も多いでしょう。

    誕生したのは1972年で、AT&Tベル研究所のデニス・リッチーという方が中心となって作成されたそうです。

    現在でも、ソフトウェア開発からコンピューター機器、自動車などのハードウェア製品など、様々なところに採用されております。

    大学や専門学校など、プログラミングを学ぶ場で、採用されている事も多いですね。(私も授業で最初に学んだのが、C言語でした)

  2. 「COBOL」

    1959年誕生と、C言語よりも歴史が古いものとなります。(おそらく、プログラミング言語の創成期くらいのものかと思います)

    当時53歳の女性のプログラマーによって、開発された言語らしいです。

    「時代遅れの言語」と揶揄されがちなイメージですが、現在でも、銀行などの金融系システムに多く使われており、金融業界では需要が高い言語となります。

  3. 「BASIC」

    こちらも、歴史が古い言語になります。

    1964年当時、米国のダートマス大学のジョン・ケメニー氏と、トーマス・カーツ氏によって開発された手続き型プログラミング言語とのこと。

    マイクロソフトの開発言語として有名な、VB(Visual Basic)は、このBASICから派生した言語になります。

  4. 「Perl」

    こちらは、上述の他の言語と比較したら、まだ歴史が新しい言語になります。(といっても、1987年の開発なので、”新しい” とは言えませんが。。)

    Perlは、スクリプト言語として有名な手続き型言語で、サーバー内で、簡単な処理をさせたい時に、よく利用されています。

以上、手続き型言語の、代表的なプログラム言語:4選でした。

というわけで、ここまで手続き型言語の特徴やメリット・デメリットについて解説してきましたが、

現在、プログラミングを学んでいる方であったり、今後に学んでいこうと思ってる方の、参考になっていれば幸いです。では。

コメントを残す

メールアドレスが公開されることはありません。