对 OOP 和过程编程做出这样的肯定是正确的吗？
Is it correct to make this affirmations about OOP and Procedural Programming?
我不得不在这里做一个真假作业，我对我一直在读的这三件事有疑问，但我读得越多，我就越困惑。这是我的结论希望你能帮助我更好地理解。
1) "Object-oriented design is hard because object-oriented technologies are tied close to peoples mental models"。我发现这是真的，因为 OOP 是人类看待问题及其解决方案的一种方式。
2) "in object-oriented programming a complex system is decomposed into a hierarchy of collaborating objects"。我说这是真的，但我有疑问，因为我不确定说协作是否正确 "objects" 我觉得它应该是组件或不同的东西但同时我明白在 OOP 对象中class 与另一个 class 的对象协作。
3) 最后 "procedural programs are easier to design than object-oriented programs" 我说的是真的，但我不确定为什么我读到的是在程序中程序员写的就像历史一样，他只是继续编写解决方案而不是'为了制作它的完整模型，他使用了一种叫做 "top-down" 的东西，是的，这就是我发现的，程序更容易设计但更难进行更改，而 OOP 更难设计但更容易进行更改。
1)
我认为你的理由是说 OOP 不难的理由。
2)
对我来说 "components" 是软件（非常具体的术语定义）。
每个组件定义一个或多个（甚至可能为零）类 个对象。对象是 类 的实例。真正协作的是对象，其行为由它们的 类 定义，这些对象在组件中编码。
3)
如果您的编程思维是 "I want to have this happen"，则设计过程式程序可能比 OOP 程序更容易（与 1) 形成对比）。如果能把人类的思维模型放到设计中，再放到代码中，OOP就容易多了。
很难说，但我会愤世嫉俗地回答 "No"，只是因为任何教授 OOP 并为其进行考试的人可能会花费一年的时间告诉您 OOP 在各个方面都更好。 （请原谅老师夸大其词，讲得越好，当然教的越平衡。）
1)面向对象设计并不难。只是，您应该首先学习过程式编程，因为它的局限性是可见的。除非学生学习过程式编程，否则 OOP 对学生来说似乎用处不大。
2) 在OOP中，Aclass是为特定的目标而设计的。其目的必须让用户清楚。如果需要多个 class 实例，则解决问题的实体被归类为 class。此外，将责任委托给一个对象是非常重要的。简单呈现读取数据等行为
在 class 中显示数据是 class 的糟糕设计。要执行复杂的任务，一个 class 必须与其他 class 共同协作来执行任务。这种方法被称为 classes 之间的协作。这
class 必须设计有基本属性和行为以反映现实世界中的想法。
3) 最后，是的，从某种意义上说，过程编程是一种自上而下的方法，而 OOP 是一种从解决方案开始的自下而上的方法。如果存在现有解决方案，则首先研究该解决方案，并以适当的方式识别和组织必要的细节。对于没有解决方案的问题，领域专家（即能够提供有用信息和未来的专家）
要求）与常规解决方案一起开始咨询。由于软件是通过首先分析解决方案来开发的，因此这种方法被称为自下而上的方法
我不得不在这里做一个真假作业，我对我一直在读的这三件事有疑问，但我读得越多，我就越困惑。这是我的结论希望你能帮助我更好地理解。
1) "Object-oriented design is hard because object-oriented technologies are tied close to peoples mental models"。我发现这是真的，因为 OOP 是人类看待问题及其解决方案的一种方式。
2) "in object-oriented programming a complex system is decomposed into a hierarchy of collaborating objects"。我说这是真的，但我有疑问，因为我不确定说协作是否正确 "objects" 我觉得它应该是组件或不同的东西但同时我明白在 OOP 对象中class 与另一个 class 的对象协作。
3) 最后 "procedural programs are easier to design than object-oriented programs" 我说的是真的，但我不确定为什么我读到的是在程序中程序员写的就像历史一样，他只是继续编写解决方案而不是'为了制作它的完整模型，他使用了一种叫做 "top-down" 的东西，是的，这就是我发现的，程序更容易设计但更难进行更改，而 OOP 更难设计但更容易进行更改。
1) 我认为你的理由是说 OOP 不难的理由。
2)
对我来说 "components" 是软件（非常具体的术语定义）。
每个组件定义一个或多个（甚至可能为零）类 个对象。对象是 类 的实例。真正协作的是对象，其行为由它们的 类 定义，这些对象在组件中编码。
3)
如果您的编程思维是 "I want to have this happen"，则设计过程式程序可能比 OOP 程序更容易（与 1) 形成对比）。如果能把人类的思维模型放到设计中，再放到代码中，OOP就容易多了。
很难说，但我会愤世嫉俗地回答 "No"，只是因为任何教授 OOP 并为其进行考试的人可能会花费一年的时间告诉您 OOP 在各个方面都更好。 （请原谅老师夸大其词，讲得越好，当然教的越平衡。）
1)面向对象设计并不难。只是，您应该首先学习过程式编程，因为它的局限性是可见的。除非学生学习过程式编程，否则 OOP 对学生来说似乎用处不大。
2) 在OOP中，Aclass是为特定的目标而设计的。其目的必须让用户清楚。如果需要多个 class 实例，则解决问题的实体被归类为 class。此外，将责任委托给一个对象是非常重要的。简单呈现读取数据等行为 在 class 中显示数据是 class 的糟糕设计。要执行复杂的任务，一个 class 必须与其他 class 共同协作来执行任务。这种方法被称为 classes 之间的协作。这 class 必须设计有基本属性和行为以反映现实世界中的想法。
3) 最后，是的，从某种意义上说，过程编程是一种自上而下的方法，而 OOP 是一种从解决方案开始的自下而上的方法。如果存在现有解决方案，则首先研究该解决方案，并以适当的方式识别和组织必要的细节。对于没有解决方案的问题，领域专家（即能够提供有用信息和未来的专家） 要求）与常规解决方案一起开始咨询。由于软件是通过首先分析解决方案来开发的，因此这种方法被称为自下而上的方法