このjavascriptのscenerioではOOPの使用法はここで正当なものですか？

Question

ここにOOPが正当化されていますか？

今日は、小規模なスタートアップ時の仕事の初日でした。スタートアップには、モーダルウィンドウなどの機能のためにOOPを使用する多くのカスタムjを持つ開発者がいます。さらに重要なことは、編集や削除ボタンで表示されるデータの行など、ほぼすべてのデータ表示をjavascriptのOOP表現の形式に変更したことです。

私たちがやっていることの1つは、モーダルの使用を一掃し、内容をメインウィンドウに完全に表示することです。通常これは、モーダルウィンドウに別の方法で表示されたhtml/phpコードのコピー/貼り付けを意味します。しかし、この開発者はOOPのすべてを開発しており、これらのすべてのUI関連オブジェクトは互いに密接に結びついているため、モーダルウィンドウから離れると、より多くの労働/修正が必要になるようです。

私がこの仕事をしたとき、私は興奮し、実践的なOOPで膝を深くする経験を得ると思いました。しかし、1日後、私はまだその有用性を見ていて、最悪の場合は非常に非生産的なようです。

何か不足していますか？ javascriptでOOPを使用するのはいつ良い/悪い考えですか？

Answer 1

私はそれが実用的なアプローチだと思っていますが、他の言語のOOPのように、それはうまく実装されているか、または貧弱に実装されている可能性があります。 JavaScriptのOOPテクニックは、厳密にはユーティリティメソッドを持たずにコードを適切に分離できるため、悪い考えではないと思います。しかし、そのサウンドから、デザインをリファクタリングしてより単純化し、コードを移動させたい場合があります。

何が行われているかによって、JavaScriptですべてを行うことに懸念がありますセキュリティ、保守性、ブラウザ間のサポートなどの機能を提供します。

HTH。

Answer 2

OOPは、コードの書き換えが不要で、コードの保守が可能であることを保証するための非常に強力なツールですが、不適切に行われた場合は逆の効果があります。 Design Patternsは、コードが保守可能であることを確認するために使用され、OOPはその大部分です。 This bookは主題に関する権限のようです。

Answer 3

JavaScriptのすべてがオブジェクトなので、コード内である程度のOOP-inessを避けるのは難しいです。 OTOHでは、ほとんどのJavaScriptフレームワークは言語の機能面に重点を置いています。

いずれにしても、実際に問題が発生していると思われるのは、UIとデータモデルのデカップリングが不十分だということです。そうであれば、明示的にそれらを分離するフレームワーク（例えばknockout.jsなど）を見てください。

私はOOPが脳を間違った形に曲げる傾向があると言います。私は、OOPとOOADの初期の段階では、オブジェクトがGUIにレンダリングする責任があるという考え方が非常に一般的であったことを覚えています。これが問題であるように、オブジェクトの振る舞いをそのデータと結びつけることがコアOOPの原則の直接的な結果でした。

Answer 4

彼の実装の詳細を知らなくても、アプローチが良いかどうかは分かりません。しかし、Webアプリケーションでは、Javascriptでクライアント上に重いオブジェクト指向設計（MVCまたはMVPデザインパターンとともに）を行う傾向が強くなっています。さらに、ページのレンダリングの多くはJavascriptで行われ、この目的のためにBackbone.js（または上記のKnockout.js）などのフレームワークは非常に一般的で非常に興味深いものです。

Javascript自体は、実際には非常に優れたオブジェクト指向言語（Douglas Crockfordがそれについて語っていることを参照）であり、現在若い開発者と並んでルネッサンスを受けています。