私の質問は簡単です。コードをオブジェクト指向にすることは可能ですか?
いくらですか?OOのために、どの時点で読みやすさと保守性を放棄していますか?
私は巨大なOOの人ですが、コードを複雑にしすぎているのではないかと思うことがあります。
考え?
私の質問は簡単です。コードをオブジェクト指向にすることは可能ですか?
いくらですか?OOのために、どの時点で読みやすさと保守性を放棄していますか?
私は巨大なOOの人ですが、コードを複雑にしすぎているのではないかと思うことがあります。
考え?
コードをオブジェクト指向にすることは可能ですか?
はい
より多くのオブジェクトがよりオブジェクト指向であると考えるなら、そうです。
オブジェクト指向設計を行う場合、バランスを取らなければならない力がいくつかあります。OO 設計のほとんどは、複雑さを軽減して処理することです。したがって、非常に複雑なソリューションを取得した場合、オブジェクト指向をあまり行っていませんが、間違っています。
プロジェクトにOOを完全に実装するために必要な時間が不必要に期限を過ぎていることに気付いた場合は、そうです。
ソフトウェアのリリースと完全なOOの忠実度の間にはトレードオフが必要です。決定する方法は、人、チーム、プロジェクト、およびプロジェクトを実行している組織によって異なります。
はい、もちろんあります:-)オブジェクト指向のテクニックはツールです...特定の仕事に間違ったツールを使用すると、物事が複雑になりすぎます(必要なのがナイフだけの場合はスプーンを考えてください)。
私にとって、「いくら」はプロジェクトの規模と範囲で判断します。小さなプロジェクトの場合、複雑さが増すことがあります。プロジェクトが大規模な場合でも、この複雑さを引き受けることになりますが、保守性、拡張性などの容易さでそれ自体が報われます。
私のアドバイスはそれを考えすぎないことです。それは通常、何かをやり過ぎたり、やりすぎたりします(OOでない場合)。私が通常使用する経験則は次のとおりです。問題が頭を包み込みやすくなる場合は、オブジェクトを使用します。別のパラダイムによって、オブジェクトを使用する場合よりも頭を包み込みやすくなる場合は、それを使用します。
その戦略はまだ私を失敗させていません。
はい、それは間違いなく可能です-一般的でもあります。私はかつて、ドロップダウンリストにバインドするデータ構造を作成した人と協力して、ユーザーが性別を選択できるようにしました。確かに、可能性のある性別のリストが変更された場合、それは便利ですが、まだ変更されていません(私たちはカリフォルニアに住んでいません)
はい、データベース設計を過度に正規化できるのと同じように。
これは、終わることのない純粋主義者対実用主義者の論争の 1 つと思われます。<:S
多くの人は、再利用の可能性を考慮せずに、最大の柔軟性と再利用のためにコードを設計しようとします。代わりに、作成しているプログラムに基づいてクラスを分割してください。特定のオブジェクトのインスタンスを 1 つだけ持つ場合は、それを包含オブジェクトにマージすることを検討してください。
あなたの質問は、「あなたのアプリケーションを構築できますか?」と読むべきだと思います。
そしてもちろん、答えはまだです。オブジェクト指向は単なる設計へのアプローチです。「ポリモーフィズムはロックだ!」という理由で、システムに不必要な複雑さを構築するのに時間を費やしている場合。それなら、おそらくあなたはOOingを超えています。
まさしく XP の答えは、どのアプローチ (OO、手続き型など) を好むかに関係なく、設計は明らかに必要なだけ複雑であるべきだということです。
はい、できます。例として、2 つのサブタイプを作成する前にインターフェイスまたは抽象クラスを作成していることに気付いた場合は、やり過ぎです。この種の考え方は、開発者が前もって (過剰に) 設計している場合によく見られます。この動作を回避するために、テスト駆動開発とリファクタリングの手法を使用しています。
コードをオブジェクト指向にすることは可能ですか?
いいえ。ただし、コードが過度に複雑になる可能性があります。たとえば、デザイン パターンを使用する目的でデザイン パターンを使用できます。ただし、コードを過度にオブジェクト指向にすることはできません。あなたのコードはオブジェクト指向かそうでないかのどちらかです。コードが適切に設計されているかそうでないかのように。
可能だと思いますが、抽象的な言葉で答えるのは難しいです(しゃれは意図されていません)。OO以上の例を挙げてください。
はい。「ゴールデンハンマー アンチパターン」の概念を参照してください
オブジェクト指向デザインが極端になり、非常に大規模なプロジェクトであっても、コードが読みにくくなり、保守しにくくなる場合があると思います。たとえば、フットウェアの基本クラス、スニーカー、ドレスシューズなどの子クラスで使用できます。しかし、NikeSneakersのクラスを作成するのに極端なように見える人々のコードを読んだり、レビューしたりしました。とReebokSneakers。確かにこの2つには違いがありますが、読みやすく保守しやすいコードを作成するには、違いを処理するための新しい子クラスを作成するのではなく、違いに適応するようにクラスを拡張することが重要であると思います。
はい、簡単です。コードが優れているのは、それがオブジェクト指向だからというだけではなく、単にモジュール式、機能的、汎用的、生成的、データフロー ベース、アスペクト指向などの理由だけで優れているということではありません。
優れたコードは、プログラミング パラダイムで適切に設計されているため、優れたコードです。
良いデザインには注意が必要です。
注意は時間がかかります。
あなたの場合の例: 私は、「オブジェクト指向」という名目で、他のクラスがそのインターフェースを実装しない場合でも、すべてのクラスが何らかのインターフェースを実装する恐ろしい Java を見てきました。ハッキングの場合もありますが、それ以外の場合は本当に無償です。
どのようなパラダイムまたはイディオムでコードを記述しても、行き過ぎたり、良いことをやりすぎたりすると、問題よりもコードが複雑になる可能性があります。その時点に達すると、たとえば、コードはもはやオブジェクト指向ではなくなったと言う人もいます。
オブジェクト指向コードは、合理的に独立した部分で、より単純で、より単純で、理解しやすく、消化しやすいように、より適切に編成されていると考えられています。オブジェクト指向コーディングのメカニズムをこの目標に反して使用しても、オブジェクト指向設計にはなりません。
明確な答えはイエスだと思いますが、あなたが言及しているドメインによっては、本当にイエスかもしれませんし、そうではないかもしれません。高レベルの.NetまたはJavaアプリを構築している場合、OOは基本的に言語に組み込まれているため、これは後者だと思います。一方、組み込みアプリに取り組んでいる場合は、オブジェクト指向を超えている危険性と可能性が高くなります。非常にレベルの高い人が組み込みプロジェクトに参加し、彼らが醜いと思っていることを過度に複雑にしているのを見ることほど悪いことはありません。
何事も「やり過ぎ」だと思います。これは、私が考えることができるほぼすべてのベスト プラクティスに当てはまります。継承チェーンが非常に複雑で、コードが事実上管理不能であるのを見てきました。