プログラミング・パラダイム
結局、「オブジェクト指向プログラミング（OOP）」というのは、1) 手続指向は構造化で、2) データは構造体で、ということであり、この両者を、3) 構造化された手続（メソッド）を、構造体（オブジェクト）単位で整理することでまとめた、というだけの話であり、これ以上でもないし、これ以下でもないのではないかと思う。
手続自体は、あくまでも構造化プログラミング的な観点で整理を行なうべきで、これを生半可なオブジェクト指向的観点で整理すると、コードが無茶苦茶になって却って“百害あって一利なし”といっても言い過ぎにはならない気がする。少なくとも、自分の場合はそうである。
そうやって、構造化プログラミング的にすっきりと整えられた個々のコードが、集合して複数のコード群としてそのままそこいらにぶちまけられている時に、手続指向の限界が急にクローズアップされてくる。
この時に整理整頓の“容れ物”として俄かに脚光を浴びることになるのが、構造体（オブジェクト）である。手続のためのコードをそのまま“裸”でそこいらにぶちまけては置かないようにしよう、必ず、構造体に入れられた（カプセル化）状態で置いておくことにしようね、というのが僕流のオブジェクト指向像である。
上のことをちゃんと自覚していないで、「オブジェクト指向スゲー」で何でもかんでもオブジェクト指向のノリを持ち込もうとすると、むしろコードの見通しが悪くなって、あっちへ飛んだり、こっちへ飛んだりと、ダイクストラ先生が「goto は使わないようにしよう」といった時代の事情に逆戻りして、あっちのメソッドこっちのメソッドを飛び回るような、いわば「goto なきスパゲッティ化プログラミング」に陥ってしまう。
新しいコードをスクラッチで組んでいく時、ここは手続指向で素直に、一つ一つの処理を継ぎ足して行ってプログラミングするのが、やはり王道なのではないかと思う。そしてそのコードが伸びるにつれ、（2回以上）多用される同様の処理は、サブルーチンとして分離する。そのことで、「コードをコピー＆ペーストして使い回すことを避ける」というのが、構造化プログラミングの単純かつ肝となる原点だと思う。ある処理に関するコードが記述される場所を一元化することで、後に変更の必要が生じた時に、あちこちを修正して回るというようなことは避けないと、例えば、一部を修正し、一部は修正し漏らしていたりした場合に、バグを生む。
まずは、メインルーチンという一本道のコードに立ち戻って、そこから構造化的にサブルーチンを分離するという作業に立ち返るのが重要である。構造化の後、構造体の容れ物に構造化された手続ルーチンを収納するところまで終ったとする。次に、類似の別のクラスを作成する場面になり、既に完成されたクラスを意識して内部の一部の処理をいじって済ませようとするのだが、不思議なことに大概が上手くいかないのである。仕方がないので、オブジェクトというカプセル化されたシャーシ（筐体）をひっぺがして、手続指向的に一本道的な処理から一つ一つを確認して組み直していくと、面倒な作業のようでいて、不思議とスーッと進められていく。一つ一つ新しい処理を継ぎ足していくだけなのだから、「どこに問題があるのだろうか?」と悩んで、四苦八苦する苦労がないのである。
つまり、オブジェクト指向という、カプセル化作業は、あくまでも、内部処理が完成してから行なうべきであって、内部処理のコーディング作業が終ってない段階から、カプセル化の部分を並行して、混ぜて、作業を行ってはいけないのである。
この手続指向部分で作業を行なう段階と、オブジェクト指向で作業を行なう段階との間には、厳然たる断絶があって、互いの領分と先後の序列はキッチリと守られるべきであると思うのだ。例えば、同じ「食べ物」に関する産業でも、農業の分野と、外食産業の分野で、全く人材人種が別個であるというような、そのくらいの世界の違いが。農家の人に、「このレンコンは、洗ってお客様に出すから、最初から泥が付かない状態で育てておいて！」などと要求する料理長がいたら、レンコンが育つのだろうか？ と。農家の人は作物を見てるし、料理人はお客さんを見ている。それぞれの立場によって、最適な視点というものが違う。世界に単一の視点（パラダイム）を押し付けようという発想こそが邪悪な根性なのだ。
コメント
コメントを投稿