As we have so many design patterns in java, like wise do we have any in c++.Or can we use the same sort of patterns in c++.
Design patterns are conceptual, that means it's not bound to langauges.
You can use the same idea on C++.
The original book on Design patterns (Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of Four) predates Java. The examples in there are in C++ and Smalltalk.
Design patterns are applicable to many object-oriented programming languages; maybe it's just that in Java they are usually so ubiquitous that you need them to solve anything non-trivial.
However, some design patterns are solved by language features (you don't need to explicitly implement an Observer Pattern in C#, for example). Others aren't even applicable to Java, as they need multiple class inheritance.
Many Java patterns are directly applicable to C++ and virtually every language. Of course, there are patterns which are elegant to write in one language, but aren't in another.
Design patterns are pretty much language agnostic, although they will fit into some programming paradigms and not others. In that regards, many patterns in Java will work very well with C++.
Meanwhile, C++'s rich (and twisted, some could say!) templating system allows for very interesting implementation of standards patterns, see for example Modern C++ Design from Alexandrescu and its very interesting policy-based design.
Design patterns are commonly used solutions to common software problems. while certain languages or frameworks do lend themselves to different patterns more easily than others, the patterns themselves are reasonably agnostic to language choice so you are likely to find pattern implementations for C++.
Refer to the boost library documentation, there they have implemented many of the design patterns like Java.
Design patterns are language agnostic. Language specific patterns are called idioms - these are solutions to recurring problems in a certain language.
For C++ there are good books like Effective C++, that introduce you to the basic ones. The wikibook More C++ idioms is also worth a look.
Design Patterns range across all languages. Was trying to find a few I have, but cannot seem to get to them right now. I believe one in particular was from the "Head Start" series. Takes a complex learning issue and makes it an easy read which in turn makes for better retaining. Other than that, there are a ton of books out there, but as the said example shows, some are better than others. Design Patterns can be complex!
As mentioned, the original book about design patterns uses C++ and some SmallTalk for code samples. Having said that, the code used in that book is not considered good C++ today, so I would be careful about applying "classic" design patterns in C++.
I would say that a pattern usually fit within one or a few programming paradigms, so it is not constrained to a single language. Some say that patterns is a sign of missing features in the paradigm/language, or a way to circumvent problems of the language/paradigm.
This question is quite amusing since Design Patterns originate in C++. The GoF book (Gamma, Johnson, Helm, Vlissides) in Introduction:
The purpose of this book is to record experience in designing object-oriented software as design patterns. Each design pattern systematically names, explains, and evaluates an important and recurring design in object-oriented systems. Our goal is to capture design experience in a form that people can use effectively. To this end we have documented some of the most important design patterns and present them as a catalog.
and then in What is a Design Pattern:
Although design patterns describe object-oriented designs, they are based on practical solutions that have been implemented in mainstream object-oriented programming languages like Smalltalk and C++ rather than procedural languages (Pascal, C, Ada) or more dynamic object-oriented languages (CLOS, Dylan, Self). We chose Smalltalk and C++ for pragmatic reasons: Our day-to-day experience has been in these languages, and they are increasingly popular.
Also, Design Patterns have been criticized on the grounds that they're mere idioms, glorified to hide the fact. The critics (sorry, no sources) say that DPs just make up for lack of direct language support. That's definitely right at least to a certain degree: see how Scala's built-in support for Singleton obviates public static getInstance()
, or recall that Visitor just simulates double dispatch.
I think that the notion of DPs as implementation idioms is just as useful as the usual interpretation (capital *D*esign). First, we need to recognize that different languages call for different approaches, and the high-brow position of DPs certainly doesn't help. Second, common vocabulary of implementation techniques, specific for each language, is as important as a, possibly cross-language, vocabulary of design approaches.