问题描述
我最近正在尝试进入OOP，但是遇到 SOLID 原理和设计模式.我明白了人们为什么使用它们，我也确实想使用它们，但是我不能全神贯注地按照规范开发类.我真的很感激能够帮助我理解这一点的一切.
I'm trying to get into OOP lately, and I'm having trouble with SOLID principles and design patterns. I see why people use them, and I really want to use them too, but I can't wrap my head around developing my classes to the specifications. I would really appreciate anything that would help my understanding of such.
推荐答案
我在大学上过一堂关于设计模式的课程，花了两个星期，然后阅读了《四人帮》 这本书无济于事.对于一个在OO编程方面没有太多经验的开发人员来说，很难理解每种模式的作用以及如何使用它们来解决我的问题.
I've taken a class in college that spent two weeks around design patters, and read the Gang of Four book to no avail. Understanding what each pattern served for and how to use them to fit my problems was very hard for me, a developer that didn't have much experience in OO programming.
真正让我点击的书是 Head First设计模式 .它首先显示了一个问题，开发人员考虑了不同的方法，然后他们最终如何使用设计模式进行修复.它使用一种非常简单的语言，使本书非常吸引人.
The book that really made it click for me was Head First Design Patterns. It starts by showing a problem, different approaches the developers considered, and then how they ended up using a design pattern in order to fix it. It uses a very simple language and keeps the book very engaging.
设计模式最终成为描述解决方案的一种方式，但是您没有使类适应该解决方案.可以将它们更多地作为指导，为解决各种问题提供良好的解决方案.
Design patterns end up being a way to describe a solution, but you don't have to adapt your classes to the solution. Think of them more as a guide that suggest a good solution to a wide array of problems.
让我们谈谈SOLID:
Let's talk about SOLID:
- 单一责任.一堂课只有一个责任.这意味着，例如，Person类仅应担心与人员本身有关的域问题，而不必担心其在数据库中的持久性.为此，您可能想要使用例如PersonDAO.人员类可能希望尽其所能尽其所能.如果一个类使用了太多的外部依赖项(即其他类)，则表明该类承担了太多的责任.当开发人员尝试使用对象对现实世界建模时，这个问题通常会出现，并且过分深入.松耦合的应用程序通常不太容易导航，并且无法准确地模拟现实世界的工作方式.
- 打开已关闭.类应该是可扩展的，但不能修改.这意味着将新字段添加到类中很好，但是更改现有内容则不行.程序上的其他组件可能取决于所述字段.
- 利斯科夫换人.如果传递了子类dog和子类cat，则期望动物类型的对象的类将起作用.例如，这意味着Animal不应具有称为bark的方法，因为cat类型的子类将无法吠叫.使用Animal类的类也不应依赖于属于Dog类的方法.请勿执行如果这种动物是狗，那么(将动物铸造成狗)吠叫.如果动物是猫，那么(将动物铸造成猫)喵叫".
- 接口隔离原则.保持界面最小.也是学生的老师应该同时实现IStudent和ITeacher接口，而不是一个名为IStudentAndTeacher的大型接口.
- 依赖倒置原则.对象不应实例化其依赖关系，而应将其传递给它们.例如，内部具有Engine对象的Car不应执行engine = new DieselEngine()，而应将所述引擎传递给构造函数.这样，汽车类将不会与DieselEngine类耦合.
- Single responsibility. A class should have only one responsibility. That means that for example, a Person class should only worry about the domain problem regarding the person itself, and not for example, its persistence in the database. For that, you may want to use a PersonDAO for example. A Person class may want to keep its responsibilities the shortest it can. If a class is using too many external dependencies (that is, other classes), that's a symptom that the class is having too many responsibilities. This problem often comes when developers try to model the real world using objects and take it too far. Loosely coupled applications often are not very easy to navigate and do not exactly model how the real world works.
- Open Closed. Classes should be extendible, but not modifiable. That means that adding a new field to a class is fine, but changing existing things are not. Other components on the program may depend on said field.
- Liskov substitution. A class that expects an object of type animal should work if a subclass dog and a subclass cat are passed. That means that Animal should NOT have a method called bark for example, since subclasses of type cat won't be able to bark. Classes that use the Animal class, also shouldn't depend on methods that belong to a class Dog. Don't do things like "If this animal is a dog, then (casts animal to dog) bark. If animal is a cat then (casts animal to cat) meow".
- Interface segregation principle. Keep your interfaces the smallest you can. A teacher that also is a student should implement both the IStudent and ITeacher interfaces, instead of a single big interface called IStudentAndTeacher.
- Dependency inversion principle. Objects should not instantiate their dependencies, but they should be passed to them. For example, a Car that has an Engine object inside should not do engine = new DieselEngine(), but rather said engine should be passed to it on the constructor. This way the car class will not be coupled to the DieselEngine class.
这篇关于似乎无法理解SOLID原理和设计模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！