OOPがカプセル化、継承、ポリモーフィズムではない理由、または私がマークアップを心配せず、愛していないことを学んだ理由

みなさんこんにちは！

ご列席の皆様、この記事では、 オブジェクト指向プログラミングとデザインからどれだけひどく燃えるかについて説明します。 最も可能性が高いのは、doherとtrochkaに似ています。 正直なところ、私はあまりグーグルしませんでしたが、最小限の試みをしました。 希望、提案を含むコメントへようこそ とドラックス 。

表記と用語

単語がカプセル化、継承、多態性などの場合 太字で示されている場合、作成者は開発者ツールを意味します。

カプセル化、継承、ポリモーフィズムなどの場合 イタリア人によって強調され、これはすでに深い哲学です。

オブジェクトに線が引かれている場合、 オブジェクトとしてのオブジェクト 指向プログラミングの概念の観点から検討する必要があります 。

本文でこれがすべてであることに気付くなら、あなたはインターフェースを持っています 。

そのような線で強調され、イタリア語で強調表示されているアクションがある場合 、これはオブジェクトが生成するアクションです（接続は構文構造を通して見ることができます）。

一部のテキストが次のように強調表示されている場合、これはデザインパターンです。

簡単な紹介

私の意見では、OOPの主な問題は、間違った側から理解されることです。

残念ながら、21世紀には、戦争への性的指向が日々成長しており、情報空間は、昨日彼が旋盤で鉄片を回転させていたように、同様の物語で満たされているだけです。黄金の山を手に入れました。 OOPとは何か、 カプセル化、継承、ポリモーフィズムとは何か、そして運がよければ説明します。 そして、そのようなOOPとはどんな獣なのか。

彼は欠員の中でPLOの原則を理解するための要件を定期的に見ていました。 さらに、雇用主自身はOOPが何であるかを特に理解していません。 インタビューの中で、 OOPとは何なのかをまったく聞いたことはありませんが 、 カプセル化、継承とポリモーフィズム、アクセス属性、継承との連携、およびターゲットテクノロジーのその他の技術的な詳細について尋ねられました。 すべてうまくいきますが、欠員は非常に深刻であり、これではなくプログラミングとアルゴリズム化の深い理解が必要です。

私は自分の国で最高の学部の1つで勉強しましたが、OOPコースは.NETプラットフォームのフレームワーク内でそれを使用する方法でした。 カプセル化、継承、ポリモーフィズム 。 しかし、実際のOOPの低下ではありません。 ところで、これは現代のIT教育の最も深刻な問題の1つです。 ちなみに、これまで、私がストリームで勉強した人たちは、このOOPの使用方法を複製していません。そして、あなたのコーデックにはたくさんの無用な工場といくつかのひどい依存関係があります。

私は自分自身にインタビューし、人々にOOPをどのように理解しているか尋ねました。 クラス、オブジェクト、インターフェイス、アクセス属性、カプセル化、継承、ポリモーフィズムなどについて説明を受けました。 さらに、OOPの主なアイデアと利益が何であるかを誰かが明確に答えることはできません。 ただの愚か者が集まって、3つの複雑な言葉を思いついたが、今では誰もがアイコンのようにねじ込んでいる。

OOP自体

まず、私が実際に何を意味するのかを理解しましょう。 全世界はオブジェクトを考えています。 椅子、テーブルに 座って、 カップからコーヒーを飲みます。 あなたはオブジェクトの世界に存在し、それらの間で生きています。 あなた自身とオブジェクト。 まず、 オブジェクト指向プログラミングの概念は、人が自分の周りの世界を見て理解する形でプログラムを描く最初の試みです。 少し深く考えると、これはコンピューターに人間のように考えるように教える試みです。 OOPの快適な特性はこれに由来します-それは本当に人々に理解できます。 簡単な例を見てみましょう。

カップを取得したいとします。 最も多様。 プログラマーではない母の観点から、さまざまなカップ、マグカップ、グラスを注文に応じて生産する工場を建設したいと考えています。 私の観点からすると、プログラマーとして、さまざまなコップ 、 マグカップ 、 グラスを順番に生産する 工場を建設したいと考えています。

カップ、マグカップ 、 グラスの基礎は、 抽象的な容器のアイデアに基づいています。その使用方法は、 それから飲まれ、その特性は内部に液体を含むことができ、何らかの材料で作られています。

abstract class Vessel { private $material; private $liquid; public function __construct(Material $material) { $this->material = material; } public function fill(Liquid $liquid) { $this->liquid = $liquid; } public function pour() { $liquid = $this->liquid; $this->liquid = null; return $liquid; } } class Cup extends Vessel { //-   } class Wineglass extends Vessel { //-   } class Mug extends Vessel { //-   } class Human { //  -  public function drink(Vessel $vessel) { $this->stomack->add($vessel->pour()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もっともっと。 マグの生産を開始するには、 工場が必要です。 工場に注文すると、 ガラスなどの必要な材料からマグカップ、カップ 、 グラスが 生産されます 。 プログラミングでは、すべてが人生と同じです。

 class VesselFactory { //   ,  . $className -   ,      , $material -    public function getVessel($className, $material) { return $className($material); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プログラマーがマグカップ、カップ、またはグラスから飲むには、 ペンが必要です。 海賊がペンから飲むには、フック用の穴が必要です。 工場がこれをどのように行うかは問題ではありません。 プログラマーが手で容器を、 海賊をフックで取ることができることが重要です。 理想的には、ペンはプログラマーと海賊の両方がペンで手をつかんだり、フックの穴からつかんだりするのではなく、マグカップをつかむことができるように、 多形である必要があります。

 interface Knob { public function take(Holder $with); } class Cup extends Vessel implements Knob { public function take(Holder $with) { //-      } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例はあまりきちんとしたものではなく、考え抜かれたものではありませんが、インタビューで必要なすべてがOOPの概念からどのように続くかを完全に伝えています。 この理解により、 SOLIDの原則に従い、美しいアーキテクチャを作成し、コントローラーからビジネスロジックを分離することができます。 実際、これらの単純なことを理解することは、現代開発の本質にあります。 フェルトブーツのように見えますが、開発者の60〜70％はこれにアクセスできません。 そしてその理由は、開発者にはプロセスの理解が提供されず、ツールが提供されるからです。

推論

ハンマーの片側で釘を打ち、反対側で引きます。 私の父は産業のロボット設計エンジニアであったため、ハンマーの鋭い側面をくさびとして、ペンをレバーとして（つまり、バールとして）使用しました。 彼はハンマーの動作原理（ウェッジ+レバー）を理解しており、ハンマーとしてだけでなくそれを使用しています。 したがって、OOPの原則を最も効果的に適用するには、OOPの原則を理解する必要があります。

英国、米国、EUの人たちとチームで働いた経験は、この大きな欠点を示しています。 信じられないほどの技術的知識を持っているすべての種類とストライプの建築家と領主は、良い建築を作ることはほとんどできません（平均的なケースについて話している、多くの優秀な人が、自宅でUMLを隠して見なければならないほどの美しさを持っています）。 OOPで明示的に指定されたガイドラインに従っているからです。 しかし、技術的な詳細を犠牲にすることは、はるかに重要な哲学的詳細をもたらします。 たとえば、システムの誤ったオブジェクトの分解は、たとえすべてのガイドラインとすべてのベストプラクティスに従って行われたとしても、開発者の人生を地獄に変えてしまいます。 通常、この場合、インターフェイスとファクトリーを持つクールなクラスが取得されますが、たとえば、クラスが少なすぎる（その動作を条件付きロジックに変更する必要がある）か、または多すぎる（そして条件付きロジックで異なるタイプのクラスを使用する必要がある）ため、コードスパゲッティなど、それらの多くがあります。 そして、拡張性が損なわれ、アルコール依存症の傾向が高まっています。

ベストプラクティスは、プログラマではなく、ビルダーであるかのようにシステムを提示することです。 なぜデザインパターンがそんなに良いのですか？ なぜなら、コードではなく、釘、ハンマー、ボードを使用して行うように、技術的な実装から抽象化し、頭の中に構造を作成できるからです。 私の同僚の多くは、C ++またはSmalltalkのコード例があるため、Four Gangを理解していないと不満を述べました。 アイデアはコードにはまったくありません。あなたはそれを打ち負かすことができます。アイデアは、家や車と同じようにプログラムを構築できるということです。 人間が理解できる方法で、完全に異なる領域からエンジニアリングの天才をコピーします。 プログラマーは、周囲のマトリックスを見始めたときにのみエンジニアとして考えることができます。 彼を囲むオブジェクトを分解し、目を引くものすべてのメソッド/インターフェース/プロパティを呼び出します。 お気に入りのマグカップから始まり、お気に入りの海賊で終わります。

Fireは、現代世界には、私たちに去勢されたOOP（hello Javascript、Go）、または技術指向（C＃、Java、C ++）を提供する、または美しいと同時にその機能を恐れる（Python、Ruby）数百万の言語があるという事実によって火に投げ込まれます、または一般的にPHP。 そして、これはこれらの言語の庭にある石ではありません。なぜなら、それらには目的、用途があり、彼らは善であり、そうかもしれないからです。

おわりに

一般的に、モラルとは何ですか。 開発者のモラルは、プログラマーになるにはエンジニアとして考える必要があるということです。 雇用主のモラルは、プログラマーがエンジニアのように考える必要があるということです。 現代文学と教育はあなたにツールを提供し、それは本当にクールです。 本を購入すると、開発用の巨大なツールボックスが手に入ります。 しかし、まず第一に、各ツールを最も効果的かつ正しく使用するには、各ツールの操作原理を理解する必要があります。 OOPはカプセル化、継承、および多態性ではなく、アイデアからのみに従います。 ただし、アイデアに基づいて構築されたツールを使用するよりも、アイデアを理解することが重要です。 もちろん、ハンマーで釘を打つだけで、賃金、場所、尊敬に値する人々がいるに違いありません。 すべての職人は、クラフトを尊重するに値します。 しかし、椅子を組み立てる前に、誰かが私たちがどの椅子を集めるのかを把握しなければなりません。 多くの男と女は お尻 この違いに気付いたときの資格。

読者の皆様、このトピックに関するアイデアや提案があれば、これを私たちと共有していただければとてもクールです。