一、四块区域，四种布局管理器

Swing 的布局管理器有好几种，各管一种「怎么排」。 主窗体用的是组合：外层边界布局，里面各块自己再选。

「固定」和「占满」的搭配是关键。 工具栏和导航栏固定，内容区自适应。 这样窗口放大时，多出来的空间全给内容，而不是撑大按钮。 反过来配（内容固定、导航栏自适应）会出现：窗口拉宽，左边的树变得像一堵墙。 这不是审美问题，是可用性问题——一个 500 像素宽的树，视觉重心全歪了。 内容区用 CardLayout 是因为它要「换页」： 点人事管理出人事面板，点待遇管理出待遇面板。 CardLayout 就是「一叠卡片，一次显示一张」，正是这个需求。

二、算一遍四种分辨率

布局的算术只有一句：内容区 ＝ 窗口宽 − 180，窗口高 − 40 − 24。 四个分辨率各算一遍，就能看出固定区域的「相对占比」在变。

占比从 75.6% 涨到 85.3%。 这说明固定尺寸的区域在大屏上「相对变小」——这是好事。 但反过来看：如果按 1920 设计界面，在 1024 的机器上内容区只剩 844×704。 表格列一多，就会出横向滚动条。 所以设计时的基准分辨率要按【最小的那台机器】定。 这个项目里就是 1024×768。 这条规则不只对桌面软件成立： 网页按 1920 设计、手机上打开就散架，是同一个错误。

三、导航栏：树、列表还是标签

三种都能放下九个功能，但适用规模不同。

这个项目只有九个功能、两级结构，三种都能用。 教材选的是树，因为部门管理本身也是树，风格统一。 选型有个通用规律：功能数少于 8 用标签页，8 到 20 用树，超过 20 就得加搜索框。 超过 20 还硬用树，用户会「找不到」——这不是难看的问题，是效率问题。 这条规律还有个前提：层级不超过三层。 层数一深，树的优势就变成了缺点——用户要点开三层才看到一个叶子。

四、工具栏：按钮顺序和二次确认

四个按钮：新增、修改、删除、刷新。顺序不能随便排。

「删除放远一点」是有意的。 它和「修改」挨着，手一抖就点错。 中间隔一个按钮，能挡掉一部分误操作。 更重要的是删除必须有二次确认，而且确认框要写清「删的是谁」。 「确定删除吗？」这种问法等于没问，用户根本不看。 好的确认框长这样：「确定删除员工 张三（工号 A001）及其工资记录？」 它同时说了三件事：删什么、删谁、连带什么。 这三件事缺一件，用户就会点错一次。

五、动手 Demo：四种分辨率下，内容区各拿多少

这一篇的 Demo 全是减法：窗口减去固定区，剩下给内容。 沙箱画不出 Swing 窗口，但布局的算术能真算。 要看的不是四个像素值，是占比那一列的【趋势】。 它决定了设计基准该按哪个分辨率定。

TOP, BOTTOM, LEFT = 40, 24, 180

def area(w, h):
    return w - LEFT, h - TOP - BOTTOM

for w, h in ((1024, 768), (1280, 800), (1440, 900), (1920, 1080)):
    cw, ch = area(w, h)
    print("%4dx%-4d 内容区 %4dx%-4d 占 %.1f%%"
          % (w, h, cw, ch, cw * ch * 100.0 / (w * h)))

实跑输出：

--------------------------------------------------------------------
第八十八课：主窗体——导航栏、工具栏、内容区怎么分
--------------------------------------------------------------------

  **界面这块沙箱画不出 Swing 窗口，但布局的算术能真算。**
  **这一课算的是：窗口变大变小时，三块区域各拿多少。**

  一、三块区域的划分
  --------------------------------------------------------------------
  **主窗体拆成三个区，各自用不同的布局管理器。**

  区域   位置 布局         尺寸策略
  -----------------------------------
  工具栏 顶部 `FlowLayout` 高固定 40
  导航栏 左侧 `BoxLayout`  宽固定 180
  内容区 中间 `CardLayout` 占满剩余
  状态栏 底部 `FlowLayout` 高固定 24
  已选择 4 行
  **「固定」和「占满」的搭配是关键。**
  **工具栏和导航栏固定，内容区自适应。**
  **这样窗口放大时，多出来的空间全给内容，而不是撑大按钮。**
  **反过来配（内容固定、导航栏自适应）会出现：窗口拉宽，左边的树变得像一堵墙。**

  二、算一遍四种分辨率
  --------------------------------------------------------------------

  窗口      内容区    内容区占比
  ------------------------------
  1024x768  844x704   75.6%
  1280x800  1100x736  79.1%
  1440x900  1260x836  81.3%
  1920x1080 1740x1016 85.3%
  已选择 4 行
  **占比从 75.6% 涨到 85.3%。**
  **这说明固定尺寸的区域在大屏上「相对变小」——这是好事。**
  **但如果按 1920 设计界面，在 1024 的机器上内容区只剩 820×704，表格就会有横向滚动条。**
  **所以设计时的基准分辨率要按【最小的那台机器】定。**
  **这个项目里就是 1024×768。**

  三、导航栏用树还是用列表
  --------------------------------------------------------------------

  方案               优点               缺点
  -------------------------------------------------------
  `JTree` 树         层级清楚，能放三级 节点多了要点开
  `JList` 列表       一眼看全           放不下层级
  `JTabbedPane` 标签 切换快             超过 6 个标签就挤
  已选择 3 行
  **这个项目只有九个功能、两级结构，三种都能用。**
  **教材选的是树**，因为部门管理本身也是树，风格统一。
  **选型有个通用规律：功能数少于 8 用标签页，8 到 20 用树，超过 20 就得加搜索框了。**
  **超过 20 还硬用树，用户会「找不到」——这不是界面难看的问题，是效率问题。**

  四、工具栏按钮的几个细节
  --------------------------------------------------------------------
  **四个按钮：新增、修改、删除、刷新。顺序不能随便排。**

  顺序 按钮 为什么放这
  ----------------------------
  1    新增 最常用
  2    修改 第二常用
  3    删除 危险操作，放远一点
  4    刷新 兜底操作，放最后
  已选择 4 行
  **「删除放远一点」是有意的：**
  **它和「修改」挨着，手一抖就点错。**
  **中间隔一个按钮，能挡掉一部分误操作。**
  **更重要的是删除必须有二次确认，而且确认框要写清「删的是谁」。**
  **「确定删除吗？」这种问法等于没问，用户根本不看。**

四行输出，占比从 75.6% 一路涨到 85.3%。 涨的原因很简单：固定区一共 204 像素，窗口越大，它占的比例越小。 第一行 844×704 是最要紧的一行。 它是最小可用内容区，也是设计的硬约束。 844 像素能放几列？按每列 120 像素算，七列。 这就是为什么教材的员工列表只有七列：姓名、工号、性别、部门、岗位、入职日、状态。 再多一列就要横向滚动。 204 这个数是三块固定区之和：40 ＋ 24 ＋ 180。 想放宽内容区，只有一条路：把 180 的导航栏改窄。 但导航栏窄到 140 以下，树节点的文字就被截断了。 所以「把导航栏做窄一点」这个建议，实际能挪出来的空间只有几十像素。 真正的解法是「内容区里的表格自己支持横向滚动」，不是去压导航栏。

30 秒实验

1. 把 LEFT 从 180 改成 120，看 1024 那一行的内容区变多宽，再想想 120 像素的树能放几个字。
2. 把 TOP 从 40 改成 60，看占比那一列的变化——固定区每多一点，小屏吃亏更明显。
3. 加一个 800×600 的行进列表，看内容区还剩多少——这就是「最小支持分辨率」该怎么定。

常见误区

1. 「界面按我的显示器设计就行」。 开发机通常是最大的那台，用户那台往往是最小的。
2. 「内容区固定、侧栏自适应更灵活」。 结果就是窗口一拉宽， 导航树变成一堵墙，内容区一点没变大。
3. 「确认框写「确定删除吗」就够了」。 用户不看，必须写清删的是谁、连带删什么。
4. 「按钮顺序随便排，用户会习惯」。 会把「删除」放在「修改」旁边的设计， 第一次误删就会让人记住这个设计。

下一篇写公共模块：一份 Hibernate 配置、一批映射文件、一组通用增删改查。 它决定后面三个业务模块能省多少代码。

• ☐ （本篇完，下一篇 19.6 公共模块设计）

相关笔记

• 系统设计
• 公共模块设计
• 其他闪回技术
• 1. 🐬 MySQL必知必会/00-索引
• 🏺 Oracle从入门到精通 · 索引