Q1. 什么样的方法应该用static修饰？不用static修饰的方法往往具有什么特性？Student的getName应该用static修饰吗？
一、什么样的方法应该用static修饰？
static 修饰的方法属于类本身，而不是类的某个具体对象。这意味着你不需要创建类的实例就可以调用它。通常，满足以下条件的方法适合用 static 修饰：
1.不依赖于对象的特定状态（成员变量） ：
如果一个方法只需要访问类的静态成员或者其自身传入的参数，而不需要访问任何非静态的成员变量，那么它可以是静态的。
2.通用工具方法 ：
例如数学运算、辅助功能等，这些方法不需要知道具体对象的信息。
3.工厂方法 ：
创建类的实例的方法，但本身不依赖于已存在的实例。
二、不用static修饰的方法往往具有什么特性？
不用 static 修饰的方法（也称为实例方法）往往具有以下特性：
1.依赖于对象的特定状态（成员变量） ：
它们需要访问或修改类的实例变量，以便对特定对象执行操作。
2.需要通过对象来调用 ：
你必须先创建类的实例，然后才能调用这些方法。
3.体现对象的行为 ：
这些方法描述了对象能够执行的动作或行为。
三、Student的getName应该用static修饰吗？
不应该 。
Student 类的 getName() 方法的目的是获取某个特定学生的姓名。
姓名（name）是 Student 类的一个实例变量，每个学生对象都有自己的姓名。
因此，getName() 方法需要访问特定 Student 对象的 name 属性。如果 getName() 被声明为 static，它将无法访问非静态的 name 变量，因为它不属于任何特定的 Student 对象。
你需要先创建一个 Student 对象，然后通过该对象来调用 getName() 方法，以获取该对象的姓名。
Q2. 购物车案例中，使用了什么方法将问题描述中的类、方法、属性找出来？方法与属性到底属于哪个类，要怎么判定呢？
一、购物车案例中，使用了什么方法将问题描述中的类、方法、属性找出来？
在分析问题的过程中寻找名词，动词。商品，订单等名词就可以得到类，而动词对应方法（如添加商品到订单，完成付款）首先识别类，然后再为各个类添加方法。
二、方法与属性到底属于哪个类，要怎么判定呢？
名词对应类，动词对应方法。
Q3. 一个项目中有很多类。怎样才能避免你项目中的类与别人编写的类同名呢？项目中类各种各样要怎么管理这些代码呢？举例说明。
一、一个项目中有很多类。怎样才能避免你项目中的类与别人编写的类同名呢？
使用命名空间（Namespaces）：
1.这是最常见和推荐的方法。命名空间提供了一种将代码组织成逻辑组的方式，并有助于防止命名冲突。
2.例如，在 C++、Java 或 C# 中，您可以将您的类放入一个唯一的命名空间中，如 MyCompany.MyProject.Networking。
使用模块（Modules）或包（Packages）：
1.在 Python 或 JavaScript 等语言中，模块和包扮演着类似命名空间的角色。每个文件通常就是一个模块，您可以将相关的类组织到不同的模块或包中。
2.例如，在 Python 中，您可以有 my_project/network/connection.py，其中 connection.py 包含 Connection 类。
遵循命名约定：
1.采用一套清晰且一致的命名约定，可以降低冲突的可能性。
2.添加前缀：为您的所有类名添加一个独特的前缀，例如 MyProject_Connection 或 MP_Connection。
3.使用描述性名称：确保类名足够描述性，可以清晰地表达其用途和上下文。
避免使用过于通用或常见的名称：
1.尽量不要使用像 Utils、Helper 或 Manager 这样过于通用的类名，因为它们很容易与他人代码中的同名类冲突。
代码审查和自动化工具：
1.定期的代码审查可以帮助发现潜在的命名冲突。
2.使用静态代码分析工具，它们有时可以检测到一些命名上的问题。
二、项目中类各种各样要怎么管理这些代码呢？
包管理，例如Java编写程序时是类就在包中
Q4. 4.阅读《阿里巴巴Java开发手册 终极版(1.3.0)》，写出至少7条Java编程规范。应包含如下几个方面：变量命名、类命名、方法命名、常量命名、包命名、代码格式、OOP规约。
1.变量命名
->代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束
->代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
2.类命名
->类名使用 UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外：DO / BO /
DTO / VO / AO
->抽象类命名使用 Abstract 或 Base 开头；
异常类命名使用 Exception 结尾；
测试类命名以它要测试的类的名称开始，以 Test 结尾。
->POJO 类中布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错误。
3.方法命名
->方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式。
4.常量命名
->常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
5.包命名
->包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
6.代码格式
->大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；
如果是非空代码块则：
1） 左大括号前不换行。
2） 左大括号后换行。
3） 右大括号前换行。
4） 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。
->左小括号和字符之间不出现空格；同样，右小括号和字符之间也不出现空格。
->if/for/while/switch/do 等保留字与括号之间都必须加空格。
->任何二目、三目运算符的左右两边都需要加一个空格。
->采用 4 个空格缩进，禁止使用 tab 字符
7.OOP规约
->避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可。
->所有的覆写方法，必须加@Override 注解。
->相同参数类型，相同业务含义，才可以使用 Java 的可变参数，避免使用 Object。
->外部正在调用或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产生影响。接口过时必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么。
->不能使用过时的类或方法