聊聊 Service 命名与设计
Service 类到底是什么含义？我相信如果碰到一个叫 SomethingService 的类，没法马上明白它到底起什么作用。
说实话，我们都很困惑。
经过多年的专业开发，在大量的代码中游走，有一点是显而易见的，开发人员不太擅长给事物命名。
作为一个菜鸟开发者，我知道当看到 SomeService 或 WhateverManager 类，或者是 WhatevsManagerService 时，你都会不知所措或疑惑不解。
Class 命名就像工作头衔
BD？实际是一个销售人员。Social Media 专家？可能是 3 周学会如何在 Instagram 上发布猫咪照片。软件工程师？实际上是堆砌代码的码农。
工作头衔和工作角色有时候不挂钩，我们更喜欢把头衔弄得比角色更花哨。
Class 命名也是如此。
服务（service）类
任何以 Service 为后缀的代码基本上都是一个逻辑垃圾箱。任何添加到程序中的新功能，最后总是以某种服务类的方式来实现。
一个服务类需要大量的构造函数参数，使得测试起来非常麻烦。要测试一个新方法 GetUserCount()？可能需要 mock 7 个完全不相关的类来实例化这个服务类。
如果 GetUserCount() 只依赖于服务类中的一个构造函数参数，那么最好把它移到自己的类中。这样一来，你就有一个非常简单的类，只有一个构造函数参数。
当然，单独的 GetUserCount 类看起来不是那么酷，但至少你知道它到底是做什么的。
测试变得轻而易举。
Manager 类
你很可能见过类似 UserManager 这样的类，它管理用户。
像服务类一样，它们也是逻辑垃圾箱。但是有一点区别。如果说服务类是一个普通的垃圾箱，那么 Manager 类就像一个纸板垃圾箱，它更特殊一点。
你会面临和服务类一样的处理单元测试的问题。在做最微小的操作之前，你需要 mock 一大堆东西。
Util 类和 Helper 类
"我们不知道把这些代码塞在哪里好，所以就弄了一个 Util 类"。
这些都是烦人的东西。关于这一点，没有什么好说的了。
怎么破？
很简单。给出与职责相匹配的合适名称。把一个类命名为GetUser，并且只有一个方法，这并不丢人。实现也简单，每个人都知道它是做什么的。容易进行单元测试。
停止代码膨胀，简化这些类。比如，构建只有一个方法的类。
关于作者：
Nicklas Millard 是一家快速发展中的银行担任软件工程师，负责构建关键任务的金融服务基础设施。
此前，他曾是 Big4 高级技术顾问，为商业客户和政府机构开发软件。
他的 LinkedIn：https://www.linkedin.com/in/nicklasmillard/
英文原文：
https://medium.com/datadriveninvestor/the-true-meaning-of-service-and-manager-class-names-d09a08731fd9
本文由高可用架构翻译，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。