1. 从“福彩3D”到“JAVA继承”：一个练手项目的设计初衷

第一次看到“福彩3D-JAVA继承”这个组合，很多人会愣一下：一个是数字型彩票玩法，一个是面向对象三大特性之一，这两者怎么凑到一块的？其实这正是我当年带新人时最常用的一个教学型练手项目——用福彩3D这个规则简单、边界清晰、结果可验证的业务场景，去承载JAVA继承体系的完整演练。它不是什么商业级彩票系统，而是一个把抽象类、接口、方法重写、多态调用、构造器链这些知识点串起来的实战载体，适合刚学完JAVA基础语法、对继承还停留在“extends关键字怎么用”阶段的同学，也适合想找个干净例子给团队做内部分享的开发者。

福彩3D的规则本身非常适合做教学建模：每期开出一个三位数（000到999），玩家可以按直选、组选三、组选六等不同方式投注，不同玩法对应不同的中奖判定逻辑和奖金规则。这个“同一份开奖号码，不同玩法给出不同判定结果”的结构，天然就是多态的绝佳素材。你想想，如果不用继承，代码里会堆满if-else判断玩法类型，每加一种玩法就要改一次核心方法，改到最后没人敢动。而用继承把“玩法”抽象成一个基类，让直选、组选各自实现自己的判定逻辑，新增玩法只需要加一个子类，核心流程一行不用动——这就是我想通过这个项目讲清楚的事。

这个项目的核心价值不在于教你买彩票，而在于让你亲手体会一件事：继承不是为了少写几行代码，而是为了把“变化的部分”隔离出去。很多教程讲继承只讲语法，讲完你还是不知道什么时候该用、什么时候不该用。而这个项目里，玩法是会不断增加的变量，开奖号码和投注流程是相对稳定的部分，继承恰好架在这条分界线上。跟着做一遍，你会对“父类放什么、子类放什么、什么时候该用抽象类而不是普通类”有一手的判断力。

我先把项目的整体轮廓交代清楚，方便你判断要不要跟下去。整个Demo包含几个核心角色：一个开奖号码的承载对象、一个投注单的抽象基类、若干具体玩法子类（直选、组选三、组选六）、一个负责结算的服务类，以及一个跑通全流程的入口。代码量不大，但继承体系该有的坑一个不少——构造器调用顺序、父类私有字段的访问、方法重写的返回值协变、抽象方法与模板方法的配合，全都能在这个场景里踩到。下面我按设计思路、核心细节、实操落地、问题排查四个层面展开，每一步都告诉你为什么这么设计，而不只是贴代码。

2. 继承体系怎么搭：先想清楚“什么是变的，什么是不变的”

2.1 为什么用抽象类而不是接口打头阵

动手写第一行代码之前，有个选型问题必须先定：投注玩法的基类，到底用抽象类还是接口？我见过不少新手上来就写interface BetType，理由是“接口更灵活”。灵活是灵活，但在这个场景里不合适。原因很实在：不同玩法之间共享大量状态和实现——投注金额、注数、开奖号码、公共的校验逻辑、公共的格式化输出，这些都应该放在基类里让子类直接复用。接口只能声明行为，没法持有实例字段，也没法提供带实现的公共方法（默认方法虽然可以，但塞状态进去很别扭）。用抽象类，父类可以把“所有玩法都一样”的部分写死，把“每个玩法不一样”的部分留成抽象方法，子类只专注实现差异点。

具体到代码结构，我设计的基类大致长这样：持有betAmount（投注金额）、betCount（注数）、openNumber（开奖号码）这几个protected字段，提供一个calculatePrize()的抽象方法让子类实现中奖金额计算，再提供一个isWin()的模板方法——它内部先做公共的号码格式校验，再调用子类的matchRule()判断是否命中，最后根据结果决定返回奖金还是零。这种“父类定流程骨架、子类填判定细节”的写法就是典型的模板方法模式，继承在这里不只是代码复用，更是流程控制权的分配。

提示：抽象类的抽象方法数量要克制。我见过有人把基类写成“全抽象”，每个方法都让子类实现，那还不如用接口。抽象类的价值恰恰在于它能承载“已实现的部分”，抽象方法只留真正因玩法而异的判定逻辑，一般一到两个就够了。

2.2 字段可见性：protected不是万能钥匙

字段用protected还是private，是这个项目里第一个容易翻车的地方。直觉上，子类要访问父类字段，那就设protected呗，省事。但我实际写下来发现，protected字段会让继承体系变得很脆——子类可以随意改父类状态，父类的任何字段调整都可能悄悄影响所有子类，而且这种耦合在编译期完全看不出来。我的做法是：字段一律private，需要给子类用的通过protected的getter暴露，或者干脆在父类提供protected的模板方法，让子类通过方法参数拿到需要的数据。

举个例子，开奖号码openNumber我设成private，父类的isWin()模板方法在调用子类matchRule(String openNumber, String betContent)时把号码作为参数传进去。子类根本不需要持有这个字段的引用，它只需要在方法签名里接收、做判定、返回布尔值。这样父类的内部状态对子类完全封闭，子类想乱改也改不了，继承体系的边界一下就清晰了。这个细节看起来小，但它决定了你后面加第十种玩法时，是安心加子类，还是提心吊胆地检查有没有子类偷偷改了父类字段。

2.3 构造器链：super()那行不能省，也不能乱放

构造器是继承里最容易被忽视、又最容易出隐蔽bug的地方。JAVA的规则是：子类构造器第一行必须调用父类构造器，你不写，编译器自动帮你插一个无参的super()。问题在于，如果父类只定义了带参构造器、没写无参构造器，子类又不显式调super(参数)，编译直接报错。我在项目里故意让基类只保留带参构造器（接收投注金额和注数），逼着每个子类构造器显式写super(betAmount, betCount)，这样投注单的初始化路径一目了然，不会出现“某个子类忘了初始化金额导致结算为0”的诡异问题。

构造器的执行顺序也值得在这里说透，因为它是很多“为什么我的字段是null”问题的根源。子类构造器执行时，先调父类构造器，父类构造器里如果调用了可被重写的方法，而此时子类字段还没初始化，方法里访问子类字段拿到的就是默认值（对象是null，数字是0）。这个坑我在早期版本里真踩过：基类构造器里调了一个initDisplayName()，子类重写了它并返回一个依赖子类字段的字符串，结果打印出来全是null。解决办法很简单——构造器里不要调用可被重写的方法，初始化逻辑挪到显式的init方法或者干脆放到使用侧。这条经验比任何语法书上的解释都管用。

3. 核心玩法子类的实现细节：直选、组选三、组选六各写各的

3.1 直选子类：最直白的全等判定

直选玩法的规则最简单：投注号码和开奖号码完全一致（顺序也要一致）才算中奖。子类实现起来就是一行字符串equals，但这里面有个细节值得抠——号码的格式化。福彩3D的开奖号码是三位，允许前导零，比如007、023。如果你在存储或比较时把它当整数处理，前导零就丢了，007变成7，跟投注的007永远对不上。所以整个项目里号码统一用定长三位的String承载，比较前先做补零格式化。这个坑非常典型，凡是涉及编号、号码、编码的场景都要警惕“数值化丢前导零”。

直选子类的matchRule实现大致是：接收开奖号码字符串和投注内容字符串，两者都格式化成三位后做equals，相等返回true。calculatePrize则根据是否命中返回固定奖金（直选单注奖金按常见规则设为1040元，这里只是教学取值，实际以官方规则为准）。注意calculatePrize里不要重复写判定逻辑，应该复用父类模板方法已经算好的命中结果，或者调用isWin()。我见过子类里把判定逻辑抄两遍的写法，改规则时改了一处漏一处，这就是继承没用好、反而制造了重复。

3.2 组选三与组选六：判定逻辑开始分叉

组选三的规则是：开奖号码三位中有两位相同（即“对子”形态，如112、454），投注号码与开奖号码的数字组合一致即中奖，不考虑顺序。组选六则是三位数字各不相同（如123），组合同样不考虑顺序。这两个玩法的判定逻辑明显比直选复杂，正好体现继承的价值——它们各自实现自己的matchRule，但共享父类的金额校验、号码格式化、模板流程。

组选三的判定我拆成两步：先判断开奖号码是否真的是“对子”形态（排序后第一位等于第二位，或第二位等于第三位），如果不是对子，这期组选三根本不存在中奖可能，直接返回false；如果是对子，再把投注号码和开奖号码各自排序后比较。组选六同理，先判断开奖号码是否三位互异，再排序比较。这里排序比较是个很实用的技巧：不考虑顺序的集合比较，先归一化（排序）再比较，比写一堆排列组合判断清爽得多。字符串排序用chars().sorted()转回来就行，三位的量级完全不用担心性能。

有个容易忽略的边界：投注号码本身的合法性。玩家投注组选三，理论上投注号码也应该是对子形态，但实际输入可能不合法。我的处理是在子类的matchRule里先校验投注号码形态，不合法直接判不中奖并记录一条警告日志，而不是抛异常中断整个结算流程。这个取舍的理由是：结算服务是批量处理投注单的，一张脏单不该拖垮整批。这种“防御性判定”的思路在真实业务里很常见，教学项目里提前养成习惯不吃亏。

3.3 方法重写的返回值与异常约定

三个子类重写matchRule时，返回值统一是boolean，签名完全一致，这是重写的基本要求。但calculatePrize这里有个值得说的点：父类声明它返回BigDecimal而不是double。金额计算用浮点数是大忌，0.1+0.2不等于0.3这种事在结算场景里会直接变成对账差异。用BigDecimal虽然写起来啰嗦一点（要用new BigDecimal("1040")而不是直接字面量），但精度可控。子类重写时返回值类型必须兼容父类声明，这里都是BigDecimal，没问题；如果哪天想让某个子类返回更具体的类型，JAVA允许协变返回（子类返回父类返回类型的子类型），但金额场景没必要玩这个花活。

异常约定也要在父类层面定好。我的约定是：matchRule不抛受检异常，所有输入问题在方法内部消化成false加日志；calculatePrize在投注单本身非法（比如金额为负）时抛IllegalArgumentException，因为这是调用方的编程错误，应该尽早暴露。把异常契约写在父类的Javadoc里，子类照着遵守，整个体系的错误处理才一致。这条经验来自一次真实的返工：早期版本里三个子类对非法输入的处理各不相同，有的抛异常有的返回null，结算服务里不得不写一堆try-catch兜底，后来统一契约后代码干净了一大截。

4. 结算服务的多态调用：一行循环搞定所有玩法

4.1 面向基类编程，而不是面向具体子类

继承体系搭好之后，结算服务的写法就非常舒服了。核心逻辑是一个循环：遍历投注单列表，每张单子声明为基类类型BetType，调用isWin()和calculatePrize()，累加总奖金。整个循环里没有任何instanceof判断，没有任何玩法类型的分支——因为多态已经把“这张单子到底是什么玩法、该怎么判定”的决定权交给了运行时。这就是面向对象设计里那句老话的落地：面向基类编程，而不是面向实现编程。

我特意在项目里保留了一段“反面对比”注释：如果用if-else写，结算方法会长什么样。大概是先判断玩法枚举，再分别调不同的判定函数，每加一种玩法这个方法就长一截，测试用例也要跟着翻倍。对比之下，多态版本的结算方法从第一种玩法到第十种玩法，代码一个字不用改。这个对比不是炫技，是让学习者直观感受到继承加多态在“可扩展性”上的真实收益，而不是背概念。

4.2 工厂方法把创建逻辑收口

投注单的创建不能散落在各处new，否则玩法类型和子类的映射关系会散得到处都是。我用一个简单的工厂方法收口：根据玩法类型枚举，返回对应的BetType子类实例。工厂里是一个switch，新增玩法时只改这一处。这个工厂本身不复杂，但它的存在让“新增玩法要改哪些地方”变得可枚举：加一个子类、加一个枚举值、在工厂里加一个case，三处，清清楚楚。这种“变更点收敛”的意识比具体代码更重要，你以后维护任何继承体系都用得上。

工厂方法还有个附带好处：可以在创建时统一做参数校验和默认值填充，比如投注金额为空时给默认值、注数非法时抛异常。这些逻辑如果散在各处new的地方，迟早会漏。收口到工厂，校验只写一遍，所有创建路径都受益。这个模式和继承体系是绝配——父类管行为骨架，工厂管实例创建，职责分明。

4.3 批量结算的现场记录

实际跑一遍批量结算，我习惯在服务里打结构化日志：每张投注单输出玩法类型、投注内容、是否命中、奖金金额，最后输出汇总。日志里玩法类型直接用getClass().getSimpleName()拿子类名，不用额外维护枚举到名称的映射。跑一批混合玩法的投注单，日志能清楚看到直选单命中多少、组选单命中多少，对账时一眼就能定位问题单。这个习惯是从真实项目里带出来的：批量处理场景下，没有逐条日志，出了问题只能靠猜。

结算结果我用一个简单的汇总对象承载：总投注金额、总奖金、命中注数、各玩法命中分布。汇总对象和投注单是聚合关系不是继承关系，这里别搞混——继承表达“is-a”，聚合表达“has-a”，结算汇总是“拥有”一堆投注单的统计结果，用组合更合适。这个区分在项目里点一句，能帮学习者避开“什么都想用继承”的常见误区。

5. 实操踩坑实录：继承体系里那些文档不写的坑

5.1 常见问题速查表

这张表里的每一条我都真实遇到过，尤其是第一条和第四条。@Override注解强烈建议每个重写方法都加，它不是可有可无的装饰——当你以为在重写、实际写成了重载时，只有它能救你。我见过一个子类的matchRule参数写成了Object，编译通过、运行永远走父类逻辑，查了大半天才发现是重载不是重写。

5.2 独家避坑心得

第一个心得关于继承层级不要超过三层。这个项目里是“基类→具体玩法子类”两层，刚好。如果哪天想抽一个“组选基类”出来让组选三和组选六继承，就变成三层了，再往上抽就危险了。层级一深，方法调用链就难追，一个方法到底最终执行的是哪一层的实现，得跳好几次才能确认。我的经验是：超过三层就该考虑用组合替代继承了，把变化的部分抽成策略对象注入，比继续往下继承清晰得多。

第二个心得关于测试先行。继承体系最怕的是“改父类影响子类”这种隐性耦合，而唯一能兜住这种风险的就是测试。我在项目里给每个子类的判定逻辑都写了参数化测试，覆盖命中、不命中、边界（全零、对子、三位互异）、非法输入几类用例。改父类模板方法后跑一遍全绿，才敢提交。没有测试的继承体系，改起来跟拆盲盒一样。

第三个心得是日志里打印实际类型。多态调用时，光看代码你不知道运行时到底是哪个子类在干活，日志里带上getClass().getSimpleName()，排查问题时能立刻定位到具体玩法。这个习惯成本极低，收益极高，我在所有多态场景里都保留。

6. 这个项目还能怎么往下长

代码跑通之后，我一般会留几个扩展方向给跟着做的人练手，因为继承体系的真正考验在“加需求”的时候。第一个方向是加一种新玩法，比如“猜大小”或者“和值”，走一遍“加子类、加枚举、加工厂case”的完整流程，体会一下改动面到底有多小。第二个方向是把奖金规则外置成配置，让子类从配置读取奖金而不是硬编码，这时候你会发现父类可以提供一个读取配置的protected方法，子类调用即可，又是一次继承复用的练习。第三个方向是引入策略模式做对比，把玩法判定从继承改成组合注入，然后自己评判两种方案在这个场景下各自的优劣——这种对比思考比单纯写代码有价值得多。

我个人在实际操作中的体会是，继承这个特性被低估的地方在于“约束”，被高估的地方在于“复用”。很多人用继承是为了少写代码，结果父子类耦合得死死的；真正用好继承的人，是用它来划定一条稳定的骨架和一条可变的扩展线，让变化被关在子类里，让稳定被锁在父类里。福彩3D这个场景小归小，但这条线画得清清楚楚，练完再去看框架源码里的模板方法、抽象基类，会有种“原来如此”的通透感。最后分享一个小技巧：每次设计继承体系前，先在纸上写两列——“所有子类都一样的”和“每个子类都不一样的”，前者进父类，后者进抽象方法，写完这两列，类图基本就出来了，比直接开IDE敲代码快得多，也不容易返工。