通常、作業は理論の長い研究からではなく、問題の理解からそれを解決する方法を見つけることから始まります。 したがって、サーバー側でサイトを作成するにはphpが使用され、クライアント側ではjavascriptが特定の機能を実行しました。
他のタスク、それぞれ、他の言語の場合。 javascriptで「すべてがオブジェクトである」という事実は、すぐにはわかりませんでした。 はい、そのようなことがありました。
それ以前は、「機能を拡張するだけで、1つの共通のコードまたはデータをどのように使用しますか？」、「同じ名前の関数が既に存在する場合はどうですか？」などの質問に常に悩まされていました。
その後、転職して面接に来たとき、彼らは「多態性」と「カプセル化」について質問しました。
これらの用語はドライであり、深い実用的な意味を含んでいませんでした。
オブジェクト指向プログラミング（OOP）では、次のように意味がありました。
- 明確な境界を持つオブジェクトの生活空間とその内部主権民主主義
- 作業ロジックを変更したり、プロジェクトを中断したりすることなく、既存のプラクティス（以前に行ったもの）を拡張する機能
OOPをphpおよびjavascriptで使用できることがわかったとたんに、それを使い始めました。
OOPには2つの欠点しかありません。1つはオブジェクトの構造をよく考え（設計できる）、コンピューターのリソースはより高価です。
はい、まだ知識が必要であり、アップグレードする時間はほとんどありません。 ただし、これは深刻な障害というよりは冗談です。
短所をリストしました。 そしてマイナスがないと、絵は客観的ではありません。
さらに多くのプラスがあります：
- プロジェクトの明確なマップ（はい、それはただ存在します！-「都市」-「国」プロジェクト内のオブジェクト）-「仕組み」を理解する複雑さを軽減します
- 既製の「キューブ」を再利用する可能性
- 数年後のコードと他のコード（OOP）のより迅速かつ明確な理解、そのメンテナンス。
- 意図しない変更からの内部アルゴリズムとデータの保護-「ブラックボックス」
これらは4つの主要な要素であり、最終的には、プロジェクトの開発とサポートの時間を短縮し、「非コアノイズ」から脳を解放し、プロジェクトが「混乱」に変わったときに境界を押し広げます。
最近、Habréで「プロシージャル対OOP」のスタイルで書かれた記事に頻繁に出会うようになりました。
このようなトピックが発生するため、これはおそらく人々にとって本当の問題（OOP-賛成/反対）です。 しかし、個人的には、可能であれば、OOPを選択します。
私にとってはより便利で簡単です。 OOPは単なるツールであることを理解することだけが重要です。
また、ツールを使用するには、常に特定のレベルの資格が必要です。
ところで、1993年のHanspeter Moessenboeckは、彼の記事「OOPのコストと利点」で長所と短所をすでに考慮していました。