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.
Related
What is the most common C++ Design Pattern libraries?
I've read about Loki library in Alexandrescu's book, but looks like it somewhat dead now. Is there something similar out there?
“Design patterns are bug reports against your programming language” --
Peter Norvig
To answer the question why there are not many C++ design pattern libraries, it is useful to know what design patterns were meant to solve in the first place. The classic GoF book states in the preface
Design patterns describe simple and elegant solutions to specific
problems in object-oriented software design.
The 90s style of object-oriented programming relied heavily on using abstract classes as interfaces, with concrete implementation classes deriving from these interfaces. The GoF patterns describe creational, structural and behavioral relationships between objects of different class types. They key element was: encapsulate and parameterize whatever will frequently change. Many of the GoF patterns can also be reformulated using templates, but then the flexibility is constrained to compile-time rather than run-time.
Object-oriented programming makes it very easy to add different concrete implementations of an interface. What OOP has a hard time with is adding new functionality to existing interfaces. The Visitor pattern is the prime example: it is essentially a work-around that relies on an extra level of indirection to allow new algorithms to work on existing data structures.
This is the exact opposite of functional programming: with functional programming it is very easy to add new functions for existing data, but it is much harder to add new data types to which such functions apply. The difficulty in getting extensibility in both functions and types is called the expression problem.
OOP style polymorphism is heavily based on internal polymorphism: the dynamic function dispatch is based on the object's type. Modern C++ also uses external polymorphism where techniques such as type erasure allow run-time flexibility with a static interface. The new std::shared_ptr and boost::any or adobe::poly classes are prime example of these techniques.
A recent ACCU presentation by Tobias Darm showed many examples of transforming the old internally polymporhic GoF patterns to this new style externally polymorphic patterns. The rough idea is to replace abstract classes with a function argument that can take std::function as a parameter. The std::function then controls the polymorphic flexibility from the outside. Many of the GoF patterns can be greatly enhanced in terms of boilerplate this way.
TL;DR: The classic GoF patterns were tailored to solve OOP shortcomings. But OOP is no longer the dominant C++ style. A combination of generic programming (the Standard Library, Boost) and OOP can solve many problems more elegantly, making classic design patterns no longer the go-to solution.
The original definition of a design pattern was a reusable approach to a reoccurring problem that could not be conveniently encapsulated in a library. Thus, the moment you can encapsulate a pattern in a library, it ceases to be a pattern, in my opinion. This has, for instance, largely happened with iterators in C++, as the standard C++ library has a comprehensive framework for implementing iterators now.
I’ve never tried to use Loki, but reading Alexandrescu’s book, I was not persuaded that a library based approach really had much to offer for many patterns.
May seems tautology, but the most common is ... the standard library itself!
It is not -strictly speaking- a "pattern library", but a folder for a number of tools addressing common pattern implementation.
Note that your question is not answerable, being a pattern just a conceptual definition commonly used in a variety of problems. Libraries don't provide patterns, they (can) use patterns (like anybody else can) to provide implementation of specific problem solutions.
Patterns are at an higher abstraction layer than coding.
In an effort to improve code maintainability, re-usability and readability, some researchers (such as GoF, Booch) started examining best practices. They have noticed that there are some patterns adopted by experienced developers to address specific design problems.
As you can see, experience created design patterns. So using design patterns is coding like a specialist. And there is no silver bullet for this.
It is true that some straightforward design patterns such as decorators find support from specific languages. But that's the limit. Domain specific frameworks also guide you to use their interfaces to complete the design pattern decided by the authors of those.
Libraries will only help you understand how design patterns used in that library will facilitate your implementation. It won't even give you a choice to change the design.
I know they are dialects of the same family of language called lisp, but what exactly are the differences? Could you give an overview, if possible, covering topics such as syntax, characteristics, features and resources.
They all have a lot in common:
Dynamic languages
Strongly typed
Compiled
Lisp-style syntax, i.e. code is written as a Lisp data structures (forms) with the most common pattern being function calls like: (function-name arg1 arg2)
Powerful macro systems that allow you to treat code as data and generate arbitrary code at runtime (often used to either "extend the language" with new syntax or create DSLs)
Often used in functional programming style, although have the ability to accommodate other paradigms
Emphasis in interactive development with a REPL (i.e. you interactively develop in a running instance of the code)
Common Lisp distinctive features:
A powerful OOP subsystem (Common Lisp Object System)
Probably the best compiler (Common Lisp is the fastest Lisp according to http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html although there isn't much in it.....)
Clojure distinctive features:
Largest library ecosystem, since you can directly use any Java libraries
Vectors [] and maps {} used as standard in addition to the standard lists () - in addition to the general usefullness of vectors and maps some believe this is a innovation which makes generally more readable
Greater emphasis on immutability and lazy functional programming, somewhat inspired by Haskell
Strong concurrency capabilities supported by software transactional memory at the language level (worth watching: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey)
Scheme distinctive features:
Arguably the simplest and easiest to learn Lisp
Hygienic macros (see http://en.wikipedia.org/wiki/Hygienic_macro) - elegantly avoids the problems with accidental symbol capture in macro expansions
The people above missed a few things
Common Lisp has vectors and hash tables as well. The difference is that Common Lisp uses #() for vectors and no syntax for hash tables. Scheme has vectors, I believe
Common Lisp has reader macros, which allow you to use new brackets (as does Racket, a descendant of Scheme).
Scheme and Clojure have hygienic macros, as opposed to Common Lisp's unhygienic ones
All of the languages are either modern or have extensive renovation projects. Common Lisp has gotten extensive libraries in the past five years (thanks mostly to Quicklisp), Scheme has some modern implementations (Racket, Chicken, Chez Scheme, etc.), and Clojure was created relatively recently
Common Lisp has a built-in OO system, though it's quite different from other OO systems you might have used. Notably, it is not enforced--you don't have to write OO code.
The languages have somewhat different design philosophies. Scheme was designed as a minimal dialect for understanding the Actor Model; it later became used for pedagogy. Common Lisp was designed to unify the myriad Lisp dialects that had sprung up. Clojure was designed for concurrency. As a result, Scheme has a reputation of being minimal and elegant, Common Lisp of being powerful and paradigm-agnostic (functional, OO, whatever), and Clojure of favoring functional programming.
Don't forget about Lisp-1 and Lisp-2 differences.
Scheme and Clojure are Lisp-1:
That means both variables and functions names resides in same namespace.
Common Lisp is Lisp-2:
Function and variables has different namespaces (in fact, CL has many namespaces).
Gimp is written in Scheme :)
In fact allot of software some folks think might be written in C++ was probably done under the Lisp umbrella, its hard to pick out the golden apples out of the bunch. The fact is C++ was not always popular, it only seems to be popular today because of a history of updates. For the lesser half of the century C++ didn't even utilize multithreading, it was where Python is today a cesspool of useless untested buggy glue code. Fasterforward a little and now we are seeing a rise in functional programming, its more like adapt or die. I think Java has it right as far as the adapt part is concerned.
Scheme was designed to simplify the Lisp language, that was its only intent except it never really caught on. I think Clojure does something similar its meant to simplify Scheme for the JVM nothing more. Its just like every other JVM language just there to inflate the user experience, only to simplify writting boilerplate in Java land.
For example pattern matching is a programming language feature that can be added to the clojure language through macros: http://www.brool.com/index.php/pattern-matching-in-clojure
What other language features can be added to the language?
Off the top of my hat I have two examples, but I'm sure there are more.
Contracts programming: https://github.com/fogus/trammel
Declarative logic: https://github.com/jduey/mini-kanren
I think its a stupid question to ask what can be added, what you should ask is what you cant add. Macros allow you to hook into the compiler that mean you can do almost anything.
At the moment you cant add your own syntax to the language. Clojure does not have a user extenseble reader, this means you don't have any reader-macros (http://dorophone.blogspot.com/2008/03/common-lisp-reader-macros-simple.html). This is not because of a technical problem but more a decition by Rich Hickey (the Clojure creator).
What you can not do is implement features that need virtual maschine support like add tail call semantics or goto.
If you want to see some stuff that has been done: Are there any Clojure DSLs?
Note that this list is not 100% up to date.
Edit:
Since you seem you took pattern matching as an example (it is a really good example for the power of macros) you should really look at the match library. Its probebly the best fastest pattern matching library in Clojure. http://vimeo.com/27860102
You can effectively add any language features you like.
This follows from the ability of macros to construct arbitrary code at compile time: as long as you can figure out what code you need to generate in order to implement your language features, it can be achieved with macros.
Some examples I've seen:
Query languages (Korma)
Logic programming (core.logic)
Image synthesis DSL (clisk)
Infix notation for arithmetic
Algebraic manipulation
Declarative definition of realtime data flows (Storm, Aleph)
Music programming (Overtone, Music As Data)
There are a few caveats:
If the feature isn't supported directly by the JVM (e.g. tail call optimisation in the mutually recursive case) then you'll have to emulate it. Not a big deal, but may have some performance impact.
If the feature requires a syntax not supported by the Clojure reader, you'll need to provide your own reader (since Clojure lacks an extensible reader at present). As a result, it's much easier if you stick to Clojure syntax/forms.
If you do anything too unusual / unidiomatic, it probably won't get picked up by others. There is a lot of value in sticking to standard Clojure conventions.
Beware of using macros where they are not needed. Often, just using normal functions (perhaps higher order functions) is sufficient to implement many new language features. The general rule is: "don't use macros unless you absolutely need to".
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.