1. 从一个看似简单的Java题目说起
第一次看到这个题目的时候，很多人会觉得它平平无奇——不就是写一个Point类描述平面坐标吗？构造函数、getter、setter，三下五除二就能搞定。但真正动手写的时候，问题就来了：setPoint方法到底该怎么设计？参数校验要不要做？坐标精度用什么类型？为什么面试官总爱拿这种"简单题"来考察候选人？
我带过不少刚入行的开发者，也帮朋友做过模拟面试，发现一个很有意思的现象：越是看起来简单的题目，越能拉开差距。一个Point类，有人写出来只有十几行，有人能写出上百行还附带完整的单元测试。这中间的差距，不是代码量的问题，而是对面向对象设计思想的理解深度。
这篇文章就围绕这个经典的Java题目展开，把Point类的设计、setPoint方法的实现、坐标系统的处理、以及在实际项目中如何优雅地使用这类基础类，掰开揉碎讲清楚。不管你是刚学Java的新手，还是想复习基础准备面试的老手，都能从里面找到有用的东西。我会从设计思路讲到代码实现，从参数校验讲到精度处理，再补充一些实际项目中踩过的坑和优化技巧，尽量做到拿来就能用。
2. Point类设计的核心思路拆解
2.1 为什么题目要这样设计
题目给出的结构其实很典型：一个Point类，包含double类型的x和y，一个无参构造，一个有参构造，再加上setPoint方法。这个设计背后藏着几个考察点。
第一个考察点是封装。x和y用private修饰，外部只能通过方法访问，这是面向对象最基本的封装原则。很多新手会直接把字段设成public，觉得这样写起来方便，但一旦项目变大，想加个校验逻辑或者改变内部存储方式，就会牵一发而动全身。
第二个考察点是构造函数的重载。无参构造和有参构造同时存在，这是Java里很常见的模式。无参构造给框架用（比如反射创建对象），有参构造给业务代码用。这里有个细节：一旦你写了有参构造，Java就不会自动生成无参构造了，必须手动补上。这个坑我见过太多人踩。
第三个考察点是setPoint方法的设计。题目里写的是"setPo..."，明显是setPoint被截断了。这个方法的作用是一次性设置x和y两个坐标，而不是分别调用setX和setY。为什么要这样设计？因为坐标是一个整体概念，单独改x或改y可能会让对象处于不一致的中间状态。一次性设置两个值，能保证操作的原子性。
2.2 数据类型选择的考量
题目明确要求用double类型，这是有道理的。平面坐标通常需要表示小数，用int会丢失精度。但double也有它的问题——浮点数运算存在精度误差，比如0.1 + 0.2不等于0.3。在实际项目中，如果涉及金额或者需要精确计算的场景，通常会改用BigDecimal。但对于坐标这种场景，double的精度（约15-17位有效数字）已经足够，而且性能更好。
这里补充一个知识点：float是32位，double是64位。float的有效数字大约7位，double大约15位。坐标计算中经常涉及开方、三角函数等运算，float的精度很容易不够用，所以double是更稳妥的选择。
2.3 可变对象还是不可变对象
这是一个进阶话题。Point类可以是可变的（提供setter），也可以是不可变的（所有字段final，不提供setter）。题目要求有setPoint方法，说明它期望的是可变对象。但在实际项目中，不可变对象有很多好处：线程安全、可以安全地作为HashMap的key、避免意外修改。
我个人的经验是：如果这个Point类只是用来做数据传输（DTO），那可变对象更方便；如果它会被多个线程共享，或者作为集合的key，那最好设计成不可变的。Java自带的java.awt.Point就是可变的，而一些现代库（比如某些图形库）会提供不可变的Point实现。
3. 核心代码实现与细节打磨
3.1 基础版本的完整实现
先给出一个符合题目要求的基础版本，然后逐步优化。
public class Point { private double x; private double y; public Point() { this.x = 0.0; this.y = 0.0; } public Point(double x, double y) { this.x = x; this.y = y; } public double getX() { return x; } public void setX(double x) { this.x = x; } public double getY() { return y; } public void setY(double y) { this.y = y; } public void setPoint(double x, double y) { this.x = x; this.y = y; } @Override public String toString() { return "Point{" + "x=" + x + ", y=" + y + '}'; } }这段代码能跑，也符合题目要求。但如果你拿这个去面试，面试官可能会追问几个问题：equals和hashCode要不要重写？坐标需不需要做范围校验？toString的格式有什么讲究？
3.2 重写equals和hashCode的必要性
默认的equals比较的是对象引用，也就是说两个坐标相同的Point对象会被判定为不相等。这在很多场景下是不符合预期的。比如你把Point放进HashSet去重，或者用List.contains判断是否包含某个坐标，都会出问题。
@Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; Point point = (Point) o; return Double.compare(point.x, x) == 0 && Double.compare(point.y, y) == 0; } @Override public int hashCode() { return Objects.hash(x, y); }注意这里用的是Double.compare而不是直接==。因为double有NaN和-0.0这些特殊值，直接比较会出问题。Double.compare能正确处理这些边界情况。这个细节很多人不知道，但在实际项目中确实会遇到。
3.3 setPoint方法的参数校验
基础版本没有做任何校验，但实际项目中，坐标往往有范围限制。比如在一个100x100的画布上，坐标不能是负数，也不能超过100。这时候setPoint就需要加校验。
public void setPoint(double x, double y) { if (Double.isNaN(x) || Double.isNaN(y)) { throw new IllegalArgumentException("坐标不能为NaN"); } if (Double.isInfinite(x) || Double.isInfinite(y)) { throw new IllegalArgumentException("坐标不能为无穷大"); } this.x = x; this.y = y; }为什么要校验NaN和无穷大？因为这两个值一旦进入计算，会污染整个坐标系统。比如你算两点距离，一个NaN进去，结果就是NaN，而且很难排查。在图形处理、地图应用这些场景里，提前拦截非法值能省下大量调试时间。
3.4 坐标精度处理的实战技巧
前面提到double有精度问题。在坐标比较时，不能直接用==，而应该用一个误差范围（epsilon）。
private static final double EPSILON = 1e-9; public boolean isSamePoint(Point other) { if (other == null) return false; return Math.abs(this.x - other.x) < EPSILON && Math.abs(this.y - other.y) < EPSILON; }EPSILON取多少合适？这取决于你的业务场景。如果是普通图形界面，1e-6就够了；如果是科学计算，可能需要1e-12。我一般用1e-9，能覆盖大多数场景。这个值不能太大，否则会把本来不同的点判定为相同；也不能太小，否则浮点误差会导致误判。
4. 从Point类延伸出的实用功能
4.1 计算两点距离
Point类最常见的操作之一就是算距离。这里涉及一个经典公式：欧几里得距离。
public double distanceTo(Point other) { if (other == null) { throw new IllegalArgumentException("目标点不能为空"); } double dx = this.x - other.x; double dy = this.y - other.y; return Math.sqrt(dx * dx + dy * dy); }这里有个性能优化点：如果只是比较距离大小，不需要开方，直接比较平方值就行。因为开方是单调函数，平方大的距离一定大。在需要大量比较的场景（比如找最近点），这个优化能省不少CPU时间。
public double distanceSquaredTo(Point other) { double dx = this.x - other.x; double dy = this.y - other.y; return dx * dx + dy * dy; }4.2 坐标平移和旋转
在实际项目中，坐标变换是很常见的需求。比如把一个图形整体向右移动10个单位，或者绕原点旋转90度。
public Point translate(double dx, double dy) { return new Point(this.x + dx, this.y + dy); } public Point rotate(double angleRadians) { double cos = Math.cos(angleRadians); double sin = Math.sin(angleRadians); double newX = this.x * cos - this.y * sin; double newY = this.x * sin + this.y * cos; return new Point(newX, newY); }注意这里返回的是新对象，而不是修改当前对象。这种设计叫"不可变操作"，能避免副作用。如果你希望修改当前对象，可以再加一个void版本的rotate方法。两种风格各有优劣，关键是要保持一致，不要混用。
4.3 坐标系统的转换
热词里提到了"坐标转换"和"EPSG坐标对照表"，这涉及到地理坐标系。在GIS（地理信息系统）开发中，经常需要在不同的坐标系之间转换。比如WGS-84（GPS用的坐标系）和Web Mercator（网页地图用的坐标系）。
虽然Point类本身不负责坐标转换，但它可以作为转换的载体。实际项目中，通常会有一个CoordinateSystem接口，然后不同的坐标系实现这个接口，提供toWgs84、toWebMercator等方法。Point类只负责存储x和y，转换逻辑放在专门的工具类里。这样职责清晰，也符合单一职责原则。
5. 常见问题与排查技巧实录
5.1 为什么我的Point放进HashSet去重失效了
这是最经典的问题。原因就是没有重写equals和hashCode。HashSet判断元素是否重复，先比较hashCode，如果hashCode相同再调用equals。默认的hashCode是基于对象地址的，两个坐标相同的Point对象hashCode不同，自然就被当成不同元素了。
解决方法就是前面说的，重写这两个方法。注意重写equals时必须同时重写hashCode，否则会出现"两个对象equals相等但hashCode不同"的矛盾情况，导致HashSet行为异常。
5.2 浮点数比较为什么总是不相等
比如你计算了一个点的坐标，理论上应该是(0.3, 0.4)，但实际存的是(0.30000000000000004, 0.4)。这是因为0.1+0.2在二进制浮点数里不等于0.3。这不是Java的bug，而是IEEE 754标准的特性。
解决办法有两个：一是用epsilon比较，前面已经讲过；二是用BigDecimal，但性能会差一些。对于坐标场景，epsilon比较是更实用的选择。
5.3 setPoint和构造函数有什么区别
从功能上看，两者都能设置坐标。区别在于：构造函数用于创建对象时初始化，setPoint用于修改已存在对象的状态。如果一个对象创建后就不应该再改变坐标，那就只提供构造函数，不提供setPoint，把它设计成不可变对象。
在实际项目中，我倾向于对值对象（Value Object）使用不可变设计。因为值对象代表一个概念，比如"坐标(3,4)"，这个概念本身不应该被改变。需要新坐标时，创建一个新对象就好。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| HashSet去重失效 | 未重写equals/hashCode | 同时重写这两个方法 |
| 浮点数比较不相等 | IEEE 754精度误差 | 使用epsilon比较 |
| 反序列化报错 | 缺少无参构造 | 手动添加无参构造 |
| 坐标出现NaN | 非法输入未校验 | setPoint中校验NaN和Infinity |
| 多线程下坐标错乱 | 可变对象共享 | 改为不可变对象或加锁 |
6. 进阶话题：Point类在实际项目中的应用
6.1 作为HashMap的key
Point作为key时，必须保证不可变性。如果对象创建后坐标还能改，那hashCode就会变，导致在HashMap里找不到原来的entry。这是一个非常隐蔽的bug，我见过有人在生产环境踩过这个坑，排查了大半天。
所以如果要把Point当key用，要么设计成不可变对象，要么在使用期间绝对不调用setPoint。前者更安全，后者靠约定，容易出问题。
6.2 序列化注意事项
如果Point需要网络传输或持久化，就要实现Serializable接口。这里有个细节：serialVersionUID最好显式声明，否则类结构一变，反序列化就会失败。
public class Point implements Serializable { private static final long serialVersionUID = 1L; // ... }另外，如果字段用了transient修饰，序列化时会被忽略。这个特性可以用来排除一些不需要传输的缓存字段。
6.3 与第三方库的集成
很多图形库和GIS库都有自己的Point类，比如java.awt.Point、JTS的Coordinate等。在集成时，通常需要做转换。我的建议是：在系统边界做转换，内部统一用一种Point。不要在不同层之间传来传去，那样会导致代码混乱。
转换代码通常很简单：
public static Point fromAwtPoint(java.awt.Point awtPoint) { return new Point(awtPoint.getX(), awtPoint.getY()); } public java.awt.Point toAwtPoint() { return new java.awt.Point((int) this.x, (int) this.y); }注意awt.Point用的是int，转换时会丢失小数部分。如果精度重要，就要考虑用java.awt.geom.Point2D.Double。
6.4 性能优化建议
在高频创建Point对象的场景（比如游戏循环、图形渲染），对象创建的开销不容忽视。这时候可以考虑几个优化方向：一是用对象池复用Point对象；二是用基本类型数组代替对象；三是用值类型（Java目前还没有，但Project Valhalla在推进中）。
不过我要提醒一句：优化之前先测量。大多数场景下，JVM的对象分配和GC已经足够快，过早优化反而会增加代码复杂度。只有当profiler明确显示Point创建是瓶颈时，才需要考虑这些手段。
7. 我个人的一些实操体会
写了这么多年Java，关于Point这类基础类，我有几个体会想分享。
第一，不要小看基础题。面试官让你写Point类，不是真的想看你会不会写getter和setter，而是想看你的代码习惯、边界意识、设计思维。一个能考虑到equals重写、参数校验、不可变设计的候选人，和一个只会写基础版本的候选人，差距是显而易见的。
第二，基础类要写得足够健壮。Point会被用在系统的各个角落，它的任何缺陷都会被放大。我见过因为Point没校验NaN，导致整个图形渲染管线崩溃的案例。基础类的代码质量，值得花更多时间打磨。
第三，保持一致性。如果你的项目里有的地方用可变Point，有的地方用不可变Point，那迟早会出问题。选定一种风格，然后在团队内统一。我个人的偏好是：传输用可变，计算用不可变，边界处做转换。
第四，善用工具。IDE能自动生成equals、hashCode、toString，但你要理解生成的是什么。Lombok的@Data能省很多代码，但要知道它默认生成的是可变对象。工具是辅助，理解才是根本。
最后分享一个小技巧：在写Point类的时候，顺手写几个单元测试。测试坐标相等、距离计算、边界值处理。这些测试不仅能验证代码正确性，还能作为文档，告诉后来者这个类应该怎么用。我现在的习惯是，任何基础类都配一套测试，长期来看省下的调试时间远超写测试的时间。
