1

次の簡略化されたクラスについて考えてみます。

class Book {
   string title;
   Author author;
}

十分に単純です。ただし、のようなメソッドを追加する場合、これはこの同じクラスgetBookFromDatabase(int bookId)のメソッドとして配置する必要がありますか、それとも別の（つまり）クラスに配置する必要がありますか？static BookManager

使用例：

Book b = Book.getBookFromDatabase(42);

対。

Book b = BookManager.getBookFromDatabase(42);

これは多少好みの問題だと思いますが、OOPガイドラインに従って最適なものは何ですか？

4

6 に答える 6

3

Repository私はバッキングストアからのオブジェクトを水分補給するためにを使用することを好みます。次のようなものが良い出発点かもしれません。

public interface IBookRepository{
    Book Load(int id);
    void Save(Book book);
}

このようにして、リポジトリの複数の異なる実装を持つことができ、必ずしもデータベースの使用に縛られる必要はありません。たとえばInMemoryBookRepository、テストやDatabaseBookRepository本番環境のような環境に使用できるがあります。

様式的には、次のような静的メソッドの使用も避けます。

BookManager.getBookFromDatabase(42);

テストが難しく、結果のコードがより緊密に結合されるため、テストと変更がはるかに困難になります。

リポジトリの実装について詳しく知るには、このStackOverflowの質問をご覧ください。 MicrosoftとMartinFowlerも、これについてさらに詳しく説明しています。

于 2012-12-09T14:45:27.080 に答える
2

Manager個人的には、「 」クラスのアプローチが好きです。ロジックを分離するので、Book自分自身を取得する方法について何も知る必要はありません。また、BookManagerここではシングルトンにすることができます-実際にを取得する必要があるまでインスタンス化されませんBook。

さらに、キャッシュなどのBookManager追加の簿記タスク（しゃれは意図されていません）Bookを実行できます。または、グローバルレベルでサブスクライブするイベントがいくつかある場合もあります。

于 2012-12-09T14:35:24.003 に答える
0

どちらのアプローチも、本質的に非OOPである静的メソッドを使用します。最善の解決策は、BookDatabaseオブジェクトを用意することです。このオブジェクトは、含まれている本への非静的アクセスを許可する必要があります。

これにより、静的メソッドがもたらす問題が解決されます。たとえば、将来的に2つ以上のBookDatabaseがある場合はどうなりますか？静的メソッドでは、これは厄介になります。データベースオブジェクトを使用すると、さまざまなデータベースを処理するために、このクラス（またはサブクラス）のインスタンスを増やすことができます。

于 2012-12-09T14:43:54.953 に答える
0

別のクラスを使うほうがいいと思います。これはBookManagerかもしれませんが、LibraryやBookShopのような仕事により適したものがあるかもしれません。オブジェクトは、次のように配列またはArrayList（ArrayListを使用することをお勧めします）の本への参照を保持する必要があります。

public class BookManager {
    ArrayList<Book> books = new ArrayList<Book>();

    public Book getBook(int index) {
        return books.get(index);
    }

    public void addBook(Book book) {
        books.add(book);
    }
}
于 2012-12-09T14:41:22.877 に答える
0

場合によります。

すべてのBookクラスの動作がデータベースから取得したフィールドの格納にある場合、すべてのクラスが関係するため、データベースから、つまりgetBookFromDatabase(int bookId)同じクラスでデータを取得する動作を追加する方が簡単な場合があります。データベースから本を取得し、それをプログラムの残りの部分にまとまって提示します。

ただし、Bookクラスに追加の動作、おそらくアプリケーションに固有の特定のBookビジネスロジックを持たせる場合は、ビジネスロジックを永続ロジックから分離しておく方が理にかなっている可能性があります。

ここでのガイドヒューリスティックは単一責任の原則である必要があります。それに関するスタックオーバーフローについては、他にもたくさんの質問があります。

また、別の関連する注記で、静的メソッドはテスト容易性に死ぬことを覚えておいてください。

于 2012-12-09T14:42:29.727 に答える
0

あなたのBookクラスはドメイン/ビジネスクラスであると思います。したがって、データベースからクラス自体にデータを取得する責任を負わせると、データベースとビジネスレイヤーの間に高い結合が生まれます。これは善の原則に反します。設計。

http://en.wikipedia.org/wiki/GRASP_(object-oriented_design）を読むことをお勧めします

そして、あなたがそれを望んでいるなら、のコピーを入手してください

UMLとパターンの適用：オブジェクト指向の分析と設計および反復開発の概要-Craig Larman ISBN13：978-0131489066

この本は、ソフトウェア開発で最も人気のある本の1つであり、強くお勧めします。

于 2012-12-09T15:53:09.323 に答える