★ FEATURED ARTICLE 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.10.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 常见问题速查表现象根因排查与解决子类字段在父类构造器里读到null父类构造器调用了被子类重写的方法此时子类字段尚未初始化构造器内不调用可重写方法初始化逻辑后移编译报“无合适构造器”父类只有带参构造器子类未显式super(参数)子类构造器首行补super调用参数对齐前导零号码比较永远不相等号码被转成整数007变7全程用定长三位String比较前统一补零新增玩法后结算结果错乱子类重写方法签名写错参数类型或返回值不匹配实际是重载不是重写加Override注解编译器帮你抓签名错误金额出现0.01元误差用double做金额运算改用BigDecimal字符串构造指定舍入模式某子类非法输入导致整批结算中断异常契约不统一子类各自抛异常父类定契约判定方法内部消化非法输入这张表里的每一条我都真实遇到过尤其是第一条和第四条。Override注解强烈建议每个重写方法都加它不是可有可无的装饰——当你以为在重写、实际写成了重载时只有它能救你。我见过一个子类的matchRule参数写成了Object编译通过、运行永远走父类逻辑查了大半天才发现是重载不是重写。5.2 独家避坑心得第一个心得关于继承层级不要超过三层。这个项目里是“基类→具体玩法子类”两层刚好。如果哪天想抽一个“组选基类”出来让组选三和组选六继承就变成三层了再往上抽就危险了。层级一深方法调用链就难追一个方法到底最终执行的是哪一层的实现得跳好几次才能确认。我的经验是超过三层就该考虑用组合替代继承了把变化的部分抽成策略对象注入比继续往下继承清晰得多。第二个心得关于测试先行。继承体系最怕的是“改父类影响子类”这种隐性耦合而唯一能兜住这种风险的就是测试。我在项目里给每个子类的判定逻辑都写了参数化测试覆盖命中、不命中、边界全零、对子、三位互异、非法输入几类用例。改父类模板方法后跑一遍全绿才敢提交。没有测试的继承体系改起来跟拆盲盒一样。第三个心得是日志里打印实际类型。多态调用时光看代码你不知道运行时到底是哪个子类在干活日志里带上getClass().getSimpleName()排查问题时能立刻定位到具体玩法。这个习惯成本极低收益极高我在所有多态场景里都保留。6. 这个项目还能怎么往下长代码跑通之后我一般会留几个扩展方向给跟着做的人练手因为继承体系的真正考验在“加需求”的时候。第一个方向是加一种新玩法比如“猜大小”或者“和值”走一遍“加子类、加枚举、加工厂case”的完整流程体会一下改动面到底有多小。第二个方向是把奖金规则外置成配置让子类从配置读取奖金而不是硬编码这时候你会发现父类可以提供一个读取配置的protected方法子类调用即可又是一次继承复用的练习。第三个方向是引入策略模式做对比把玩法判定从继承改成组合注入然后自己评判两种方案在这个场景下各自的优劣——这种对比思考比单纯写代码有价值得多。我个人在实际操作中的体会是继承这个特性被低估的地方在于“约束”被高估的地方在于“复用”。很多人用继承是为了少写代码结果父子类耦合得死死的真正用好继承的人是用它来划定一条稳定的骨架和一条可变的扩展线让变化被关在子类里让稳定被锁在父类里。福彩3D这个场景小归小但这条线画得清清楚楚练完再去看框架源码里的模板方法、抽象基类会有种“原来如此”的通透感。最后分享一个小技巧每次设计继承体系前先在纸上写两列——“所有子类都一样的”和“每个子类都不一样的”前者进父类后者进抽象方法写完这两列类图基本就出来了比直接开IDE敲代码快得多也不容易返工。
阅读完成 · 觉得有帮助？
