第03周 面向对象入门2与类的识别

1.什么样的方法应该用static修饰?不用static修饰的方法往往具有什么特性?Student的getName应该用static修饰吗?

  • 什么样的方法应该用static修饰

工具方法:这些方法不依赖于类的特定实例,而是提供一些通用的功能,比如数学计算(如计算阶乘、判断一个数是否为质数等)、字符串处理(如字符串的格式化、验证等)等。
单例对象的方法:当类设计为单例模式时,为了获取单例对象的操作通常可以定义为静态方法。

  • 不用static修饰的方法往往具有什么特性

操作实例变量:实例方法通常用于操作类的实例变量,它们的行为与类的特定实例相关。

  • Student的getName应该用static修饰吗

Student类的getName方法不应该用static修饰。
原因是getName方法通常是与Student类的特定实例相关的操作,每个Student对象都有自己的名字,需要通过对象实例来调用该方法获取特定学生的名字信息。如果将getName定义为静态方法,它就不能访问非静态的实例变量,并且也不符合面向对象编程中方法与对象实例关联的设计原则。

2.购物车案例中,使用了什么方法将问题描述中的类、方法、属性找出来?方法与属性到底属于哪个类,要怎么判定呢?

  • 购物车案例中,使用了什么方法将问题描述中的类、方法、属性找出来

从问题描述的名词中识别类:仔细阅读问题描述,将其中表示实体的名词提取出来作为潜在的类。例如,在购物车案例中,“购物车”“商品”“用户” 等通常就是类。
从动词中识别方法:与这些类相关的动词往往可以对应到类的方法。比如对于购物车类,“添加商品”“删除商品”“计算总价” 等动词短语可以确定为购物车类的方法;对于商品类,“获取商品价格”“获取商品描述” 等是商品类的方法。
从描述信息中识别属性:描述类的特征的信息通常就是属性。例如商品类中商品的 “价格”“名称”“颜色” 等,购物车类中 “商品列表”“总金额” 等都是属性。

  • 方法的判定

基于功能关联性:一个方法应该与它所在类的主要功能和职责相关。例如,购物车类的主要职责是管理商品的集合相关操作,所以 “添加商品到购物车” 这个方法就属于购物车类,因为它是对购物车这个实体执行的操作。
操作对象的归属:如果一个方法操作的是某个类的实例变量(属性),那么它很可能属于该类。比如商品类有一个 “价格” 属性,“修改商品价格” 这个方法就应该属于商品类,因为它直接作用于商品类的属性。

  • 属性的判定

描述主体一致性:属性是用来描述类的特征的,如果一个信息是专门用来描述某个类的某个方面的特征,那么它就是这个类的属性。例如,商品类中,商品的重量、尺寸等信息是用来描述商品这个实体的,所以它们是商品类的属性。
在类的上下文中的唯一性:某个属性在特定类的上下文中才有意义,而在其他类中没有直接关联,那么它属于该特定类。例如购物车类的 “已选商品数量” 属性,它只在购物车的概念范围内有意义,和商品类或者用户类没有直接关联,所以它属于购物车类。

3.一个项目中有很多类。怎样才能避免你项目中的类与别人编写的类同名呢?项目中类各种各样要怎么管理这些代码呢?举例说明。

  • 避免类名冲突以及管理项目中各类代码的方法:

使用包(package)机制
在 Java 中,通过将类放置在不同的包中来避免类名冲突。例如,你可以将自己公司开发的项目中的类都放在以公司域名反转作为前缀的包下,如com.mycompany.myproject。如果有一个类叫User,它在com.mycompany.myproject包下,而其他人开发的类也叫User但在其他包下(如com.othercompany.otherproject),它们在各自的包命名空间内是唯一的,不会产生冲突。

  • 管理项目中的代码:

按功能模块划分
分层架构:例如在一个电商项目中,可以分为数据访问层(DAO 层)、业务逻辑层(Service 层)、表示层(Controller 层或 View 层)等。数据访问层可以有ProductDAO类用于操作产品数据,OrderDAO类用于操作订单数据;业务逻辑层有ProductService处理产品相关业务逻辑,OrderService处理订单相关业务逻辑等。
按业务领域划分:如一个企业资源规划(ERP)系统,有财务模块、人力资源模块、生产模块等。在财务模块中可以有Account类(账户类)、Invoice类(发票类)等相关的类;人力资源模块有Employee类(员工类)、Department类(部门类)等。
使用设计模式
单例模式管理全局配置类:例如在整个项目中需要一个全局的配置类GlobalConfig来存储一些系统级的配置信息,如数据库连接信息、日志级别等。通过单例模式确保在任何地方都能获取到同一个配置实例,避免多个实例导致的混乱。
工厂模式创建对象:在一个游戏开发项目中,有多种游戏角色,如Warrior(战士)、Mage(法师)、Archer(弓箭手)等。可以创建一个CharacterFactory类,根据不同的条件(如玩家选择、游戏关卡等)来创建不同类型的游戏角色,这样可以将对象的创建和使用分离,便于代码管理和维护。

4.阅读《阿里巴巴Java开发手册 终极版(1.3.0)》,写出至少7条Java编程规范。应包含如下几个方面:变量命名、类命名、方法命名、常量命名、包命名、代码格式、OOP规约。

变量命名
变量命名采用驼峰法(camelCase),例如 userName、orderNumber等,禁止使用拼音与英文混合的方式,或者中文标识符。
类命名
类名使用大驼峰命名法(UpperCamelCase),每个单词的首字母大写,如 UserService、ProductController。
抽象类命名使用 Abstract 或 Base 开头,如 AbstractDao、BaseController。
方法命名
方法名使用驼峰法,一般为动词或动词短语,如 getUserInfo、calculateTotalPrice等。
常量命名
常量命名全部大写,单词间用下划线分隔,例如 MAX_COUNT、DEFAULT_VALUE。
包命名
包名统一使用小写,且尽量简洁明了,由多个单词组成时也用小写字母,用点分隔,例如 com.alibaba.util、org.project.config。
公司内部项目包名以公司域名反转作为前缀,如 com.mycompany.myproject。
代码格式
大括号的使用风格,左大括号前不换行,后换行;右大括号前换行,后不换行。
每行最多字符数不超过 120 个,超出则换行,换行时遵循运算符与下文一起换行等原则。
OOP 规约
避免在构造方法中执行复杂的初始化逻辑,可将复杂逻辑移到单独的初始化方法中。
所有的覆写方法,必须加 @Override 注解,这样可以避免因方法签名书写错误而导致的覆写失败。
相同参数类型,相同业务含义,才可以使用 Java 的可变参数,避免使用可变参数代替数组。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值