如果getter对象的状态无效，是否应该抛出异常？

我经常遇到这个问题，特别是在Java中，即使我认为这是一个普遍的OOP问题。即：引发异常会揭示设计问题。

假设我有一个包含一个String name字段和一个String surname字段的类。

然后，它使用这些字段来组成一个人的全名，以便将其显示在某种文件上，例如发票。

public void String name;
public void String surname;

public String getCompleteName() {return name + " " + surname;}

public void displayCompleteNameOnInvoice() {
    String completeName = getCompleteName();
    //do something with it....
}

现在，我想通过displayCompleteNameOnInvoice在分配名称之前调用引发错误来增强类的行为。似乎是个好主意，不是吗？

我可以在getCompleteName方法中添加引发异常的代码。但是以这种方式，我违反了与类用户的“隐式”合同。通常，如果未设置获取方法的值，则不应将其抛出异常。好的，这不是标准的获取方法，因为它不会返回单个字段，但是从用户的角度来看，区分可能太微妙了，无法考虑它。

或者，我可以从中抛出异常displayCompleteNameOnInvoice。但是，这样做我应该直接测试name或surname字段，这样做会违反表示的抽象getCompleteName。检查并创建完整名称是此方法的责任。根据其他数据，它甚至可以决定在某些情况下足够了surname。

因此，唯一的可能性似乎是将方法的语义更改getCompleteName为composeCompleteName，这表明行为更“活跃”，并且具有抛出异常的能力。

这是更好的设计解决方案吗？我一直在寻找简单性和正确性之间的最佳平衡。有针对此问题的设计参考吗？

不要在没有分配名称的情况下构造您的类。

DeadMG提供的答案几乎可以解决这个问题，但让我用不同的措词来表达：避免使对象具有无效状态。对象在完成任务的上下文中应该是“整个”的。否则它不应该存在。

因此，如果您需要流动性，请使用诸如Builder Pattern之类的东西。或与“真实事物”相反的其他任何东西，它是对构造中对象的单独验证，在后者中，保证后者具有有效状态，并且实际上是公开针对该状态定义的操作（例如getCompleteName）的事物。

没有具有无效状态的对象。

构造器或构造器的目的是将对象的状态设置为一致且可用的状态。没有这种保证，对象中初始化状态不正确的问题就会出现。如果您要处理并发，并且在完全设置对象之前，某些对象可以访问该对象，则此问题会变得更加复杂。

因此，这部分的问题是“为什么要允许名称或姓氏为空？” 如果那不是使类正常工作的有效方法，请不要允许它。有一个可以正确验证对象创建的构造函数或生成器，如果不正确，请在那时提出问题。您可能还希望使用现有的@NotNull注释之一来帮助传达“此不能为空”并在编码和分析中强制执行。

有了此保证，就可以更轻松地对代码进行推理，做什么，而不必在奇数处引发异常或对getter函数进行过多检查。

获得更多功能的吸气剂。

关于这个问题有很多地方。您已经在Getters中获得了多少逻辑，并且在getters和setters中应该允许什么？从这里开始，getter和setter在Stack Overflow上执行其他逻辑。这是在类设计中一次又一次出现的问题。

其核心来自：

通常，如果未设置它们的值，则不应该将它们都抛出异常

你是对的。他们不应该。他们应该向世界其他地方“哑巴”，并尽其所能。在其中放置过多的逻辑会导致违反最小惊讶法则的问题。顺便说一句，您真的不想用a来包装吸气剂，try catch因为我们知道总体上我们有多喜欢这样做。

在某些情况下，您必须使用getFooJavaBeans框架之类的方法，并且在EL调用中有一些东西期望获得一个bean（因此<% bar.foo %>实际上是getFoo()在类中调用-撇开'bean应该做组合还是应该留给视图？”，因为一个人很容易想到其中一个显然可以是正确答案的情况）

还应意识到，有可能在接口中指定给定的getter，或者使其成为要重构的类的先前公开的公共API的一部分（以前的版本只是返回了“ completeName”，并且重构中断了）它分为两个字段）。

在一天结束时...

做最容易推理的事情。与设计代码相比，您将花费更多的时间维护代码（尽管花费的设计时间越少，维护的时间就越多）。理想的选择是以一种不会花费太多时间来维护的方式进行设计，但是也不要坐在那里几天思考它-除非这确实是一个设计选择，它将在几天后产生影响。 。

试图坚持使用吸气剂的语义纯正性private T foo; T getFoo() { return foo; }将使您在某个时候遇到麻烦。有时，代码只是不适合该模型，而试图将其保持为这种方式所要经过的扭曲是没有意义的，最终使设计变得更加困难。

有时，请接受您无法在代码中实现设计理想的想法。准则是准则-并非束缚。

我不是Java专家，但这似乎符合您提出的两个约束。

getCompleteName如果名称未初始化，则不会引发异常，并且displayCompleteNameOnInvoice不会。

public String getCompleteName()
{
    if (name == null || surname == null)
    {
        return null;
    }
    return name + " " + surname;
}

public void displayCompleteNameOnInvoice() 
{
    String completeName = getCompleteName();
    if (completeName == null)
    {
        //throw an exception.
    }
    //do something with it....
}

似乎没人在回答您的问题。
与人们喜欢相信的东西不同，“避免无效对象”通常不是实际的解决方案。

答案是：

是的，应该。

简单的例子：FileStream.Length在C＃/。NET中，NotSupportedException如果文件不可搜索则抛出该错误。

您将整个检查名称的内容颠倒了。

getCompleteName()不必知道哪些功能会利用它。因此，不具有namewhen呼叫displayCompleteNameOnInvoice()不是getCompleteName()责任。

但是，这name是的明确前提displayCompleteNameOnInvoice()。因此，它应该承担检查状态的责任（或者，如果愿意，应该将检查的责任委托给另一种方法）。