Skip to content

Latest commit

 

History

3 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 

Repository files navigation

Design patterns: Application to Non Object-Oriented Software (work in progress)

This is a reimplementation in non Object-Oriented software of the famous 23 design patterns written initially in the book Design Patterns: Elements of Reusable Object-Oriented Software (1994).

Initially written for Object-Oriented programming (OOP), I believe it is entirely possible to adapt their implemention into Non Object-Oriented styles, while keeping their underlying benefits (increased modularity, high cohesion/low coupling, ultimately leading to less bugs etc.).

Note: In case you were wondering, this entire repository (including readme and code examples) is written by me exclusively, you're not reading any LLM generated tokens.

Tools used

I've chosen multiple programming languages for the implementation. The reasoning behind these choices is a combination of my own curiosity + tools I like working with.
The idea is to reimplement them in multi-paradigm programming languages with one (Java) being the corresponding implementation in OOP.

  • Java (Object-Oriented implementation)
  • Typescript
  • Python
  • Go
  • C#
  • Elixir
  • Haskell

Motivations

Based on my own experience working mostly in non Object-Oriented corporate environments, I felt the need to look for a more structured approach to write softwares.

When working in a team, the codebase can very quickly become convoluted, which leads to recurring bugs that I think could be avoided by spending more time doing low level design.
I would argue it's even worse in this era (2026) of LLM assisted software engineering.

After going over the internet and reading blogs, articles and forum posts, I noticed that talks about these same design patterns applied to non OOP were not very focused on practicality or simply did not exist for the most part.

Why "Non Object-Oriented" rather than "Functional programming" ?

Simply because I think design patterns can sometimes solve recurring problems in software engineering that are not inherently associated with a programming paradigm.

This is also because I've never wrote purely Functional, Object-Oriented or even Procedural programs, but often time a combination of multiple paradigms.

Therefore, I imagine it would be limiting to think they can be applied to only one kind of programming.

Contributions

The only contributions I accept are the ones correcting errors I will inevitably make.

I will not add new programming languages or new examples. The idea is only to show practical examples of implementations in other programming paradigm that still solve the same underlying issues the original patterns were written for.

Once all design patterns are implemented, I won't be updating this repository anymore.
This is because I don't plan on doing ongoing maintenance or modifications, therefore I voluntarily limit the scope.

Patterns left to do

Creational

  • singleton ❌
  • factory-method ❌
  • abstract-factory ❌
  • builder ❌
  • prototype ❌

Structural

  • adapter ❌
  • bridge ❌
  • composite ❌
  • decorator ❌
  • facade ❌
  • flyweight ❌
  • proxy ❌

Behavioral

  • chain-of-responsibility ❌
  • command ❌
  • interpreter ❌
  • iterator ❌
  • mediator ❌
  • memento ❌
  • observer ❌
  • state ❌
  • strategy 💫
  • template-method ❌
  • visitor ❌

Legend

💫: in progress
❌: not done
✅: done

If you had the attention span to go through all of it, well, congrats and thank you for reading. Hopefully this will prove useful to you or anyone.

About

Design patterns: Application to Non Object-Oriented Software

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Contributors

Languages