13
votes

I've always programmed in procedural languages and currently I'm moving towards object orientation. The main problem I've faced is that I can't see a way to practice object orientation in an effective way. I'll explain my point. When I've learned PHP and C it was pretty easy to practice: it was just matter of choosing something and thinking about an algorithm for that thing.

In PHP for example, it was matter os sitting down and thinking: "well, just to practice, let me build one application with an administration area where people can add products". This was pretty easy, it was matter of thinking of an algorithm to register some user, to login the user, and to add the products. Combining these with PHP features, it was a good way to practice.

Now, in object orientation we have lots of additional things. It's not just a matter of thinking about an algorithm, but analysing requirements deeper, writing use cases, figuring out class diagrams, properties and methods, setting up dependency injection and lots of things.

The main point is that in the way I've been learning object orientation it seems that a good design is crucial, while in procedural languages one vague idea was enough. I'm not saying that in procedural languages we can write good software without design, just that for sake of practicing it is feasible, while in object orientation it seems not feasible to go without a good design, even for practicing.

This seems to be a problem, because if each time I'm going to practice I need to figure out tons of requirements, use cases and so on, it seems to become not a good way to become better at object orientation, because this requires me to have one whole idea for an app everytime I'm going to practice.

Because of that, what's a good way to practice object orientation?

closed as primarily opinion-based by gnat, GlenH7, user40980, Kilian Foth, Bart van Ingen Schenau Nov 5 '13 at 10:50

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

locked by Thomas Owens Nov 3 '17 at 10:28

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Read more about locked posts here.

  • 1
    During my university early years, a great introduction to OOP was the book "Thinking in Java" by Bruce Eckel. It was the recommended read both for programming newbies and for people coming from procedural development backgrounds - maybe it will help you. – Ivaylo Slavov Nov 4 '13 at 14:43
  • 3
    PHP is object-oriented; you just haven't been using it. php.net/manual/en/language.oop5.php – Robert Harvey Nov 4 '13 at 16:09
  • You could just implement the same app again using an OOP approach. After all, it is just a tool. The recommendation from below to have a GOF book and try to re-think your existing procedural code in an object-oriented manner may also be a good practice. – JensG Nov 4 '13 at 18:21
  • Make small games (without graphics), card games or similar at start, try to reuse classes in those games. stackoverflow.com/questions/1301606/… – grizwako Nov 5 '13 at 10:56
20
votes

Now, in object orientation we have lots of additional things.

No you don't...

It's not just a matter of thinking about an algorithm, but analysing requirements deeper, writing use cases, figuring out class diagrams, properties and methods, setting up dependency injection and lots of things.

None of those things are necessary for practicing object oriented programming.

This was pretty easy, it was matter of thinking of an algorithm to register some user, to login the user, and to add the products.

All object oriented programming is instead of thinking of the algorithms to do these steps, you think about what objects are needed to do these steps - what functionality you want, what state is needed to do that, and what sort of interface you want to expose to the user. Just like you have to do in procedural programming.

The only difference is that instead of focusing on the functions you need and how they work, you focus on how the functionality and state is grouped into responsibilities, and how those responsibilities interact.

How to practice? The same way you practice procedural programming: pick a problem and solve the problem using bundles of classes. Figure out how that sucked, repeat with lessons learned.

  • 3
    +1 "Figure out how that sucked" That's how I code: Filled with shame and self loathing... always fighting to learn from previous projects. – WernerCD Nov 4 '13 at 20:54
  • 1
    I like the approach. Instead of over-complicating and trying to learn everything at once, start with smaller steps and iterate applying all the knowledge you gain. – superM Nov 5 '13 at 7:39
6
votes

Good question. Of course, what you are saying is that practicing OOP actually means practicing all of these things (requirements analysis, use cases, design patterns, etc.), which is true and may seem daunting at first.

My advice would be start your practice sessions by keeping two things in mind: test-driven development and the single responsibility principle.

Then just start off like you did with PHP/C: come up with an idea, think about what you need for that and implement these things one after the other. However, keep in mind, that you need to start from the tests (which forces you to define proper interfaces, as otherwise testability immediately suffers) and that TDD implies a red-green-refactor cycle. In other words, you have a tiny little bit of functionality, and once it's working you refactor to get a proper OO-design if you didn't make it from the start (which you won't).

When doing this refactoring step always remind yourself of the SRP. If you added a second responsibility to your object it's time to create something new.

When you develop like this, you need to be aware that your final solution will be far different from what you start with. Your learning curve will also be rather steep. For example, you will not learn what a Factory pattern is, but instead you will recognize the need for something that creates instances of your class in different ways. So if you haven't heard of object-oriented design patterns at all, it's good to read up a bit on those in parallel.

  • 1
    So basically you're saying "learn TDD and GOF" – Robert Harvey Nov 4 '13 at 16:07
3
votes

If you're just starting in OOP, you can amuse yourself and "practice" offline by looking at just about any real-world system and considering what the objects are and what the relation between them is and what methods/interfaces they might support and how you'd represent them in a class hierarchy and as a collection of instantiated objects and what the object ownership relations would be and so on (note: I don't mention the word "algorithms" in the above at all). Draw lots of diagrams (learn a bit of UML or similar) before you think about coding anything.

This will help you develop a much better sense of IS-A and HAS-A relations, which is probably the single most important classification in any OOP design (and despite that, it still seems to be something which many seasoned OOP language programmers struggle with). If you master IS-A/HAS-A there's also IS-IMPLEMENTED-IN-TERMS-OF (which I've also seen described as IS-KIND-OF-A :^)

Seriously, next trip to the supermarket, just imagine someone has given you the job of writing a OOP simulation of the place...

  • If you're writing software to help biologists track radio tagged tigers, the fact that a tiger is-a animal and has-a stripes doesn't matter and won't be reflected in the software. But if you think about a tiger in the abstract and in terms of is-a and has-a, that's what you get. – Michael Shaw Nov 4 '13 at 22:10
  • 1
    But that's why I'm suggesting this sort of exercise, because it would should quickly become apparent that tigers and stripes are irrelevant to a good solution, whereas things like whether a tracked coordinate originates with (guessing) GPS, inertial nagivation or radio triangulation might be the sort of thing a tracker OOP design should be capturing. When I say "look at a real world system" I do mean looking beyond the purely physical attributes. e.g the supermarket simulation would surely need to include more abstract concepts like "queues", not just the obvious "carts" and "shoppers". – timday Nov 9 '13 at 15:34
1
vote

What I remember from my C times (far far back in the past), we used to separate functions and procedures to different files based on their responsibility. I am not claiming that is perfect or anything, but it was a good starting point for when I actually started to program in object oriented languages. So maybe, you could start with converting files to objects.

As far as OOP goes, it is really all about practice and striving for improvement. Rarely anyone gets it right from the ground up. Thus, iterations happen throughout project's life-cycle.

0
votes

Let's add some terminology, object-oriented analysis and object-oriented design, as Peter Coad did in the 1990's.

Together these form a software engineering discipline OOAD that can (done right) support the programmer at the point of writing and testing code. Object-oriented programming can then have its proper level of granularity, skillful use of programming language features to meet the functional objectives and design requirements specified at a project level.

Sometimes it's a one-person project, and then you must wear all the hats (but not necessarily all at the same time). I'm a huge fan of test-driven development for my own personal projects (see Frank's recommendation), but it doesn't pertain only to object-oriented software development.

In a team project having a good division of responsibilities is a key to successful implementation. Skillful use of object-oriented design patterns helps team understanding by limiting the visible interfaces needed for analysis, data-feeds, and business logic to share a usable framework.

0
votes

"well, just to practice, let me build one application with an administration area where people can add products". This was pretty easy, it was matter of thinking of an algorithm to register some user, to login the user, and to add the products.

Why not do the same thing only this time with user objects and product objects? Also if you are using a language that supports both procedural and OO then you could try to implement objects based on the procedural standard library, like a file object.

Not the answer you're looking for? Browse other questions tagged or ask your own question.