摆脱程序思维 [英] Getting out of a procedural mindset

问题描述

在大学学习计算毕业后，我已经在编程（作为工作）约3-4个月。

I have been programming (as a job) for around 3-4 months now after having graduated from university studying computing.

在大学，我被教导面向对象编程我觉得我很好的掌握了这一点，直到我开始处理真正的问题。

At university I was taught object orientated programming and I felt I had a good grasp on this until I started working on real problems.

我只是似乎无法做任何事情，但提出了解决方案的程序代码 - 尽管我正在使用类和基本的oop技术，代码基本上是程序化的，我知道有更好的解决方案，但我似乎无法匹配我想要做的模式等。

I just cant seem to do anything but come up with procedural code for solutions - although i am using classes and basic oop techniques the code is essentially procedural inside and I know there are better solutions but i just cant seem to match patterns etc up with what i am trying to do.

在使用oop技术真正开始编程之前，需要多长时间/多的练习，而不仅仅是使用充满程序代码的课程。

How long / much practice does it take before you can really start programming properly using oop techniques - as opposed to just using classes filled with procedural code.

另外有没有什么建议可以正确地解决问题的方式真正进步？

Also, are there any advice on how to really progress with being able to design solutions to problems properly?

推荐答案

我认为只需要很多练习。

I think it just takes a lot of practice.

这里有人说： OOP正在建模真实世界的对象。但是，这正是他们通常在学校告诉你的事情，而且从OP中可以明白，真的没有那么有用。

Some people here say: OOP is modelling real world objects. But that's what they usually tell you at school too, and as I understand from the OP, it really hasn't been that helpful.

当我看看我的代码看到它与绝对没有真实世界表征的各种对象不堪重负：数据库映射器，对象工厂，表达式构建器等。它们可能听起来像真实世界的对象，但它们真的不像。他们只是抽象，帮助我们管理整个程序的复杂性。

When I look at my code I see it overwhelmed with all kinds of objects that have absolutely no real world representations: database mappers, object factories, expression builders, etc. They might sound like real world objects, but they are really nothing like. They are just abstractions that help us to manage the whole complexity of the program.

我认为OOP的主要困难在于这一点。你不能只看你的问题领域，例如处理汽车，说：我知道，我需要一个汽车类！即使你需要一个汽车课，这个知识并不能帮助你决定真正把它放在哪里。显然，你不能把所有十万个功能处理汽车里面的一个类。那么你如何管理呢？怎么切片？汽车班应该负责什么？谁也应该知道汽车班？这些都是难以解决的问题，但是程序本身的作者本人都无法真正回答。即使是最有经验的人也很少在第一时间回答所有的问题。

I think the main hard part of OOP is exactly that. You can't just look at your problem domain, which for example deals with cars and say: I know, I need a Car class! Even if you do need a Car class, this knowledge doesn't help you decide what to really put inside it. Obviously you can't just put all the hundred thousand features that deal with cars inside that one class. So how do you manage it? How do slice it up? What should be the responsibility of the Car class? Who should also know about Car class? These are the hard questions for which no-one but the author of the program himself can really answer. And even the most experienced ones rarely answer all the questions right at the first time.

但是我猜想有一些一般的好的OOP原则要遵循。保持对象之间的耦合尽可能低。按照违反法律。 SOLID 原则很好记住。但最重要的是：一直保留 DRY 。

But I guess there are some general good OOP principles to follow. Keep the coupling between objects as low as possible. Follow the law of demeter. The SOLID principles are good keep in mind. But most importantly: keep it DRY all the way.

另外：不要将自己限于面向对象的方法。学习功能编程，正则表达式，编译器构建，汇编语言，以及可以管理的许多不同的更高级别的语言 - 仅仅了解OOP不会使你成为一个好的程序员，而是研究所有不同的方法和工具将允许您可以以更加鲜明的观点来看OOP，从而更深入地了解这个OOP的真实情况。

Additionally: Don't limit yourself to object-oriented approach. Study functional programming, regular expressions, compiler construction, assembly language, and a as many different higher level languages as you can manage - knowing OOP alone isn't going to make you a good programmer, but studing all those different approaches and tools will allow you to look OOP at more distinct perspectives, allowing deeper understanding of what this OOP-thing really is about.

这篇关于摆脱程序思维的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！