# Contract extensibility pattern **URL:** \ **Category:** SNIPs\ **Tags:** cairo, conventions\ **Created:** [December 15, 2021, 12:18am UTC](https://community.starknet.io/t/contract-extensibility-pattern/210 "2021-12-15T00:18:05Z")\ **Posts on this page:** 1\ **Showing post:** 11
**Author:** ![maciejka](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/maciejka/32/96_2.png) [@maciejka](https://community.starknet.io/u/maciejka)\ **Post date:** [January 3, 2022, 11:46am UTC](https://community.starknet.io/t/contract-extensibility-pattern/210/11 "2022-01-03T11:46:23Z")
If I were asked to vote on the direction Cairo should take to answer the question of code reuse, I would strongly vote to apply wisdom from the development of object oriented paradigm, which is [composition over inheritance](https://en.wikipedia.org/wiki/Composition_over_inheritance). Inheritance can be so easily abused that it should be considered an [antipattern](https://www.quora.com/Is-inheritance-bad-practice-in-OOP-Many-places-that-teach-design-patterns-say-to-opt-for-composition-over-inheritance-but-what-about-when-multiple-classes-share-logic-from-an-abstract-class-such-as-in-the-Template-Method-design-pattern). In my opinion current code inclussion mechanism should be refined rather in the direction of [traits](http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf) than a full blown inheritance. --- _[View the full topic](https://community.starknet.io/t/contract-extensibility-pattern/210)._