# Alternative to OOP?

**URL:** <https://discourse.julialang.org/t/alternative-to-oop/137543>\
**Category:** Performance\
**Tags:** question\
**Created:** [June 10, 2026, 12:51pm UTC](https://discourse.julialang.org/t/alternative-to-oop/137543 "2026-06-10T12:51:16Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [June 10, 2026, 10:04pm UTC](https://discourse.julialang.org/t/alternative-to-oop/137543/7 "2026-06-10T22:04:55Z")

</div>

Apart from the more convenient auto-complete, my main OOP-issue in julia is the following:

It is very hard to take an existing type `MyType`, on which a lot of methods are defined, and saying “ok; now I want a `AlmostMyType` that has the same behavior, except for some few cases that I want to overwrite”.

The reason for this is that people dispatch on the concrete unextendable type `MyType`. Turning all these methods into ones that dispatch on `AbstractMyType` instead is a refactoring chore within a project, and a major API break if it crosses projects.

My thoughts how to deal with that are [here](https://discourse.julialang.org/t/oop-brained-design-patterns/135423/). That linked thread describes a design-pattern that is not terribly unergonomic, but not super pretty either.

I think that does capture both the julia / multiple-dispatch spirit and the OOP-spirit (it does at least mostly reproduce the exact same data-layout as C++ single inheritance).

---

_[View the full topic](https://discourse.julialang.org/t/alternative-to-oop/137543)._