第三次blog作业-有关课程的总结

一.前言
本学期的专业课程学习与我而言是一次相当有创新和挑战的经历，无论是线下和线上课的组合学习还是每个阶段的blog总结还是创意十足的翻转课堂，对我来说都是十分宝贵的学习经历。尤其是课堂内容和pta习题难度的层层递进，再能够保证学习到基本的知识的前提下还对课外知识有适当的延伸，既顾及了学习能力略有欠妥的同学还满足了学力旺盛的同学的兴致。
1:对于pta的习题，我认为难度是倾向于初学者，这对于大一的学生我认为是正好的，当然在其中也有难度较大的题目（例如两次的习题迭代）但难度还是比较符合初学者，问题的内容也跳脱了传统的文字游戏，更加注重于现实生活的相连，这不仅便于同学们的理解问题，也时不时地告诉我们，学这个专业的目的到底是什么。
2:对于实验提交系统，其中，我认为争议比较大的就是提交的过程的代码需要手打上去，老师希望提升我们的打字速度的初衷我完全可以理解，但是系统的本身还是存在一些问题（例如，字体形状比较抽象，难以看清，输入中文依旧会偶尔输成字母），如果这些问题解决了，我想老师的初衷可以更高效的实现。
3:对于线下课程，我认为是十分出色的，老师的讲课风格十分的有特色，通常会将理论和现实相结合，这对我理解课堂知识是相当有利的，并且后续的翻转课堂的设计也是相当大胆，这不仅能调动同学们的积极性，还能便于对相关知识的理解，但是其中还是存在一些问题，例如不同同学对于讲解的不同水平在不同知识点的学习影响较大，讲的好的学的好，讲的欠缺的学的也马马虎虎。
二.面向对象技术总结
对于面向对象的总结，可以大致分为封装，继承，多态，设计原则和javafx。
对于前者，正如课本所讲
封装（Encapsulation）
封装是把对象的状态（也就是属性）和行为（也就是方法）捆绑成一个独立的单元，同时对外部隐藏内部实现细节，仅对外提供公开的访问接口。在 Java 中，一般通过以下方式实现封装：
将类的属性设为私有（使用private关键字）。
提供公共的访问器（getter）和修改器（setter）方法。
可以在访问器和修改器方法里添加逻辑验证。
继承（Inheritance）
继承是指一个类（子类、派生类）可以继承另一个类（父类、基类）的属性和方法，并且可以添加自己的新特性或者重写父类的方法。在 Java 中，使用extends关键字来实现继承，而且一个类只能直接继承自一个父类（单继承），不过可以通过接口实现多重继承。
多态（Polymorphism）
多态是指不同的对象可以通过相同的接口来表现出不同的行为。在 Java 中，多态主要通过方法重写（运行时多态）和方法重载（编译时多态）来实现：
方法重写：子类重写父类的方法，在运行时根据对象的实际类型来调用相应的方法。
方法重载：在同一个类中，多个方法可以使用相同的名称，但参数列表必须不同
然后是设计原则，和前者大差不差。
单一职责原则 (SRP - Single Responsibility Principle)
定义：一个类应该只有一个引起它变化的原因。
解释：每个类应该只负责一个特定的功能模块，避免将过多职责耦合在一起。
开闭原则 (OCP - Open/Closed Principle)
定义：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。
解释：通过抽象和多态实现扩展，而不是直接修改现有代码。
里氏替换原则 (LSP - Liskov Substitution Principle)
定义：子类可以替换其父类而不影响程序的正确性。
解释：子类必须遵循父类的契约，不改变父类方法的预期行为。
接口隔离原则 (ISP - Interface Segregation Principle)
定义：客户端不应该依赖它不需要的接口。
解释：将庞大的接口拆分为更小、更具体的接口，避免类实现不需要的方法
依赖倒置原则 (DIP - Dependency Inversion Principle)
定义：高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。
解释：通过接口或抽象类解耦，降低模块间的直接依赖。
迪米特法则 (LoD - Law of Demeter / 最少知识原则)
定义：一个对象应该对其他对象有最少的了解。
解释：减少类之间的直接交互，通过中间层或代理间接通信。
合成复用原则 (CRP - Composite Reuse Principle)
定义：优先使用对象组合，而不是继承。
解释：通过组合（Has-A 关系）实现代码复用，避免继承带来的耦合问题
接口最小化原则
定义：接口应尽可能小，只包含必要的方法。
解释：避免设计大而全的接口，保持接口的单一职责。
依赖注入原则 (DI - Dependency Injection)
定义：通过外部注入依赖对象，而不是在类内部创建。
解释：提高代码的可测试性和可维护性，常见于 Spring 框架。
而对于javafx,其的涉及面过于庞大，不在此过多赘述，但是它对于ui的建设或是程序应用的开发是必不可少的。
踩坑心得
javafx的ui设计过程中，我遇到的第一个问题便是想象力和现实的不匹配，对于实验的要求，我的想象力可能是过于抽象，以至于具体实现时不知从何下笔，再加上涉及到的javafx的相关知识过多，即使具体列出来大致方向也不知道如何具体实现。在过程中，也只好大量借阅翻转课堂中同学们提供的例子，在此基础上学习和改进修正，在此过程中，我也是在不断地学习和收获新的知识。
改进建议和总结
实验提交系统希望改进的更加人性化。题目的设计继续保持贴合生活现实。
本学期的课程极大的告知于我，学这门课的意义，将它的结果更加直观的体现出来，我也学习了大量程序设计上的设计思路，为今后的学习打下了理论的基础。总结上来说，这节课让我受益匪浅，也大大的激发了我对于后续学习的期待。