Я пытаюсь следовать некоторым из наиболее современных принципов проектирования, включая SOLID и Domain Driven Design. Мой вопрос касается того, как люди обрабатывают «Инициализацию» объектов домена.
Вот простой пример:
На основе SOLID я не должен зависеть от конкрементов, поэтому создаю интерфейс и класс. Так как я пользуюсь преимуществами Domain Driven Design, я создаю объект с соответствующими методами. (то есть без анемии).
Interface IBookstoreBook
{
string Isbn {get; set;}
int Inventory {get; set;}
void AddToInventory(int numBooks);
void RemoveFromInventory(int numBooks);
}
public class BookstoreBook : IBookstoreBook
{
public string Isbn {get; set;}
public int Inventory {get; private set;}
public void AddToInventory(int numBooks);
public void RemoveFromInventory(int numBooks);
}
Чтобы помочь с тестированием и быть более слабо связанным, я также использую контейнер IoC для создания этой книги. Поэтому, когда книга создается, она всегда создается пустой. Но если у книги нет ISBN и инвентаря, она недействительна.
BookstoreBook(string bookISBN, int bookInventory) {..} // Does not exist
У меня может быть 4 или 5 разных классов, использующих BookstoreBook. Для одного,
public class Bookstore : IBookstore
{
...
public bool NeedToIncreaseInventory(BookstoreBook book) { ...}
...
}
Как любой метод узнает, что получает действительную книгу? Мои решения ниже, похоже, нарушают принцип «Говори, не спрашивай».
а) Должен ли каждый метод, использующий книжный магазин, проверяться на достоверность? (т. е. должен ли NeedToIncreaseInventory проверять действительность книг? Я не уверен, что он должен знать, что делает BookstoreBook действительным.)
б) Должен ли я иметь «CreateBook» в объекте IBookstoreBook и просто «предполагать», что клиенты знают, что они должны вызывать это в любое время, когда они хотят инициализировать BookstoreBook? Таким образом, NeedToIncreaseInventory просто будет доверять тому, что «CreateBook» уже был вызван в BookstoreBook.
Меня интересует, какой рекомендуемый подход здесь.
