9

1つまたは2つのメソッドしかないクラスがたくさんあるというのは悪い設計の兆候ですか？

私はOOP設計を学ぼうとしていて、小さなアプリケーション（小さな）を作成しました。

その結果、1つまたは2つのメソッドのみを含むインターフェイスを実装するクラスがかなり多くなりました。

うまく分離されているように感じますが、クラスにメソッドが非常に少ないのは悪いようです。

それぞれのシナリオが異なることは知っていますが、これは一般的な観点から悪いですか？

アプリケーションのごく一部が犬に餌をやるスケジュールを決定します（私が知っているラメ）：

だから私はここで戦略パターンを実装しようとしました：

class DogFeedController
{
    protected $strategy = null;

    public function __construct(iDogFeedStrategy $strategy) {
        $this->strategy = $strategy;
    }

    public function getFeedingSchedule() {
        $morningFeeds = $this->strategy->generateMorningFeeds();
        $eveningFeeds = $this->strategy->generateEveningFeeds();       
    }

}


class GeneralFeedStrategy implements iDogFeedStrategy
{
    public function generateMorningFeeds() {
        //do stuff here
    }

    public function generateEveningFeeds() {
        //do stuff here
    }
}
4

5 に答える 5

8

それが多すぎる場合は、自分で測定する必要があります。OOPは、意味のある現実的な方法でロジックを分離するための優れた方法ですが、保守性に悪影響を与える可能性があり、その時点で誤って適用されています。

アプリケーションがどこに向かっているのかを考えてください。いつも小さなアプリになるのでしょうか？もしそうなら、あなたは多くの非常に一般的なインターフェースを作成する必要はありません。それらを組み合わせてみてください。1つのクラスだけがインターフェースを実装している場合は、インターフェースを完全に削除できる可能性があります。

If you anticipate your application will grow substancially, the interfaces might actually help you maintain and add features in the future. For example if you created an application to manage a car lot that only has parking spaces for cars, you might want to create a generic automobile interface if you anticipate growth to different types of vehicles (e.g. motorcycles only take half a parking space). That said, you shouldn't try to cover every conceivable change in requirements at the onset of a project and make the code too abstract. Measuring the risk of change in requirements can help you predict what code needs to be abstracted.

If you're a software engineer on a team, diagram your design and show it to your colleagues to get their opinions too.

Finally, be careful of code smells.

于 2012-08-23T17:29:16.820 に答える
7

一般的な観点から、クラスが大きすぎるか、逆に小さすぎる場合は、どちらも悪い習慣と見なされ、いわゆるコードの臭いと呼ばれます。私が言及している2つは、ラージクラス（別名神オブジェクト）とレイジークラス（別名フリーローダー）です。

ウィキペディアとコーディングホラーからの定義は次のとおりです。

ラージクラス：大きくなりすぎたクラス。

長いメソッドのような大きなクラスは、読み、理解し、トラブルシューティングするのが困難です。クラスにはあまりにも多くの責任が含まれていますか？大きなクラスを再構築したり、小さなクラスに分割したりできますか？

と

怠惰なクラス：少なすぎるクラス。

クラスは自分の体重を引く必要があります。クラスを追加するたびに、プロジェクトの複雑さが増します。自分でお金を払うのに十分なことをしていないクラスがある場合、それを折りたたんだり、別のクラスに結合したりできますか？

一方、オブジェクト指向設計には、「クライアントが使用しないメソッドに依存することを強制されるべきではない」というインターフェイス分離の原則と呼ばれる原則があります。あなたの場合、メソッドの数が少ないインターフェースは実際にはこの原則に準拠しています。

上記を要約すると、あなたのデザインはかなり正しいです。メソッドの数が少ないインターフェースは優れているため、それらのインターフェースを実装するクラスは、使用しないメソッドとともにすべてのメソッドを実装する必要はありません。クラスに関しては、やがて大きくなると思います。インターフェイスを実装することは、実装されたインターフェイスで定義されているよりも多くのメソッドを持つことができないという意味ではないことを覚えておいてください。つまり、より多くのロジックをそこに配置してみてください。

SOLID、オブジェクト指向設計の原則の詳細については、ウィキペディアを参照してください。

PS。コードの臭いは悪いデザインの症状であり、SOLIDは治療法です。

于 2012-08-23T18:22:16.230 に答える
3

自分に問いかけるべき質問だと思います。このクラスはそれがしていることに責任がありますか？責任を識別して分離できることは、OOPの基礎です。Securityたとえば、ランダムなパスワードを作成するメソッドが1つしかないクラスを作成できます。

ランダムパスワードがレジスターでのみ使用される場合、そのクラスのプライベートメソッドを作成する代わりに、そのメソッドを新しいクラスに分離すると思います（これは私の意見です）Security。Registerクラスの責任。

さらに、アプリケーションは小さいため、クラスごとにメソッドがほとんどないのはまったく正常なことです。

編集：あなたのコードを見て、私はいくつかのアドバイスをすることができますが、私は全体像を見ることができないことを覚えておいてください。

まだ読んでいない場合は、MVCパターンについて読む必要があります。アプリケーションにビューがない可能性がありますが、コントローラーをモデルから分離することをお勧めします。

あなたDogFeedControllerはコントローラーでありGeneralFeedStrategy、モデルのようです。私は自分のクラスの名前をそれらが何であるかで終わらせるのが好きです。たとえばUserController、、、UserViewおよびUserModel。これでわかりやすいと思いますが、やはり私の意見です。

持っている意味はわかりませんiDogFeedStrategyが、やはり全体像は見えません。インターフェイスの基本的な使用法は、クラスのグループがどれほど異なっていても、同じAPIを持つようにし、インターフェイスを実装する各クラスの詳細をカプセル化することです。

于 2012-08-23T17:25:20.850 に答える
0

関心の分離以外のOOPのもう1つの重要な側面は、クラスの結束です。クラスは、他の多くのものがその「ゲッター」と呼ばれ、情報を使って何かをするのではなく、「自重を引く」必要があります。ポリモーフィックな動作が必要な場合、または将来アプリを拡張する予定がある場合は、インターフェースを作成します。分離のためだけにインターフェースを作成しないでください。インターフェイスが2つ以上のサブクラスによって実装されていない場合は、それらを削除します。（インターフェイスを使用して、依存性逆転の原則を適用し、依存性サイクルを中断することもできます）

OOPでの設計上の決定は、特定の問題に意識的に対処するために常に行う必要があります。それ以外の場合は、シンプルに保ちます。

于 2012-08-23T17:41:29.087 に答える
0

単純な関係を持つ少数の大きなオブジェクトよりも複雑な関係を持つ多くの小さなオブジェクトを優先します。これは保守性を優先し、将来の変更に備えるためです。

あなたのデザインは私にはとてもよく見えます。あなたが今プログラミングを始めていて、初心者はいつも逆のことをしていることを考えると、なおさらです。

于 2015-05-19T15:48:28.047 に答える