1. 从“重复劳动”到“优雅设计”为什么我们需要继承和多态我记得刚学Java那会儿老师布置过一个作业让我计算一堆不同形状的周长和面积。那时候我写了两个数组一个放矩形一个放圆形然后写了两个循环一个算矩形的一个算圆形的。代码又长又啰嗦而且每次要加一个新形状比如三角形我就得再声明一个数组再加一个循环。那时候我就想这肯定不是最好的办法太笨了。后来接触到面向对象特别是继承和多态这两个概念我才恍然大悟。原来之前那种写法本质上还是在用面向过程的思维去处理数据。而Java PTA里这个经典的Shape练习就是帮你把思维从“怎么做”扭转到“是什么”的绝佳桥梁。它不只是一个练习题更像是一个设计思维的启蒙。这个练习的核心场景很明确你有一个需求要管理多种几何形状计算它们的总面积和总周长。最原始的做法就像我开头说的是为每种形状维护单独的列表写重复的累加代码。这种代码的“坏味道”很明显紧耦合和低扩展性。代码逻辑和具体的形状类型死死绑在一起加一个新形状就得动好多地方。而面向对象的设计尤其是利用继承和多态能让我们写出像“魔法”一样的代码。你可以创建一个Shape数组里面既能放Rectangle也能放Circle。当你遍历这个数组调用getArea()方法时Java运行时会自动判断当前元素到底是矩形还是圆形然后执行对应的方法。你不需要写if (shape instanceof Rectangle)这样的判断语句代码变得异常简洁和统一。这背后的思想就是抽象和统一接口。我们把“形状”这个概念抽象出来规定所有形状都必须有能力回答“你的周长是多少”和“你的面积是多少”这两个问题。至于具体怎么算那是矩形、圆形它们自己的事。作为使用者的我们只需要关心“形状”这个抽象概念而不必操心具体是哪种形状。这种设计带来的好处是巨大的代码更容易维护也更容易扩展。下次要加一个三角形你只需要新建一个Triangle类继承Shape实现那两个方法就行之前计算总和的核心代码一行都不用改。2. 庖丁解牛一步步拆解Shape继承体系的设计2.1 定下规矩抽象类Shape的基石作用抽象类Shape在这个设计里扮演着“宪法”的角色。它自己不实现具体功能但它立下了所有子类必须遵守的规矩。abstract class Shape { static final double PI 3.14; public abstract double getPerimeter(); public abstract double getArea(); }我们一行行来看。abstract class关键字宣告了这是一个抽象类它不能被new出来。你没法创建一个叫“形状”的实体就像现实世界里你没法画一个既不是圆也不是方仅仅是“形状”的东西。但它定义了“形状”应该有的行为契约。static final double PI 3.14;这一行很有意思。static意味着这个常量属于Shape类本身而不是任何一个实例。final意味着它是不可变的常量。把它放在父类Shape里是一种很好的设计。因为圆周率PI是圆形计算需要的矩形用不到。那为什么不放在Circle类里呢放在Shape里体现了“共享”和“归属”的概念。所有形状至少在数学范畴内都可能用到圆周率比如椭圆、扇形。即使现在只有Circle用从设计上把它放在更抽象的顶层也显得更加合理和面向未来。我在实际项目里就见过把一些基础常量比如错误码、基础配置放在顶级抽象类或接口中的做法方便所有子类引用。最关键的是那两个抽象方法getPerimeter()和getArea()。用abstract修饰表示只有方法签名没有方法体没有{}。这就是在说“我Shape要求我的所有子孙不管你是圆是方还是三角都必须给我实现怎么算周长和面积这个方法。具体怎么算我不管但你必须得有。” 这就是定义规范。它强制了所有子类都必须具备这两种能力保证了整个家族体系行为的一致性。2.2 具体实现Rectangle和Circle如何各司其职规矩定好了接下来就是具体的“打工人”来实现这些规矩。Rectangle和Circle类通过extends Shape关键字宣告了它们对Shape的继承关系。这意味着它们自动拥有了Shape里定义的PI常量同时也必须实现那两个抽象方法否则自己也会变成抽象类没法实例化。先看Rectangleclass Rectangle extends Shape { private int width; private int length; public Rectangle(int width, int length) { this.width width; this.length length; } Override public double getPerimeter() { return 2 * (width length); // 矩形周长公式 } Override public double getArea() { return width * length; // 矩形面积公式 } Override public String toString() { return Rectangle [width width , length length ]; } }这里有个细节值得注意属性width和length被声明为private。这是封装思想的体现。将数据隐藏起来只通过公共方法如构造方法和getter本题未要求getter进行访问和修改保证了对象内部状态的安全性和可控性。构造方法用于在创建对象时初始化这些属性。Override注解是个好习惯虽然不是强制的但我强烈建议你每次都写上。它告诉编译器和读代码的人“这个方法是我从父类那里重写实现的。” 如果一不小心写错了方法名或签名编译器会立刻报错帮你避免很多低级错误。getPerimeter()和getArea()的实现就是简单的数学公式把矩形的业务逻辑封装在了内部。toString()方法的重写也很有用。当你用System.out.println打印一个对象或者像题目中那样用Arrays.toString()打印数组时会自动调用这个方法来获取对象的字符串表示。默认的Object.toString()输出的是类名和哈希码可读性很差。重写后我们能一眼看出这个矩形的宽和高是多少调试的时候非常方便。Eclipse/IDEA的自动生成功能Source - Generate toString()...可以快速生成这个方法的代码。Circle类的结构如出一辙只是属性换成了radius计算周长面积时用到了父类的PI常量public double getPerimeter() { return PI * this.radius * 2; // 2πr } public double getArea() { return PI * this.radius * this.radius; // πr² }注意这里可以直接使用PI也可以使用Shape.PI但更简洁的方式是直接使用PI因为继承下来了。这里也体现了继承的一个好处代码复用。我们不需要在每个圆形对象里都存一个PI的副本大家共用父类的那一份就行。2.3 灵魂所在多态机制如何让代码“活”起来前面都是铺垫多态才是让这一切设计产生化学反应的催化剂。多态简单说就是“同一个行为方法在不同的对象上会有不同的实现”。在Main类的sumAllArea和sumAllPerimeter方法里我们清晰地看到了多态的魔力public static double sumAllArea(Shape[] shapes) { double sum 0; for (Shape s : shapes) { sum s.getArea(); // 看这里 } return sum; }这个方法接收一个Shape[]数组。注意数组的类型是Shape这意味着它里面可以存放任何Shape类型的对象或者说任何Shape的子类对象这是多态在赋值上的体现“父类引用可以指向子类对象”。在循环里我们调用s.getArea()。这里的s在编译时类型是Shape。编译器只知道s是一个形状它只关心Shape类里有没有getArea()这个方法。至于运行的时候s到底是Rectangle还是Circle编译器不关心。当程序运行时Java虚拟机JVM会查看s实际指向的对象类型。如果对象是Rectangle就执行Rectangle类中实现的getArea()如果是Circle就执行Circle类的getArea()。这个动态绑定方法的过程就是运行时多态。这带来的好处是颠覆性的计算总和的代码完全与具体的形状类型解耦了。它只依赖于Shape这个抽象契约。无论未来数组里加入多少种新形状Triangle,Ellipse等只要它们正确继承了Shape并实现了那两个方法这段求和的代码就永远不需要修改。这极大地提高了代码的可扩展性和可维护性。对比一下最初面向过程的写法你需要知道数组里具体有哪些类型然后写一堆if-else来判断和调用。那种写法每加一种新形状你就得去修改这个核心的求和函数违反了“对修改关闭对扩展开放”的开闭原则。而多态的实现完美符合了这一原则。3. 实战演练深入Main方法中的关键细节与踩坑点3.1 输入处理的“坑”nextInt()与nextLine()的混用PTA题目和很多实际输入场景中经常需要混合读取整数和字符串。这里有一个经典的“坑”题目提示里也专门提到了“处理输入的时候使用混合使用nextInt与nextLine需注意行尾回车换行问题”。我们来看看题目的main方法里是怎么处理的int n in.nextInt(); // 读取形状个数 in.nextLine(); // 读取掉数字后面的换行符 Shape[] shapes new Shape[n]; for (int i 0; i n; i) { String shape in.nextLine(); // 读取形状类型 rect 或 cir if (shape.equals(rect)) { int width in.nextInt(); int length in.nextInt(); in.nextLine(); // 再次读取掉数字后面的换行符 shapes[i] new Rectangle(width, length); } else { int radius in.nextInt(); in.nextLine(); // 同上 shapes[i] new Circle(radius); } }为什么需要那么多in.nextLine()这是因为Scanner的nextInt()方法只读取整数而不读取整数后面跟着的换行符\n。这个换行符会留在输入缓冲区里。当紧接着调用nextLine()时nextLine()会读取直到换行符为止的内容并把换行符消耗掉。如果缓冲区里已经有一个换行符那么nextLine()就会立刻读取到一个空字符串。举个例子假设输入是2 rect 1 2in.nextInt()读取2缓冲区剩下\nrect\n1 2\n。如果不调用in.nextLine()直接进入循环String shape in.nextLine()会立刻读取到那个遗留的\n得到一个空字符串这显然不是我们想要的rect。所以在in.nextInt()后需要立刻加一句in.nextLine()来“吞掉”那个换行符让缓冲区指针移动到下一行的开头。同理在if分支里读取完width和length两个整数后缓冲区又留下了换行符为了下一次循环能正确读取形状类型必须再用一个in.nextLine()清理掉。这个细节在编程题中非常容易出错我当年就没少在这里丢分。一个更稳健的做法是全部使用nextLine()读取然后用Integer.parseInt()来转换数字这样可以避免混用带来的问题。3.2 工具方法的设计放在哪里用static吗题目最后有一个思考题“你觉得sumAllArea和sumAllPerimeter方法放在哪个类中更合适是否应该声明为static”这是一个很好的设计思维训练。我们先看题目给出的做法是放在Main类里并且声明为static。这样做的好处是简单直接因为main方法也是static的在同一个类里调用很方便。但从面向对象的设计角度我们可以有更优的考虑。1. 放在哪里这两个方法操作的对象是Shape数组功能是计算所有形状的几何属性总和。它们本质上是对一组Shape对象进行操作的工具方法。一个更面向对象、职责更清晰的做法是创建一个专门的工具类比如叫ShapeUtils或GeometryCalculator把这些方法放进去。这样Main类只负责程序流程控制输入输出计算逻辑被分离到工具类中符合单一职责原则。更进一步如果这些方法和某个具体的Shape子类关系特别紧密比如某些计算只针对矩形组合也可以考虑放在对应的子类里但本题中是对所有形状的通用操作所以工具类或父类Shape本身是更合适的位置。实际上放在Shape类里作为一个静态方法也是不错的选择因为它逻辑上属于“形状”这个范畴的运算。2. 是否应该声明为static声明为static意味着这个方法属于类而不是类的某个实例。调用时直接用类名.方法名()。对于sumAllArea这样的方法它不需要访问或修改某个特定Shape对象的内部状态它只读取每个对象的面积值它的功能仅依赖于传入的参数Shape[]因此非常适合设计成static方法。这样调用起来更方便无需先创建某个类的实例。如果非要做成实例方法那它应该属于谁呢属于数组这很奇怪。属于某个Shape对象让一个矩形去计算一堆形状的总面积在逻辑上说不通。所以在这个场景下声明为static方法是合理且推荐的。综合来看一个更优雅的设计可能是public abstract class Shape { // ... 原有属性和抽象方法 ... // 将工具方法放在父类中作为静态方法 public static double sumAllArea(Shape[] shapes) { // ... 实现 ... } public static double sumAllPerimeter(Shape[] shapes) { // ... 实现 ... } } // 或者在另一个工具类中 public final class ShapeUtils { private ShapeUtils() {} // 私有构造防止实例化 public static double sumAllArea(Shape[] shapes) { ... } public static double sumAllPerimeter(Shape[] shapes) { ... } }3.3 类型信息探查getClass()与反射的初窥题目的输出要求里最后一部分是输出每个形状的类型与父类型。这是用到了Java的反射机制的一个简单入门。for (Shape s : shapes) { System.out.println(s.getClass() , s.getClass().getSuperclass()); }s.getClass()返回的是s对象运行时实际的Class对象它包含了这个类的元信息。getSuperclass()则返回其父类的Class对象。所以对于Rectangle对象会输出class Rectangle,class Shape。这里要注意输出格式getClass()返回的字符串通常包含class前缀。这在调试和某些需要根据类型做动态处理的场景中非常有用。不过在实际生产代码中除非必要比如编写通用框架、序列化工具应尽量避免直接使用getClass()进行类型判断因为这会破坏多态带来的优势。更好的方式依然是定义好抽象方法让多态去分发行为。4. 举一反三如何将Shape设计应用到更复杂的场景掌握了这个基本的Shape继承体系后我们可以玩出更多花样让设计更贴近真实项目。4.1 扩展新形状三角形、椭圆与更多现在要加一个Triangle类简直轻而易举。这就是开闭原则的魅力对扩展开放。class Triangle extends Shape { private double a, b, c; // 三条边 public Triangle(double a, double b, double c) { // 这里最好加入三角形合法性校验两边之和大于第三边 this.a a; this.b b; this.c c; } Override public double getPerimeter() { return a b c; } Override public double getArea() { // 使用海伦公式 double p getPerimeter() / 2; return Math.sqrt(p * (p - a) * (p - b) * (p - c)); } }你看我们只需要新建一个类实现该实现的。原来的Main方法、sumAllArea等函数完全不需要动。把Triangle对象放进Shape[]数组一切照常运行。这就是设计良好的系统应有的弹性。再比如Ellipse椭圆它的面积公式是π*a*b周长计算比较复杂没有初等精确公式可用近似公式。我们同样可以继承Shape在getPerimeter()里实现一个近似算法。这展示了另一个点子类实现的方法其内部复杂度对使用者是透明的。使用者只管调用getPerimeter()不关心你是简单乘法还是复杂近似计算。4.2 引入接口让设计更具弹性抽象类Shape定义了一个“是什么”IS-A的关系矩形是一种形状。但有时候我们需要定义“能做什么”CAN-DO的关系。这时接口就派上用场了。假设我们的系统不仅需要计算面积周长还需要某些形状能够被“绘制”Drawable或者被“移动”Movable。我们可以定义接口interface Drawable { void draw(Graphics g); // 假设有一个Graphics对象用于绘制 } interface Movable { void move(int deltaX, int deltaY); }然后可以让Circle和Rectangle在继承Shape的同时实现这些接口class Circle extends Shape implements Drawable, Movable { // ... 原有属性方法 ... Override public void draw(Graphics g) { g.drawOval(...); // 绘制圆形的具体实现 } Override public void move(int deltaX, int deltaY) { // 更新圆心坐标 } }这样Circle就具备了多重能力。在程序中我们可以这样用Shape s new Circle(5); if (s instanceof Drawable) { ((Drawable) s).draw(canvas); // 进行绘制 }接口提供了比继承更灵活的“能力”组合方式。一个类只能继承一个父类但可以实现多个接口。通过“抽象类定义核心属性接口定义扩展能力”的方式可以构建出非常灵活和强大的对象体系。4.3 设计模式初探工厂方法创建对象观察Main方法中的输入处理部分有一段根据字符串创建不同对象的代码if (shape.equals(rect)) { shapes[i] new Rectangle(width, length); } else { shapes[i] new Circle(radius); }如果形状类型很多这里的if-else会变得很长。这是一个典型的“变化点”。我们可以引入简单工厂模式来封装对象创建逻辑。class ShapeFactory { public static Shape createShape(String type, Scanner scanner) { switch (type.toLowerCase()) { case rect: int w scanner.nextInt(); int l scanner.nextInt(); scanner.nextLine(); // 吞换行 return new Rectangle(w, l); case cir: int r scanner.nextInt(); scanner.nextLine(); // 吞换行 return new Circle(r); case tri: double a scanner.nextDouble(); double b scanner.nextDouble(); double c scanner.nextDouble(); scanner.nextLine(); return new Triangle(a, b, c); default: throw new IllegalArgumentException(Unsupported shape type: type); } } }然后在main方法中创建对象的代码就变得非常简洁String type in.nextLine(); shapes[i] ShapeFactory.createShape(type, in);这样一来对象创建的细节被隐藏在了工厂类里。以后要新增形状只需要修改ShapeFactory类而main方法中的业务逻辑完全不受影响。这进一步降低了耦合提高了代码的可维护性。工厂模式是面向对象设计中用来处理对象创建的一种非常常用的模式理解了这个简单的例子就算是迈进了设计模式的大门。