这个java案例显示战术犯规吃到黄牌几次？

wen java案例 2026-11-10 2

引言：当Java代码遇上足球规则
案例背景：战术犯规与黄牌统计的业务逻辑
Java代码实现：如何统计战术犯规的黄牌次数
关键逻辑拆解：为什么这个案例值得关注
常见误区与问答环节
从案例到实战的迁移思路

引言：当Java代码遇上足球规则

在足球比赛中,战术犯规是球员为了阻止对方有威胁的进攻而故意采取的犯规行为，裁判会根据犯规的严重程度出示黄牌或红牌，如果用一个Java案例来模拟“战术犯规吃到黄牌几次”的统计场景，代码应该如何设计？这个看似简单的需求，背后涉及数据结构、条件判断、累计计数等多个编程核心知识点，本文将以一个典型的Java案例为线索，完整拆解战术犯规黄牌统计的实现逻辑，并结合搜索引擎中已有的技术文章进行去伪原创与精髓提炼，帮助读者真正掌握这类计数场景的编程思路。

案例背景：战术犯规与黄牌统计的业务逻辑

假设我们正在开发一个足球比赛事件记录系统,系统需要记录每一名球员的犯规类型（普通犯规、战术犯规）以及裁判的判罚结果（无牌、黄牌、红牌），业务需求是：统计某场比赛中，因“战术犯规”而吃到黄牌的次数。

这里的核心条件有两个：

犯规类型必须为“战术犯规”；
判罚结果必须为“黄牌”。

只有同时满足这两个条件的事件,才计入统计，这个案例的典型性在于，它考察了开发者对“多条件联合过滤”与“计数器累加”的掌握程度。

Java代码实现：如何统计战术犯规的黄牌次数

下面给出一个精简而完整的Java示例：

import java.util.ArrayList;
import java.util.List;
class FoulEvent {
    String playerName;
    String foulType;   // "战术犯规" 或 "普通犯规"
    String cardType;   // "黄牌"、"红牌"、"无牌"
    public FoulEvent(String playerName, String foulType, String cardType) {
        this.playerName = playerName;
        this.foulType = foulType;
        this.cardType = cardType;
    }
}
public class TacticalFoulCardCounter {
    public static void main(String[] args) {
        List<FoulEvent> events = new ArrayList<>();
        events.add(new FoulEvent("球员A", "战术犯规", "黄牌"));
        events.add(new FoulEvent("球员B", "普通犯规", "黄牌"));
        events.add(new FoulEvent("球员C", "战术犯规", "黄牌"));
        events.add(new FoulEvent("球员D", "战术犯规", "红牌"));
        events.add(new FoulEvent("球员E", "战术犯规", "无牌"));
        int yellowCardCount = 0;
        for (FoulEvent event : events) {
            if ("战术犯规".equals(event.foulType) && "黄牌".equals(event.cardType)) {
                yellowCardCount++;
            }
        }
        System.out.println("战术犯规吃到黄牌的次数为：" + yellowCardCount);
    }
}

运行结果为：战术犯规吃到黄牌的次数为：2。

这段代码清晰地展示了统计逻辑：遍历事件列表，使用逻辑与（&&）联合判断犯规类型与判罚结果，满足条件则计数器加一。

关键逻辑拆解：为什么这个案例值得关注

第一,字符串比较的安全性，代码中使用"战术犯规".equals(event.foulType)而非event.foulType.equals("战术犯规")，可以有效避免空指针异常，这是Java字符串比较的经典规范。

第二,计数器的初始化与累加。int yellowCardCount = 0;确保计数从零开始，循环中仅在条件满足时自增，逻辑严谨。

第三,业务条件的不可拆分性，战术犯规与黄牌是两个独立维度，必须同时满足才计入统计，若误用逻辑或（||），结果会严重偏离业务预期，这个案例提醒开发者：统计类需求首先要明确“与”和“或”的边界。

第四,可扩展性，若后续需要按球员统计，只需在循环中增加按球员名分组的逻辑即可，说明该结构具备良好的扩展基础。

常见误区与问答环节

问：如果一名球员先因战术犯规吃黄牌，后来又因战术犯规吃第二张黄牌被罚下，统计时算几次？
答：按本案例的统计口径，每一次“战术犯规+黄牌”的事件都独立计数，因此算2次，若业务要求统计“因战术犯规累计黄牌而被罚下”的次数，则需要额外增加红牌关联判断。

问：为什么不用Stream流式写法？
答：Stream写法同样可行，例如events.stream().filter(e -> "战术犯规".equals(e.foulType) && "黄牌".equals(e.cardType)).count()，但本案例以基础循环呈现，更利于初学者理解计数本质，两种写法在结果上一致。

问：这个案例能直接用于真实比赛系统吗？
答：作为教学案例足够，但真实系统还需考虑事件时间戳、比赛ID、球员ID、裁判判罚复核等因素，本案例的价值在于提炼出“多条件联合计数”的通用模板。

问：如果犯规类型或黄牌字段出现null会怎样？
答：由于使用了常量在前的equals写法，null不会引发异常，只会被判定为不匹配，从而安全跳过，这正是该写法的优势所在。

从案例到实战的迁移思路

这个Java案例虽然简短,却完整覆盖了“定义数据模型—构建集合—条件过滤—累加计数—输出结果”的标准流程，回答“战术犯规吃到黄牌几次”这一问题，代码给出的答案是2次，而读者真正收获的是：面对任何多条件统计需求时，先厘清业务条件之间的逻辑关系，再选择安全的比较方式与清晰的循环结构，掌握这一思路，类似“统计某类事件发生次数”的编程任务都能迎刃而解。

本文地址： https://bmjup.com/post/68723.html