sli*_*mbo 9 java architecture uml naming-conventions
我现在在几家不同的公司工作,每个人都有关于如何命名类和包的不同规则.它们各自具有不同的包布局和类之间的工作流程.通过这些经历,我了解了如何布局项目; 但是,我想更具体地定义如何布局项目.这个问题更多的是关于uml而不是关于命名约定.
我很好奇的是关于以下内容的官方架构定义是什么(我已经看到帮助器用作实用程序和管理器用作帮助程序等).
对我来说:
帮助程序是一个外观,或者它编码/解码特定的数据格式,并且在调用之间没有状态.
实用程序用于编码/解码格式或执行IO,如果创建连接,则通常不会保持连接或在调用之间保持文件打开.
管理员就像一个助手,但确实在通话之间有状态.
Factory是一个获取或创建然后返回一个对象(自定义对象或API对象)的类.
简单和默认通常只是指基类.
我的"类"往往是用于预先飞行的想法和代码示例,尽管它有时用于生产代码,例如MyApplication和MyView(主要用于命名单例).
这些类名实际上是.这些是我最常创建和看到的含义,但经常会出现矛盾的命名方案和不一致.它们不是正式的设计模式名称,在实践中,任何这些名称的选择似乎几乎是任意的.有些人用它们中的一个来标记所有类的线程安全的类,以及那些与另一个不同的类.
通常我也会看到一个"管理器"名称被赋予一个类,该类使用对象或键执行ORM函数,或者对仲裁连接的对象执行.
编辑
我看到一个构建在框架上的应用程序通常具有以下主要对象:
我认为专注于最大化可测试性并最小化这些接口的表面积比包命名和文件命名更重要; 我认为您应该按照自己的想法为您的项目进行详细的细分和命名.将代码拆分为用于SCM目的的不同文件对于上面的多个子弹所依赖的共享文件特别重要.
编辑
我使用单身,飞重,复合,迭代器,纪念品,观察者,状态,策略作为例行事项.我使用Facade,代理,模块之间和UI代码中的责任链.我偶尔会在复杂的数据系统中使用工厂,原型和构建器,在系统特别复杂的概念上使用模板和访问者.当行为复杂时,偶尔会使用适配器,桥接器,工厂,抽象工厂,装饰器.我很少使用Interpreter,我使用mediator来帮助我在某些情况下编写更多通用代码.我个人并不喜欢在GoF之后命名我的课程,但很多人都很高兴,这可能是一个好主意,我并不反对这种做法.它可以是非常有用的,如果它让人们开心,它确实帮助每个人清楚地了解特定情况下发生的事情,那就太棒了.
我只是觉得调用我的app对象是Singleton,Composite或ChainOfResponsibilityLink(？)感觉并不好,并且调用我的网络和数据库代码Adapters感觉并不好,所以我称之为Managers.而且我在GoF,Helpers或Utilities下调用了许多应该称为Facades的东西,因为我觉得它更清楚意味着什么.
| 归档时间： |
|
| 查看次数： |
1339 次 |
| 最近记录： |