Getting out of a procedural mindset

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.

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 kno开发者_高级运维w there are better solutions but i just cant seem to match patterns etc up with what i am trying to do.

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.

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.

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.

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.

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.

Procedural is not objectively worse than object oriented design, but its a handy tool. the core way of getting OOP to work well is to think of your program as modeling the interaction of real world objects, each real world object is modeled by a programmatic object, and each interaction between those objects is a method.

But if that's not enough to get you rolling, maybe what you need is some more tools under your belt to work with. A widely reccomended source is the GOF book, which describes, in great detail, a number of ways to construct programs, with an emphasis on OOP. A word of caution, though, be sure any pattern you apply is well suited to the problem, as it will cause you and your collegues endless headaches if you apply them haphazardly.

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.

Don't despair, its totally normal at the beginning. Be careful with what you do when addressing it, make sure you only apply patterns to solve actual problems you see in the code. Code should be simple, you may have a scenario that doesn't call for any advanced technique. Whatever you learn try to keep in mind that what you want is to introduce simple elements that do give you advantages without ending with a bunch of unnecessary code / patterns.

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.

Depends in what you mean with properly. You may learn to apply specific approaches very early, and even achieve some very cools things, but imho to really master it takes years. I just think there are pieces of the puzzle that take a good time to really sink in.

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

I strongly recommend reading these 2 "ebooks" S.O.L.I.D. principles and 31 Days of Refactoring. The one on SOLID is very good in the design aspects of the code, specially in an agile environment. The one on refactoring helps you on identifying improvement opportunities in your existing code.

I think that in your case, you should start code the way you can, even procedural. Once finished, and the code works, study it and see how you can break it into modules. Find common functionality that should be placed in object's method. At the same time, try to see how you can refactor your code to fit a pattern you read. In time, you will undestand what you did wrong in your design and improve yourself

Looking at Numerical Recipes in C you will experience procedural programming. Function calls with endless parameter lists, program flow control spread over many procedures. Take a simple algorithm like 'Runke-Kutta' and port it to an OOP language of your choice. Encapsulation and message passing is a complete different mindset.

OOP is modeling, as TokenMacGuy already said, "the interaction of real world objects". Whereas procedural programming focuses more on 'algorithms'.

One step in learning OOP is the ability to transform/model real world objects into class properties and methods. Books like Effective Java, Implementation Patterns, GoF help you choosing best practices while putting real world objects into code.

In addition to @TokenMacGuy's response, there is a useful guideline to adopt when designing classes - they should know how not know what. For example, in a system that uses position for some purpose classes should know how to find out their position rather than store it and record it. While not a panacea, it is very useful to bear in mind, as it helps set your mind in an appropriate direction.

Implement COM objects in C and you'll understand the difference between OOP and procedural...

By the way, studying object models (COM for instance, but this is so 1995...) is a good way to grasp the superiority of OOP as to modularity. Take your favorite huge library (Qt is a good start if you're into C++ or python), and read docs, write small programs.