OOP to soon?

Started by
6 comments, last by NoobProger 16 years, 6 months ago
Ok so I've been learning C++ for afew months now, and I'm pretty bad at remembering the syntax of the language, but I remember the how everything works. I understand... data types, functions, refs, pointers... and when I step'd into the wonderful world of classes I got it at first... but the book quickly moved onto more indetailed subjects about OOP... and I feel like I'm lost at some points... once the book explains the syntax in full detail I understand it.. I've been reading about OOP now for about 2 weeks, and I feel I can't even remember how to program regular things (to program without the use of classes, just functions with refs and pointers...) should I back off the reading throttle, and let my mind take everything in, or push forward and keep learning about classes, inheritance, and polymorphism? I can make functions... or methods I guess they are called in classes rather easy... I understand private and public... and attributes as well... but I can't hang onto the syntax for anything, its annoying to refer back to a book over and over again when I'm trying to make something rather simple. Either way just figure'd I would vent about how I should of maybe went with C# first... Just joking I'm happy with C++, just wondering what some of you vets did when learning... Thanks in advance. BTW - reading "Beginning C++ Game Programming" - Michael Dawson. Its my second book in C++ - the first was a quick start primer book.
09/03/07 - "I was feeling abit okward when I made the switch statement, like I was using a wrench to drive a nail into the deck, when I have a nice hammer right beside me... "
Advertisement
EDIT: I AM NOWHERE NEAR A VET, but I could tell you about my own experience.

Hello,

Are you actually making simple programs on your own, or even typing the source from the book? I believe that would actually help you learn the syntax a lot better if you actually start coding and not just reading the code, because any one can do that. Also, it don't help you out in the long run. For example, if you was taking a math class would you just read how to do something and expect to actually understand how to do it. No. You would actually attempt to do it problems your self to see that you understand. As for OOP. [opinion] I believe OOP is a really good topic to actually learn. [/opinion] I actually had problems when I was first learning OOP. It was really hard for me to imagine things as objects, and how to approach those things. I actually had prefered procedural programming because I couldn't understand OOP. Then I decided to pick up C# and I actually learned how to do OOP. It came a lot easier in C#, then in C++ for me. Maybe its the same for everyone, or just for a few. Now I would actually tell you I like both a lot. I would more do a mixed approach when coding with C++, but in C# you are bound to do a OOP approach.

~Carl J. Loucius
You should try things out as you learn them. Your book probably has some exercises at the end of each chapter, be sure to do some of those, and write a few other small programs too, to get some practical experience with the stuff you're reading about. But that's nothing specific to OOP or anything else. It's just a general rule when learning programming. You don't understand it until you've used it. And you shouldn't read on until you understand the previous chapters.
Well OOP is also difficult to understand in smaller programs, or tidbits of code.

When you create larger programs you start to notice where OOP is useful.
Quote:Original post by dillscon
Well OOP is also difficult to understand in smaller programs, or tidbits of code.

When you create larger programs you start to notice where OOP is useful.


I would disagree.

As an exercise original poster, and to let things sink in a bit - I would suggest making a Rock, Scissors, Paper, Stone game in anyway you feel comfortable with. Then try and identify what might be objects in the system, what data they would have and their responsibilities within that system. You can do that scribbling on a bit of paper.

Then *refactor* your existing code in to an object model. Refactoring is a large part of professional development. It's the nature of software... requirements change and developing in a way that allows change to be relatively painless is a key skill.

If your functions in your original design are well written, you should be able to easily factor them in to objects once you decide what each concept is and it's responsibilty.

I've [google]'ed "crc cards" for you, and found you this tutorial. It might be useful to you: http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/
Anything posted is personal opinion which does not in anyway reflect or represent my employer. Any code and opinion is expressed “as is” and used at your own risk – it does not constitute a legal relationship of any kind.
Check this out:

http://www.fafiles.com/cpp_index.php

It has some video tutorials in C++. In the last lesson you are given an example of a class, I found it really useful.

Edit: proper linkification, using the standard <a href=""></a> tags - Emmanuel

[Edited by - Emmanuel Deloget on October 18, 2007 10:41:03 AM]
Quote:Original post by paulecoyote
Quote:Original post by dillscon
Well OOP is also difficult to understand in smaller programs, or tidbits of code.

When you create larger programs you start to notice where OOP is useful.


I would disagree.



I dont mean that OOP isnt useful on a smaller scale...I've found that its more simple to understand on a larger scale, and by large I dont mean too large either.

For me OOP made no sense at all if it was in the context of some simple Hello World program. But everyone catches on to things in their own way.

I've learned from the get-go that you've got to practice what you've learned, and I do so - I complete all 3 off the question/exercises at the end of the chapters... and from time to time I sit down and have a rather randomized session of coding (I'll make a calculator... a program that takes/stores/saves a list of entered data to a .txt file, text based RPG's...(very short ones.) - all the things that simply let me apply what I've learned.) Maybe the problem is that in turn the book is not detailed enough in C++, and that it has a rough over-view of how to program in relation to GAMES, and simply not enough information for me to learn to program C++ in general... this is only my second book on C++, the first which was small also (in detail) I thought it would be more important to try to grasp the concepts of programming at first rather then the syntax...

I'll give that rock - paper - scissors game a go and see how things turn out.

Thanks for the tutorials and links - I'll be checking them out guys.
09/03/07 - "I was feeling abit okward when I made the switch statement, like I was using a wrench to drive a nail into the deck, when I have a nice hammer right beside me... "

This topic is closed to new replies.

Advertisement