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.
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.
There are a number of posts here on SO dealing with this, for instance:
What is the best source to learn C++?
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. ;-)
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.
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!
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.
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.
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.
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.
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.
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.
You should read Tony Albrecht's Pitfalls of Object Oriented Programming.