一、什么样的方法应该用static修饰？不用static修饰的方法往往具有什么特性？Student的getName应该用static修饰吗？
（1）什么样的方法应该用static修饰？
1.工具类或者辅助方法
例如：Math.sqrt()、Arrays.sort()等，这些方法不依赖于对象状态，只执行特定功能
2.main方法
public static void main(String[] args)是程序的入口，必须声明为static
3.工厂方法
静态方法常用于创建对象实例
（2）不用static修饰的方法往往具有什么特性？
1.依赖对象的状态
例如：getter/setter方法
2.需要对象实例调用
必须先创建对象，否则无法调用
3.访问权限较为灵活
可以直接访问静态与非静态成员（变量和方法）
（3）Student的getName应该用static修饰吗？
回答：不需要，也不应该
原因：
getName()方法的目的是返回某个特定学生对象的姓名。姓名通常是Student类的一个实例变量，而静态方法无法直接访问类的非静态变量。
同时也违背了面向对象原则，面向对象的核心思想是对象通过方法操作自己的数据。getName()是一个典型，它作用于一个具体的Student对象上。将其设置为静态汇让人认为getName()方法是属于“学生”这个类别，而不是属于一个具体的学生对象
二、购物车案例中，使用了什么方法将问题描述中的类、方法、属性找出来？方法与属性到底属于哪个类，要怎么判定呢？
（1）使用了什么方法将问题描述中的类、方法、属性找出来？
其实就是先想清楚，在购物车案例这个场景里有哪些 “东西”，也就是类，比如买东西时肯定有商品、购物车，还有一个运行整个程序的入口。然后看每个 “东西” 有什么特点，也就是属性，比如商品得有名字和价格，购物车得装着一堆商品。最后看每个 “东西” 能做什么，也就是方法，比如购物车能加商品、算总价、展示商品，这些动作就成了它的方法。
（2）方法与属性到底属于哪个类，要怎么判定呢？
属性是某个东西自己的特点，比如 “价格” 是商品自己的，就归商品类；购物车里的商品列表是购物车自己装的，就归购物车类。
方法是某个东西能做的事，比如 “添加商品” 是购物车干的活，就归购物车类；“算总价” 也是购物车负责算的，就归购物车类。简单说，谁的特征就归谁，谁做的动作就归谁。
三、一个项目中有很多类。怎样才能避免你项目中的类与别人编写的类同名呢？项目中类各种各样要怎么管理这些代码呢？举例说明。
（1）怎样才能避免你项目中的类与别人编写的类同名呢？
使用包（Package）机制
Java 的包机制是解决类名冲突最有效的方式，通过将类组织到不同的包中，即使类名相同也不会产生冲突。包名通常采用反转的域名（避免与其他组织的包冲突）
// 我的类package com.me.project.model;public class User { ... }// 第三方库的类package com.third.lib;public class User { ... }
AI运行代码
java
（2）项目中类各种各样要怎么管理这些代码呢？
1.按功能模块划分包结构
2.使用访问修饰符控制可见性
public：所有类可见
protected：同包及子类可见
private：仅当前类可见
3.遵循命名约定
方法名和变量名：驼峰命名法
常量：全大写 + 下划线
四、阅读《阿里巴巴Java开发手册 终极版(1.3.0)》，写出至少7条Java编程规范。应包含如下几个方面：变量命名、类命名、方法命名、常量命名、包命名、代码格式、OOP规约
1.变量命名规范
（1）命名风格统一
方法名、参数名、成员变量、局部变量均需使用lowerCamelCase驼峰风格，且不能以下划线或美元符号开头/结尾。
（2）POJO 布尔变量禁用 “is” 前缀
布尔类型的 POJO 属性（含包装类型Boolean）禁止加is前缀，避免框架解析时出现序列化错误。
（3）语义完整无歧义
变量命名需使用完整单词组合表达含义，杜绝无意义缩写或单字母命名（如a、b），实现 “代码自解释”。
2.类命名规范
（1）驼峰风格与特殊后缀
类名使用UpperCamelCase帕斯卡驼峰风格，特殊类需加固定后缀 / 前缀
（2）禁用拼音与中文
严禁拼音与英文混合命名，更不允许直接使用中文。国际通用拼音（如alibaba、hangzhou）可视同英文。
（3）体现设计模式
若类采用设计模式，命名需包含模式关键词，便于快速理解架构。
3.方法命名规范
（1）分层语义前缀
Service/DAO 层方法需按功能加固定前缀，语义清晰统一。
（2）接口与实现类区分
Service/DAO 接口的实现类需加Impl后缀，与接口明确区分（基于 SOA 理念）。
（3）避免复杂逻辑嵌入条件
条件判断中禁止嵌入复杂语句，需将逻辑结果赋值给有意义的布尔变量，提升可读性。
4.常量命名规范
(1)全大写 + 下划线分隔
常量命名需全部大写，单词间用下划线隔开，力求语义完整，不追求 “短名称”。
（2）禁用 “魔法值”
代码中禁止直接使用未经定义的常量（魔法值），需定义为常量后引用。
（3）按功能归类维护
避免用单个常量类维护所有常量，需按功能拆分（如缓存相关放CacheConsts，配置相关放ConfigConsts），便于定位修改。
5.包命名规范
（1）全小写 + 语义单词
包名统一使用小写字母，点分隔符之间仅包含一个自然语义的英语单词，且优先使用单数形式。
（2）域名反转前缀
包名建议以反转的域名开头（如公司 / 组织域名），避免与其他项目的包冲突，符合行业通用规范。
6.代码格式规范
（1）大括号与缩进
大括号内为空时简写为{}；非空代码块需遵循 “左括号前不换行、后换行，右括号前换行”；
采用 4 个空格缩进，禁止使用tab字符（IDE 需配置tab自动转为 4 个空格）。
（2）运算符与空格
二目 / 三目运算符（如=、&&、+、?:）左右两边必须加一个空格；
if/for/while等保留字与括号之间必须加空格，括号内与字符之间无空格。
（3）单行字符与换行
单行字符数不超过 120 个，超出需换行：第二行相对第一行缩进 4 个空格，运算符 / 方法点符号与下文一起换行，逗号后换行。
7.OOP 规约
（1）覆写方法加@Override
所有覆写父类 / 接口的方法必须添加@Override注解，避免因方法签名错误（如字母0与数字0混淆）导致覆写失败。
（2）包装类型与基本类型使用场景
POJO 类属性、RPC 方法的参数 / 返回值必须使用包装数据类型（如Interger、Boolean），避免自动拆箱导致 NPE；
局部变量优先使用基本数据类型（如int、boolean），提升性能。反例：POJO 中用int age；（数据库查询为null时自动拆箱抛 NPE）
（3）序列化类维护serialVersionUID
实现序列化的类需显式定义serialVersionUID，新增属性时禁止修改该值（避免反序列化失败）；完全不兼容升级时才允许修改。
（4）访问控制从严
类成员与方法的访问权限需最小化：
工具类构造方法必须为private（禁止外部new）；
仅本类使用的变量 / 方法用private，子类共享用protected，避免public滥用导致解耦困难。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/Daybreak_OvO/article/details/151925505
 - 详解)
