首先确定设计模式

项目放在一个大文件里面——houserent

domain——实体类

service——功能实现层（存储、检测改动是否合理，检查合理后改动）

//这个整个逻辑就是为了增改删除
//都是建立在已经有了表的基础上的，所以要一开始就初始化好，这就像到了构造器

Utility——“公司”给的工具包

view——展示界面设计（）

为什么从输出开始？

这验证了我的猜想——化繁为简，要多简单？

依据就是能及时反馈的

view可以修改数据

但是设计到直接的——变量 = 实例 要回到Service里面

//不如直接setter，放也只是判断是否放默认值

//service只考虑到要用到的单次的那一层，只是单纯的实现

可以传输类——信息打包

其实如果传输类就很难检测是否合法如果是小项目，不如直接setter或者再Houseview里面用setter（）

先只是简单的输入switch（）判断sout输出

要认真学习数据结构！

我在插表的时候就意识到了必须要用数据结构才能解决分配问题

APP程序入口，连界面都无法修改

只能修改是否创建

settr

本来就是包了一层的，封装实现

总结

• 直接使用 Setter 方法 适用于简单的场景，代码更简洁，但缺乏业务逻辑的封装。
• 使用 HouseService 更新 适用于需要封装复杂业务逻辑的场景，代码更加模块化和可维护。

根据你的具体需求，如果你希望更好地封装业务逻辑并提高代码的可维护性，建议使用 HouseService 来更新房屋信息。如果你的应用比较简单，直接使用 Setter 方法也是可以接受的。