Принцип на единична отговорност и класове

Надявам се, че мога да изясня с какво се боря :-) Ето го. Чудя се как да внедря 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