2014-09-10 2 views
0

Я стараюсь следовать совету, согласно которому «использование геттеров/сеттеров в ваших классах является злым». Так, скажем, у меня есть совокупный класс Invoice со следующей подписью:Как избежать геттеров в совокупной внутренней коллекции?

public class Invoice{ 
    ISet<Line> _lines; 
    public void ChangeLineAmount(int LineId, double newAmount){ 
       //Your answer here 
      } 
    } 

Как я могу найти конкретную строку для изменения, если Line класса не имеет добытчиков?

+0

И нижний предел для? – Apocatastasis

+0

просто прочитал ваш вопрос, посмотрели ли вы на это руководство MSDN по коллекциям http://msdn.microsoft.com/en-us/library/dn169389(v=vs.110).aspx – MethodMan

+0

Хорошо, я просто прочитал его. Я не подвергаю свою коллекцию внешнему миру, поэтому я не понимаю вашу точку зрения, за исключением соглашений об именах. – Apocatastasis

ответ

1

Причина, по которой фраза «использование геттеров/сеттеров в ваших классах зла» в отношении DDD заключается в том, что геттеры и сеттеры обычно не представляют ваш UL (вездесущий язык) и приводят к анемичным сущностям. Но если в вашем UL есть что-то вроде «Мне нужно количество этой строки», тогда вы можете создать геттер, но назовите его в соответствии с UL, например: invoice.lineAmount(lineId).

Внутри метода вы можете просто получить доступ к собственности, поскольку CharlesNRice уже ответил. Если вы чувствуете, что вам понадобится специальное лечение для линий чтения/настройки, вы можете создать частный геттер, чтобы использовать его внутри методов логики домена.

UPDATE:

геттеры и сеттеры были необходимы в первую очередь потому, что позже в этом проекте вы могли бы хотеть, чтобы добавить некоторые дополнительные проверки/преобразования перед установкой/получение имущества, без него вы бы чтобы найти каждый кусок кода, который приобретает свойство и изменить его. С getter/setter вы получаете доступ к собственности в одном месте, поэтому вы меняете код в одном месте - гораздо проще в обслуживании. Но поскольку в DDD вы должны использовать только логические методы домена, тогда вы не получаете доступ к своим свойствам прямо где-либо за пределами данного объекта, поэтому вам также не нужно использовать геттеры и сеттеры. Ваши методы домена, такие как invoice.lineAmount(lineId), фактически работают так же, как и геттеры, но идут вместе с UL, поэтому они в порядке. Вы бы подумали о создании реальных геттеров/сеттеров для внутреннего использования, если увидите, что вы используете свойство в нескольких местах вашего класса сущности.

+0

Итак, совет должен быть «геттеры и сеттеры злы, если это не требуется». Может быть, они могут быть внутренними, чтобы уменьшить его использование до совокупности, к которой они принадлежат? – Apocatastasis

+0

Я обновил свой ответ. –

+1

Оригинальное заявление, похоже, исходит от 11-летней статьи JavaWorld. Я прочитал статью, и она читается как разглагольствование с коленом по поводу злоупотребления «геттерами» и «сеттерами». В терминах DDD я лично не вижу ничего плохого в использовании «getter», чтобы выставить значение, которое вы разработали для публичной рекламы. –

-1

_line - это просто поле, если у него нет геттера или сеттера. Если вы добавите их, это свойство. Чтобы получить линию, вы будете использовать ее так же, как и свойство.

public class Invoice{ 
    ISet<Line> _lines; 
    public void ChangeLineAmount(int LineId, double newAmount) 
    { 
     var line = _lines.FirstOrDefault(l=>l.LineId == LineId); 
     if (line != null) 
     { 
      line.Amount = newAmount; 
     } 
    } 
} 

Я думаю, что это личное мнение, если «использование геттеров/сеттеров в ваших классах является злым». Я лично этого не чувствую.

2
  • В «ванильным» DDD, рекомендуется, чтобы избежать прямых сеттеры (или добытчиков изменяемых коллекций) и сделать операции домена явно вместо этого. Использовать намеренные, вездесущие, совместимые с языком, инвариантные правила поведения (методы), чтобы по возможности мутировать ваши сущности. Тем не менее, в этом подходе сущности - это то место, где вы читаете данные, они должны раскрывать свое состояние для читателей, поэтому я не вижу, как вы могли бы обойтись без геттеров.

  • Признак DDD CQRS (+ ES) будет иметь прочитанную модель, где вы, очевидно, можете получить доступ ко всему, что хотите, с помощью геттеров и агрегатов, состояние которых вы можете изменять только с помощью команд. Поскольку все считывания выполняются с помощью вспомогательных объектов модели считывания и всех операций записи через команды, вам не нужны геттеры или сеттеры на ваших внешних элементах внешнего вида, но сами корни должны иметь возможность изменять объекты внутри своего собственного агрегата, что иногда требует сеттера.

В любом случае, все не так просто, как «использование геттеров/сеттеров в ваших классах является злым».