确定类和类命名策略

时间:2016-01-07 09:32:01

标签: solid-principles design-principles

我正在尝试理解单一责任原则,并确定可能在我的系统中的可能类。

现在我知道鲍勃叔叔说的原则,即  避免像经理,数据,超级或处理器那样的狡猾的话。 我们应该能够在不使用“if”,“and”,“或”和“<”等词语的情况下用少于25个单词写出课程描述。

然而,当我试图确定我是否真的正确地遵循SRP时会出现问题。

例如:我有一个场景 1.我需要向用户发送电子邮件。 2.当用户点击链接

时,将验证电子邮件

所以,我的课就像:

  

情景1:

CREATE OR REPLACE PROCEDURE SYSTEM.create_table_from_schema IS
  v_dml_str VARCHAR2 (400);
  v_own_array     VARCHAR2(128);
  v_tab_array   VARCHAR2(128);
  cursor c1 is
     SELECT owner,table_name
    from SYS.all_tables  
  where global_stats='YES'
  And owner = 'MEDICINE';
BEGIN

   FOR i in c1
   LOOP
    v_dml_str := 'Create table MEDICINE2.'
                 ||i.table_name||' as (select * from '||i.owner||'.'|| i.table_name
                 ||' minus select * from MEDICINE1.'|| i.table_name||' )'  ;             
    EXECUTE IMMEDIATE v_dml_str;
  END LOOP;
END;
/

OR

  

情景2:

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

如果我说场景1是正确的,我试着写出类的描述,就像是,

  

EmailVerifier类向客户发送电子邮件验证电子邮件。

如果我说场景2是正确的,那么对于我遇到的每个动词或每个函数,例如: verifyEmail(),sendEmail(),addEmail(),我需要创造新的课程。

请告诉我可能的正确方法。

此外,

我有一个场景,我必须,

  

添加客户,删除客户,编辑客户,节省客户   通过id搜索客户,选择所有客户,FindCustomer

对于这样的类,我可以将它们命名为 CustomerService 类,或者任何其他命名策略会更好。

注意:我已经看过其他问题了 Naming Classes - How to avoid calling everything a "<WhatEver>Manager"?

1 个答案:

答案 0 :(得分:1)

让我们从Customer示例开始,因为这更简单。 在标准MVC架构中,您将拥有与CustomerController交互的CustomerDAO。如果有必要,我会将其留作练习,以便您使用 MVC架构数据访问对象这些术语。

在电子邮件示例中,我们可以通过应用更多面向对象的方法而不是程序方法来简化命名问题。简单来说,OOP告诉我们数据应该与操作它的逻辑相结合。在这种情况下,我建议将Email对象(数据)与verify函数(逻辑)结合使用,从而允许电子邮件自行验证。

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

更好的是,诸如Builder之类的设计模式将允许在构造Email对象之前进行验证;因为,毕竟,如果无法通过验证,为什么要首先创建一个Email对象呢?请注意,验证逻辑可能会因为与电子邮件对象本身的结构相同的原因而发生更改。改变的原因相同==单一责任。

最后,由于发送电子邮件与电子邮件本身无关,因此MailSender仍为其自己的类,即发送也是单一责任。