tags:

views:

606

answers:

13

HI all. I have started a new job recently where I am supposed to work with C++/ I have been doing programming in C language for past 5 years. I am looking for ways to get me up to an acceptable level in OOP. I have all the basic concepts of C++ and OOP but don't have much experience of actual class designing. What I really am looking for is ways to learn class library designing as I will be working in a team who is writing C++ libraries for other programmers to use. Please suggest principles like "responsibility assignment" which can help me design classes in general.

+1  A: 

This post can help Learning OOP

ArsenMkrt
+12  A: 

Give a loook to Bob Martin SOLID principles:

  • SRP The Single Responsibility Principle: A class should have one, and only one, reason to change.
  • OCP The Open Closed Principle: You should be able to extend a classes behavior, without modifying it.
  • LSP The Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
  • ISP The Interface Segregation Principle: Make fine grained interfaces that are client specific.
  • DIP The Dependency Inversion Principle: Depend on abstractions, not on concretions.
philippe
Beware of catchy names and abbreviations. Each of those principles takes a huge article or chapter to explain, including lots of exceptions, "it doesn't really mean that"'s and "not to be followed blindly"'s. Throwing around "SOLID" is misleading at best.
ima
Exactly the sort of thing I was looking for. Thanks.
6pack kid
holy crap, its an acronym of acronyms
TM
Also, whatever happens, get "Effective C++" by Scott Meyers. You aren't a C++ programmer unless you have read it, it's so very important.
Mike Weller
+11  A: 

I know this isn't the type of answer you've been looking for; it's more like a extension of the other answers (already done and yet to come). I thought I'd add some general stuff...

  • Write one class declaration per .hpp file, one class definition per .cpp file. Name files like the class they contain. (It's surprising and frustrating to find how much code doesn't get this basic rule right.)
  • Be aware that C++ is a multi-paradigm language. Some things are better solved without a class hierachy. (Some things call for templates, some things are best done in good old procedural style.)
  • Learn about the Boost libraries, and how they do things. They're a good showcase of well-done C++, especially on the user interface side. And they are useful in your everyday work, too.
  • Read "Effective C++", "More Effective C++" and "Effective STL" by Scott Meyers. If in doubt, just get the first, and you'll find out why you should read the other two yourself.

Couldn't resist giving these basics, seeing a newcomer to the language that actually asks for advice before getting into lots of bad habits. ;-)

DevSolar
+1 Read "Effective C++", "More Effective C++" and "Effective STL" by Scott Meyers ... go through these, try examples and make sure you understand, start with the first one. It's not complicated but gives you solid background in what c++ is all about
stefanB
I have been trying to make up source code examples [ http://github.com/ardsrk/Effective-CPP-Programs ] for each Item in Effective C++ with the intention to help me better understand the advice given in each item and also in the hope that it may be useful to guys like you.
ardsrk
As far as #2 goes, I consider a deep inheritance hierarchy in C++ to be a bad smell. It usually means you're doing more inheritance and less composition than is ideal.
David Thornley
+1  A: 

The SOLID principles are good guides, but don't forget that you have to have concrete use cases if you are going to be able to do good OOD. If you are designing a class (for other programmers) to inherit from, you need at least three concrete (and as different/realistic as possible) cases where you actually inherit from the class, or you will not be able to see how the classes should work.

JesperE
+3  A: 

I still like Bjarne Stroustrup's book. It has several chapters devoted to design and it's also a great language reference. It can be pretty dense reading at times, but it's worth the effort.

I found C++ to be a great tool, but only after I really learned how to use it. Read all the references suggested here by others, and there's no substitute for practice!

Steve K
Which book? Granted that I haven't gotten very far in "Programming: Principles and Practices using C++", I'm impressed by what I've seen. "The C++ Programming Language" is an excellent book about the language, but I don't think as well-suited for learning it.
David Thornley
"The C++ Programming Language" is the one I refer to. I agree, it's not the first book to grab when starting off. It was my first C++ textbook in college and I hated it then. But after I got a handle on the basics, I really appreciated its treatment of the finer details.
Steve K
+1  A: 

Try designing everything in UML before you code using proper sequence of diagrams down to class and sequence. Despite all (rightly) criticisms of UML, it will force you to treat program as a system of interacting objects and not sequence of code.

Most of "principles of OOP" are easily reduced to absurdity if you try to design program following them exactly. Refactoring is another story.

Otherwise, make sure you really know C++ and STL. Good or bad, STL is what is expected in C++ code.

ima
I'm not sure that "everything through UML first" is that good an idea. C++ is not purely OOP (templates!), and if you pipe everything and the kitchen sink through UML first you lose quite some of the expressiveness of C++.
DevSolar
No argument here, I don't use strict UML much myself. But for someone who moves from C and mostly worried about OO aspects of C++ I believe UML is a necessary experience.
ima
A: 

I recently started working with C++ too, and this is what I did: First, I got the book C++ In Action from a coworker, and went through its 'Language' part, doing all the exercises. The 'Techniques' chapter is also an important one.

Then, the thing that helped me the most, I think, is reading a lot of my team's already written code and trying to understand the reason for everything in it. If your team members know how to code well, this is quite educating. And anyway, it definitely helps you understand the purpose and methods of your project, and what's expected of you.

Reading part the project's code might be something you'd have to do anyway, I believe (in order to use library functions, implement similar functions, or add to existing code), but sometimes people skip that part or do it very superficially.

Daniel Hershcovich
+1  A: 

Designing C++ class hierarchies for others to use is a minefield. I would highly recommend reading up on some of the common pitfalls in class design. Two books I suggest:

  • C++ Coding Standards (Herb Sutter & Andrei Alexandrescu). Packed full of concrete examples of how to create proper classes in an easy to understand way.
  • Effective C++ (Scott Mayers). How to write correct C++, starting from the transition from C to C++. A classic.
mikelong
+1  A: 

Refer this link. This pdf consists of "Design Principles and Design Patterns" http://www.objectmentor.com/resources/articles/Principles%5Fand%5FPatterns.pdf

The above link will help u a lot.

Abhi
+1  A: 

Depending on how STL oriented your new job is, you'll either get praised, or shot, for reading: Modern C++ Design by Alexandrescu.

Even if you don't use any of the patterns in it, it will open a new world of C++ to you.

I'd put that book second on your reading list, after some Meyers books. Alexandrescu is pretty... intense.

RyanWilcox
+1  A: 

It takes a few years to become proficient in C++. The books that have been suggested will help. I also suggest that you read Herb Sutter's Exceptional C++ series.

For the short term, you should find a C++ mentor to help you get up to speed in the new company. Each company has its own "culture" around C++. Dos and don'ts. This may be more relevant to your job than what you read. For example, your company may not use STL, so learning it may turn out be just an academic exercise. Many companies practice "Cargo Cult" programming - in this case, avoiding powerful but scary features of the language - so you may find you're frustrated that you can't use what you learn from the books.

It's hard for me to imagine trying to learn a language as complex as C++ just for the job. Reading all those books and practicing takes time. You can learn what you need for the job, and make a useful contribution. I think you have to love it to become proficient.

Rob deFriesse
+1  A: 

You should read Tony Albrecht's Pitfalls of Object Oriented Programming.

Gregory Pakosz