Определите классы и стратегии именования классов

Я пытаюсь понять принцип единой ответственности и определить возможный класс, который может быть в моей системе.

На данный момент я знаю принципы, сказанные дядей Бобом, а именно: избегайте ласковых слов, таких как "менеджер", "данные", "супервизор" или "процессор". Мы должны иметь возможность написать описание класса менее чем из 25 слов без использования таких слов, как «если», «и», «или» и «но».

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

Например: у меня был сценарий, в котором 1. Мне нужно отправить электронное письмо пользователю. 2. Электронная почта будет проверена, когда пользователь перейдет по ссылке.

Итак, мой класс будет таким:

Сценарий 1:

class EmailVerifier
{
      function sendEmail();
      function verifyEmail();
}

OR

Сценарий 2:

class EmailVerifier
    {
          function verifyEmail();
    }

class MailSender
    {
          function verifyEmail();
    }

Если я скажу, что сценарий 1 верен, я попытался написать описание класса, это будет примерно так:

Класс EmailVerifier отправляет электронное письмо клиенту и проверяет его.

Если я говорю, что сценарий 2 верен, то для каждого встречающегося глагола или каждой функции, например: verifyEmail (), sendEmail (), addEmail (), мне нужно создать новый класс.

Подскажите, пожалуйста, какой способ правильный.

Также,

У меня есть сценарий, в котором я должен,

Добавить клиента, Удалить клиента, Изменить клиента, Сохранить клиента Поиск клиента, Выбрать всех клиентов, Найти клиента по идентификатору

Могу ли я назвать такие классы как CustomerService class или любая другая стратегия именования будет лучше.

Примечание. Я уже видел другие подобные вопросы
Именование классов - Как не называть все« менеджером »‹WhatEver›?


solid-principles design-principles
person swapyonubuntu    schedule 07.01.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Начнем с примера Customer, потому что так проще. В стандартной архитектуре MVC у вас будет CustomerController, который взаимодействует с CustomerDAO. Я оставляю вам в качестве упражнения при необходимости погуглить термины архитектура MVC и объект доступа к данным.

В примере с электронной почтой мы можем упростить проблему именования, применив более объектно-ориентированный подход в отличие от процедурного. Проще говоря, ООП говорит нам, что данные должны быть объединены с логикой, которая ими управляет. В этом случае я предлагаю объединить объект (данные) Email с функцией (логикой) verify, что позволит электронной почте проверить себя.

class Email
{
  function verify();
  function getMessage();
  // etc.
}

Еще лучше, чтобы шаблон проектирования, такой как Builder, позволял выполнять проверку перед построением объекта Email; потому что, в конце концов, зачем вообще создавать Email объект, если он не может пройти проверку? Обратите внимание, что логика проверки может измениться по той же причине, что и структура самого объекта электронной почты. По той же причине изменить == Единая ответственность.

Наконец, поскольку отправка электронного письма не зависит от самого электронного сообщения, MailSender остается отдельным классом, т.е. отправка также является единственной обязанностью.

person jaco0646    schedule 08.01.2016
comment
Я знаком с MVC и DAO, и я сослался на ваш код, у меня есть сомнения: почему я буду делать новый Email (). Verify (). Build (), как вы сказали, я не буду создавать электронную почту, если она недействительна? - person swapyonubuntu; 09.01.2016
comment
В шаблоне Builder проверка обычно происходит в методе build(). Например, Email.builder().setArg1().setArg2().build(). Метод build() либо возвращает объект Email, либо вызывает исключение. Обратите внимание, что пример кода в моем ответе не строителя. - person jaco0646; 09.01.2016