If yes, then are there any patterns that are specific to C++, and some that are not?
Which are they, if any? Well I am referring to these design patterns: http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
RAII is a powerful pattern that relies on C++'s scope cleanup mechanism. In garbage-collected environments this language feature is usually missing. Other languages (e.g. Ruby) have other ways of using user-provided control flow constructions.
I'm not sure if there is another answer other than "Yes".
If the design pattern depends on language-agnostic object behavior, the same DP can be applied across languages.
However if the design pattern is dependent on some language features, then translating it to another language would require some effort or be impossible. Some patterns might come into existence because of some characteristics of a specific language (but are not needed in other languages).
People come up with patterns all the time. So yes.
I think the best answer here is "it depends" because the notion of pattern has some fuzzy boundaries.
If you are willing to say "C++ virtual function" or "Java interface" is a "pattern" then, well, you have by default come up with a "pattern" that is applicable to exactly one language at the exclusion of all others. Given that a pattern is simply a way of solving a problem that can be applied in varying contexts, you could argue technically that single-language patters can in theory exist.
However the common use of the term "pattern" is something slightly more abstract than a specific language feature. What I think most people can agree on is that there are patterns that are specific to certain families of languages, where the family can be very small, e.g., languages supporting OO, supporting actors, supporting channel-based communication, etc.
When your pattern becomes so specific that the language family to which it applies winds all the way down to a single language, you get into the fuzzy area where people might quibble about whether something is a pattern or a language feature. The rationale here is that "well heck, can't someone just create another language based on this language so that the pattern will apply to the derived language too?"
However, if you can reasonably argue that your alleged pattern is indeed a way of solving a problem that can be used in different contexts, and that no other programming language in existence can reasonably implement this solution, then you can say yes.
.... Until someone creates that dialect! :-)
Yes.
The most notable way to see this is to experiment with a paradigm shift. For example, compare Java (OO) to Haskell (Functional).
Let's take the Flyweight pattern, in Java. In Haskell, it's a no-brainer, data (which is immutable) is implicitly shared.
Other example: the Command pattern. Haskell supports first-class functions (and curryism), commands are built-in.
Some will argue that DP exist to cover what a language does not provide in a built-in way. In this sense, the higher level a language, the more DP are embedded.
The patterns which uses the specific language functions like Multiple Inhertance in C++, Dynamic behaviors like Reflections are quite language dependent. GoF design patterns are considered as the base for most of the patterns but as the years went, systems became more complex and distributed. Hence the fundamental design patterns and principles were evolved and extended. Web frameworks and libraries are one of the best examples for implementing real-world scenarios to meet the developers/users need. Like dynamic page generation, AJAX etc. But I seriously believe that, the patterns must be generic and should not rely on languages.
For e.g if you're is using too much patterns which depends on PHP, may not help them to switch to some other dynamic languages like Python. The general/generic implementations can be realized easily across most of the languages.
I am learning C++
I don't know much about this stuff except the fact that programming design pattern is neccesary when actually working in large projects.I hope its correct to some extent.
Is this common to all object oriented languages or do I need to look specifically into
C++ design patterns.
Also How does it helps you.Is this realy important to learn as a C++ programmer.
Please suggest
Design patterns are often misunderstood. They are really a way for experienced users to have shorthand for describing common situations. You don't need to worry about them too much while you are learning C++.
You will hear discording opinions about design patterns, in the programming community at large.
In my opinion, it is sure that there are abstractions that patterns encapsulate that are really useful (factory, singleton, delegate, etc.). I use patterns a lot, but I myself am sometime puzzled by the apparent lack of depth or level of insight that you get by reading a pattern description. This is also in tune with the proliferation of design patterns that specialize for any kind of things.
When the design hey are useful, they are a very good means of communication and certainly they guide you through the process of designing or defining the architecture of your app. They are useful both for small project and for large ones, and they can be applied at different granularity levels.
Patters are a generic concept and all programming languages support them. Anyway, if you work in C++, a book focusing on it is best, because you will get the pattern adapted to the characteristics of the language.
In my opinion, the really fundamental book about design patterns are:
GoF, Design Patterns: Elements of Reusable Object-Oriented Software
VV.AA., Pattern-Oriented Software Architecture Volume 1: A System of Patterns
VV.AA., Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
Most of the design pattern are common to all object oriented languages.
For me design patterns are nothing but abstractions that shorten communication time between programmers. Instead of expressing a complex idea of how your program is designed, you can probably find a name of a pattern that describes the design of your program.
E.g. TPM says "We should use singleton here", and you interpret "We should use one instance of the class here".
Patterns are useful to learn, but one can program without knowing any patterns, yet using them a lot.
I see design patterns as collections of wisdom gained by experience, particularly addressing issues of flexibility and maintainability of code. For example: by using a facade we can change implementations without changing the code that uses the facade.
I think it's fair to say that all programming languages have wisdom to be captured, and design patterns of some sort will be useful. The C/C++/Java/C# heritage languages seem to offer a particularly rich seem to be mined for wisdom. C++ being quite gnarly really does benefit from some key design patterns.
Some folk see Design Patterns as a way of patching over language deficiencies, that would imply that "better" langauges might need fewer patterns. My feeling is that in all cases we have something to learn from experienced folks and Patterns help us codify their wisdom.
Edited to add: Interesting point made by Munish, it is best to do a little reinvention first? By writing some real code without explicit use of Patterns you may well start to feel dissatisfied with what you write ... when I change this, I need to change all that, is there a better way to write this? ... this may drive you to really need patterns and hence motivate your study.
If you have the luxury of time to learn this way then I think you'll probably benefit.
Design patterns are solutions to commonly occuring problems in Design phase of a project.These patterns provide the solutions which we can use independent of programming language.For e.g. there is Singleton design pattern which ensures that there is only one instance of a class.Now there are numerous occaions on which this may be required.You can use the solution of these pattern and use in your code.
They provide the re usability in Software development .Put simply, design patterns
help a designer get a design right faster.
For more better understanding you could refer Design Patterns: Elements of Reusable Object-Oriented Software
Lately I am losing my trust in OOP. I have already seen many
complaints about common OOP misuses or just simple overuse. I do not
mean the common confusion between is-a and has-a relationship. I mean
stuff like the problems of ORM when dealing with relational databases,
the excessive use of inheritance from C# and also several years of looking
at code with the same false encapsulation belief that Scott Meyers
mentions in the item 23 of Effective C++
I am interested in learning more about this and non OOP software
patterns that can solve certain problems better than their OOP
counterparts. I am convinced that out there there are many people
giving good advice on how to use this as an advantage with non pure OOP
languages such as C++.
Does anyone knows any good reference (author, book, article) to get
started?
Please, notice that I am looking for two related but different things:
Common misuses of OOP concepts (like item 23)
Patterns where OOP is not the best solution (with alternatives)
Well I can recommend you a book Agile Principles, Patterns, and Practices in C#.
Examples are in C# of course, but the idea of the book is universal. Not only it covers Agile but also focuses on bad practices and shows in examples how to convert bad code to a good code. It also contains descriptions of many design pattern and shows how to implement them in semi-real example of Payroll application.
This has to be done but if you truly want to get away from OOP or at least take a look at concepts which are not OOP but are used with great effectiveness: Learn you a Haskell. Try a new programming paradigm and then start seeing where you can apply much of the concepts back to OOP languages. This addresses your second bullet, not in a direct way but trust me, it'll help more than you can think.
It's a bit odd that you mention C#. It has very powerful keywords to keep the usual inheritance misery in check. The first one ought to be the internal keyword. The notion of restricting the visibility to a module. That concept is completely absent in C++, the build model just doesn't support it. Otherwise a great concept, "I only trust the members of my team to get it right". Of course you do.
Then there's the slammer one, the sealed keyword. Extraordinary powerful, "the buck stops here, don't mess with me". Used with surgical precision in the .NET framework, I've never yet found a case where sealed was used inappropriately. Also missing in C++, but with obscure ways to get that working.
But yes, the WPF object model sucks fairly heavy. Inheriting 6 levels deep and using backdoors like a dependency property is offensive. Inheritance is hard, let's go shopping.
I would say to look at game engines. For the most part, OOP has a tendency to cause slight performance decreases, and the gaming industry is seemingly obsessed with eliminating minor slowdowns (and sometimes ignoring large ones). As such, their code, though usually written in a language that supports OOP, will end up using only those elements of OOP that are necessary for clean code / ease of maintenance that also balances performance.
EDIT:
Having said that, I don't know if I would really go look at Unreal. They do some strange things for the sake of making their content pipeline easier for developers... it makes their code... well, look if you really want to know.
One common overuse is forcing OOP in programs/scripts that take some input, turn it to output, then exit (and not receiving input from anywhere else during the process). Procedural way is much cleaner in these cases.
Typical example of this is forcing OOP in PHP scripts.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What C++ idioms should C++ programmers use?
After reading books like C++ Primer, Effective C++ and TC++PL I want to learn some important design patterns.
So, what are the famous design patterns that every C++ programmer should know?
C++-specific ones: RAII and PIMPL.
The obvious answer is the Gang-Of-Four patterns from the famous book. These are the same patterns that get listed all over the place.
http://en.wikipedia.org/wiki/Design_Patterns
Beyond that, have a look around Martin Fowlers web site...
http://martinfowler.com/
There's a fair bit on there - the "famous" one is probably "dependency injection". Most others are pretty domain specific, though.
"Mixin layers" can be interesting for C++. A template class takes its own base as a template parameter, so that the template can be used to add the same functionality to many different classes, or as a composition method so that various features can be easily included/excluded for a library. The curiously recurring template trick is sometimes used as well (the original base is the final fully-composed class) so that the various mixin layers can do some degree of "reflection", so that intermediate methods can be defined in terms of fully-composed member types etc. Of course it can be a bit prone to unresolvable cyclic dependencies, if you're not careful.
http://portal.acm.org/citation.cfm?id=505148
Note - "the original base" doesn't mean the original base class that's inhereted from as that would cause an illegal inheritance cycle - it's just a template parameter used to refer to, to access the types/constants/etc in the final result and perhaps for metaprogramming reflection techniques.
I honestly don't know at this point if I was confused when I wrote "base", or just chose a confusing word.
Read the Design Patterns: Elements of Reusable Object-Oriented Software.
In no particular order, the Gang of Four patterns I see and use most, are probably the following:
Composite
Template Method
Abstract Factory
Singleton (much hated, but everywhere)
Visitor
Builder
Proxy
I suggest reading Head First Design Patterns. It's a fun read, and you'll learn about a lot of the common design patterns.
The think pattern. It's a silver bullet.
I find myself always trying to fit everything into the OOP methodology, when I'm coding in C/C++. But I realize that I don't always have to force everything into this mold. What are some pros/cons for using the OOP methodology versus not? I'm more interested in the pros/cons of NOT using OOP (for example, are there optimization benefits to not using OOP?). Thanks, let me know.
Of course it's very easy to explain a million reasons why OOP is a good thing. These include: design patterns, abstraction, encapsulation, modularity, polymorphism, and inheritance.
When not to use OOP:
Putting square pegs in round holes: Don't wrap everything in classes when they don't need to be. Sometimes there is no need and the extra overhead just makes your code slower and more complex.
Object state can get very complex: There is a really good quote from Joe Armstrong who invented Erlang:
The problem with object-oriented
languages is they’ve got all this
implicit environment that they carry
around with them. You wanted a banana
but what you got was a gorilla holding
the banana and the entire jungle.
Your code is already not OOP: It's not worth porting your code if your old code is not OOP. There is a quote from Richard Stallman in 1995
Adding OOP to Emacs is not clearly an
improvement; I used OOP when working
on the Lisp Machine window systems,
and I disagree with the usual view
that it is a superior way to program.
Portability with C: You may need to export a set of functions to C. Although you can simulate OOP in C by making a struct and a set of functions who's first parameter takes a pointer to that struct, it isn't always natural.
You may find more reasons in this paper entitled Bad Engineering Properties
of Object-Oriented Languages.
Wikipedia's Object Oriented Programming page also discusses some pros and cons.
One school of thought with object-oriented programming is that you should have all of the functions that operate on a class as methods on the class.
Scott Meyers, one of the C++ gurus, actually argues against this in this article:
How Non-Member Functions Improve Encapsulation.
He basically says, unless there's a real compelling reason to, you should keep the function SEPARATE from the class. Otherwise the class can turn into this big bloated unmanageable mess.
Based on experiences in a previous large project, I totally agree with him.
A benefit of non-oop functionality is that it often makes exporting your functionality to different languages easier. For example a simple DLL containing only functions is much easier to use in C#, you can use the P/Invoke to simply call the C++ functions. So in this sense it can be useful for writing extremely time critical algorithms that fit nicely into single/few function calls.
OOP is used a lot in GUI code, computer games, and simulations. Windows should be polymorphic - you can click on them, resize them, and so on. Computer game objects should be polymorphic - they probably have a location, a path to follow, they might have health, and they might have some AI behavior. Simulation objects also have behavior that is similar, but breaks down into classes.
For most things though, OOP is a bit of a waste of time. State usually just causes trouble, unless you have put it safely in the database where it belongs.
I suggest you read Bjarne's Paper about Why C++ is not just an Object-Oriented Programming Language
If we consider, for a moment, not object-orienatation itself but one
of the keystones of object-orientation: encapsulation.
It can be shown that change-propagation probability cannot increase
with distance from the change: if A depends on B and B depends on C,
and we change C, then the probability that A will change
cannot be larger than the proabability that B will
change. If B is a direct dependency on C and A is an indirect
dependency on C, then, more generally, to minimise the potential cost
of any change in a system we must miminimise the potential number of
direct dependencies.
The ISO defines encapsulation as the property that the information
contained in an object is accessible only through interactions at the
interfaces supported by the object.
We use encapsulation to minimise the number of potential dependencies
with the highest change-propagation probability. Basically,
encapsulation mitigates the ripple effect.
Thus one reason not to use encapsulation is when the system is so
small or so unchanging that the cost of potential ripple effects is
negligible. This is also, therefore, a case when OO might not be used
without potentially costly consequences.
Well, there are several alternatives. Non-OOP code in C++ may instead be:
C-style procedural code, or
C++-style generic programming
The only advantages to the first are the simplicity and backwards-compatibility. If you're writing a small trivial app, then messing around with classes is just a waste of time. If you're trying to write a "Hello World", just call printf already. Don't bother wrapping it in a class. And if you're working with an existing C codebase, it's probably not object-oriented, and trying to force it into a different paradigm than it already uses is just a recipe for pain.
For the latter, the situation is different, in that this approach is often superior to "traditional OOP".
Generic programming gives you greater performance (among other things because you often avoid the overhead of vtables, and because with less indirection, the compiler is better able to inline), better type safety (because the exact type is known, rather than hiding it behind an interface), and often cleaner and more concise code as well (STL iterators and algorithms enable much of this, without using a single instance of runtime polymorphism or virtual functions.
OOP is little more than an aging buzzword. A methodology that everyone misunderstood (The version supported by C++ and Java has little to do with what OOP originally meant, as in SmallTalk), and then pretended was the holy grail. There are aspects to it that are useful, certainly, but it is often not the best approach for designing an application.
Rather, express the overall logic by other means, for example generic programming, and when you need a class to encapsulate some simple concept, by all means design it according to OOP principles.
OOP is just a tool among many. The goal is not to write OOP code, but to write good code. Sometimes, the way to do this is by using OOP principles, but often, you can get better code using generic programmming principles, or functional programming.
It is a very project dependent decision. My general feel of OOP is that its useful for organizing large projects that involve multiple components. One area I find that OOP is especially pointless is school assignments. Excepting those specifically designed to teach OOP concepts, or large software design concepts, many of my assignments, specifically those in more algorithmy type classes are best suited to non-OOP design.
So specifically, smaller projects, that are not likely to grow large, and projects that center around a single algorithm seem to be non-OOP candidates in my books. Also, if you can write the specification as a linear set of steps, e.g., with no interactive GUI or state to maintain, this would also be an opportunity.
Of course, if you're required to use an OOP design, or an OOP toolkit, or if you have well defined 'objects' in you're spec, or if you need the features of polymorphism, etc. etc. etc...there are plenty of reasons to use it, the above seem to be indicators of when it would be simple not to.
Just my $0.02.
Having an Ada background, I develop in C in terms of packages containing data and their associated functions. This gives a code very modular with pieces of code that can be taken apart and reused on other projects. I don't feel the need to use OOP.
When I develop in Objective-C, objects are the natural container for data and code. I still develop with more or less the package concept in mind with some new cool features.
I'm used to be an OOP fanboy... Then realized using functions, generics and callbacks can often make a more elegant and change-friendly solution in C++ than classes and virtual functions.
Other big names realized it too: http://harmful.cat-v.org/software/OO_programming/
IMHO, I have a feeling that the OOP concept is not really suits the needs of the Big Data, as OOP assume all the stuff to be kept in memory (concept of Objects and member variables). This always result in memory demanding and heavy applications when OOP is used for example for big images processing. Instead, the simplicity of C maybe used with intensive parallel I/O making apps more efficient and easy to implement. It is the year 2019 I am writing this message...Everything may change in a year! :)
In my mind it comes down to what kind of model suits the problem at hand. It seems to me that OOP is best suited to coding GUI programs, in that the data and functionality for a graphical object is easily bundled together. Other problems- (such as a webserver, as an example off the top of my head), might be more easily modeled with a data centric approach, where there's no strong advantage to having a method and its data near each-other.
tl;dr depends on the problem.
I'd say the greatest benefit of C++ OOP is inheritance and polymorphism (Virtual function etc...) .
This allows for code reuse and extendibility
C++, use OOP - - - C, no, with certain exceptions
In C++ you should use OOP. It's a nice abstraction and it's the tool you are given. You either use it or leave it in the box where it can't help. You don't use the power saw for everything but I would read the manual and have it ready for the right job.
In C, it's a more difficult call. While you can certainly write arbitrarily object-oriented code in C, it's enough of a pain that you immediately find yourself fighting the language in order to use it. You may be more productive dropping the doesn't-fit-so-well design pattern and programming as C was intended to be used.
Furthermore, every time you make an array of function pointers or something in an OOP-in-C design pattern, you sever almost completely all visible links in the inheritance chain, making the code hard to maintain. In real OOP languages, there is an obvious chain of derived classes, often analyzed and documented for you. (mmm, javadoc.) Not so in OOP-in-C, and the tools available won't be able to see it.
So, I would argue in general against OOP in C. For a really complex program, you may well need the abstraction, and then you will have to do it despite needing to fight the language in the process and despite making the program quite hard to follow by anyone other than the original author.
But if you knew the program was going to become that complicated, you shouldn't have written it in C in the first place...
In C, there are some times when I 'emulate' the object oriented approach, by defining some sort of constructor with granular control over things like callbacks, when running several instances of it.
For instance, lets say I have some spiffy event handler library and I know that down the road I'm going to need many allocated copies:
So I would have (in C)
MyEvent *ev1 = new_eventhandler();
set_event_callback_func(ev1, callback_one);
ev1->setfd(fd1);
MyEvent *ev2 = new_eventhandler();
set_event_callback_func(ev2, callback_two);
ev2->setfd(fd2);
destroy_eventhandler(ev1);
destroy_eventhandler(ev2);
Obviously, I would later do something useful with that like handle received events in the two respective callback functions. I'm not going to really elaborate on the method of typing function pointers and structures to hold them, nor what would go on in the 'constructor' because its pretty obvious.
I think, this approach works for more advanced interfaces where its desirable to allow the user to define their own callbacks (and change them on the fly), or when working on complex non-blocking I/O services.
Otherwise, I much prefer a more procedural / functional approach.
Probably an unpopular idea but I think you should stick with non-OOP unless it adds something useful. In most practical problems OOP is useful but if I'm just playing with an idea I start writing non-object code and put functions and data into classes if it becomes useful.
Of course I still use other objects in my code (std::vector et al) and I use namespaces to help organise my functions but why put code into objects until it is useful? Equally don't shy away from free functions in an OO solution.
The question is tricky because OOP encompasses several concepts: object encapsulation, polymorphism, inheritance, etc. It's easy to take those ideas too far. Here's a concrete example:
When C++ first caught on, zillions of string classes sprung into being. Everything you could possibly imagine doing to a string (upcasing, downcasing, trimming, tokenizing, parsing, etc.) was a member function of some string class.
Notice, though, that std::strings from the STL don't have all these methods. STL is object-oriented--the state and implementation details of a string object are well encapsulated, only a small, orthogonal interface is exposed to the world. All the crazy manipulations that people used to include as member functions are now delegated to non-member functions.
This is powerful, because these functions can now work on any string class that exposes the same interface. If you use STL strings for most things and a specialty version tuned to your program's idiosyncracies, you don't have to duplicate member functions. You just have to implement the basic string interface and then you can re-use all those crazy manipulations.
Some people call this hybrid approach generic programming. It's still object-oriented programming, but it moves away from the "everything is a member-function" mentality that a lot of people associate with OOP.