Update public notes

Author: actions-user

content/编程相关/OOP 世界观.md

@@ -0,0 +1,69 @@
+---
+created: 2025-12-08
+updated: 2025-12-08
+tags:
+  - OOP
+---
+起一个 OOP 导航笔记，整理一下目前见过的 OOP 知识。
+
+懒得具体阐明什么是 OOP，如果感兴趣可以先从基本面向对象知识开始，也就是三大特征——封装、继承、多态。
+
+OOP 作为一个很有年代感的编程范式，源自于早年间大型软件项目的实践经验，虽然已经可以看见极端 OOP 因为带来的繁琐性而不可取（点名 Java），但是在大型软件项目中因为其高效地多态而依旧受到欢迎。OOP 的大部分技巧如设计模式本质上是代码复用的技巧，可以说，学 OOP 其实是在学如何高效复用代码。
+
+就写这么多吧，下面会注明一些 OOP 技巧
+
+## 基本概念
+
+封装、继承、多态。
+
+## 设计原则
+*基础之上的基础。* 
+
+只要为了写好 OOP 很多时候会很自然的遵守这些原则中的大部分。或者说，并不是为了写好代码而遵循原则，而是在好代码会自然遵循了这些原则——即便不知道这些原则，只要代码写好了同样也会自动遵循。
+
+其中，最重点也是新手最容易违背的就是单一职责。经验来说，很多情况下其他原则都是为了在实现第一条原则的时候顺便遵循的良好实现。
+
+[[OOP 设计原则]]
+
+## 设计模式
+*遵循设计原则，对实践问题的优质解答。*
+
+设计模式可以看作 OOP 的预制菜。很多经典设计模式来自于对真实生产问题的优质解答。你可以不用这些经典的设计模式，可以自己寻找优质的设计。但是，现成的历经时间和前人多次检验后的答案摆在这里——为什么不参考呢？
+
+[[对象池]]
+
+[[有限状态机]]
+
+## 架构
+*软件开发的定式。*
+
+在设计模式上更高一层的则是架构——作为软件根基的设计模式。
+
+更大层面的 OOP 则是架构。一个好的软件架构对于软件的可维护性、可拓展性、健壮性是有帮助的。而前人已经在 OOP 上探索很多，有不少经典好用的架构模式。
+
+反过来，如果要作为软件开发的参与者，同样也需要知道软件的架构，这样才能更好的进行开发而不是拉出兼容性差或复用效率低、难以阅读的石山代码。 
+
+[[MVC MVP MVVM]]
+
+## 范式的范式
+*源自于代码复用，发展于实践，最终还是回到本质的代码复用问题。*
+
+有很多更加本质甚至脱离 OOP 的理念，它们虽然是为了解决 OOP 的不足，但是本质上是对代码的更有效复用问题的理念上的回答。
+
+## 面向接口编程 Interface Oriented Programming
+
+IOP 强调定义和实现分离，通过接口进行约束。
+
+实现类的时候不需要知道另一个类怎么实现，只需要知道接口上有什么方法。
+
+ 其实遵循了依赖倒置原则——高层模块不依赖低层模块，而是二者都依赖于抽象（接口）.
+
+相关的还有 **接口驱动开发（Interface Driven Development）**。
+
+## 面向切面编程 Aspect Oriented Programming
+
+AOP 强调的是逻辑上的「**切面**」，也就是所谓的注意点分离。
+
+比如说我要写一个函数。如果要考虑实现、日志、安全、报错后怎么处理……等等这些问题，就会导致这个函数职责过多，变得臃肿。因此完全可以在逻辑上将日志、安全、报错拆出去，让函数只关注本应有的实现。
+
+AOP 依赖注解和代码生成。

content/编程相关/MVC MVP MVVM.md content/编程相关/OOP/MVC MVP MVVM.mdcontent/编程相关/MVC MVP MVVM.md renamed to content/编程相关/OOP/MVC MVP MVVM.md

@@ -2,7 +2,7 @@
 created: 2025-03-11
 updated: 2025-03-11
 ---
-## 设计模式六原则
+## 设计原则
 分别是这六个：
 - **开闭原则**：类、模块、函数等应该对修改封闭，对扩展开放。（你可以在不修改其原代码的情况下轻松扩展）
 - **单一职责原则**：一个类只做一件事，修改它的原因也只有一个。