它避免了脆弱的基类问题。每个类都带有一组隐式或显式保证和不变式。Liskov替代原则要求该类的所有子类型还必须提供所有这些保证。但是，如果不使用，这很容易违反final。例如，让我们有一个密码检查器：
public class PasswordChecker {
public boolean passwordIsOk(String password) {
return password == "s3cret";
}
}
如果我们允许重写该类，则一个实现可以将所有人锁定，另一个实现可以使所有人访问：
public class OpenDoor extends PasswordChecker {
public boolean passwordIsOk(String password) {
return true;
}
}
这通常不行，因为子类现在的行为与原始行为非常不兼容。如果我们确实打算将班级与其他行为一起扩展，那么责任链会更好：
PasswordChecker passwordChecker =
new DefaultPasswordChecker(null);
// or:
PasswordChecker passwordChecker =
new OpenDoor(null);
// or:
PasswordChecker passwordChecker =
new DefaultPasswordChecker(
new OpenDoor(null)
);
public interface PasswordChecker {
boolean passwordIsOk(String password);
}
public final class DefaultPasswordChecker implements PasswordChecker {
private PasswordChecker next;
public DefaultPasswordChecker(PasswordChecker next) {
this.next = next;
}
@Override
public boolean passwordIsOk(String password) {
if ("s3cret".equals(password)) return true;
if (next != null) return next.passwordIsOk(password);
return false;
}
}
public final class OpenDoor implements PasswordChecker {
private PasswordChecker next;
public OpenDoor(PasswordChecker next) {
this.next = next;
}
@Override
public boolean passwordIsOk(String password) {
return true;
}
}
当更多复杂的类调用其自己的方法时，问题将变得更加明显，并且这些方法可以被覆盖。在漂亮地打印数据结构或编写HTML时，有时会遇到这种情况。每个方法负责一些小部件。
public class Page {
...;
@Override
public String toString() {
PrintWriter out = ...;
out.print("<!DOCTYPE html>");
out.print("<html>");
out.print("<head>");
out.print("</head>");
out.print("<body>");
writeHeader(out);
writeMainContent(out);
writeMainFooter(out);
out.print("</body>");
out.print("</html>");
...
}
void writeMainContent(PrintWriter out) {
out.print("<div class='article'>");
out.print(htmlEscapedContent);
out.print("</div>");
}
...
}
现在，我创建一个子类，添加更多样式：
class SpiffyPage extends Page {
...;
@Override
void writeMainContent(PrintWriter out) {
out.print("<div class='row'>");
out.print("<div class='col-md-8'>");
super.writeMainContent(out);
out.print("</div>");
out.print("<div class='col-md-4'>");
out.print("<h4>About the Author</h4>");
out.print(htmlEscapedAuthorInfo);
out.print("</div>");
out.print("</div>");
}
}
现在暂时忽略这不是生成HTML页面的好方法，如果我想再次更改布局会怎样？我必须创建一个SpiffyPage以某种方式包装该内容的子类。我们在这里看到的是模板方法模式的偶然应用。模板方法是基类中定义明确的扩展点，将被覆盖。
如果基类发生变化会怎样？如果HTML内容更改太多，则可能会破坏子类提供的布局。因此，事后更改基类并不真正安全。如果您所有的类都在同一个项目中，则这并不明显，但是如果基类是其他人所构建的某些已发布软件的一部分，则这一点将非常明显。
如果打算采用这种扩展策略，我们可以允许用户交换每个零件的生成方式。无论哪种情况，都可以从外部提供每个块的策略。或者，我们可以嵌套装饰器。这将等同于上面的代码，但是更加明确和灵活得多：
Page page = ...;
page.decorateLayout(current -> new SpiffyPageDecorator(current));
print(page.toString());
public interface PageLayout {
void writePage(PrintWriter out, PageLayout top);
void writeMainContent(PrintWriter out, PageLayout top);
...
}
public final class Page {
private PageLayout layout = new DefaultPageLayout();
public void decorateLayout(Function<PageLayout, PageLayout> wrapper) {
layout = wrapper.apply(layout);
}
...
@Override public String toString() {
PrintWriter out = ...;
layout.writePage(out, layout);
...
}
}
public final class DefaultPageLayout implements PageLayout {
@Override public void writeLayout(PrintWriter out, PageLayout top) {
out.print("<!DOCTYPE html>");
out.print("<html>");
out.print("<head>");
out.print("</head>");
out.print("<body>");
top.writeHeader(out, top);
top.writeMainContent(out, top);
top.writeMainFooter(out, top);
out.print("</body>");
out.print("</html>");
}
@Override public void writeMainContent(PrintWriter out, PageLayout top) {
... /* as above*/
}
}
public final class SpiffyPageDecorator implements PageLayout {
private PageLayout inner;
public SpiffyPageDecorator(PageLayout inner) {
this.inner = inner;
}
@Override
void writePage(PrintWriter out, PageLayout top) {
inner.writePage(out, top);
}
@Override
void writeMainContent(PrintWriter out, PageLayout top) {
...
inner.writeMainContent(out, top);
...
}
}
（必须使用附加top参数来确保调用writeMainContent通过装饰器链的顶部。这模拟了称为open recursion的子类功能。）
如果我们有多个装饰器，我们现在可以更自由地混合它们。
重用现有类的某些部分的需求远比稍微修改现有功能的需求更多。我见过这样的情况：有人想要一堂课，您可以在其中添加项目并遍历所有项目。正确的解决方案是：
final class Thingies implements Iterable<Thing> {
private ArrayList<Thing> thingList = new ArrayList<>();
@Override public Iterator<Thing> iterator() {
return thingList.iterator();
}
public void add(Thing thing) {
thingList.add(thing);
}
... // custom methods
}
相反，他们创建了一个子类：
class Thingies extends ArrayList<Thing> {
... // custom methods
}
这突然意味着的整个界面ArrayList已成为我们界面的一部分。用户可以remove()事物或get()特定索引处的事物。打算这样吗？好。但通常，我们不会仔细考虑所有后果。
因此建议
- 从来
extend没有认真思考过的课程。
- 始终将您的类标记为，
final除非您打算覆盖任何方法。
- 在要交换实现的地方创建接口，例如用于单元测试。
有许多示例必须打破此“规则”，但它通常会指导您进行良好而灵活的设计，并避免由于基类的意外更改（或子类作为基类的实例的意外使用）而导致的错误。 ）。
一些语言具有更严格的执行机制：
- 默认情况下，所有方法都是最终方法，必须将其显式标记为
virtual
- 它们提供的私有继承不继承接口，而仅继承实现。
- 它们要求将基类方法标记为虚方法，并且还要求将所有替代标记为标记。这样可以避免出现以下问题：子类定义了新方法，但后来将具有相同签名的方法添加到基类中，但不希望将其用作虚拟方法。
final？许多人（包括我在内）发现，使每个非抽象类都成为一个很好的设计final。