# Design Pattern the Julian way?

**URL:** <https://discourse.julialang.org/t/design-pattern-the-julian-way/29002>\
**Category:** General Usage\
**Tags:** design-pattern\
**Created:** [September 20, 2019, 2:33pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002 "2019-09-20T14:33:54Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![atthom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/atthom/32/7173_2.png) [@atthom](https://discourse.julialang.org/u/atthom)\
**Post date:** [September 20, 2019, 2:33pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/1 "2019-09-20T14:33:54Z")

</div>

Design Patterns are the firsts building blocks when developing an application.  
There are a few of them, most developers recognize or use them when building a medium/large application.  
They are listed here: [Software design pattern - Wikipedia](https://en.wikipedia.org/wiki/Software_design_pattern)

I was wondering if there is something equivalent in Julia. Due to multiple dispatch which is a fundamental difference over OOP, I expect some variations, and maybe some patterns are just not applicable. Multiple Dispatch is a very powerful tool, a showcase (tutorial or book?) of what is possible to do would be very interesting.

Thanks!

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 20, 2019, 5:31pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/2 "2019-09-20T17:31:41Z")

</div>

> [@atthom](#):
>
> Due to multiple dispatch which is a fundamental difference over OOP, I expect some variations, and maybe some patterns are just not applicable.

In fact, multiple dispatch is so powerful that the usual OO “design patterns” are mostly not needed. Some studies were written about this for Common Lisp/Dylan, and most if it is applicable to Julia (even more so, since Julia’s parametric type system is more advanced in some directions).

See [this well-known presentation by Peter Norvig](http://norvig.com/design-patterns/design-patterns.pdf). There is also a view that design patterns are boilerplate that [reveal flaws in a language](http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures).

---

<div class="post-metadata">

**Author:** ![Duane\_Wilson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/duane_wilson/32/9506_2.png) [@Duane\_Wilson](https://discourse.julialang.org/u/Duane_Wilson)\
**Post date:** [September 20, 2019, 5:44pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/3 "2019-09-20T17:44:05Z")

</div>

While what Tamas says is true that does not mean there are not design patterns for Julia. They are, however, different from the traditional OOP ones. The Julia documentation has a section dedicated to design patterns for parametric methods.

[https://docs.julialang.org/en/v1/manual/methods/#Design-Patterns-with-Parametric-Methods-1](https://docs.julialang.org/en/v1/manual/methods/#Design-Patterns-with-Parametric-Methods-1)

Things like Holy Traits and promotion rules, which promotes type stability and allowing the complier to better inline specific methods are the name of the game.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [September 21, 2019, 3:58am UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/4 "2019-09-21T03:58:13Z")

</div>

This is really fascinating. I’m excited to see how this continues to develop as Julia progresses. There are a lot of cool things about Julia, but one of the most fun things is how well positioned it is to discover and improve new programming paradigms. Transducers.jl is a great example of this (although not really a new approach it’s still neat that we can use it).

I can’t wait for the day that Julia has been around long enough that someone has the time to write a full book on these things.

---

<div class="post-metadata">

**Author:** ![tk3369](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tk3369/32/2824_2.png) [@tk3369](https://discourse.julialang.org/u/tk3369)\
**Post date:** [September 21, 2019, 5:12pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/5 "2019-09-21T17:12:06Z")

</div>

Hi. I’m indeed writing a book about design patterns at the moment.

Please post any specific topics that you would like to see being covered. I already have a plan about the contents but when time permits I will try to accommodate topics that the developer community is interested in.

The [Hands on Design Patterns for Julia](https://www.packtpub.com/application-development/hands-design-patterns-julia-10) book is slated to be published some time around the end of this year.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [September 22, 2019, 1:28pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/6 "2019-09-22T13:28:35Z")

</div>

This looks pretty neat! One thing that would be really interesting is metaprogramming and intermediate representations of code, because Julia is uniquely positioned to address it.

---

<div class="post-metadata">

**Author:** ![atthom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/atthom/32/7173_2.png) [@atthom](https://discourse.julialang.org/u/atthom)\
**Post date:** [September 22, 2019, 1:42pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/7 "2019-09-22T13:42:06Z")

</div>

Thank you all for your answers.

I read a lot of your different links, but I’m not sure I understood it well:  
All the “classic OOP” patterns no longer exist in Julia? However, new design patterns related to multiple dispatch exist in Julia.  
Does all these new patterns are described in this [Julia doc page](https://docs.julialang.org/en/v1/manual/methods/#Design-Patterns-with-Parametric-Methods-1)?

Also, the first paragraph states:

> While complex dispatch logic is not required for performance or usability, sometimes it can be the best way to express some algorithm.

Does it mean that most of the time we should avoid implementing these design patterns?

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [September 22, 2019, 1:55pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/8 "2019-09-22T13:55:27Z")

</div>

I think it means that the more complex patterns aren’t required for new users to achieve usability. Although, there are some topics you occasionally find that are both more complex and less desirable for general usage (`@pure` is a perfect example of this).

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 22, 2019, 2:40pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/9 "2019-09-22T14:40:26Z")

</div>

> [@atthom](#):
>
> All the “classic OOP” patterns no longer exist in Julia? However, new design patterns related to multiple dispatch exist in Julia.

Broadly, yes. The “design patterns” documented on that page are mostly about compile-time computation in type space, something more or less unique to Julia when combined with multiple dispatch in this way.

> [@atthom](#):
>
> all these new patterns are described in this [Julia doc page](https://docs.julialang.org/en/v1/manual/methods/#Design-Patterns-with-Parametric-Methods-1)?

There is a wider range of what you can call “good practices”, not everything is documented on that page.

Julia is still evolving, how various patterns and interact with advanced usage (eg source-to-source transformations) is in flux, the compiler also keeps getting better of figuring out things without help. What you see described on that page is well-established usage.

In a sense, “design patterns” for Julia tend to be (1) more optional and (2) simpler than their OOP counterparts. You may be interested in

[![](https://global.discourse-cdn.com/julialang/original/3X/c/5/c5a2f02c81c376da005f8610ce9cdd4ad47cfdf4.jpeg "JuliaCon 2019 | The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski") ](https://www.youtube.com/watch?v=kc9HwsxE1OY)

which explains why this is to a large extent.

---

<div class="post-metadata">

**Author:** ![o314](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/o314/32/252_2.png) [@o314](https://discourse.julialang.org/u/o314)\
**Post date:** [September 22, 2019, 4:15pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/10 "2019-09-22T16:15:41Z")

</div>

## Design patterns in functional programming

It’s sunday today,  
Good stuff [there](https://fsharpforfunandprofit.com/fppatterns/) to laugh a bit while prepping seriously next week.

> [![fp%20design%20patterns%20w%20scott](https://global.discourse-cdn.com/julialang/original/3X/4/0/40182fb6d5b95b510f3f1fb9c564cfd1ae51627e.jpeg)](https://fsharpforfunandprofit.com/fppatterns/)  
> _Scott WLASCHIN, 2014_

Thanks to Scott WLASCHIN for its work with F# to explain us better how to design with functional programming language. He also publishes :

> [Domain Modeling Made Functional](https://learning.oreilly.com/library/view/domain-modeling-made/9781680505481/)  
> _Scott WLASCHIN, 2018_

## Design patterns in programming

> [Clean Architecture](https://learning.oreilly.com/library/view/clean-architecture-a/9780134494272/)  
> _Robert MARTIN, 2017_

> [Implementing Domain-Driven Design](https://learning.oreilly.com/library/view/implementing-domain-driven-design/9780133039900/)  
> _Vaughn VERNON, 2013_

are very, very good books about this matters.

## Design Patterns anywhere

(Very) serious people can learn / enhance their skills about design patterns here too :

> [Analyzing Object-Oriented Design Patterns from an Object-Process Viewpoint](https://www.researchgate.net/publication/221278322_Analyzing_Object-Oriented_Design_Patterns_from_an_Object-Process_Viewpoint)  
> _Dov DORI, 2006_

FYI Dov Dori teaches at MIT/technion about modeling, systems engineering.  
Nonetheless its thesis about [Object Process Methodology](https://en.wikipedia.org/wiki/Object_Process_Methodology) became an ISO norm few years ago !  
IMHO, that work encompasses and surpasses UML, maybe SysML too.

## And now

Julia is sufficiently well grounded into science land to be very well accommodated with such methodologies. This famous talk in the the julia community about multidispatch given @ Juliacon can be watch before for a great introduction :

> [The Unreasonable Effectiveness of Multiple Dispatch](https://www.youtube.com/watch?v=kc9HwsxE1OY)  
> _Stefan KARPINSKI, 2019_

---

<div class="post-metadata">

**Author:** ![sairus7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sairus7/32/10816_2.png) [@sairus7](https://discourse.julialang.org/u/sairus7)\
**Post date:** [September 23, 2019, 10:43am UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/11 "2019-09-23T10:43:13Z")

</div>

There is also some uncertainty in modules and packages organization for programmers who are rewriting in Julia large OOP codebases with many classes.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 23, 2019, 11:48am UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/12 "2019-09-23T11:48:22Z")

</div>

While some design patterns are genuinely useful, I still don’t think that they are the best way to become a proficient Julia programmer.

I recognize that for some languages, especially C++ & friends, design patterns have become an essential skill. Like many people, I see them as exposing a deficiency in these languages: lacking various abstractions, the programmers are required to implement some boilerplate, frequently “customized” for a particular problem, which means that the reader has to wade through 200+ LOC to spot those customizations.

I imagine that it is natural that programmers coming from C++, who have learned the a large set of these patterns, think that to learn Julia it is both necessary and mostly sufficient to learn a different set of “design patterns”. But I don’t think that Julia works this way:

1. Julia has much more powerful abstractions with parametric types and multiple dispatch, and the general attitude in the community is to eliminate boilerplate code, not to formalize it,

2. [some patterns](https://docs.julialang.org/en/latest/manual/methods/#Design-Patterns-with-Parametric-Methods-1) exist, but they are very “shallow” (frequently 2–5 LOC), and should be taken more like examples of various neat solutions that can be freely modified/combined, without insisting on identifying/formalizing the outcome as a “pattern”,

3. The language is young, and not all patterns of use are widely explored, so it is perfectly possible for someone to come up with a powerful, succinct, and elegant solution to a problem that is not catalogued as a “pattern” by anyone. I see this on a daily basis on this forum. Knowing good examples is useful, but relying on them can be somewhat constraining.

For C++ programmers adapting to Julia, I would recommend making contributions to packages (or Julia itself). This is a great learning experience since it implies reading the source of a package, seeing a lot of examples of the idiomatic way of doing things, and finally getting an in-depth code review from experts (for free 😉).

---

<div class="post-metadata">

**Author:** ![o314](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/o314/32/252_2.png) [@o314](https://discourse.julialang.org/u/o314)\
**Post date:** [September 23, 2019, 1:47pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/13 "2019-09-23T13:47:23Z")

</div>

Patterns come from a swing between programming in the large and programming in the small.  
They are only partially influenced by the language itself (by its paradigms, not punctuation).  
They often answer to an engineering or business questions.  
Extracting a field or a type is a too low level question in my sense to be considered as a pattern.

Julia is quite young, Julia packages even more younger. There is not so much programming in the large involved today but it will come.

Patterns are useful, not a magic bullet. But i believe you should know when you have one in front of you.

An example, the **composite pattern**  
 ![composite%20pattern](https://global.discourse-cdn.com/julialang/original/3X/e/8/e8bf531be5b3cb1791912d5295fb03398654339b.jpeg)  
It’s encoding in UML and OPM compared.

Two more ones : **chain of responsability** and **observer**

 ![patterns%202](https://global.discourse-cdn.com/julialang/original/3X/0/9/09f98e80b22e13019270cddf440932a026a5c8fe.jpeg)

UML was all the rage sometimes ago. But did not success so much.  
OPM has been developed at MIT, Technion during decade, is very simple, short and synthetic.  
Is an iso norm since 2015 and is teached to thousand of engineers every year at [MIT mooc](https://learn-xpro.mit.edu/systems-engineering). Last but not least, is not entangled in OOP like UML.

I encourage you to appreciate its versability, expressivity thru conciness while keeping precision  
Last example, a **classification of patterns** table

![patterns%20classification](https://global.discourse-cdn.com/julialang/original/3X/3/3/33f0ed95b5cd08382f66039fcc4e696cb8139be1.jpeg)

NB: an ellipse is a function, a square a data

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 23, 2019, 2:08pm UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/14 "2019-09-23T14:08:03Z")

</div>

> [@o314](#):
>
> Julia is quite young, Julia packages even more younger. There is not so much programming in the large involved today

I disagree, there are some reasonable complex codebases. The obvious one is Julia itself with the standard libraries, but [JuliaDiff](https://github.com/JuliaDiff/) is another major one.

That said, arguably the size of a single library or even a collection of them is not the right way to measure code size in Julia, since many packages can be used to form a coherent toolkit for some purpose, often without the intention of the original designers, or just with minor fixes.

This is the “unreasonable effectiveness” pointed out multiple times above. To have this in C++ & friends indeed does require a lot of planning, architectural decisions, and meta-modeling languages like the latest variation on UML. In contrast, _in Julia it just happens_, and people consider it a bug when it does not. I never cease to be amazed by this.

---

<div class="post-metadata">

**Author:** ![vpetukhov](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vpetukhov/32/12954_2.png) [@vpetukhov](https://discourse.julialang.org/u/vpetukhov)\
**Post date:** [September 24, 2019, 6:40am UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/15 "2019-09-24T06:40:29Z")

</div>

Some time ago, another book on OO on Julia was posted here: [https://github.com/ninjaaron/oo-and-polymorphism-in-julia](https://github.com/ninjaaron/oo-and-polymorphism-in-julia). Not sure if the project is alive, but may be helpful.

---

<div class="post-metadata">

**Author:** ![ninjaaron](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ninjaaron/32/6392_2.png) [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)\
**Post date:** [September 24, 2019, 9:35am UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/16 "2019-09-24T09:35:01Z")

</div>

@vpetukhov Well, it isn’t “dead”! I plan to update syntax and examples when and if language changes require it, but I’m not actively working on adding new material, though I’m thinking maybe I should add some stuff about modules. Thanks for the mention.

I was going to jump in here and mention my guide (I wouldn’t quite call it a “book”), but also that simply using the word “object oriented” in the title was quite controversial with some people! (c.f. [I wrote a guide about Object Orientation and Polymorphism in Julia. opinions wanted!](https://discourse.julialang.org/t/i-wrote-a-guide-about-object-orientation-and-polymorphism-in-julia-opinions-wanted/25425)) I would point out that @ChrisRackauckas wrote a blog post covering many of the same patterns, but didn’t get the same kind of push-back on the topic, because he presented them as an alternative to OO, where I presented them as a special case of OO. Chris’ post is here: [Type-Dispatch Design: Post Object-Oriented Programming for Julia](http://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/)

Anyway, no matter what you call it, Chris’ guide and mine are both good general introductions to designing types and interfaces in Julia, though nowhere near as a extensive as the gang of four book.

One thing to keep in mind, and other posts have touched on this, is that a lot of the gang of four patterns are about ways to achieve polymorphism and flexibility in statically-typed, strict OO environment like Java or C++.

As a dynamically-typed language, Julia gets a lot of this polymorphism for free. For example, the factory pattern is meaningless in Julia, since functions are allowed to return arbitrary types. One typically doesn’t need to design hierarchies of types, because any types that have all the required methods can be used interchangeably, regardless of their, uh, “heritage”. Inheritance in Julia is merely a tool for code reuse, since functions are polymorphic by default.

Other principles in gang of four are simply built directly into the language. For example, the emphasis on using interfaces over inheritance (programming to an interface rather than an implementation) is the _only way to do inheritance in Julia_, since it is only possible to inherit from abstract types, which provide only methods, not internal data layout.

For this reason, Julia programmers also tend to rely on composition more than inheritance. [Method forwarding](https://render.githubusercontent.com/view/ipynb?commit=fe34963ada34fae9e4b09608f640dba0486b3d2c&enc_url=68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f6e696e6a6161726f6e2f6f6f2d616e642d706f6c796d6f72706869736d2d696e2d6a756c69612f666533343936336164613334666165396534623039363038663634306462613034383662336432632f706f6c796d6f72706869736d2e6970796e62&nwo=ninjaaron%2Foo-and-polymorphism-in-julia&path=polymorphism.ipynb&repository_id=192606342&repository_type=Repository#Composition-and-method-forwarding:-an-alternative-to-inheritance.) is a common strategy to make this easier.

Another concern in design patterns is encapsulation, in the sense of providing an interface that doesn’t allow the client to rely on implementation details of the API. One could argue, and I think I’d agree, that this is one area where Julia is a bit lacking. Nothing is private in Julia. It’s the responsibility of the programmer not to poke around in the implementation of other people’s modules, not to access struct fields unless invited, and not to commit “type piracy” (extending functions that aren’t yours to dispatch on types that aren’t yours). Unfortunately, there are a lot of examples of people ignoring proper etiquette in these matters.

On the other hand, this kind of encapsulation isn’t necessarily as essential in Julia as it is in languages like Java. For one thing, types in Julia, aside from collections, tend to be immutable. You can look at the parts, but you can’t stick your hand in the lawnmower while it’s running, so to speak. Disallowing inheritance of data layout in types also means you’re less likely have code that’s cutting cross-wise into some freaky layer cake of complexity. What you see is what you get.

Another element here is culture. Though Julia is not a functional language (collections are almost always built up with side effects), it has good support for many functional programming techniques and the community tends to favor a functional programming style. Specifically, programs tend to be structured in terms of sequences of data flowing through a processing pipeline, not in terms of defining object relationships. For this reason, composite types in Julia tend to be much simpler and less prone to abuse–though there are definite exceptions, and I think some kind of privacy enforced at the module level would be a useful feature.

I’m working on a companion to my OO guide about functional patterns in Julia. Suffice it to say that, pervasiveness of arrays and loops notwithstanding, idiomatic Julia is structured much more like Lisp than Java–and the same is true in good code in any dynamic language: Python, JS, Ruby, etc. Julia’s type system also lends itself to some interesting patterns that normally occur in statically-typed functional languages: multiple dispatch as a mechanism for pattern matching, for example, which has also lead to the trait pattern (and the trait pattern in Julia is definitely a case of a pattern being boilerplate to compensate for a missing language feature).

Anyone interested in idiomatic Julia would benefit from a general study on patterns in functional programming.

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [September 24, 2019, 11:02am UTC](https://discourse.julialang.org/t/design-pattern-the-julian-way/29002/17 "2019-09-24T11:02:27Z")

</div>

Thanks for this, maybe this kind of insight could glean some direction to this thread : [Planning Large Projects](https://discourse.julialang.org/t/planning-large-projects/28562)