Принцип единой ответственности и классы

Я надеюсь, что смогу прояснить, с чем я борюсь :-) Вот. Мне интересно, как реализовать SRP в следующем случае:

Есть проект. По завершении контакт должен быть отправлен по почте с опросом, в котором он дает отзыв о том, как прошел проект.

Программное обеспечение имеет проектный класс. Есть процедура, которая перебирает все проекты. Я выделил весь код для рассылки в класс ContactMailer, который принимает проект в качестве параметра, что-то вроде ContactMailer.AttemptMail(project);

Но есть определенные условия, при которых письмо НЕ должно быть отправлено: проект помечен как DoNotSurvey или как Challenged (= кто-то оспаривает, что письмо не должно быть отправлено, и решение об этом должен принять админ), и если нет действительный опрос для такого рода проекта.

Мой вопрос: эта проверка может быть в процедуре типа CheckMailConditions или что-то в этом роде, но где эта процедура? Должно ли это быть в де ContactMailer? Это кажется несколько странным, хотя это и есть проверка, следует ли отправлять почту. Или это должен быть отдельный класс? Это похоже на SRP (класс, у которого есть одна обязанность: проверка условий), но это привело бы к одному классу с одним методом, что кажется излишним.

Или я должен проверить эти условия еще до вызова ContactMailer.AttemptMail, так как они являются свойствами проекта? Я немного потерян.

Заранее спасибо за ваши мысли!


person Community    schedule 07.08.2013    source источник


Ответы (1)


Я не думаю, что вы нарушаете правило единой ответственности, включая проверки в свой класс ContactMailer. Он будет нести единственную ответственность за отправку почты, если проект соответствует определенным условиям.

Класс с одним методом не обязательно является излишним, и могут быть веские причины для абстрагирования логики проверки в отдельный класс, которые мне не очевидны из вашего вопроса. Однако из того, что вы сказали, я думаю, что ваша архитектура звучит абсолютно нормально.

Кстати, если бы вы выделили логику проверки в отдельный класс, как бы вы назвали этот класс? MailConditionsChecker? По моему опыту, обычно это плохой знак, если трудно придумать осмысленное существительное для названия своего класса.

person net.uk.sweet    schedule 07.08.2013
comment
Спасибо за отзыв, который помогает мне быть более уверенным в выборе. Хорошее эмпирическое правило о сложности именования, я буду иметь это в виду :) Ваше предложенное имя звучит так, как имя, которое я бы использовал. Просто из любопытства, какие были бы веские причины для абстрагирования логики проверки в класс, как вы упомянули? Одна из причин, которая приходит на ум, заключается в том, что если есть много условий, которые сделают код беспорядочным, но тогда вы также можете просто поместить его в процедуру. - person ; 08.08.2013
comment
Я могу придумать несколько причин для его разделения - возможно, другой класс должен иметь возможность использовать ту же логику проверки. Или, возможно, вам нужно иметь возможность запускать почтовый класс без логики проверки в определенных средах/ситуациях, возможно, при тестировании. - person net.uk.sweet; 08.08.2013
comment
Кстати, добро пожаловать в stackoverflow! Если ответ был вам полезен, не забудьте нажать на зеленую стрелку, чтобы принять его. Спасибо. - person net.uk.sweet; 09.08.2013