JavaBeans方法的签名必须遵循某些约定，例如set ... / get ...等。它们的约定是...例如isEven()可以是Integer类测试布尔值的方法。但后来我想知道为什么没有...也是一个合法的标识符，因为我有必要测试一些东西，例如对于Person类或类似的hasCar()。
你明白我的问题吗？你觉得怎么样？
答案 0 :(得分：5)
嗯，一般惯例是使用get...和set...，因此is...只是布尔值的例外。对于is...，约定很简单：你需要返回一个布尔值，可以跳过getter，相应的setter也会得到一个布尔参数。
has...的约定会更加困难：has...会返回一个布尔值，但你仍然需要一个处理不同类型的getter和setter。因此，has...不能替代get...而不是is...，因为JavaBeans约定的那部分通常只是关于getter和setter has...不适合那里。
来自JavaBeans规范：
属性是Java Bean的离散命名属性......
属性以多种方式显示：
- ...
- 可以通过调用其 getter 的其他组件以编程方式访问属性 和 setter 方法（参见下面的第7.1节）。
- ...
使用has...访问的任何属性都不会持久存在，也不会被其getter方法访问。
示例：如果某人拥有car属性，则您希望拥有getCar()访问者。 hasCar()不会是访问者，因为派生属性hasCar需要名为getHasCar()或isHasCar()的访问者。如果has是访问者前缀，则该属性将具有冲突的名称car。
答案 1 :(得分：1)
get/set和is/set只是约定。我同意，有时候调用getter hasSomething会更具可读性。例如hasChildren()。但是让我们继续前进并说可以调用方法canWrite()或willFly()或providesResult()等等。你可以使用这些名称，但这些名称不符合java bean约定，因此会不被java bean框架识别为getter。
Java Beans是很多年前发明的。定义注释@Setter和@Getter可能不是一个坏主意。如果这些注释变得普遍，那么所有java bean框架都可以支持它们，程序员可以根据需要调用getter，但使用注释@Getter标记它们。但是现在不支持这样的注释，因此唯一的建议是遵循现有的命名约定。
答案 2 :(得分：0)
我认为这根本不是一个坏问题！我也考虑过这一点，发现人们确实使用它like you intend to use it。只是大多数库（比如你可以使用的库）都没有。
我同意它应该对布尔属性有效。