Design patterns are useful for object oriented languages.

But how can a non-object-oriented language such as C make of use them?

  • 2
    Languages like C need design patterns even more, as one of the primary reasons why they exist at all is because of inadequacies of the underlying language. Aug 5 '12 at 20:55
  • 4
    You can write object-oriented code in C or even in assembly. It's just that it's a ton of work. It's relatively easy to write C programs with public interfaces but private implementation (encapsulation). Inheritance and polymorphism are possible too, but have to write a ton of boiler-plate code for every data structure that you want to support them. Aug 5 '12 at 22:34
  • @CharlesE.Grant Actually, it is not that hard to implement inheritance & polymorphism, simply use opaque types. Bit more crude than languages with OO support but gets the job done.
    – user29079
    Aug 8 '12 at 13:02
  • 2
    @Yousha If you believe that there are object-oriented and non-object-oriented languages, you haven't grasped what object orientation means. There are languages with support for OO features. No code automatically turns object-oriented because you write it in C++ or Java, nor does it automatically turn object-oriented because you use the class keyword. Object-orientation is quite language-independent. The most important features are modular design, encapsulation and inheritance. The former two has little to do with the language, but a lot to do with the program design.
    – user29079
    Aug 8 '12 at 13:05
  • Design Patterns are just proven solution to common Problems. OOP itself is a form Design Pattern where you create the concept of Object in your software for certain benefits. Some patterns might make more sense in OOP languages, however that doesn't stop the non-OOP languages to make use of it.
    – Mahdi
    Apr 10 '14 at 6:09

To reinforce the answers already given, a quote from GOF Design Patterns book itself:

Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance", "Encapsulation" and "Polymorphism".

While the design patterns described there are geared towards object-oriented software, and certainly object-oriented programming languages are a natural fit for it, the concepts they embody are language agnostic. What varies is the work overhead you would have to invest to implement the required OOP feature or a workaround for it.

  • 2
    +1. You could also say that many of the design patterns are implementation overhead themselves for missing features in common OOP language implementations..
    – Macke
    Apr 10 '14 at 5:29
  • 1
    @Macke: Good point. As an example, the visitor pattern is used with OOP languages that only provide single-dispatch.
    – Giorgio
    Apr 10 '14 at 10:37

From the wikipedia article on Software design patterns:

a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design

As you can see, there is no mention of object oriented programming here.

Design patterns apply to any computer language and sometimes are higher level (architectural patterns).

One example is for SQL - there is a even a book for SQL Design Patterns.


Design patterns are not limited to certain languages or language families. You could come up with design patterns for any language or paradigm.

If you are referring to the GOF patterns: Have a look at stdout, stderr and stdinin C. That's the strategy pattern which does not seem so OO after all.

BTW: Object Oriented Programming is not language dependend. Some languages make it easier, some make it harder, but you can program "object oriented" in any universal (as in 'not special purpose' like e.g. SQL) language.

  • Excuse me, how are stdout/stderr/stdin instances of the strategy pattern? They are just global variables. Sure, you can replace them to change where certain functions write to/read from, but that's pretty basic stuff and a way to avoid lots and lots of extra parameters.
    – user7043
    Aug 5 '12 at 20:59
  • @delnan He is referring to the concept of standard output/error/input streams in C, and not the global variables with the same name.
    – Oskar N.
    Aug 5 '12 at 23:00
  • @OskarN. I'm afraid I don't follow. How does the concept of having a couple of streams for everyone to write to have anything to do with the strategy pattern, which is a design pattern by which an implementation of an algorithm is chosen at runtime?
    – user7043
    Aug 5 '12 at 23:05
  • 2
    @delnan The concept of standard output/error/input streams is that your application can write to stdout and read from stdin without concern where this is actually read from/written to. When your application is running, stdin could be redirected to read from a TCP socket, and stdout could be redirected to write directly to a printer (for example)
    – Oskar N.
    Aug 5 '12 at 23:10
  • 1
    @delnan Sure, why not? Strategy pattern in C++ using polymorphism is just variables as well (exchange the object pointer). Any behavior/algorithm that can be exchanged at run-time without changing the client interface is the strategy pattern.
    – Oskar N.
    Aug 5 '12 at 23:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.