相关疑难解决方法(0)

提出好的,准确的课程名称是众所周知的困难.如果做得好,它会使代码更加自我记录,并提供一个词汇表来推断更高抽象级别的代码.

实现特定设计模式的类可以根据众所周知的模式名称(例如FooFactory,FooFacade)给出一个名称,直接模拟域概念的类可以从问题域中获取它们的名称,但是其他类呢？当我缺乏灵感,并且想避免使用泛型类名(如FooHandler,FooProcessor,FooUtils和FooManager)时,有什么类似于程序员的词库吗？

在课程结束时,您发现自己经常使用哪些名词？

例如,我习惯坚持Info传递信息的类,但没有做很多事情:

• ImportInfo
• SiteInfo

或者用于协调课程:

• UserManager
• SecurityManager

我最终Builder经常使用字符串相关的类,即使它几乎没有任何建筑:

• TemplateBuilder
• HtmlBuilder

当然还有永恒的Helper/Utility类:

• PhraseHelper
• NumberUtility
• FileHelper

你有什么好处,我的意思是你经常用来表示班级主要角色的简洁和描述性的名词或单词吗？

这个问题针对.NET世界,但可以扩展到Java,C++,Python等.

我正在阅读书清洁代码http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

作者提到您应该在类的名称中避免使用管理器,处理器,数据或信息等单词.我到处都用过这些.什么是更好的名字？我有一个负责启动和停止连接的类.所以我把它命名为ConnectionManager.

我经常很难决定如何命名一个班级.不是因为班级的目的不明确,而是因为名字像xxx***控制器***,xxx***经理***,xxx***信息***,xxx***助手***,xxx***Util***等我到处都看到了.

如果我有一个通过HTTP上传一些内容的类,我倾向于将它命名为HttpUploader或者其他内容.我见过很多实例,其中一个类似的类被命名为HttpUploadManager,HttpTransmissionController,HttpUploadHelper等等.

关于何时使用Controller,Manager,Info等,我有点困惑. 是否有任何文章或书籍可以帮助我成为更好的课程名称？

PS:此外,与HttpTransmissionController或HttpDispatchManager相比,像HttpSender这样的名字听起来相当贫血:P

随着我职业生涯的成长，我认为命名约定非常重要。我注意到人们会乱扔控制器、LibraryController服务、LibraryService提供者，LibraryProvider并且在某种程度上可以互换使用它们。使用其中一种与另一种有什么具体的理由吗？

如果有网站有更具体的定义那就太好了。

假设我有一个PetManager和一个Cat：

class PetManager
{
    PetManager(IBusinessLayer businessLayer, IWashingService washingService);

    IBusinessLayer BusinessLayer;

    IWashingService WashingService;
}

class Cat
{
    Cat(PetManager manager, string name, int levelOfStupidity);
}

现在让我们说，我的猫需要洗衣服，要从我的宠物经理那里得到抚养费，它是如此地难道吗？

class Cat
{
    Cat(PetManager manager, string name, int levelOfStupidity)
    {
        this.manager = manager;
        this.name = name;
        this.levelOfStupidity = levelOfStupidity;
    }

    IWashingService WashingService
    {
        get { return this.manager.WashingService; }
    }
}

我强烈怀疑是的，这可能是...

我有一个负责发送和接收消息的类。消息是通过 using 发送的myInstance.send(message, channel)，消息是通过注册MessageListener一个频道来收听的。

我通常只是将其称为相当通用的东西，例如 MessageManager，但我最近阅读了命名类 - 如何避免将所有内容都称为“<WhatEver>Manager”？这让我试图找到另一个名字。我最接近一个好名字的是 MessageDispatcher，它并没有真正传达也接收消息的事实。这种性质的类是否有任何常用名称？

我目前在一个项目中有几个“经理”类，但是看到了很多建议您不要使用经理类，但在我的情况下似乎没有提供其他选择的东西。我有一个ClickManager，其中包含“可单击”对象的映射，以及一个ConfigManager，它负责加载和保存配置文件，因为config类来自我正在使用的API，并且太笨而无法加载自身。

在这些情况下，使用“经理”有哪些替代方案？