From a1809f0020fd8200fff43a9e17ee8e6f1c7b6e8d Mon Sep 17 00:00:00 2001 From: ydf0509 <909686719@qq.com> Date: Wed, 7 Jul 2021 13:33:58 +0800 Subject: [PATCH 01/21] Update README.md --- README.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/README.md b/README.md index 620c209..02e6a66 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,10 @@ +``` +编程时候,设计新的模块或者项目,下不了笔,要思考三天三夜怎么设计,主要是没学设计模式。 + +编程时候,有时候脑子一瞬间感觉 灵光出现,觉得这么写台好了太合适了,这样写节约代码 扩展高,瞬间感到这是个天才想法, +主要是由于没有专门学习设计模式,只能偶尔灵机一动,形成不了一套稳定的输出,所以才会有这种突然感觉是天才设计的想法。 +``` + ``` 不要纠结是23种还是36种了,有细分的,举个例子 观察者模式和发布订阅模式,是有了少许变化,多了解一种总没啥坏处。 为什么是36种,因为是摘自菜鸟教程或者w3cschool网站,这两个网站都是36种,包含了j2ee模式,多了解没坏处。 From 77a5027dcdaa71fdbc730a5f301bea144982bb28 Mon Sep 17 00:00:00 2001 From: ydf0509 <909686719@qq.com> Date: Wed, 7 Jul 2021 13:34:54 +0800 Subject: [PATCH 02/21] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 02e6a66..3e802a6 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ 编程时候,设计新的模块或者项目,下不了笔,要思考三天三夜怎么设计,主要是没学设计模式。 编程时候,有时候脑子一瞬间感觉 灵光出现,觉得这么写台好了太合适了,这样写节约代码 扩展高,瞬间感到这是个天才想法, -主要是由于没有专门学习设计模式,只能偶尔灵机一动,形成不了一套稳定的输出,所以才会有这种突然感觉是天才设计的想法。 +主要是由于没有专门学习设计模式,只能偶尔灵机一动,形成不了一套稳定的输出,所以才会有这种突然感觉某个代码设计是天才设计这种感受。 ``` ``` From 28f393a4da9b1caf248a5a3ad9e02ff524174f05 Mon Sep 17 00:00:00 2001 From: ydf0509 <909686719@qq.com> Date: Tue, 7 Mar 2023 17:26:31 +0800 Subject: [PATCH 03/21] =?UTF-8?q?Update=20=E5=88=9B=E5=BB=BA=E5=9E=8B?= =?UTF-8?q?=E6=A8=A1=E5=BC=8F-=E5=8D=95=E4=BE=8B=E6=A8=A1=E5=BC=8F-?= =?UTF-8?q?=E5=85=83=E7=B1=BB.py?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...276213円346円250円241円345円274円217円-345円205円203円347円261円273円.py" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git "a/345円210円233円345円273円272円345円236円213円346円250円241円345円274円217円-345円215円225円344円276円213円346円250円241円345円274円217円-345円205円203円347円261円273円.py" "b/345円210円233円345円273円272円345円236円213円346円250円241円345円274円217円-345円215円225円344円276円213円346円250円241円345円274円217円-345円205円203円347円261円273円.py" index 310617e..cd11c1c 100644 --- "a/345円210円233円345円273円272円345円236円213円346円250円241円345円274円217円-345円215円225円344円276円213円346円250円241円345円274円217円-345円205円203円347円261円273円.py" +++ "b/345円210円233円345円273円272円345円236円213円346円250円241円345円274円217円-345円215円225円344円276円213円346円250円241円345円274円217円-345円205円203円347円261円273円.py" @@ -53,5 +53,5 @@ def eat(self): "D:/coding2/python36patterns/创建型模式-单例模式.py:30" 16:00:25 001 吃饭 "D:/coding2/python36patterns/创建型模式-单例模式.py:30" 16:00:25 001 吃饭 "D:/coding2/python36patterns/创建型模式-单例模式.py:40" 16:00:25 True -"D:/coding2/python36patterns/创建型模式-单例模式.py:30" 16:00:25 003 吃饭 +"D:/coding2/python36patterns/创建型模式-单例模式.py:30" 16:00:25 001 吃饭 """ From 61acf2f33449b06ee77d7759f73bf59afb9ef10c Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:04:02 +0800 Subject: [PATCH 04/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) diff --git a/README.md b/README.md index 3e802a6..9c62b3c 100644 --- a/README.md +++ b/README.md @@ -74,3 +74,99 @@ https://zhuanlan.zhihu.com/p/19835717 代码不可维护,没有高扩展性 写新文件要想破头皮三天三夜才能开始下笔。 ``` + +## !【重要】 简单例子说明极端面向过程编程非常愚蠢low + +情不自禁纯粹极端面向过程编程还是c语言中毒了,从来都不使用面向对象,不用提设计模式。 + +有些人完全没思考过面向对象,一味的只会说大型项目才需要面向对象,小项目面向过程更合适。简直是胡说八道,不看场景只看项目大小。 + +比如一个简单需求,描写人,吃饭 增加体重和身高,拉尿体重降低。需求是非常非常的简单了吧,绝对是非常小的项目,单个文件就好了,来验证下是不是小项目面向过程最好。 + +面向过程来实现,看看代码多垃圾。 +```python +# 吃饭函数 +def eat(name, height, weight, food_weight): + """吃饭:增加体重和身高""" + new_weight = weight + food_weight + new_height = height + food_weight * 0.01 + print(f"{name} 吃了 {food_weight} 千克食物,体重: {new_weight} 千克,身高: {new_height} 厘米") + return new_height, new_weight + +# 拉尿函数 +def pee(name, height, weight, pee_weight): + """拉尿:减少体重""" + if pee_weight> weight: + pee_weight = weight + new_weight = weight - pee_weight + print(f"{name} 拉了 {pee_weight} 千克尿,体重: {new_weight} 千克,身高: {height} 厘米") + return height, new_weight + +# 测试代码 +if __name__ == "__main__": + # 小明的初始状态 + xiaoming_height = 170 + xiaoming_weight = 60 + + # 小红的初始状态 + xiaohong_height = 160 + xiaohong_weight = 50 + + print(f"小明 初始状态 - 身高: {xiaoming_height} 厘米,体重: {xiaoming_weight} 千克") + print(f"小红 初始状态 - 身高: {xiaohong_height} 厘米,体重: {xiaohong_weight} 千克") + + # 小明吃饭和拉尿 + xiaoming_height, xiaoming_weight = eat("小明", xiaoming_height, xiaoming_weight, 2) + xiaoming_height, xiaoming_weight = pee("小明", xiaoming_height, xiaoming_weight, 1) + + # 小红吃饭和拉尿 + xiaohong_height, xiaohong_weight = eat("小红", xiaohong_height, xiaohong_weight, 3) + xiaohong_height, xiaohong_weight = pee("小红", xiaohong_height, xiaohong_weight, 2) +``` + +面向对象来实现,看看代码实现多简单调用多方便 +```python +class Person: + def __init__(self, name, height, weight): + self.name = name + self.height = height # 身高,单位:厘米 + self.weight = weight # 体重,单位:千克 + + def eat(self, food_weight): + """吃饭:增加体重和身高""" + self.weight += food_weight + self.height += food_weight * 0.01 + print(f"{self.name} 吃了 {food_weight} 千克食物,体重: {self.weight} 千克,身高: {self.height} 厘米") + + def pee(self, pee_weight): + """拉尿:减少体重""" + if pee_weight> self.weight: + pee_weight = self.weight + self.weight -= pee_weight + print(f"{self.name} 拉了 {pee_weight} 千克尿,体重: {self.weight} 千克,身高: {self.height} 厘米") + +# 测试代码 +if __name__ == "__main__": + # 创建小明和小红 + xiaoming = Person("小明", 170, 60) + xiaohong = Person("小红", 160, 50) + + # 小明吃饭和拉尿 + xiaoming.eat(2) + xiaoming.pee(1) + + # 小红吃饭和拉尿 + xiaohong.eat(3) + xiaohong.pee(2) +``` + +``` +面向对象起码有封装,极端面向过程那就实现时候,每个函数结尾需要疯狂的return 一大堆变量,然后将一大堆变量传给另外一个函数进行处理。 + +而面向对象不需要你把一大堆入参疯狂在各个函数传来传去,return来return去。 + +如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没用,更别提更高阶的设计模式了。 + +``` + +#### 只需要按文档的面向过程转op4步走里面,降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 \ No newline at end of file From 9242962a49d094a66baa3751ace4615c7928af9f Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:05:55 +0800 Subject: [PATCH 05/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9c62b3c..32744af 100644 --- a/README.md +++ b/README.md @@ -83,7 +83,7 @@ https://zhuanlan.zhihu.com/p/19835717 比如一个简单需求,描写人,吃饭 增加体重和身高,拉尿体重降低。需求是非常非常的简单了吧,绝对是非常小的项目,单个文件就好了,来验证下是不是小项目面向过程最好。 -面向过程来实现,看看代码多垃圾。 +面向过程来实现,看看代码实现多垃圾,调用时候多么麻烦。 ```python # 吃饭函数 def eat(name, height, weight, food_weight): From 035f7fcb6ac25f136307aa842fd7c096ca87c870 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:08:16 +0800 Subject: [PATCH 06/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 32744af..ddf8aca 100644 --- a/README.md +++ b/README.md @@ -169,4 +169,4 @@ if __name__ == "__main__": ``` -#### 只需要按文档的面向过程转op4步走里面,降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 \ No newline at end of file +#### 只需要按文档的面向过程转 oop 4步走里面的固定公式,全局变量->实例属性,函数->方法 降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 \ No newline at end of file From bc3f56bbf79241050b11312fbd787620357e8c14 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:17:15 +0800 Subject: [PATCH 07/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index ddf8aca..750b243 100644 --- a/README.md +++ b/README.md @@ -165,6 +165,9 @@ if __name__ == "__main__": 而面向对象不需要你把一大堆入参疯狂在各个函数传来传去,return来return去。 +如果你给我说,定义一个结构体或者字典来存放 身高 体重 姓名,然后充分利用字典是可变类型,这样既减少了每个函数的入参数量,又不需要return一大堆变量,还是可以用面向过程来写这个代码, +就避免了上面我说的疯狂传参和疯狂return的弊端,那么继承呢? 如果b函数依赖a函数,你想修改a函数,那么继承就是你的救星,你不需要在源代码去修改a函数。 + 如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没用,更别提更高阶的设计模式了。 ``` From 41b333e041bcebc27023d1258c31ad16f9326d7b Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:17:15 +0800 Subject: [PATCH 08/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README.md b/README.md index ddf8aca..1c23896 100644 --- a/README.md +++ b/README.md @@ -165,6 +165,11 @@ if __name__ == "__main__": 而面向对象不需要你把一大堆入参疯狂在各个函数传来传去,return来return去。 +如果你给我说,定义一个结构体或者字典来存放 身高 体重 姓名,然后充分利用字典是可变类型,这样既减少了每个函数的入参数量, +又不需要return一大堆变量,还是可以用面向过程来写这个代码, +就避免了上面我说的疯狂传参和疯狂return的弊端,那么继承呢? +如果b函数依赖a函数,你想修改a函数,那么继承就是你的救星,你不需要在源代码去修改a函数。 + 如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没用,更别提更高阶的设计模式了。 ``` From 090e123297c963bc980dca3ceb59dc7e062b5b34 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:24:50 +0800 Subject: [PATCH 09/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 157574a..2d35b02 100644 --- a/README.md +++ b/README.md @@ -162,18 +162,14 @@ if __name__ == "__main__": ``` 面向对象起码有封装,极端面向过程那就实现时候,每个函数结尾需要疯狂的return 一大堆变量,然后将一大堆变量传给另外一个函数进行处理。 - 而面向对象不需要你把一大堆入参疯狂在各个函数传来传去,return来return去。 -<<<<<<< HEAD + 如果你给我说,定义一个结构体或者字典来存放 身高 体重 姓名,然后充分利用字典是可变类型,这样既减少了每个函数的入参数量, 又不需要return一大堆变量,还是可以用面向过程来写这个代码, 就避免了上面我说的疯狂传参和疯狂return的弊端,那么继承呢? 如果b函数依赖a函数,你想修改a函数,那么继承就是你的救星,你不需要在源代码去修改a函数。 -======= -如果你给我说,定义一个结构体或者字典来存放 身高 体重 姓名,然后充分利用字典是可变类型,这样既减少了每个函数的入参数量,又不需要return一大堆变量,还是可以用面向过程来写这个代码, -就避免了上面我说的疯狂传参和疯狂return的弊端,那么继承呢? 如果b函数依赖a函数,你想修改a函数,那么继承就是你的救星,你不需要在源代码去修改a函数。 ->>>>>>> origin/master + 如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没用,更别提更高阶的设计模式了。 From 099ab55456ad17d5c3102ba1bc1535e5aca2c5fc Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:36:29 +0800 Subject: [PATCH 10/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 2d35b02..91c90f3 100644 --- a/README.md +++ b/README.md @@ -167,11 +167,13 @@ if __name__ == "__main__": 如果你给我说,定义一个结构体或者字典来存放 身高 体重 姓名,然后充分利用字典是可变类型,这样既减少了每个函数的入参数量, 又不需要return一大堆变量,还是可以用面向过程来写这个代码, -就避免了上面我说的疯狂传参和疯狂return的弊端,那么继承呢? -如果b函数依赖a函数,你想修改a函数,那么继承就是你的救星,你不需要在源代码去修改a函数。 +就避免了上面我说的疯狂传参和疯狂return的弊端,那么继承和多态阁下有如何应对呢? +比如大人吃1kg长0.1kg体重,小孩吃1kg长0.2kg体重,并且我假设eat函数调用了另外一个_eat2的私有函数来执行体重增加计算, +你在面向过程时候,要加一个 大人eat的函数 加一个 大人_eat2 的函数, 并且大人eat的函数里面调用大人_eat2的函数,整个链路的就都要替换, +你想下纯粹极端面向过程实现公共代码时候有多low多复杂,并且调用它的时候有多麻烦。 -如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没用,更别提更高阶的设计模式了。 +如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没有,更别提更高阶的设计模式了。 ``` From 3df8d9251438cb971661115e90d6a9dc03c36529 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:38:44 +0800 Subject: [PATCH 11/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 91c90f3..a47942a 100644 --- a/README.md +++ b/README.md @@ -169,8 +169,10 @@ if __name__ == "__main__": 又不需要return一大堆变量,还是可以用面向过程来写这个代码, 就避免了上面我说的疯狂传参和疯狂return的弊端,那么继承和多态阁下有如何应对呢? -比如大人吃1kg长0.1kg体重,小孩吃1kg长0.2kg体重,并且我假设eat函数调用了另外一个_eat2的私有函数来执行体重增加计算, -你在面向过程时候,要加一个 大人eat的函数 加一个 大人_eat2 的函数, 并且大人eat的函数里面调用大人_eat2的函数,整个链路的就都要替换, +比如大人吃1kg长0.1kg体重,小孩吃1kg长0.2kg体重,并且我假设eat函数调用了另外一个_eat2的私有函数来具体的执行体重增加计算, +你在面向过程时候,就要加一个 大人eat的函数 加一个 大人_eat2 的函数, +并且大人eat的函数里面调用大人_eat2的函数,小孩eat的函数里面调用小孩_eat2的函数, 整个链路的就都要替换, +而面向对象仅仅需要继承重写 _eat2这个私有方法就好了。 你想下纯粹极端面向过程实现公共代码时候有多low多复杂,并且调用它的时候有多麻烦。 如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没有,更别提更高阶的设计模式了。 From a1e722f8b02d5588822eef0333f4ca24a688d08b Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Thu, 6 Mar 2025 17:46:56 +0800 Subject: [PATCH 12/21] =?UTF-8?q?=20readme=E5=A2=9E=E5=8A=A0=20=E6=9E=81?= =?UTF-8?q?=E7=AB=AF=E9=9D=A2=E5=90=91=E8=BF=87=E7=A8=8B=E7=BC=96=E7=A8=8B?= =?UTF-8?q?=E5=92=8Coop=E7=9A=84=E7=9B=B4=E8=A7=82=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a47942a..db1782a 100644 --- a/README.md +++ b/README.md @@ -171,8 +171,8 @@ if __name__ == "__main__": 比如大人吃1kg长0.1kg体重,小孩吃1kg长0.2kg体重,并且我假设eat函数调用了另外一个_eat2的私有函数来具体的执行体重增加计算, 你在面向过程时候,就要加一个 大人eat的函数 加一个 大人_eat2 的函数, -并且大人eat的函数里面调用大人_eat2的函数,小孩eat的函数里面调用小孩_eat2的函数, 整个链路的就都要替换, -而面向对象仅仅需要继承重写 _eat2这个私有方法就好了。 +并且大人eat的函数里面调用大人_eat2的函数,在小孩eat的函数里面调用小孩_eat2的函数, 整个链路的就都要替换, +而面向对象仅仅需要增加一个大人的类,继承重写 _eat2这个私有方法就好了。 你想下纯粹极端面向过程实现公共代码时候有多low多复杂,并且调用它的时候有多麻烦。 如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没有,更别提更高阶的设计模式了。 From 762b13aea5e5f52d670b3dc7564765db159a68a1 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: Fri, 7 Mar 2025 11:28:05 +0800 Subject: [PATCH 13/21] Changes --- ...50241円214円344円270円200円346円254円241円init.py" | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 "345円210円233円345円273円272円345円236円213円346円250円241円345円274円217円-344円272円253円345円205円203円346円250円241円345円274円217円_345円217円252円350円277円220円350円241円214円344円270円200円346円254円241円init.py" diff --git "a/345円210円233円345円273円272円345円236円213円346円250円241円345円274円217円-344円272円253円345円205円203円346円250円241円345円274円217円_345円217円252円350円277円220円350円241円214円344円270円200円346円254円241円init.py" "b/345円210円233円345円273円272円345円236円213円346円250円241円345円274円217円-344円272円253円345円205円203円346円250円241円345円274円217円_345円217円252円350円277円220円350円241円214円344円270円200円346円254円241円init.py" new file mode 100644 index 0000000..0fbce28 --- /dev/null +++ "b/345円210円233円345円273円272円345円236円213円346円250円241円345円274円217円-344円272円253円345円205円203円346円250円241円345円274円217円_345円217円252円350円277円220円350円241円214円344円270円200円346円254円241円init.py" @@ -0,0 +1,32 @@ +""" +相比这个文件, 创建型模式-享元模式.py + +使 __init__ 只运行异常,阻止相同对象多次运行 __init__ +""" + +import dataset + + +class DatasetSink: + # 类级别的实例缓存,按 db_url 存储 + _instances = {} + _has__init_set =set() # 把执行了 __init__的对象id保存起来对比 + + def __new__(cls, db_url): + # 如果 db_url 已存在,直接返回已有实例 + if db_url not in cls._instances: + # 创建新实例并存入缓存 + self = super(DatasetSink, cls).__new__(cls) + cls._instances[db_url] = self + return cls._instances[db_url] + + def __init__(self, db_url): # 相同的db_url不要每次都运行这个__init__。 + if id(self) not in self.__class__._has__init_set : + print(f'创建连接 {db_url}') + self.db = dataset.connect(db_url,ensure_schema=True) + self.__class__._has__init_set.add(id(self)) + + def save(self, table_name:str,data:dict,): + # 使用已有的连接插入数据 + table = self.db[table_name] + table.insert(data) \ No newline at end of file From 160b1beb0c84c70eba21f205276d77ee889fca93 Mon Sep 17 00:00:00 2001 From: ydf0509 <909686719@qq.com> Date: 2025年6月19日 17:41:07 +0800 Subject: [PATCH 14/21] Update README.md --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index db1782a..c4fbb3f 100644 --- a/README.md +++ b/README.md @@ -42,6 +42,8 @@ https://zhuanlan.zhihu.com/p/19835717 使用这个公式,不需要背设计模式,不需要每次写新文件先花几天想破头皮怎么设计布局代码成为高扩展和高维护。 +https://github.com/ydf0509/python36patterns/tree/master/%E5%BF%98%E6%8E%89%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%9C%80%E5%BC%BA%E6%9C%80%E7%A8%B3%E5%AE%9A%E6%9C%80%E6%9C%89%E5%A5%97%E8%B7%AF%E7%9A%84%E4%B8%87%E8%83%BD%E7%BC%96%E7%A8%8B%E6%80%9D%E7%BB%B4-python%20oop%E5%9B%9B%E6%AD%A5%E8%BD%AC%E5%8C%96%E5%85%AC%E5%BC%8F%E3%80%82 + ## 常见问题回答 1、老是纠结类和函数?类和函数有什么区别。 @@ -179,4 +181,4 @@ if __name__ == "__main__": ``` -#### 只需要按文档的面向过程转 oop 4步走里面的固定公式,全局变量->实例属性,函数->方法 降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 \ No newline at end of file +#### 只需要按文档的面向过程转 oop 4步走里面的固定公式,全局变量->实例属性,函数->方法 降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 From 47548f528fe29e94cc32fb56ec8fda53112d8263 Mon Sep 17 00:00:00 2001 From: ydf0509 <909686719@qq.com> Date: 2025年6月19日 17:43:52 +0800 Subject: [PATCH 15/21] Update README.md --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index c4fbb3f..afdab02 100644 --- a/README.md +++ b/README.md @@ -38,10 +38,12 @@ https://www.zhihu.com/question/25432487 https://zhuanlan.zhihu.com/p/19835717 -## 介绍神级别通用固定oop转化公式,写代码下笔时候行云流水。 +## 介绍神级别通用固定oop转化公式,写代码下笔时候行云流水(只需学习这套固定面向过程转oop公式,远强于背诵设计模式)。 使用这个公式,不需要背设计模式,不需要每次写新文件先花几天想破头皮怎么设计布局代码成为高扩展和高维护。 +忘掉设计模式,使用最强最稳定最有固定套路的万能编程思维-python oop四步转化公式。 + https://github.com/ydf0509/python36patterns/tree/master/%E5%BF%98%E6%8E%89%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%9C%80%E5%BC%BA%E6%9C%80%E7%A8%B3%E5%AE%9A%E6%9C%80%E6%9C%89%E5%A5%97%E8%B7%AF%E7%9A%84%E4%B8%87%E8%83%BD%E7%BC%96%E7%A8%8B%E6%80%9D%E7%BB%B4-python%20oop%E5%9B%9B%E6%AD%A5%E8%BD%AC%E5%8C%96%E5%85%AC%E5%BC%8F%E3%80%82 ## 常见问题回答 From ae299e04dbeee9ede036189e92166b0106d24f6b Mon Sep 17 00:00:00 2001 From: ydf0509 <909686719@qq.com> Date: 2025年6月19日 17:46:13 +0800 Subject: [PATCH 16/21] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index afdab02..2df6d9d 100644 --- a/README.md +++ b/README.md @@ -42,9 +42,9 @@ https://zhuanlan.zhihu.com/p/19835717 使用这个公式,不需要背设计模式,不需要每次写新文件先花几天想破头皮怎么设计布局代码成为高扩展和高维护。 -忘掉设计模式,使用最强最稳定最有固定套路的万能编程思维-python oop四步转化公式。 -https://github.com/ydf0509/python36patterns/tree/master/%E5%BF%98%E6%8E%89%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%9C%80%E5%BC%BA%E6%9C%80%E7%A8%B3%E5%AE%9A%E6%9C%80%E6%9C%89%E5%A5%97%E8%B7%AF%E7%9A%84%E4%B8%87%E8%83%BD%E7%BC%96%E7%A8%8B%E6%80%9D%E7%BB%B4-python%20oop%E5%9B%9B%E6%AD%A5%E8%BD%AC%E5%8C%96%E5%85%AC%E5%BC%8F%E3%80%82 + +[忘掉设计模式,使用最强最稳定最有固定套路的万能编程思维-python oop四步转化公式](https://github.com/ydf0509/python36patterns/tree/master/%E5%BF%98%E6%8E%89%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%9C%80%E5%BC%BA%E6%9C%80%E7%A8%B3%E5%AE%9A%E6%9C%80%E6%9C%89%E5%A5%97%E8%B7%AF%E7%9A%84%E4%B8%87%E8%83%BD%E7%BC%96%E7%A8%8B%E6%80%9D%E7%BB%B4-python%20oop%E5%9B%9B%E6%AD%A5%E8%BD%AC%E5%8C%96%E5%85%AC%E5%BC%8F%E3%80%82) ## 常见问题回答 From cc9da44e09993ddc1f2060c137e4e4c619c5a5c7 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: 2025年6月19日 19:48:49 +0800 Subject: [PATCH 17/21] --- README.md | 172 ++++++++++++++++-- .../README.md" | 117 ++++++++---- 2 files changed, 240 insertions(+), 49 deletions(-) diff --git a/README.md b/README.md index db1782a..1b5712f 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,40 @@ +# 0 介绍36种设计模式(包括23种的变种和python独有例如猴子补丁),最最重要是介绍 oop四部转化公式!!! + +## 0.1 python36种设计模式 + +一共有36种设计模式,23种里面有些还需要细分,你去看菜鸟教程网站的设计模式,那就不止罗列了23个例子,达到三十多种了,有些是变种,有些是python独有例如猴子补丁技术。 + +## 0.2 介绍 oop四部转化公式,这是项目最重要的文档!!。 + + +介绍23种设计模式的博客 教程 网站文档 已经烂大街了,毫不稀奇。 + +但是这个项目里面介绍的 oop四部转化公式,是项目最重要的部分,没有任何人是我这么总结如何写oop代码的,学校老师和书本只会教你背诵 +封装 继承 多态 这几个词语本身.你只会看到下面这段类似的话: + + +**面向对象编程(OOP)** 是一种以**对象**为核心的编程范式,将数据(属性)和操作(方法)封装成类,通过**继承**实现代码复用,**多态**实现灵活扩展。 适用于复杂系统(如游戏、GUI),代表语言:Java、C++、Python。 + +**核心特点**: +1. **封装**:隐藏细节,暴露接口,增强安全性。 +2. **继承**:子类复用父类功能,减少冗余代码。 +3. **多态**:同一方法在不同类中有不同实现,提高灵活性。 + +**好处**: +✅ **模块化**:代码结构清晰,易于维护。 +✅ **复用性**:继承减少重复开发。 +✅ **扩展性**:新增功能不影响旧代码。 +✅ **易协作**:对象抽象更贴近现实,方便团队开发。 + + + + +然后呢,你背诵上面了这段话,并没有什么作用,因为话术很空洞很虚幻,说了好像又什么都没说,无法落地,没有给你实操步骤,也没有给你具体例子比较面向过程,没有比较根本原因为什么需要oop。 + + + + +# 1 为什么写项目很难下笔,尤其是开发一个框架要抓破脑袋思考设计几天几夜 ``` 编程时候,设计新的模块或者项目,下不了笔,要思考三天三夜怎么设计,主要是没学设计模式。 @@ -20,7 +57,7 @@ ``` -## 一些介绍 +# 2 一些介绍 学弟啊,你代码能不能不要写得这么烂 https://www.toutiao.com/a6739759206997426696/ @@ -38,13 +75,103 @@ https://www.zhihu.com/question/25432487 https://zhuanlan.zhihu.com/p/19835717 -## 介绍神级别通用固定oop转化公式,写代码下笔时候行云流水。 +# 3 介绍神级别通用固定oop 4步转化公式,写代码下笔时候行云流水(只需学习这套固定面向过程转oop 4步走转化公式,远强于背诵设计模式)。 + +**使用这个公式,不需要背设计模式,不需要每次写新文件先花几天想破头皮怎么设计布局代码成为高扩展和高维护。** + + +[忘掉设计模式,使用最强最稳定最有固定套路的万能编程思维-python oop四步转化公式](https://github.com/ydf0509/python36patterns/tree/master/%E5%BF%98%E6%8E%89%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%9C%80%E5%BC%BA%E6%9C%80%E7%A8%B3%E5%AE%9A%E6%9C%80%E6%9C%89%E5%A5%97%E8%B7%AF%E7%9A%84%E4%B8%87%E8%83%BD%E7%BC%96%E7%A8%8B%E6%80%9D%E7%BB%B4-python%20oop%E5%9B%9B%E6%AD%A5%E8%BD%AC%E5%8C%96%E5%85%AC%E5%BC%8F%E3%80%82) + + +这个oop四步走转化公式是最重要的,其他的36个设计模式python例子你在很多地方都能看到类似的。 + +先简要说明四步转化公式,具体的看上面链接的文档 + +## 3.1 四步走转化公式,具体步骤如下 + +### 第0步,按照模块+函数写python代码,脑子里面打草稿,写全局变量多多益善 + +**第0步是灵魂步骤,后面3步是死板的代码形式转化。你不做这一步,直接做后面三步,那就是写出无效废物装逼滑稽类,因为写出来也是面向过程的类。** + +python模块文件下面多写全局变量,全局变量要多多益善; +多个函数之间不要疯狂传递一大堆相同名字或意义的入参; +每个函数末尾不要疯狂return一大堆中间状态变量; +不要把这些return出来的变量,频繁传递给另外一个函数; + +**你应该尽可能全部设计成全局变量,然后每个函数里面去修改这一堆全局变量,这样就大幅避免了多个函数频繁传递一大堆入参,也不需要每个函数末尾疯狂return一大堆中间状态变量。** + +这一步是脑子打草稿,多写全局变量,每个函数少传一大堆入参,少写return一大堆结果变量。 + +这一步和老师教你要少写全局变量不同,似乎是反智,但请往下看。 + +### 第1步 模块降级为类名 + +就是要把模块级代码移到class 类下面 + +写个class 类,就是把你之前脑子打的草稿,模块 + 全局变量 + 函数,改成 类+实例属性+实例方法 + +### 第2步 全局变量降级为实例属性 -使用这个公式,不需要背设计模式,不需要每次写新文件先花几天想破头皮怎么设计布局代码成为高扩展和高维护。 +之前为什么让你多写全局变量,就是为了这一步,全局变量降级为实例属性。你以为最终目的是为了多写全局变量吗?多写全局变量肯定是不行的是反语言的。 -## 常见问题回答 +### 第3步 函数降级为实例方法 -1、老是纠结类和函数?类和函数有什么区别。 +函数改为实例方法,但是函数第一个入参要加个self。 + +之前模块函数里面直接用全局变量 var_xx,现在实例方法里面读取和修这个"全局变量",使用 self.var_xx。 + +## 3.2 oop 四步走转化公式的说明: + +转化oop要有灵魂的第0步,如果跳过此步骤,直接执行第1到3步,就会想当然以为转化oop就是函数外面加个class关键字外壳,觉得转化没用。 +那是因为你不按照我说的步骤走,造成写成了无效废物装逼滑稽面向过程类,当然会觉得不需要转化。oop要的是内涵不要搞形式class外壳。 + +## 3.3 为什么要 oop 四步走转化,说明最根本核心原因 + +### 3.1 直接 模块级 + 多多益善的全局变量 + 函数 有什么问题? + +``` +最根本原因是因为模块是单例的,模块的变量是全局唯一的,例如按照第五章的代码你 描述一个人 吃喝拉撒(函数) 影响人的身高体重(全局变量)。 + +如果你要调用 小红 小明 小黄 小黑 4个人吃喝拉撒,由于全局变量只有一份,那会互相影响,因为全局变量没有隔离。小红调用吃饭,为什么要增加小明的体重? + +所以你为了避免这种全局变量不适合多个人调用吃喝拉撒的问题,就写出了类似5.1教程的代码,写成了多个函数间疯狂传参,疯狂return一大堆变量,把这些变量再外部保存,并在函数间传来传去。 +``` + +### 3.2 使用oop的天然多实例,每个实例的属性互不干扰的特性,天然解决全局变量只有一份的问题 + +``` +既想写代码简单粗暴,全局变量加函数的思维,又要解决 全局变量只有一个,不能隔离的问题。那就是使用oop开发代码, +oop的类天然就是多实例的,每个实例的属性是互不干扰的,天然解决全局变量只有一份的问题。 + +oop写代码后,类的每个对象的方法访问和修改实例属性,就像函数里面操作全局变量那样丝滑,并且是每个实例的属性天生是各自的,不会互相干扰的。 +你调用 小红.吃饭() 再也不用担心影响到 小明.体重 了。 +``` +### 3.3 不要用辩证法说有时候面向过程编程有时候更有优势 之类的话! + +有的人就是杠精,我说 "考公务员都是精致的利己主义者,就是为了工资高 永不失业 退休金高"; +他却辩证法说 "也有考公务员是为了成为高尚的人民公仆,例如雷锋就是不喜欢钱,就是喜欢把国家发的工资和退休金都捐给农村老人用"。 + +``` +最怕有的人,完全不去思考为什么需要oop,自己懒得要死,上来就来一句 "有时候面向过程编程更简单更好" 的话 或者 "只有大项目才需要oop" 的话。 + +不要这么使用辩证法偷懒好吗。我没说过任何场景一定要用oop,最最关键的判断依据是你需不需要多实例, 你不需要多实例那就可以不要面向对象写法, +也不需要单例模式装逼写个类,你直接模块加函数就好了,反正不需要全局变量隔离的需求。 + +例如本文档第5章节,描写一个人吃喝拉撒运动影响了身高体重,这个需求是非常非常简单吧,绝对是你口中的小项目,绝对是你认为的不需要oop。 +但事实就是,用oop来完成需求,比面向过程写法实现时候简单多了,最重要的是调用时候简单太多了。 + +为什么我写的所有包,例如 funboost nb_time nb_log都很好用,都是用法十分简单但功能十分强大的python包,原因就是在于此。 +假如你来封装python三方包或框架给别人用,如果你不按我的思路写代码,就会造成不仅你自己实现框架时候很麻烦、很难扩展、爱出错、不好维护, +更重要的是你把这个包发布出来后,即使功能能达到目的,但用户会感觉极端难使用、不好用、不方便。 +例如5.1写法封装的模块,用户来调用人.吃饭() 和人.撒尿() ,用户需要风控传一大堆入参和接受并保存一大堆返回,体验太差了。 +``` + +- **需要多实例** → 用OOP +- **不需要多实例** → 用面向过程(模块+函数) + +# 4 常见问题回答 + +## 4.1 老是纠结类和函数?类和函数有什么区别。 ``` 问函数和类的区别,这简直是牛头不对马嘴的伪问题。 @@ -61,12 +188,13 @@ https://zhuanlan.zhihu.com/p/19835717 所以如果需要多实例,类 + 方法 + 实例属性(成员变量) 远好于 模块 + 函数 + 全局变量。 模块 + 函数 + 全局变量 由于要模拟多实例,使全局变量(状态) 不唯一,大部分情况下需要写成 函数反复传参和反复return。 -这种面向过程的封装的写法曲折程度毫无疑问被oop暴击了,面向过程导致写代码慢想破头皮搞一堆传参和return。何况oop不只有封装还有继承和多态。 +这种面向过程的封装的写法曲折程度毫无疑问被oop暴击了,面向过程导致写代码慢想破头皮搞一堆传参和return。 +何况oop不只有封装还有继承和多态。 能写类的人100%就能写函数,能写函数的人不一定能写类(说的是真oop的类,排除无效废物面向过程滑稽类),这是不可逆的。 ``` -2、 不学设计模式的坏处 +## 4.2 不学设计模式的坏处 ``` 只爱学python语法,只学怎么使用if else break, 学字典 列表怎么用,代码就很low @@ -75,15 +203,15 @@ https://zhuanlan.zhihu.com/p/19835717 写新文件要想破头皮三天三夜才能开始下笔。 ``` -## !【重要】 简单例子说明极端面向过程编程非常愚蠢low +# 5【重要】 简单例子说明极端面向过程编程非常愚蠢low,代码模拟人 吃喝拉撒导致身高体重变化。 情不自禁纯粹极端面向过程编程还是c语言中毒了,从来都不使用面向对象,不用提设计模式。 -有些人完全没思考过面向对象,一味的只会说大型项目才需要面向对象,小项目面向过程更合适。简直是胡说八道,不看场景只看项目大小。 +有些人完全没思考过面向对象,一味的只会说"大型项目才需要面向对象,小项目面向过程更合适"。简直是胡说八道,不看场景只看项目大小。 -比如一个简单需求,描写人,吃饭 增加体重和身高,拉尿体重降低。需求是非常非常的简单了吧,绝对是非常小的项目,单个文件就好了,来验证下是不是小项目面向过程最好。 +比如一个简单需求,描写人,吃饭 增加体重和身高,拉尿体重降低。需求是非常非常的简单了吧,绝对是非常小的项目,单个文件就好了,来验证下是不是小项目面向过程就好了。 -面向过程来实现,看看代码实现多垃圾,调用时候多么麻烦。 +## 5.1 面向过程来实现,看看代码实现时候有多垃圾麻烦,调用时候多么麻烦。 ```python # 吃饭函数 def eat(name, height, weight, food_weight): @@ -115,16 +243,16 @@ if __name__ == "__main__": print(f"小明 初始状态 - 身高: {xiaoming_height} 厘米,体重: {xiaoming_weight} 千克") print(f"小红 初始状态 - 身高: {xiaohong_height} 厘米,体重: {xiaohong_weight} 千克") - # 小明吃饭和拉尿 + # 小明吃饭和拉尿,调用封装的函数太恶心了,传了一大堆入参,还要return一大堆变量,还要在调用处保存这些变量 xiaoming_height, xiaoming_weight = eat("小明", xiaoming_height, xiaoming_weight, 2) xiaoming_height, xiaoming_weight = pee("小明", xiaoming_height, xiaoming_weight, 1) - # 小红吃饭和拉尿 + # 小红吃饭和拉尿,调用封装的函数太恶心了,传了一大堆入参,还要return一大堆变量,还要在调用处保存这些变量 xiaohong_height, xiaohong_weight = eat("小红", xiaohong_height, xiaohong_weight, 3) xiaohong_height, xiaohong_weight = pee("小红", xiaohong_height, xiaohong_weight, 2) ``` -面向对象来实现,看看代码实现多简单调用多方便 +## 5.2 面向对象来实现,看看代码实现多简单调用多方便 ```python class Person: def __init__(self, name, height, weight): @@ -151,11 +279,11 @@ if __name__ == "__main__": xiaoming = Person("小明", 170, 60) xiaohong = Person("小红", 160, 50) - # 小明吃饭和拉尿 + # 小明吃饭和拉尿, 调用太爽了,不用传一大堆入参,不用return一大堆变量,不用在调用处保存这些变量 xiaoming.eat(2) xiaoming.pee(1) - # 小红吃饭和拉尿 + # 小红吃饭和拉尿,调用太爽了,不用传一大堆入参,不用return一大堆变量,不用在调用处保存这些变量 xiaohong.eat(3) xiaohong.pee(2) ``` @@ -179,4 +307,14 @@ if __name__ == "__main__": ``` -#### 只需要按文档的面向过程转 oop 4步走里面的固定公式,全局变量->实例属性,函数->方法 降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 \ No newline at end of file +# 6 再次说明,项目最重要的是oop四步走转化公式 + +**只需要按文档的面向过程转 oop 4步走里面的固定公式,全局变量->实例属性,函数->方法 降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。** + + + + + + + + diff --git "a/345円277円230円346円216円211円350円256円276円350円256円241円346円250円241円345円274円217円357円274円214円344円275円277円347円224円250円346円234円200円345円274円272円346円234円200円347円250円263円345円256円232円346円234円200円346円234円211円345円245円227円350円267円257円347円232円204円344円270円207円350円203円275円347円274円226円347円250円213円346円200円235円347円273円264円-python oop345円233円233円346円255円245円350円275円254円345円214円226円345円205円254円345円274円217円343円200円202円/README.md" "b/345円277円230円346円216円211円350円256円276円350円256円241円346円250円241円345円274円217円357円274円214円344円275円277円347円224円250円346円234円200円345円274円272円346円234円200円347円250円263円345円256円232円346円234円200円346円234円211円345円245円227円350円267円257円347円232円204円344円270円207円350円203円275円347円274円226円347円250円213円346円200円235円347円273円264円-python oop345円233円233円346円255円245円350円275円254円345円214円226円345円205円254円345円274円217円343円200円202円/README.md" index f902abf..4059bee 100644 --- "a/345円277円230円346円216円211円350円256円276円350円256円241円346円250円241円345円274円217円357円274円214円344円275円277円347円224円250円346円234円200円345円274円272円346円234円200円347円250円263円345円256円232円346円234円200円346円234円211円345円245円227円350円267円257円347円232円204円344円270円207円350円203円275円347円274円226円347円250円213円346円200円235円347円273円264円-python oop345円233円233円346円255円245円350円275円254円345円214円226円345円205円254円345円274円217円343円200円202円/README.md" +++ "b/345円277円230円346円216円211円350円256円276円350円256円241円346円250円241円345円274円217円357円274円214円344円275円277円347円224円250円346円234円200円345円274円272円346円234円200円347円250円263円345円256円232円346円234円200円346円234円211円345円245円227円350円267円257円347円232円204円344円270円207円350円203円275円347円274円226円347円250円213円346円200円235円347円273円264円-python oop345円233円233円346円255円245円350円275円254円345円214円226円345円205円254円345円274円217円343円200円202円/README.md" @@ -1,4 +1,4 @@ -## 列举出4种编程方式,并介绍万能的oop 四步转化公式。 +# 列举出4种编程方式,并介绍万能的oop 四步转化公式。 ``` 包含4种编程写法 1)模块级 全局变量 + 函数 @@ -12,54 +12,107 @@ 此种编程方式,可以使任意极端纯面向过程代码的文件和项目减少50%行至95%行,写法更直观,并达到流程级可复用。 ``` -## oop四步走转化公式 +# 3 介绍神级别通用固定oop 4步转化公式,写代码下笔时候行云流水(只需学习这套固定面向过程转oop 4步走转化公式,远强于背诵设计模式)。 + +**使用这个公式,不需要背设计模式,不需要每次写新文件先花几天想破头皮怎么设计布局代码成为高扩展和高维护。** + + +[忘掉设计模式,使用最强最稳定最有固定套路的万能编程思维-python oop四步转化公式](https://github.com/ydf0509/python36patterns/tree/master/%E5%BF%98%E6%8E%89%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%9C%80%E5%BC%BA%E6%9C%80%E7%A8%B3%E5%AE%9A%E6%9C%80%E6%9C%89%E5%A5%97%E8%B7%AF%E7%9A%84%E4%B8%87%E8%83%BD%E7%BC%96%E7%A8%8B%E6%80%9D%E7%BB%B4-python%20oop%E5%9B%9B%E6%AD%A5%E8%BD%AC%E5%8C%96%E5%85%AC%E5%BC%8F%E3%80%82) + + +这个oop四步走转化公式是最重要的,其他的36个设计模式python例子你在很多地方都能看到类似的。 + +先简要说明四步转化公式,具体的看上面链接的文档 + +## 3.1 四步走转化公式,具体步骤如下 + +### 第0步,按照模块+函数写python代码,脑子里面打草稿,写全局变量多多益善 + +**第0步是灵魂步骤,后面3步是死板的代码形式转化。你不做这一步,直接做后面三步,那就是写出无效废物装逼滑稽类,因为写出来也是面向过程的类。** + +python模块文件下面多写全局变量,全局变量要多多益善; +多个函数之间不要疯狂传递一大堆相同名字或意义的入参; +每个函数末尾不要疯狂return一大堆中间状态变量; +不要把这些return出来的变量,频繁传递给另外一个函数; + +**你应该尽可能全部设计成全局变量,然后每个函数里面去修改这一堆全局变量,这样就大幅避免了多个函数频繁传递一大堆入参,也不需要每个函数末尾疯狂return一大堆中间状态变量。** + +这一步是脑子打草稿,多写全局变量,每个函数少传一大堆入参,少写return一大堆结果变量。 + +这一步和老师教你要少写全局变量不同,似乎是反智,但请往下看。 + +### 第1步 模块降级为类名 + +就是要把模块级代码移到class 类下面 + +写个class 类,就是把你之前脑子打的草稿,模块 + 全局变量 + 函数,改成 类+实例属性+实例方法 + +### 第2步 全局变量降级为实例属性 + +之前为什么让你多写全局变量,就是为了这一步,全局变量降级为实例属性。你以为最终目的是为了多写全局变量吗?多写全局变量肯定是不行的是反语言的。 + +### 第3步 函数降级为实例方法 + +函数改为实例方法,但是函数第一个入参要加个self。 + +之前模块函数里面直接用全局变量 var_xx,现在实例方法里面读取和修这个"全局变量",使用 self.var_xx。 + +## 3.2 oop 四步走转化公式的说明: + +转化oop要有灵魂的第0步,如果跳过此步骤,直接执行第1到3步,就会想当然以为转化oop就是函数外面加个class关键字外壳,觉得转化没用。 +那是因为你不按照我说的步骤走,造成写成了无效废物装逼滑稽面向过程类,当然会觉得不需要转化。oop要的是内涵不要搞形式class外壳。 + +## 3.3 为什么要 oop 四步走转化,说明最根本核心原因 + +### 3.1 直接 模块级 + 多多益善的全局变量 + 函数 有什么问题? + +``` +最根本原因是因为模块是单例的,模块的变量是全局唯一的,例如按照第五章的代码你 描述一个人 吃喝拉撒(函数) 影响人的身高体重(全局变量)。 + +如果你要调用 小红 小明 小黄 小黑 4个人吃喝拉撒,由于全局变量只有一份,那会互相影响,因为全局变量没有隔离。小红调用吃饭,为什么要增加小明的体重? + +所以你为了避免这种全局变量不适合多个人调用吃喝拉撒的问题,就写出了类似5.1教程的代码,写成了多个函数间疯狂传参,疯狂return一大堆变量,把这些变量再外部保存,并在函数间传来传去。 ``` -一、针对已有全局变量加函数无限复制粘贴扣字的写法, -0) 如果没有写成极致的全局变量加函数写法,就需要在脑袋里多多的抽取全局变量,全局变量多多益善(要大大减少反复return/传参)。 -1) 模块级降级为类名 -2) 全局变量改成实例属性 -3) 函数改为方法 +### 3.2 使用oop的天然多实例,每个实例的属性互不干扰的特性,天然解决全局变量只有一份的问题 -二、针对已有在一组函数中频繁return和大量重复传参的写法 -1、转化公式1 (先在脑袋中把代码形式转化为全局变量加函数的写法,在使用公式一) -0)在脑袋中重构,把写法形式改成全局变量加函数的写法,此时不用担心全局变量是唯一的, -不用大量重复传参和return,所有需要传参和return的都想象成使用全局变量和操作全局变量。 -1) 模块级降级为类名 -2) 全局变量改成实例属性 -3) 函数改为方法 -后面三个步骤是一样的。全局变量变为实例属性后,每次实例化后每个对象的实例属性都是互不干扰的。 -每个对象可以看作为一个模块级写法的 模块文件的无限深拷贝。 +``` +既想写代码简单粗暴,全局变量加函数的思维,又要解决 全局变量只有一个,不能隔离的问题。那就是使用oop开发代码, +oop的类天然就是多实例的,每个实例的属性是互不干扰的,天然解决全局变量只有一份的问题。 -2、转化公式2 (直接转化,比较熟悉了之后) -1) 新增一个类 -2)把重复传参和return的形参,全都去掉,抽取为改成实例属性 -3) 函数改为方法。 +oop写代码后,类的每个对象的方法访问和修改实例属性,就像函数里面操作全局变量那样丝滑,并且是每个实例的属性天生是各自的,不会互相干扰的。 +你调用 小红.吃饭() 再也不用担心影响到 小明.体重 了。 +``` +### 3.3 不要用辩证法说有时候面向过程编程有时候更有优势 之类的话! -三、新写代码: -可以使用老的编程方式在脑袋里写,然后使用oop转化公式。 -也可以跳过老的编程方式,直接oop,最重要是实例属性多多益善(但不能没事乱把局部变量含义的东西也加self), -理解oop的多例。 +有的人就是杠精,我说 "考公务员都是精致的利己主义者,就是为了工资高 永不失业 退休金高"; +他却辩证法说 "也有考公务员是为了成为高尚的人民公仆,例如雷锋就是不喜欢钱,就是喜欢把国家发的工资和退休金都捐给农村老人用"。 -四、 -对任何面向过程写法,使用转化公式,一定就可以修改成oop,然来的代码思维不需要做任何改变, -只要按这个公式就可以改造。(前提是满足需要使用oop的两个条件,才需要改造) +``` +最怕有的人,完全不去思考为什么需要oop,自己懒得要死,上来就来一句 "有时候面向过程编程更简单更好" 的话 或者 "只有大项目才需要oop" 的话。 -转化oop要有灵魂的第0步,如果跳过此步骤就会想当然以为转化oop就是函数外面加个class关键字外壳,觉得转化没用。 -那是因为你不按照我说的步骤走,造成写成了无效废物装逼滑稽面向过程类,当然会觉得不需要转化。oop要的是内涵不要搞形式外壳。 +不要这么使用辩证法偷懒好吗。我没说过任何场景一定要用oop,最最关键的判断依据是你需不需要多实例, 你不需要多实例那就可以不要面向对象写法, +也不需要单例模式装逼写个类,你直接模块加函数就好了,反正不需要全局变量隔离的需求。 +例如本文档第5章节,描写一个人吃喝拉撒运动影响了身高体重,这个需求是非常非常简单吧,绝对是你口中的小项目,绝对是你认为的不需要oop。 +但事实就是,用oop来完成需求,比面向过程写法实现时候简单多了,最重要的是调用时候简单太多了。 +为什么我写的所有包,例如 funboost nb_time nb_log都很好用,都是用法十分简单但功能十分强大的python包,原因就是在于此。 +假如你来封装python三方包或框架给别人用,如果你不按我的思路写代码,就会造成不仅你自己实现框架时候很麻烦、很难扩展、爱出错、不好维护, +更重要的是你把这个包发布出来后,即使功能能达到目的,但用户会感觉极端难使用、不好用、不方便。 +例如5.1写法封装的模块,用户来调用人.吃饭() 和人.撒尿() ,用户需要风控传一大堆入参和接受并保存一大堆返回,体验太差了。 ``` -## oop转化公式的重要本质需要理解的方面 + +# oop转化公式的重要本质需要理解的方面 ``` 最重要是理解: 命名空间 全局变量 实例属性 多实例需求 函数和方法 的关系,搞清楚了, 写oop十分之简单,不会造成极端面向过程的曲折写法。 在word文档中会写更详细的解释。 ``` -## 常见问题解答 +# 常见问题解答 ``` 1、是不是所有代码都要用oop? 答:不是,按照上面的方式判断用那种方式好,再用oop转化公式,使用真正得oo编程。 @@ -74,7 +127,7 @@ oop是 狗.eat(shit) ``` -## python编程范式 +# python编程范式 ``` 1.1 方式一,平铺指令。 从上往下叠加指令,适合简单的独立脚本。不需要和没机会被别的模块导入。 1.2 方式二,面向过程函数式编程。适合实现独立的转化功能,基本原理是要实现转化 y = f(x), From 26dfb2e4d1f79657b703e1a5d062704bb41ec66e Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: 2025年6月19日 19:55:01 +0800 Subject: [PATCH 18/21] --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 98f3eef..820197a 100644 --- a/README.md +++ b/README.md @@ -284,11 +284,11 @@ if __name__ == "__main__": xiaoming = Person("小明", 170, 60) xiaohong = Person("小红", 160, 50) - # 小明吃饭和拉尿, 调用太爽了,不用传一大堆入参,不用return一大堆变量,不用在调用处保存这些变量 + # 小明吃饭和拉尿, 调用太爽了,不用传一大堆入参,不用return一大堆变量,不用在调用处保存这些中间变量 xiaoming.eat(2) xiaoming.pee(1) - # 小红吃饭和拉尿,调用太爽了,不用传一大堆入参,不用return一大堆变量,不用在调用处保存这些变量 + # 小红吃饭和拉尿,调用太爽了,不用传一大堆入参,不用return一大堆变量,不用在调用处保存这些中间变量 xiaohong.eat(3) xiaohong.pee(2) ``` From 9fab77f1d1fb509b984faefae131cdbbea9c1f69 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: 2025年6月20日 11:30:18 +0800 Subject: [PATCH 19/21] 1 --- README.md | 164 ++++++++++-- .../README.md" | 233 ++++++++++++++++++ 2 files changed, 380 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 820197a..4e8fa33 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,13 @@ # 0 介绍36种设计模式(包括23种的变种和python独有例如猴子补丁),最最重要是介绍 oop四部转化公式!!! -## 0.1 python36种设计模式 +## 0.1 python的36种设计模式 一共有36种设计模式,23种里面有些还需要细分,你去看菜鸟教程网站的设计模式,那就不止罗列了23个例子,达到三十多种了,有些是变种,有些是python独有例如猴子补丁技术。 ## 0.2 介绍 oop四部转化公式,这是项目最重要的文档!!。 -介绍23种设计模式的博客 教程 网站文档 已经烂大街了,毫不稀奇。 +虽然这是我自己亲自写得36个python文件例子,但介绍23种设计模式的博客 教程 网站文档 烂大街了,毫不稀奇。 但是这个项目里面介绍的 oop四部转化公式,是项目最重要的部分,没有任何人是我这么总结如何写oop代码的,学校老师和书本只会教你背诵 封装 继承 多态 这几个词语本身.你只会看到下面这段类似的话: @@ -29,7 +29,7 @@ -然后呢,你背诵上面了这段话,并没有什么作用,因为话术很空洞很虚幻,说了好像又什么都没说,无法落地,没有给你实操步骤,也没有给你具体例子比较面向过程,没有比较根本原因为什么需要oop。 +然后呢,你背诵上面了这段空洞理论的话,并没有什么作用,因为话术很空洞很虚幻,说了好像又什么都没说,无法有固定实操套路落地,没有给你实操步骤,也没有给你具体例子比较面向过程,没有比较根本原因为什么需要oop。 @@ -52,7 +52,7 @@ 使用设计模式或oop转化公式,能使几乎任意项目代码减少50%至90%行,编码速度快一倍。 扩展性和维护性提高数十倍,bug减少5倍。 -如果是使用极端纯面向过程(或者加入了少量无效废物类)的方式来写python代码, +如果是使用极端纯面向过程(或者加入了少量无效废物类(假装 OOP 的类壳代码))的方式来写python代码, 我不用看,就知道一定很low。 ``` @@ -83,11 +83,6 @@ https://zhuanlan.zhihu.com/p/19835717 [忘掉设计模式,使用最强最稳定最有固定套路的万能编程思维-python oop四步转化公式](https://github.com/ydf0509/python36patterns/tree/master/%E5%BF%98%E6%8E%89%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%9C%80%E5%BC%BA%E6%9C%80%E7%A8%B3%E5%AE%9A%E6%9C%80%E6%9C%89%E5%A5%97%E8%B7%AF%E7%9A%84%E4%B8%87%E8%83%BD%E7%BC%96%E7%A8%8B%E6%80%9D%E7%BB%B4-python%20oop%E5%9B%9B%E6%AD%A5%E8%BD%AC%E5%8C%96%E5%85%AC%E5%BC%8F%E3%80%82) -## 常见问题回答 - -[忘掉设计模式,使用最强最稳定最有固定套路的万能编程思维-python oop四步转化公式](https://github.com/ydf0509/python36patterns/tree/master/%E5%BF%98%E6%8E%89%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%EF%BC%8C%E4%BD%BF%E7%94%A8%E6%9C%80%E5%BC%BA%E6%9C%80%E7%A8%B3%E5%AE%9A%E6%9C%80%E6%9C%89%E5%A5%97%E8%B7%AF%E7%9A%84%E4%B8%87%E8%83%BD%E7%BC%96%E7%A8%8B%E6%80%9D%E7%BB%B4-python%20oop%E5%9B%9B%E6%AD%A5%E8%BD%AC%E5%8C%96%E5%85%AC%E5%BC%8F%E3%80%82) - - 这个oop四步走转化公式是最重要的,其他的36个设计模式python例子你在很多地方都能看到类似的。 先简要说明四步转化公式,具体的看上面链接的文档 @@ -96,7 +91,7 @@ https://zhuanlan.zhihu.com/p/19835717 ### 第0步,按照模块+函数写python代码,脑子里面打草稿,写全局变量多多益善 -**第0步是灵魂步骤,后面3步是死板的代码形式转化。你不做这一步,直接做后面三步,那就是写出无效废物装逼滑稽类,因为写出来也是面向过程的类。** +**第0步是灵魂步骤,后面3步是死板的代码形式转化。你不做这一步,直接做后面三步,那就是写出无效废物装逼滑稽类(假装 OOP 的类壳代码),因为写出来也是面向过程的类。** python模块文件下面多写全局变量,全局变量要多多益善; 多个函数之间不要疯狂传递一大堆相同名字或意义的入参; @@ -128,7 +123,7 @@ python模块文件下面多写全局变量,全局变量要多多益善; ## 3.2 oop 四步走转化公式的说明: 转化oop要有灵魂的第0步,如果跳过此步骤,直接执行第1到3步,就会想当然以为转化oop就是函数外面加个class关键字外壳,觉得转化没用。 -那是因为你不按照我说的步骤走,造成写成了无效废物装逼滑稽面向过程类,当然会觉得不需要转化。oop要的是内涵不要搞形式class外壳。 +那是因为你不按照我说的步骤走,造成写成了无效废物装逼滑稽面向过程类(假装 OOP 的类壳代码),当然会觉得不需要转化。oop要的是内涵不要搞形式class外壳。 ## 3.3 为什么要 oop 四步走转化,说明最根本核心原因 @@ -196,7 +191,7 @@ oop写代码后,类的每个对象的方法访问和修改实例属性,就 这种面向过程的封装的写法曲折程度毫无疑问被oop暴击了,面向过程导致写代码慢想破头皮搞一堆传参和return。 何况oop不只有封装还有继承和多态。 -能写类的人100%就能写函数,能写函数的人不一定能写类(说的是真oop的类,排除无效废物面向过程滑稽类),这是不可逆的。 +能写类的人100%就能写函数,能写函数的人不一定能写类(说的是真oop的类,排除无效废物面向过程滑稽类(假装 OOP 的类壳代码)),这是不可逆的。 ``` ## 4.2 不学设计模式的坏处 @@ -208,7 +203,11 @@ oop写代码后,类的每个对象的方法访问和修改实例属性,就 写新文件要想破头皮三天三夜才能开始下笔。 ``` -# 5【重要】 简单例子说明极端面向过程编程非常愚蠢low,代码模拟人 吃喝拉撒导致身高体重变化。 +# 5【重要】使用三种代码设计思路写代码模拟人 吃喝拉撒导致身高体重变化。(具体例子,产生强烈对比) + +**代码体验分为两部分,第一部分是作者自己封装公共代码时候是否爽快容易扩展维护;第二部分是别人调用你封装的公共包是否感觉爽快好用。** + +**三个写法思路分别是: 封装痛苦,调用更苦 封装爽快,调用更爽 封装爽快,调用痛苦** 情不自禁纯粹极端面向过程编程还是c语言中毒了,从来都不使用面向对象,不用提设计模式。 @@ -216,7 +215,11 @@ oop写代码后,类的每个对象的方法访问和修改实例属性,就 比如一个简单需求,描写人,吃饭 增加体重和身高,拉尿体重降低。需求是非常非常的简单了吧,绝对是非常小的项目,单个文件就好了,来验证下是不是小项目面向过程就好了。 -## 5.1 面向过程来实现,看看代码实现时候有多垃圾麻烦,调用时候多么麻烦。 +## 5.1 使用频繁传参和大量return的面向过程来实现,看看代码实现时候有多垃圾麻烦,调用时候多么麻烦。(封装痛苦,调用更苦) + +这个面向过程代码实现很麻烦,要频繁传很多入入参和return大量参数;调用时候更加痛苦; +所以面向过程开发工程师不仅自己写代码麻烦,还造成封装的公共包使用很麻烦 + ```python # 吃饭函数 def eat(name, height, weight, food_weight): @@ -248,7 +251,7 @@ if __name__ == "__main__": print(f"小明 初始状态 - 身高: {xiaoming_height} 厘米,体重: {xiaoming_weight} 千克") print(f"小红 初始状态 - 身高: {xiaohong_height} 厘米,体重: {xiaohong_weight} 千克") - # 小明吃饭和拉尿,调用封装的函数太恶心了,传了一大堆入参,还要return一大堆变量,还要在调用处保存这些变量 + # 小明吃饭和拉尿,调用封装的函数太恶心了,传了一大堆入参,还要return一大堆变量,还要在调用处保存这些变量,如果把小红的体重和小明的姓名传混乱就乱了。 xiaoming_height, xiaoming_weight = eat("小明", xiaoming_height, xiaoming_weight, 2) xiaoming_height, xiaoming_weight = pee("小明", xiaoming_height, xiaoming_weight, 1) @@ -257,7 +260,11 @@ if __name__ == "__main__": xiaohong_height, xiaohong_weight = pee("小红", xiaohong_height, xiaohong_weight, 2) ``` -## 5.2 面向对象来实现,看看代码实现多简单调用多方便 +## 5.2 面向对象来实现 方法加实例属性,看看代码实现多简单调用多方便 (封装爽快,调用更爽) + +这个oop面向对象代码,实现时候很丝滑很容易,不需要在每个方法频繁传一大堆入参,和每个方法return 一大堆变量; +用户在调用时候很简单很爽快。 + ```python class Person: def __init__(self, name, height, weight): @@ -312,4 +319,127 @@ if __name__ == "__main__": ``` -#### 只需要按文档的面向过程转 oop 4步走里面的固定公式,全局变量->实例属性,函数->方法 降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 + +## 5.3 使用模块 + 全局变量多多益善 + 函数 的写法,来实现吃喝拉撒影响身高体重,实现是爽 !!但调用时候不可理喻。(封装爽快,调用痛苦) + +这个写法思路不需要多个函数之间频繁传参,实现代码时候很丝滑平顺。!!!但是 但是 但是调用时候无法多实例隔离全局变量,实际不可理喻! + +老师和任何教程都说过,写代码要少用全局变量,在编程实践中应当尽量减少其使用。csdn或者ai去搜索 "少用全局变量" 的博客一大堆,自己去看为什么,不展开啰嗦了。 + +这种 使用模块 + 全局变量多多益善 + 函数 的写法,来实现吃喝拉撒影响身高体重,实现代码时候的确很丝滑, +因为这个代码实现时候,完全不需要频繁在不同函数之间传一大堆入参,也不需要每个函数return一大堆变量,所以实现起来很爽快。 + +但是调用时候,由于全局变量是唯一的,所以调用时候无法多实例隔离全局变量,实际不可理喻!因为你一会儿要小红吃饭撒尿影响小红体重,一会儿要小明吃饭撒尿影响小明体重,但姓名 身高 体重 由于是全局变量在内存中只有一份,虽然实现爽,但实际上可调用性很差。 +如果你的场景是脚本单独单次运行,不存在同时需要实现小明 小红 小黑 来复用调用公共包的需求,那你可以使用这种面向过程写法,我从没说过任何场景一定要用oop,一定要你使用oop四步走转化公式写个class类。 + +这种写法平铺直叙很爽快,适合在单个脚本来单次自己使用,不适合作为公共包被其他地方或其他人调用复用。 + +所以再次印证了,我上面说的,什么时候应该用面向对象,什么时候可以使用面向过程,不是以项目代码长度来作为依据。而是以是否需要多实例作为依据 + + +- **需要多实例** → 用OOP +- **不需要多实例** → 用面向过程(模块+函数) + + +```python +# 全局变量多多益善 +name = "" +height = 0 +weight = 0 + +def eat(food_weight): + """吃饭:增加体重和身高""" + global weight, height + weight += food_weight + height += food_weight * 0.01 + print(f"{name} 吃了 {food_weight} 千克食物,体重: {weight} 千克,身高: {height} 厘米") + +def pee(pee_weight): + """拉尿:减少体重""" + global weight + if pee_weight> weight: + pee_weight = weight + weight -= pee_weight + print(f"{name} 拉了 {pee_weight} 千克尿,体重: {weight} 千克,身高: {height} 厘米") + +# 测试代码 - 写代码很丝滑! +if __name__ == "__main__": + # 小明的情况 + name = "小明" + height = 170 + weight = 60 + + eat(2) # 不需要传一堆参数! + pee(1) # 不需要return和接收一堆变量! + + # 但是现在要处理小红,全局变量就乱了... + name = "小红" # 这会覆盖掉小明的数据 + height = 160 + weight = 50 + + eat(3) # 小红吃饭,但前面小明的状态丢失了 +``` + + +## 5.4 鼓励面向过程工程师在脑子里打草稿使用5.3的写法,然后使用4步走转化公式,转化成oop写法。 + +文章第三章介绍了万能的oop四步走转化公式,你可以在脑子里打草稿使用5.3的写法,然后使用4步走转化公式,转化成oop写法。 + +如果你是面向过程工程师,不知道怎么设计oop。 +请你一定要按照5.3的 模块 + 全局变量多多益善 + 函数 实现代码思路,然后套用oop四步走转化公式。 +千万不要再使用5.1的 模块 + 无全局变量 + 多个函数之间频繁传一堆参数 + 每个函数末尾风控return一大堆变量 的写法。 +你使用5.1的写法,就是在面向过程一条道走到黑,不光自己实现代码麻烦难扩展维护,更严重的别人调用你封装的公共包还贼恶心贼难用。 + + +## 5.5 何时需要使用oop + +如何上面用真实代码证明的,何时需要使用oop。 + +- **需要多实例** → 用OOP +- **不需要多实例** → 用面向过程(模块+函数) + + +### 5.5.2 如果你还是不确定是否需要多实例,建议全部写成oop类。 + +为什么建议不确定是否要多实例时候,全部写成类oop形式? + +#### 第一,oop多实例总是能满足单例需求,但单例无法满足多实例需求。 + +因为你现在不确定啊,oop是多实例,即使你永远不需要多实例,但你可以只实例化一次,多实例的实现能兼容单例调用。 +反过来,你一开始写成模块 + 全局变量 + 函数,那就是个单例,如果你需要多实例,单例不能反过来兼容多实例调用的需求。 + +``` +就好比你设计一个api接口,一个订单下面的商品,是设计成数组还是单个元素? + +如果你设计成单个元素,万一以后老板说一个订单能购买多个不同的商品呢?如果你一开始设计成单个元素, +原来的api接口设计和代码就无法满足需要大改特改了。 + +反之,如果你之前是设计成订单下的商品是一个数组,即使一个订单只能购买一个商品,你数组也能兼容里面只包含一个元素, +而且也能兼容以后一个订单购买多个商品。 + +这说的是可逆和不可逆的区别。 +``` + +例如5.3的代码,你原来只需要小明来调用可以,你后面要小明 小红 小黑都调用,那就全局变量无法隔离,无法满足需求。 + +#### 第二,全局变量在函数里面修改需要麻烦的global声明,否则是生成修改局部变量,oop天然是实例属性,不需要global声明,不存在变量隔离和污染。 + +如5.3代码所示,全局变量在函数里面使用并修改时候,需要麻烦的使用global 声明一下,这正是python设计之初,担心用户随意修改污染全局变量。 + +#### 第三,复杂系统时候,代码量很大,你都写成模块 + 函数,那要分成很多个py文件,类能把一个py文件划分成多个更小模块。 + +如果吧一组相关功能写一个模块,那要分成很多个py文件,py文件太多了。 + +而如果把不相关函数放在一个模块,那就很混乱,不知道哪一组函数是负责a功能的,哪一组函数是负责b功能的。 + +如果写成class类,有代码缩进,通过不同的类名有代码快缩进,就能知道哪些函数是负责什么的,你一个py文件下的100个函数分贝是什么作用能划分更清晰。 + + + + + + + +#### 只需要按文档的面向过程转 oop 4步走里面的固定公式,脑子里面打草稿全局变量设计得多多益善 + 全局变量->实例属性,函数->方法 降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 + +先oop再考虑设计模式不迟。只情不自禁使用面向过程,那无法使用所有设计模式。 \ No newline at end of file diff --git "a/345円277円230円346円216円211円350円256円276円350円256円241円346円250円241円345円274円217円357円274円214円344円275円277円347円224円250円346円234円200円345円274円272円346円234円200円347円250円263円345円256円232円346円234円200円346円234円211円345円245円227円350円267円257円347円232円204円344円270円207円350円203円275円347円274円226円347円250円213円346円200円235円347円273円264円-python oop345円233円233円346円255円245円350円275円254円345円214円226円345円205円254円345円274円217円343円200円202円/README.md" "b/345円277円230円346円216円211円350円256円276円350円256円241円346円250円241円345円274円217円357円274円214円344円275円277円347円224円250円346円234円200円345円274円272円346円234円200円347円250円263円345円256円232円346円234円200円346円234円211円345円245円227円350円267円257円347円232円204円344円270円207円350円203円275円347円274円226円347円250円213円346円200円235円347円273円264円-python oop345円233円233円346円255円245円350円275円254円345円214円226円345円205円254円345円274円217円343円200円202円/README.md" index 4059bee..f0ea9c2 100644 --- "a/345円277円230円346円216円211円350円256円276円350円256円241円346円250円241円345円274円217円357円274円214円344円275円277円347円224円250円346円234円200円345円274円272円346円234円200円347円250円263円345円256円232円346円234円200円346円234円211円345円245円227円350円267円257円347円232円204円344円270円207円350円203円275円347円274円226円347円250円213円346円200円235円347円273円264円-python oop345円233円233円346円255円245円350円275円254円345円214円226円345円205円254円345円274円217円343円200円202円/README.md" +++ "b/345円277円230円346円216円211円350円256円276円350円256円241円346円250円241円345円274円217円357円274円214円344円275円277円347円224円250円346円234円200円345円274円272円346円234円200円347円250円263円345円256円232円346円234円200円346円234円211円345円245円227円350円267円257円347円232円204円344円270円207円350円203円275円347円274円226円347円250円213円346円200円235円347円273円264円-python oop345円233円233円346円255円245円350円275円254円345円214円226円345円205円254円345円274円217円343円200円202円/README.md" @@ -142,3 +142,236 @@ oop是 狗.eat(shit) 面向过程了。比如猴子补丁可以搞定继承,闭包可以搞定封装,但是没什么好处,实现麻烦。先要转oop,只有放弃极端面向过程,不对面 向过程过分的偏执和喜欢,才能开始学习更多设计模式。 ``` + + +# 5【重要】使用三种代码设计思路写代码模拟人 吃喝拉撒导致身高体重变化。(具体例子,产生强烈对比) + +**代码体验分为两部分,第一部分是作者自己封装公共代码时候是否爽快容易扩展维护;第二部分是别人调用你封装的公共包是否感觉爽快好用。** + +**三个写法思路分别是: 封装痛苦,调用更苦 封装爽快,调用更爽 封装爽快,调用痛苦** + +情不自禁纯粹极端面向过程编程还是c语言中毒了,从来都不使用面向对象,不用提设计模式。 + +有些人完全没思考过面向对象,一味的只会说"大型项目才需要面向对象,小项目面向过程更合适"。简直是胡说八道,不看场景只看项目大小。 + +比如一个简单需求,描写人,吃饭 增加体重和身高,拉尿体重降低。需求是非常非常的简单了吧,绝对是非常小的项目,单个文件就好了,来验证下是不是小项目面向过程就好了。 + +## 5.1 使用频繁传参和大量return的面向过程来实现,看看代码实现时候有多垃圾麻烦,调用时候多么麻烦。(封装痛苦,调用更苦) + +这个面向过程代码实现很麻烦,要频繁传很多入入参和return大量参数;调用时候更加痛苦; +所以面向过程开发工程师不仅自己写代码麻烦,还造成封装的公共包使用很麻烦 + +```python +# 吃饭函数 +def eat(name, height, weight, food_weight): + """吃饭:增加体重和身高""" + new_weight = weight + food_weight + new_height = height + food_weight * 0.01 + print(f"{name} 吃了 {food_weight} 千克食物,体重: {new_weight} 千克,身高: {new_height} 厘米") + return new_height, new_weight + +# 拉尿函数 +def pee(name, height, weight, pee_weight): + """拉尿:减少体重""" + if pee_weight> weight: + pee_weight = weight + new_weight = weight - pee_weight + print(f"{name} 拉了 {pee_weight} 千克尿,体重: {new_weight} 千克,身高: {height} 厘米") + return height, new_weight + +# 测试代码 +if __name__ == "__main__": + # 小明的初始状态 + xiaoming_height = 170 + xiaoming_weight = 60 + + # 小红的初始状态 + xiaohong_height = 160 + xiaohong_weight = 50 + + print(f"小明 初始状态 - 身高: {xiaoming_height} 厘米,体重: {xiaoming_weight} 千克") + print(f"小红 初始状态 - 身高: {xiaohong_height} 厘米,体重: {xiaohong_weight} 千克") + + # 小明吃饭和拉尿,调用封装的函数太恶心了,传了一大堆入参,还要return一大堆变量,还要在调用处保存这些变量,如果把小红的体重和小明的姓名传混乱就乱了。 + xiaoming_height, xiaoming_weight = eat("小明", xiaoming_height, xiaoming_weight, 2) + xiaoming_height, xiaoming_weight = pee("小明", xiaoming_height, xiaoming_weight, 1) + + # 小红吃饭和拉尿,调用封装的函数太恶心了,传了一大堆入参,还要return一大堆变量,还要在调用处保存这些变量 + xiaohong_height, xiaohong_weight = eat("小红", xiaohong_height, xiaohong_weight, 3) + xiaohong_height, xiaohong_weight = pee("小红", xiaohong_height, xiaohong_weight, 2) +``` + +## 5.2 面向对象来实现 方法加实例属性,看看代码实现多简单调用多方便 (封装爽快,调用更爽) + +这个oop面向对象代码,实现时候很丝滑很容易,不需要在每个方法频繁传一大堆入参,和每个方法return 一大堆变量; +用户在调用时候很简单很爽快。 + +```python +class Person: + def __init__(self, name, height, weight): + self.name = name + self.height = height # 身高,单位:厘米 + self.weight = weight # 体重,单位:千克 + + def eat(self, food_weight): + """吃饭:增加体重和身高""" + self.weight += food_weight + self.height += food_weight * 0.01 + print(f"{self.name} 吃了 {food_weight} 千克食物,体重: {self.weight} 千克,身高: {self.height} 厘米") + + def pee(self, pee_weight): + """拉尿:减少体重""" + if pee_weight> self.weight: + pee_weight = self.weight + self.weight -= pee_weight + print(f"{self.name} 拉了 {pee_weight} 千克尿,体重: {self.weight} 千克,身高: {self.height} 厘米") + +# 测试代码 +if __name__ == "__main__": + # 创建小明和小红 + xiaoming = Person("小明", 170, 60) + xiaohong = Person("小红", 160, 50) + + # 小明吃饭和拉尿, 调用太爽了,不用传一大堆入参,不用return一大堆变量,不用在调用处保存这些中间变量 + xiaoming.eat(2) + xiaoming.pee(1) + + # 小红吃饭和拉尿,调用太爽了,不用传一大堆入参,不用return一大堆变量,不用在调用处保存这些中间变量 + xiaohong.eat(3) + xiaohong.pee(2) +``` + +``` +面向对象起码有封装,极端面向过程那就实现时候,每个函数结尾需要疯狂的return 一大堆变量,然后将一大堆变量传给另外一个函数进行处理。 +而面向对象不需要你把一大堆入参疯狂在各个函数传来传去,return来return去。 + + +如果你给我说,定义一个结构体或者字典来存放 身高 体重 姓名,然后充分利用字典是可变类型,这样既减少了每个函数的入参数量, +又不需要return一大堆变量,还是可以用面向过程来写这个代码, +就避免了上面我说的疯狂传参和疯狂return的弊端,那么继承和多态阁下有如何应对呢? + +比如大人吃1kg长0.1kg体重,小孩吃1kg长0.2kg体重,并且我假设eat函数调用了另外一个_eat2的私有函数来具体的执行体重增加计算, +你在面向过程时候,就要加一个 大人eat的函数 加一个 大人_eat2 的函数, +并且大人eat的函数里面调用大人_eat2的函数,在小孩eat的函数里面调用小孩_eat2的函数, 整个链路的就都要替换, +而面向对象仅仅需要增加一个大人的类,继承重写 _eat2这个私有方法就好了。 +你想下纯粹极端面向过程实现公共代码时候有多low多复杂,并且调用它的时候有多麻烦。 + +如果你的思维是c语言中毒了,情不自禁极端面向过程编程,连入门的面向对象封装概念都没有,更别提更高阶的设计模式了。 + +``` + + +## 5.3 使用模块 + 全局变量多多益善 + 函数 的写法,来实现吃喝拉撒影响身高体重,实现是爽 !!但调用时候不可理喻。(封装爽快,调用痛苦) + +这个写法思路不需要多个函数之间频繁传参,实现代码时候很丝滑平顺。!!!但是 但是 但是调用时候无法多实例隔离全局变量,实际不可理喻! + +老师和任何教程都说过,写代码要少用全局变量,在编程实践中应当尽量减少其使用。csdn或者ai去搜索 "少用全局变量" 的博客一大堆,自己去看为什么,不展开啰嗦了。 + +这种 使用模块 + 全局变量多多益善 + 函数 的写法,来实现吃喝拉撒影响身高体重,实现代码时候的确很丝滑, +因为这个代码实现时候,完全不需要频繁在不同函数之间传一大堆入参,也不需要每个函数return一大堆变量,所以实现起来很爽快。 + +但是调用时候,由于全局变量是唯一的,所以调用时候无法多实例隔离全局变量,实际不可理喻!因为你一会儿要小红吃饭撒尿影响小红体重,一会儿要小明吃饭撒尿影响小明体重,但姓名 身高 体重 由于是全局变量在内存中只有一份,虽然实现爽,但实际上可调用性很差。 +如果你的场景是脚本单独单次运行,不存在同时需要实现小明 小红 小黑 来复用调用公共包的需求,那你可以使用这种面向过程写法,我从没说过任何场景一定要用oop,一定要你使用oop四步走转化公式写个class类。 + +这种写法平铺直叙很爽快,适合在单个脚本来单次自己使用,不适合作为公共包被其他地方或其他人调用复用。 + +所以再次印证了,我上面说的,什么时候应该用面向对象,什么时候可以使用面向过程,不是以项目代码长度来作为依据。而是以是否需要多实例作为依据 + + +- **需要多实例** → 用OOP +- **不需要多实例** → 用面向过程(模块+函数) + + +```python +# 全局变量多多益善 +name = "" +height = 0 +weight = 0 + +def eat(food_weight): + """吃饭:增加体重和身高""" + global weight, height + weight += food_weight + height += food_weight * 0.01 + print(f"{name} 吃了 {food_weight} 千克食物,体重: {weight} 千克,身高: {height} 厘米") + +def pee(pee_weight): + """拉尿:减少体重""" + global weight + if pee_weight> weight: + pee_weight = weight + weight -= pee_weight + print(f"{name} 拉了 {pee_weight} 千克尿,体重: {weight} 千克,身高: {height} 厘米") + +# 测试代码 - 写代码很丝滑! +if __name__ == "__main__": + # 小明的情况 + name = "小明" + height = 170 + weight = 60 + + eat(2) # 不需要传一堆参数! + pee(1) # 不需要return和接收一堆变量! + + # 但是现在要处理小红,全局变量就乱了... + name = "小红" # 这会覆盖掉小明的数据 + height = 160 + weight = 50 + + eat(3) # 小红吃饭,但前面小明的状态丢失了 +``` + + +## 5.4 鼓励面向过程工程师在脑子里打草稿使用5.3的写法,然后使用4步走转化公式,转化成oop写法。 + +文章第三章介绍了万能的oop四步走转化公式,你可以在脑子里打草稿使用5.3的写法,然后使用4步走转化公式,转化成oop写法。 + +如果你是面向过程工程师,不知道怎么设计oop。 +请你一定要按照5.3的 模块 + 全局变量多多益善 + 函数 实现代码思路,然后套用oop四步走转化公式。 +千万不要再使用5.1的 模块 + 无全局变量 + 多个函数之间频繁传一堆参数 + 每个函数末尾风控return一大堆变量 的写法。 +你使用5.1的写法,就是在面向过程一条道走到黑,不光自己实现代码麻烦难扩展维护,更严重的别人调用你封装的公共包还贼恶心贼难用。 + + +## 5.5 何时需要使用oop + +如何上面用真实代码证明的,何时需要使用oop。 + +- **需要多实例** → 用OOP +- **不需要多实例** → 用面向过程(模块+函数) + + +### 5.5.2 如果你还是不确定是否需要多实例,建议全部写成oop类。 + +为什么建议不确定是否要多实例时候,全部写成类oop形式? + +#### 第一,oop多实例总是能满足单例需求,但单例无法满足多实例需求。 + +因为你现在不确定啊,oop是多实例,即使你永远不需要多实例,但你可以只实例化一次,多实例的实现能兼容单例调用。 +反过来,你一开始写成模块 + 全局变量 + 函数,那就是个单例,如果你需要多实例,单例不能反过来兼容多实例调用的需求。 + +``` +就好比你设计一个api接口,一个订单下面的商品,是设计成数组还是单个元素? +如果你设计成单个元素,万一以后老板说一个订单能购买多个不同的商品呢?如果你一开始设计成单个元素,原来的api接口设计和代码就无法满足需要大改特改了。 +反之,如果你之前是设计成订单下的商品是一个数组,即使一个订单只能购买一个商品,你数组也能兼容里面只包含一个元素, +而且也能兼容以后一个订单购买多个商品。 + +这说的是可逆和不可逆的区别。 +``` + +例如5.3的代码,你原来只需要小明来调用可以,你后面要小明 小红 小黑都调用,那就全局变量无法隔离,无法满足需求。 + +#### 第二,全局变量在函数里面修改需要麻烦的global声明,否则是生成修改局部变量,oop天然是实例属性,不需要global声明,不存在变量隔离和污染。 + +如5.3代码所示,全局变量在函数里面使用并修改时候,需要麻烦的使用global 声明一下,这正是python设计之初,担心用户随意修改污染全局变量。 + +#### 第三,复杂系统时候,代码量很大,你都写成模块 + 函数,那要分成很多个py文件,类能把一个py文件划分成多个更小模块。 + +如果吧一组相关功能写一个模块,那要分成很多个py文件,py文件太多了。 + +而如果把不相关函数放在一个模块,那就很混乱,不知道哪一组函数是负责a功能的,哪一组函数是负责b功能的。 + +如果写成class类,有代码缩进,通过不同的类名有代码快缩进,就能知道哪些函数是负责什么的,你一个py文件下的100个函数分贝是什么作用能划分更清晰。 + + + +#### 只需要按文档的面向过程转 oop 4步走里面的固定公式,脑子里面打草稿全局变量设计得多多益善 + 全局变量->实例属性,函数->方法 降维转化,就可以设计出强大的代码,无需死记硬背23种设计模式。 From b2dc4fe79158ad815fd7a974304a7447bde3c177 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: 2025年6月20日 11:38:28 +0800 Subject: [PATCH 20/21] --- README.md | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 4e8fa33..8907fd6 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,23 @@ + +# 目录 + +### 0. 介绍文档里面36种设计模式和oop四步走转化公式的文件 + +### 1. 介绍为什么写项目很难下笔,尤其是开发一个框架要抓破脑袋思考设计几天几夜 + +### 2. 网上的oop介绍 + +### 3. 介绍神级别通用固定oop转化公式,写代码下笔时候行云流水(只需学习这套固定面向过程转oop公式,远强于背诵设计模式)。 + +### 4. 网上一些oop介绍 + +### 5. 使用三种代码设计思路写代码模拟人 吃喝拉撒导致身高体重变化。(具体例子,产生强烈对比) + +### 6. 何时需要使用oop + + + + # 0 介绍36种设计模式(包括23种的变种和python独有例如猴子补丁),最最重要是介绍 oop四部转化公式!!! ## 0.1 python的36种设计模式 @@ -57,7 +77,7 @@ ``` -# 2 一些介绍 +# 2 网上的一些oop介绍 学弟啊,你代码能不能不要写得这么烂 https://www.toutiao.com/a6739759206997426696/ @@ -391,7 +411,7 @@ if __name__ == "__main__": 你使用5.1的写法,就是在面向过程一条道走到黑,不光自己实现代码麻烦难扩展维护,更严重的别人调用你封装的公共包还贼恶心贼难用。 -## 5.5 何时需要使用oop +# 6 何时需要使用oop 如何上面用真实代码证明的,何时需要使用oop。 @@ -399,7 +419,7 @@ if __name__ == "__main__": - **不需要多实例** → 用面向过程(模块+函数) -### 5.5.2 如果你还是不确定是否需要多实例,建议全部写成oop类。 +### 6.2 如果你还是不确定是否需要多实例,建议全部写成oop类。 为什么建议不确定是否要多实例时候,全部写成类oop形式? From 3f4f5c567738cee39d05ed5e8ed6ad1d9ee03480 Mon Sep 17 00:00:00 2001 From: "LAPTOP-7V78BBO2\\ydf19" Date: 2025年7月17日 14:16:45 +0800 Subject: [PATCH 21/21] dsd --- README.md | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 77 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 8907fd6..99b2bad 100644 --- a/README.md +++ b/README.md @@ -223,11 +223,15 @@ oop写代码后,类的每个对象的方法访问和修改实例属性,就 写新文件要想破头皮三天三夜才能开始下笔。 ``` -# 5【重要】使用三种代码设计思路写代码模拟人 吃喝拉撒导致身高体重变化。(具体例子,产生强烈对比) +# 5【重要】使用四种代码设计思路写代码模拟人 吃喝拉撒导致身高体重变化。(具体例子,产生强烈对比) **代码体验分为两部分,第一部分是作者自己封装公共代码时候是否爽快容易扩展维护;第二部分是别人调用你封装的公共包是否感觉爽快好用。** -**三个写法思路分别是: 封装痛苦,调用更苦 封装爽快,调用更爽 封装爽快,调用痛苦** +**四个写法思路分别是: +1. 封装痛苦,调用更苦 +2. 封装爽快,调用更爽 +3. 封装爽快,调用痛苦 +4. 封装痛苦,调用更苦,外表唬人** 情不自禁纯粹极端面向过程编程还是c语言中毒了,从来都不使用面向对象,不用提设计模式。 @@ -401,16 +405,84 @@ if __name__ == "__main__": ``` -## 5.4 鼓励面向过程工程师在脑子里打草稿使用5.3的写法,然后使用4步走转化公式,转化成oop写法。 +## 5.4 演示最无能的 废物class类 ,实质是面向过程编程写法 (封装痛苦,调用更苦,外表唬人) + +写了class类,但空有其表,实际上是100%极端面向过程的写法. + +```python +class Person: + """ + 废物类示例:虽然用了class和实例方法,但疯狂传参和return + 完全违背了面向对象的封装原则,空有其表! + """ + + def eat(self, name, height, weight, food_weight): + """吃饭:疯狂传参,还要return一堆变量""" + new_weight = weight + food_weight + new_height = height + food_weight * 0.01 + print(f"{name} 吃了 {food_weight} 千克食物,体重: {new_weight} 千克,身高: {new_height} 厘米") + return name, new_height, new_weight # 疯狂return! + + def pee(self, name, height, weight, pee_weight): + """拉尿:还是疯狂传参和return""" + if pee_weight> weight: + pee_weight = weight + new_weight = weight - pee_weight + print(f"{name} 拉了 {pee_weight} 千克尿,体重: {new_weight} 千克,身高: {height} 厘米") + return name, height, new_weight # 继续疯狂return! + +# 测试代码 - 这种写法简直是灾难! +if __name__ == "__main__": + person = Person() # 创建了实例,但毫无意义 + + # 小明的数据要手动维护 + ming_name = "小明" + ming_height = 170.0 + ming_weight = 60.0 + + # 每次调用都要传一堆参数,还要接收一堆返回值 + ming_name, ming_height, ming_weight = person.eat(ming_name, ming_height, ming_weight, 2.0) + ming_name, ming_height, ming_weight = person.pee(ming_name, ming_height, ming_weight, 0.5) + + print(f"小明最终状态:身高 {ming_height} 厘米,体重 {ming_weight} 千克") + + # 小红的数据也要手动维护 + hong_name = "小红" + hong_height = 160.0 + hong_weight = 50.0 + + # 又是疯狂传参和接收返回值 + hong_name, hong_height, hong_weight = person.eat(hong_name, hong_height, hong_weight, 1.5) + hong_name, hong_height, hong_weight = person.pee(hong_name, hong_height, hong_weight, 0.3) + + print(f"小红最终状态:身高 {hong_height} 厘米,体重 {hong_weight} 千克") + + # 这种写法的问题: + # 1. 虽然用了class,但完全没有封装性 + # 2. 每个方法都要传入所有状态参数 + # 3. 每个方法都要return所有状态变量 + # 4. 调用者需要手动维护所有状态 + # 5. 代码冗余,容易出错 + # 6. 完全违背了面向对象的设计原则 + # 这就是典型的"穿着西装的农民工"! +``` + + +**如果你按照oop四步走转化公式,把核心第0步全局变量多多益善省了,只是按照后三步骤机械的把模块降为类,把函数降为方法,** +**那你就会写出废物滑稽面向过程的类,压根不是真oop,只能吓唬小白说自己是面向对象编程.** + + +## 5.5 鼓励面向过程工程师在脑子里打草稿使用5.3的写法,然后使用4步走转化公式,转化成oop写法。 文章第三章介绍了万能的oop四步走转化公式,你可以在脑子里打草稿使用5.3的写法,然后使用4步走转化公式,转化成oop写法。 -如果你是面向过程工程师,不知道怎么设计oop。 -请你一定要按照5.3的 模块 + 全局变量多多益善 + 函数 实现代码思路,然后套用oop四步走转化公式。 +如果你是面向过程工程师,不知道怎么设计oop。 +请你一定要按照5.3的 模块 + 全局变量多多益善 + 函数 实现代码思路,然后套用oop四步走转化公式。 千万不要再使用5.1的 模块 + 无全局变量 + 多个函数之间频繁传一堆参数 + 每个函数末尾风控return一大堆变量 的写法。 你使用5.1的写法,就是在面向过程一条道走到黑,不光自己实现代码麻烦难扩展维护,更严重的别人调用你封装的公共包还贼恶心贼难用。 + # 6 何时需要使用oop 如何上面用真实代码证明的,何时需要使用oop。

AltStyle によって変換されたページ (->オリジナル) /