我目前正在将一些项目从Ant迁移到Maven.循规蹈矩,因为我,我想用行之有效的约定查找groupId和artifactId,但我找不到任何详细的约定(也有一些,但不包括我想了解一下点).
以此项目为例,首先是Java包: com.mycompany.teatimer
Tea计时器实际上是两个单词,但Java包命名约定禁止插入下划线或连字符,所以我将它们全部写在一起.
我选择了groupId相同的包ID,因为我认为这是一个好主意.是吗？
最后,我必须选择一个artifactId,我目前去了teatimer.但是当我查看其他Maven项目时,他们使用连字符来分割artifactIds中的单词,如下所示:tea-timer.但是当连接到groupId:时确实看起来很奇怪com.mycompany.teatimer.tea-timer.
你会怎么做？
另一个例子:
包裹名字: com.mycompany.awesomeinhouseframework
groupId:( com.mycompany.awesomeinhouseframework？)
artifactId:( awesome-inhouse-framework？)
我通常使用1.0.0版开始我的项目.只要我有一些东西在一起,我将其发布为1.0.0并继续使用1.1.0.
但是,这导致了我编写的大多数内容的可用但不完全特征完整的1.0.0版本.然后我添加功能,并在1.6.0附近得到一个不错的版本.许多项目从版本0.1.0开始,这将与我的1.0.0一样可用.
你会建议做什么？从1.0.0或0.1.0开始？
最后一个数字仅适用于bugfix版本.您可以将我的1.0.0视为1.0和0.1.0为0.1,这对您来说更容易.
关于C++中的访问器方法的几个问题已经被问到,但没有一个能够满足我对这个问题的好奇心.
我试图尽可能避免使用访问器,因为像Stroustrup和其他着名的程序员一样,我认为一个类很多都是OO的标志.在C++中,我可以在大多数情况下为类添加更多的责任或使用friend关键字来避免它们.但在某些情况下,您确实需要访问特定的班级成员.
有几种可能性:
1.根本不要使用存取器
我们可以公开相应的成员变量.这在Java中是不行的,但对于C++社区似乎没问题.但是,我有点担心的情况是一个显式副本或一个对象的只读(const)引用应该返回,是夸大了吗？
2.使用Java样式的get/set方法
我不确定它是否来自Java,但我的意思是:
int getAmount(); // Returns the amount
void setAmount(int amount); // Sets the amount
3.使用客观的C风格的get/set方法
这有点奇怪,但显然越来越普遍:
int amount(); // Returns the amount
void amount(int amount); // Sets the amount
为了使其工作,您必须为您的成员变量找到不同的名称.有些人附加下划线,其他人加上"m_".我也不喜欢.
你使用哪种风格？为什么？
我正在学习测试驱动的开发,我注意到它会强制松散耦合的对象,这基本上是一件好事.然而,这有时也会迫使我为通常不需要的属性提供访问器,我认为SO上的大多数人都认为访问器通常是设计糟糕的标志.做TDD时这是不可避免的吗？
这是一个例子,没有TDD的实体的简化绘图代码:
class Entity {
private int x;
private int y;
private int width;
private int height;
void draw(Graphics g) {
g.drawRect(x, y, width, height);
}
}
实体知道如何绘制自己,这很好.一切都在一个地方.但是,我正在做TDD,所以我想通过我即将实现的"fall()"方法检查我的实体是否正确移动了.以下是测试用例的样子:
@Test
public void entityFalls() {
Entity e = new Entity();
int previousY = e.getY();
e.fall();
assertTrue(previousY < e.getY());
}
我必须查看对象的内部(好的,至少逻辑上)状态,并查看位置是否正确更新.因为它实际上是在路上(我不希望我的测试用例依赖于我的图形库),所以我将绘图代码移动到"Renderer"类:
class Renderer {
void drawEntity(Graphics g, Entity e) {
g.drawRect(e.getX(), e.getY(), e.getWidth(), e.getHeight());
}
}
松散耦合,很好.我甚至可以用一个以完全不同的方式显示实体的渲染器替换渲染器.但是,我不得不公开实体的内部状态,即所有属性的访问器,以便渲染器可以读取它.
我觉得这是由TDD特别强制的.我该怎么办？我的设计可以接受吗？Java是否需要C++中的"friend"关键字？
更新:
感谢您迄今为止的宝贵意见!但是,我担心我选择了一个不好的例子来说明我的问题.这完全弥补了,我现在将演示一个更接近我的实际代码:
@Test
public void entityFalls() {
game.tick();
Entity initialEntity = mockRenderer.currentEntity;
int numTicks = …我正在使用下划线命名样式(与camel case相反)编写C++,这也是STL和boost使用的.但是,由于类型和变量/函数都被命名为全小写,因此如下的成员变量声明将导致编译器错误(或至少是麻烦):
position position;
名为position的成员变量,其类型为position.我不知道如何命名它:它通常是一个位置,但它也是对象的位置.在驼峰的情况下,这对编译器来说没问题:
Position position;
但在C++中它会导致问题.我不想切换到驼峰的情况下,使用匈牙利表示法或添加一个尾随下划线因此,所以我想知道:将类似的成员命名为一个好的做法是不是很好？
在C中,为此使用神秘的单字母变量是很常见的:
int i;
但我发现有点,嗯,神秘:
position p;
我可以用来避免这种变量命名的经验法则吗？
如果您需要处理以下内容,我的代码中会有更多示例:
mouse_over(entity entity) // Returns true if the mouse is over the entity
manager &manager; // A reference to the framework's manager
audio audio; // The audio subsystem
编辑:
我很想知道Bjarne Stroustrup本人在这个问题上是否有话要说.显然,他没有,但他提出了可以解决我的编译器问题的编码约定:
例如,大写非标准库用户定义类型并使用小写字母启动非类型
这与STL和提升是一致的,所以我可能会使用它.但是,大多数人都同意,无论是否编译,都应避免使用此命名.Stroustrup也是如此:
选择仅以大小写不同的名称是不明智的.
在大多数团队中,有一条规则规定@author和@since关键字必须用于所有记录的类,有时甚至是方法.
为了关注重要的事情,我不使用这些关键字,而是依赖于我可以使用源代码管理系统来确定类的作者是谁以及何时存在的事实.
我相信@author和@since来自版本控制尚未普及的时代,我认为它们现在已经相当多余了.你觉得这个怎么样？现代Java项目应该使用它们吗？