Паттерн DAO портит сплоченность / SRP?

Давайте использовать в качестве примера:

class AccountDAO {
    create(){..}
    read(){..}
    update(){..}
    delete() {..}
}

Сколько у вас обязанностей? 1 или 4?


design-patterns dao single-responsibility-principle cohesion
person ejaenv    schedule 26.06.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

SRP не следует понимать строго. У одного объекта должно быть очень мало обязанностей, а не «одна».

Здесь AccountDAO отвечает только за сохранение Учетной записи, поэтому у него есть только одна ответственность.

person Tristan    schedule 26.06.2011
comment
Как следует описать ответственность этого класса? Если я скажу, что AccountDAO отвечает за сохранение учетной записи, это 1 ответственность, но если я скажу, что AccoundDAO отвечает за создание, чтение, обновление И удаление, это 4. В общем, в литературе говорится, что если вам нужно использовать AND для описания это означает более чем одну ответственность. Итак, какой уровень описания правильный? - person ejaenv; 12.07.2011
comment
У вас возникнет проблема детализации (en.wikipedia.org/wiki/Granularity) вашего всю карьеру, если работаешь дизайнером / программистом. Для этой конкретной проблемы DAO в литературе говорится, что лучше реализовать все операции CRUD в одном классе (см. java.sun.com/blueprints/corej2eepatterns/Patterns/). Пожалуйста, отметьте мой ответ как действительный, если вы так считаете. - person Tristan; 12.07.2011
comment
Я отмечу как действительный, поскольку вы, конечно, ответили на него для моего сформулированного класса DAO, но я вижу, что я пропустил способ формулировки вопроса; вместо того, чтобы быть специфичным для DAO, я искал способ правильной детализации для описания ответственности. Сформулирую это другим вопросом. - person ejaenv; 13.07.2011
comment
Я нашел свой вопрос DAO, сформулированный здесь (stackoverflow.com/questions/2643547/). Ему ответили так же, как и вам. Кроме того, в ответах говорится, что SRP не нарушается, пока DAO сосредоточен только на одном объекте данных. - person ejaenv; 13.07.2011