Given two permutations of $[1…n]$, say $\pi_1(n)$ and $\pi_2(n)$, find the minimum number of swaps required to get from $\pi_1$ to $\pi_2$.

This is the easier version of the problem, since all the elements are guaranteed to be distinct. To go from $\pi_1$ to $\pi_2$, the $i$-th element of $\pi_1$ needs to go from its position $i$ in $\pi_1$ to a new position $j_i$ in $\pi_2$. It somewhat looks like this:

This looks somewhat like a graph! When we untangle this gnarly mess and straighten out the curves, this is what we get:

This graph is special: each node has exactly one outdegree and one indegree. We note that such a graph will be composed entirely of loops, considering also singleton nodes with self-loops, if any.

Theorem: Consider a digraph $G$ with $n$ nodes. If each node $i \in V_G$ has exactly one outdegree and one indegree, then $G$ consists entirely of disjoint cycles, including self-loops.

Proof: The idea that permutations can be decomposed into disjoint cycles comes from group theory. For more, see Permutation Graph. For a proof of the theorem, look at this Math SE answer.

Now if we swap two non-consecutive elements in the graph, we simply swap the two nodes and nothing else happens. But if we swap two consecutive elements, say $1$ and $5$, then $5$ goes to the place it wanted to go, and gets out of the graph, with its out-degree pointing to itself. On the other hand, the place where $3$ wanted to go, earlier occupied by $5$, is now occupied by $1$ and so the outdegree of $3$ is directed towards $1$. Thus, in a cycle of size $k$, each swap of consecutive elements reduces the cycle length by $1$ by putting one element (the one in the pair from which the outdegree emanates) in the correct place, except when $k=2$ when it puts both the elements in their correct place. So to demolish a cycle of length $k$, we need exactly $k - 1$ swaps.

Thus, if the total number of nodes in the graph is $n$ and the total number of disjoint connected components is $c$, then the minimum number of swaps needed is $\sum_{C \text{is a connected component}}(\text{Number of nodes in C} - 1) = n - c$

One special case to consider is that of the positions which are already in place, i.e. $i = j_i$. These will be represented in the graph by nodes which have self-loops and no outside connections, thus forming a singleton. Of course, involving these in a swap can never be optimal, since we will have to again waste a swap operation to bring it back to the correct place. These will, notably, not disturb the formula since we need $1-1=0$ swaps to put it to its correct place.

Thus the final algorithm to find the minimum number of swaps for two given permutations as input is:

1. Convert the transformation from permutation $\pi_1$ to $\pi_2$ into a permutation graph
2. Find the number of connected components in the graph via a standard algorithm (such as DFS), say it is k.
3. The answer is $n - k$.

Now, sitting in the returning office cab and looking at this video, my mind immediately spawns the following problem:

Given two permutations of $[1…n]$, say $\pi_1(n)$ and $\pi_2(n)$, let $f(\pi_1, \pi_2)$ be the minimum number of swaps required to get from $\pi_1$ to $\pi_2$. Find $\mathbb E[f(\pi_1, \pi_2)]$ where $\pi_1(n)$ and $\pi_2(n)$ are sampled uniformly from the set of $n!$ permutations of $[1…n]$.

A few great takes on this puzzle can be found here.

As the saying goes, the internet is full of wacky curiosities, some of which you keep coming back to years after you first discovered them, out of the very human need to internet-surf your time away, rather than out of necessity. I present to you my collection of, what I like to call, “fun stuff”.

1. Neal.fun: I personally believe that no “fun internet websites” list can be complete without a mention of the legendary neal.fun page. I personally love the “Draw a Perfect Circle” challenge the most, not only because it reminds me of A Perfect Circle, but also because figuring out a formula to calculate a percentage score for an “almost-circle” that makes sense is a nice math challenge.

2. sandtris: Tetris, but with a twist. Do try it out.

3. pointlesssites: A huge catalogue of “interesting” stuff that is enough to bash this list into obsolescence. Have fun exploring the website, for you might look up from your screen to find 2 years have passed by while you were digging into rabbitholes in this page.

4. The Evolution of Trust: Simply put, a cool guide to Game Theory without seeming like one.

5. We Become What We Behold: A nice commentary on how yellow journalism impacts how we feel about others in society, and how mass media has a huge leverage on the general public sentiment towards an event or a group of people. Makes you stop and think.

6. Nicky Case: Another creator who makes nice engaging “games” which sometimes double up as learning tools. The above two entries are actually made by Case himself but I put them separately because I discovered them independently of his general website where these are also hosted.

7. Zen Pencils: A set of ~200 beautiful webcomics, each of which takes a memorable quote, and illustrates life into it.

8. Math With Bad Drawings: I can almost smell the marker ink from those drawings.

9. QWOP: Built by Bennett Foddy, a prolific game designer, this game is more difficult than gathering yourself to study for your college exams. Contact me if you can run the full 100 metres on a regular basis ;) He’s made variations too, such as CLOP and 2QWOP.

10. Universal Paperclips: You start off with one goal: to make as many paperclips as possible. Time goes by until that goal fades into distance, with Quantum Computing, Stock Market Investing, Strategy Modeling and Space Exploration taking center stage until … all the matter in the universe is turned into paperclips and you are the only non-paperclip object in the universe. Do you have the gumption to sacrifice yourself for the greater good of having as many paperclips as possible?

11. Play Spent: Appreciate all the riches that you have.

12. One Day You Will Find Yourself …: Unsolicited advice is sometimes welcome, especially in times of boredom!

13. The Museum of Hoaxes: Some hoaxes are purely for satirical value, while some have ulterior motives behind them. Click on to uncover a world of trickery!

14. Math: One for the math nerds; this problem set has much historical value. Description of thd contents: simple solutions which are difficult to find.

15. MAN: We are moving into the more poignant territory now. What happens when a species dominates the planet and carries out mass extermination of all the remaining species, which just want to survive in harmony with the natural laws? The sequel is no less awesome.

16. There is No Game: Why click on it when there is, in fact, no game? Let’s move on to the next entry in the list…

17. Literature Clock: A very cool website for all book lovers; this website tells the time down to the minute with a quote from a book.

18. TEXnique: Competitive ranked TEXing is, apparently, a thing.

19. Wait But Why Been a lifesaver on multiple occasions.

Given a permutation $p$ of $n$ numbers, we create an array $a$ consisting of $2n$ numbers, which is equal to $p$ concatenated with its reverse. We then define the beauty of $p$ as the number of inversions in $a$. Your task is to find the sum of beauties of all $n!$ permutations of size $n$. Print the remainder we get when dividing this value by $1000000007$.

Let us call the reverse of $p$ as $\operatorname {rev}(p)$, then we notice that if $0\leq i \lt j \lt 2n$ form an inversion in $a$ then either one of these three cases must occur:

• $i \in p, \quad j \in p$
• $i \in p, \quad j \in \operatorname {rev}(p)$
• $i \in \operatorname {rev}(p), \quad j \in \operatorname {rev}(p)$

Since we are going to iterate over all permutations of $p$, we note that the first and third cases are exactly the same and we write, considering $\operatorname{inv}(p)$ to be the number of inversions in $p$, and $\pi(\cdot)$ being the set of all permutations of an array:

Summing over all the $n!$ permutations of $p = $ {$1 \dots n$} we get

Now the task of finding the sum of the number of inversions over all permutations of [1…n] is something we must tackle. $(**)$

EDIT

09 November 2024
Wait! This approach makes the problem significantly harder than it needs to be.

Approach 1

Pick any two numbers (not indices) $x$ and $y$ in $p$. In $a$, they can appear either in the order $x\ y \ y \ x$ or $y \ x \ x \ y$, in both of which cases we get a total of two inversions. Thus for any permutation $p$, its beauty is given by $2\cdot \displaystyle\binom{n}{2} = n(n-1)$, independent of the specific permutation $p$.

Hence the total number of inversions is simply this constant multiplied by the number of possible permutations, which is $n!\cdot n(n-1)$.

Approach 2

Suppose we pick two indices $i, j$ from $p$. If $(i, j)$ is an inversion in the first half of $a$, then $(i + n, j + n)$ will not be an inversion in the second half of $a$. However, if $(i, j)$ is NOT an inversion in the first half of $a$, then $(i + n, j + n)$ MUST be an inversion in the second half of $a$.

This simply means that any pair of indices $(i, j)$ from $p$ will give us exactly one inversion in $a$, and there are $\displaystyle \binom n2$ such pairs. Add to this the cross inversion term from $(2)$ and we get the same answer again, $n!\cdot n(n-1)$.

So the lesson learnt is sometimes we might need to stop a little bit early and look at the problem from a holistic point of view instead of simplifying the expression as much as possible.

$(**)$A really nice Math SE post regarding the total number of inversions across all permutations of $[1…n]$

Once upon a time, Toma found himself in a binary cafe. It is a very popular and unusual place.

The cafe offers visitors $k$ different delicious desserts. The desserts are numbered from $0$ to $k−1$. The cost of the $i$-th dessert is $2^i$ coins, because it is a binary cafe! Toma is willing to spend no more than $n$ coins on tasting desserts. At the same time, he is not interested in buying any dessert more than once, because one is enough to evaluate the taste.

In how many different ways can he buy several desserts (possibly zero) for tasting?

Upfront, this looks like a hard one: formally stated, we need to find the number of (potentially empty) subsets $S \in$ {$0, 1, \dots, k-1$} such that \(\displaystyle \sum_{i\in S}2^i \leq n.\) But when you start thinking in binary, this simplifies down to absolutely nothing! The cost when you choose the $i$ th object is $(c_i)_2 = 10000\dots 0$ where there are $i-1$ zeros. Thus, choosing a subset $S$ corresponds to activating the $j$ th bit from the right in the total cost. Eg. choose {$0, 2, 7$} and the cost is $2^0 + 2^2 + 2^7 = 128 + 4 + 1 = 133$ which corresponds exactly to $1000101$: the $0$ th, $2$ nd and $7$ th bits are on.

We, then, only need to find the number of ways we can choose places in the $k$ positions provided to us such that this combination is never greater than $n$. If the number of total places, $k$, is less than the number of bits in n, then no matter what we do, even if we choose all the elements we will still ensure total cost to be less than $n$. There are $2^k$ ways to do this, including the empty set.

On the other hand, if this is not the case, we have $n$ as our bottleneck. Here we note that if a bit is unset in $n$, it can never be selected when all the leftward set bits are selected. This gives rise to the following algorithm for this case:

• Initialise $sum = 0$.
• For each set bit in $n$, add $2^\text{number of bits to the right of the bit}$ to $sum$. This represents the number of choices when $b_i$ is turned off and all the bits to the left of $b_i$ that were set in $n$ are set.
• Finally, add $1$ to $sum$ to account for the total cost being exactly equal to $n$, which is always possible given $k > \lceil{\lg n}\rceil$.

Thus our final code is:

#include <bits/stdc++.h>
typedef long long ll;
using namespace std;
#define F first
#define S second
#define rep(i, init, upper) for(size_t i=init; i<upper; i++)

int binpow(int a, int b){
    int result = 1;
    while(b){
        if(b & 1) result *= a;
        a *= a;
        b /= 2;
    }
    return result;
}

void solve(){
    int n, k;
    cin >> n >> k;
    int total_bits = CHAR_BIT * sizeof(int);
    int leading_zeros = __builtin_clz(n);
    int msb_pos = total_bits - leading_zeros - 1;

    if(k - 1 < msb_pos) cout << binpow(2, k) << "\n";
    else{
        bool is_set[total_bits];
        for(int i=0; i<total_bits; i++) is_set[i] = (n >> i) & 1;

        int sum = 1; // for when total price is exactly n
        int power2 = 1;
        for(int i=0; i<total_bits; i++){
            if(is_set[i]) sum += power2;
            power2 *= 2;
        }
        cout << sum << "\n";
    }
}

int main(){
    ios_base::sync_with_stdio(false);
    cin.tie(nullptr); cout.tie(nullptr);
    #ifndef ONLINE_JUDGE
        freopen("../input.txt", "r", stdin);
        freopen("../output.txt", "w", stdout);
    #endif
    int t;
    cin >> t;
    while(t--){
        solve();
    }
    return 0;
}

While creating software from scratch to solve our problems, we often face many design choices. One of them that an object-oriented programmer invariably has to deal with is how to structure the polymorphic behaviour of their classes and subclasses. It is here that we start to appreciate the famous diamond problem and its many nuances.

You probably got a lot of your features from your mother, and also a lot of them from your father. In biological systems, this process of choosing which feature is inherited from whom is inherently random, and that causes the vast diversity in the world that we celebrate (or at least, should celebrate). However, as software engineers, our task is cut out and we cannot have our child classes behaving randomly, with their attributes a chaotic amalgamation of similar attributes defined in their parent classes. So we need to find a way to address this problem and define, deterministically, which attribute is inherited from which class.

Suppose we have the above class design. B is a child of A, C is a child of A, and D is a child of both B and C. This is a classic case of multiple inheritance. In the case that B and C have some common methods which are defined differently, how do we decide which implementation D should inherit? In other words, how do we implement a deterministic order in which the methods in the child classes are resolved?

Python does this through a special object called the Method Resolution Order. The MRO is a list of classes and subclasses which tells us the order in which to look for any method (which is being called) of a child class in all the classes in its inheritance hierarchy. As an example, let us implement the very simple inheritance structure A -> B -> C:

class A:  
  def func():  
    pass  
  
class B(A):  
  def func():  
    pass  
  
class C(B):  
  pass

Printing C.mro gives me <built-in method mro of type object at 0x5685f2d2d910> and calling the object with C.mro() gives us the order [C, B, A], which is intuitively expected. Now, in the case of a much more complex inheritance hierarchy, how do we define a deterministic MRO?

In Python, this is done using an algorithm called C3 Linearization. This is a linearization technique which takes into account the depth of each parent class in the inheritance hierarchy. The output of this algorithm is such that superclasses lower down in the inheritance hierarchy are searched first when looking for a method in the child class. The main step of the algorithm looks like a simple divide-and-conquer step:

C3_Linearization(C) = [C] + merge(C3_Linearization(Parents(C)), Parents(C))

The merge of Parents’ linearizations and Parents list is done by selecting the first head (the first entry of a list) of the lists which does not appear in the tail (all elements of a list except the first) of any of the lists. A singleton list is simply a head by itself. The rationale behind this first step is that any superclass that is just a head without appearing in any tail is much closer to the child semantically than any other parent which is also a parent of the child class’s parent (which is what appearing in the tail implies). Note, that a good head may appear as the first element in multiple lists at the same time, but it is forbidden to appear anywhere else.

The selected element is removed from all the lists where it appears as a head and appended to the output list. This is repeated until all remaining lists are exhausted. If at some point no good head can be selected, because the heads of all remaining lists appear in any one tail of the lists, then our algorithm fails because:

1. A class X appearing as head means that it is a parent of some layer of child classes at the given step in the algorithm
2. A class X appearing in the tail of a list implies that it is above the head of the list in the inheritance hierarchy.

Thus, if the heads of all remaining lists appear in any one tail of the lists, this implies a cyclic class hierarchy which, simply, cannot be resolved. In that case we might still run our algorithm with the additional check of not re-entering an already visited class.

Let us have an example.

In this reasonably complex class hierarchy, we have

class O  
class A extends O  
class B extends O  
class C extends O  
class D extends O  
class E extends O  
class K1 extends C, A, B  
class K3 extends A, D  
class K2 extends B, D, E  
class Z extends K1, K3, K2

the linearization of Z is computed as

L(O)  := [O]                                                  
// the linearization of O is trivially the singleton list [O],   
// because O is the ultimate base class   
   
L(A)  := [A] + merge(L(O), [O])    
    = [A] + merge([O], [O])  
    = [A, O]                           
   
L(B)  := [B, O] // linearizations of B, C, D and E are computed similarly as A  
L(C)  := [C, O]  
L(D)  := [D, O]  
L(E)  := [E, O]  
  
L(K1) := [K1] + merge(L(C), L(B), L(A), [C, A, B])            
// first, find the linearization of K1's parents, L(C), L(B), and L(A)  
// and merge them with the parent list [C, A, B]  
      = [K1] + merge([C, O], [B, O], [A, O], [C, A, B])      
// class C is a good head for the first merge step, because it only   
// appears as the head of the first and last lists  
      = [K1, C] + merge([O], [B, O], [A, O], [A, B])         
// class O is not a good candidate for the next merge step, because it  
// also appears in the tails of list 2 and 3. Class B is also not good;   
// but class A is a good candidate.  
      = [K1, C, A] + merge([O], [B, O], [O], [B])            
// class B is a good candidate; class O still appears in the tail of list 2  
      = [K1, C, A, B] + merge([O], [O], [O])                 
// finally, class O is a valid candidate, which also exhausts all   
// remaining lists and gives us our final linearization  
      = [K1, C, A, B, O]  
  
L(K3) := [K3] + merge(L(A), L(D), [A, D])  
      = [K3] + merge([A, O], [D, O], [A, D])               // select A  
      = [K3, A] + merge([O], [D, O], [D])                  // select D  
      = [K3, A, D] + merge([O], [O])                       // select O  
      = [K3, A, D, O]  
  
L(K2) := [K2] + merge(L(B), L(D), L(E), [B, D, E])  
      = [K2] + merge([B, O], [D, O], [E, O], [B, D, E])    // select B  
      = [K2, B] + merge([O], [D, O], [E, O], [D, E])       // select D  
      = [K2, B, D] + merge([O], [O], [E, O], [E])          // select E  
      = [K2, B, D, E] + merge([O], [O], [O])               // select O  
      = [K2, B, D, E, O]  
  
L(Z)  := [Z] + merge(L(K1), L(K3), L(K2), [K1, K3, K2])  
      = [Z] + merge([K1, C, A, B, O], [K3, A, D, O], [K2, B, D, E, O], [K1, K3, K2])    // select K1  
      = [Z, K1] + merge([C, A, B, O], [K3, A, D, O], [K2, B, D, E, O], [K3, K2])        // select C  
      = [Z, K1, C] + merge([A, B, O], [K3, A, D, O], [K2, B, D, E, O], [K3, K2])        // select K3  
      = [Z, K1, C, K3] + merge([A, B, O], [A, D, O], [K2, B, D, E, O], [K2])            // select A  
      = [Z, K1, C, K3, A] + merge([B, O], [D, O], [K2, B, D, E, O], [K2])               // select K2  
      = [Z, K1, C, K3, A, K2] + merge([B, O], [D, O], [B, D, E, O])                     // select B  
      = [Z, K1, C, K3, A, K2, B] + merge([O], [D, O], [D, E, O])                        // select D  
      = [Z, K1, C, K3, A, K2, B, D] + merge([O], [O], [E, O])                           // select E  
      = [Z, K1, C, K3, A, K2, B, D, E] + merge([O], [O], [O])                           // select O  
      = [Z, K1, C, K3, A, K2, B, D, E, O]

Now for another example!

The output of this algorithm is such that superclasses lower down in the inheritance hierarchy are searched first when looking for a method in the child class.

We’ll now understand this line using the following example:

Now D inherits from both C, placed at depth 2, and B, which is placed at depth 1. In this case the linearization of D will be calculated as:

L(O)  := [O]                                                  
  
L(A)  := [A] + merge(L(O), [O])    
    = [A] + merge([O], [O])  
    = [A, O]                           
   
L(B)  := [B, O]  
  
L(C) := [C] + merge(L(B), L(A), [B, A])  
      = [C] + merge([B, O], [A, O], [B, A])  
      = [C, B] + merge([O], [A, O], [A]) // choose B  
      = [C, B, A] + merge([O], [O]) // choose A  
      = [C, B, A, O]  
  
L(D) := [D] + merge(L(B), L(C), [C, B])  
      = [D] + merge([B, O], [C, B, A, O], [C, B])  
      = [D, C] + merge([B, O], [B, A, O], [B]) // choose C  
      = [D, C, B] + merge([O], [A, O]) // choose B  
      = [D, C, B, A] + merge([O], [O]) // choose A  
      = [D, C, B, A, O]

As we see, the superclass C comes first in the MRO generated by our algorithm since C is below B in the inheritance hierarchy. A crucial point to note is that the exact form of MRO depends on the order of the classes in the definition of our inheritance relationship. So writing

class B(A, O):  
  pass  
  
# and  
   
class B(O, A):  
  pass

should be expected to return different behaviour for the MRO, and can be tested readily in Python.

If you have some previous experience in algorithms, you would be curious about the time complexity of the algorithm. The algorithm is linear in the number of classes in the final MRO, plus the total number of relationships that we define from one class to another, since during the merge step we find the linearizations of the parents which recursively visits all the superclasses till the base class exactly once and traverses each relationship once. A new perspective can be found if we simply realize that the inheritance hierarchy, when visualised, is simply a directed graph, with nodes as classes and edges as relationships!

The C3 linearization algorithm can simply be represented as a topological sorting of the directed graph of the inheritance hierarchy. Also, the fact that a cyclic inheritance relationship cannot be formed into an MRO without additional conditions and compromises, is a direct analogue of the fact that only Directed ACYCLIC graphs can be linearized using topological sorting. This also gives credence to the claim of linear O(n + m) complexity in n, the number of nodes, plus m, the number of edges.

Concluding thoughts

But are complex inheritance structures actually useful? Consider the following structure:

Here, we model a GradTeachingFellow as both a Student and a Teacher. But picture this: how would you want to inherit getDepartment() for GradTeachingFellow? They might be student in one department and teach in another one. This calls for a decision to be taken for each such attribute, which is now equivalent to simply implementing all the methods of the GradTeachingFellow class using overrides, thus reducing the inheritance structure purely down to semantic significance.

We conclude with the air that having a complicated inheritance structure as the ones described above must be readily avoided for the sake of maintainability and cleanliness of code. A good software design bypasses the need for complex relationships such as circular inheritance and heavy calculations like these are best left for academic purposes!

References:

1. https://en.wikipedia.org/wiki/C3_linearization
2. https://stackoverflow.com/questions/561729/can-the-diamond-problem-be-really-solved

(Migrated from Medium on 17 August 2026)

While starting out with more advanced topics in Python, one frequently encounters a formidable beast called ‘Decorators’. While students usually learn the syntax and how to use the ‘@’ symbol above function definitions before moving on, decorators are much more fundamental to software design than they seem at first.

Decorators are a software ‘Design Pattern’ in OOPS: they are templates used to solve a specific problem in software design. Now, what is the problem that we would like to solve? We would like to have objects that fulfil one small, specific function (in keeping with the Single Responsibility Principle) and whose functionality can be extended without modifying their code (satisfying the Open-Closed Principle). We would also like to be able to add multiple functionalities, flexibly, to objects at runtime without affecting other objects from the same class.

WHY DECORATORS?

EXAMPLE: Suppose you go to buy some pizza. The pizza house has lots of toppings, sauces and vegetables, and allows customers to fully customise their pizzas. We want to design a software that calculates the price of the pizza based on the customer’s choice of ingredients.

Now, one intuitive approach to this problem would be subclassing. In this approach, we have a root class called Pizza (with a cost() method), and then we add layers of subclasses to it, with each subclass representing a unique variety of pizza that can be concocted from the given menu. Suppose the available menu is as follows:

CRUST: More cheese, Less cheese

TOPPINGS: Chilli flakes, black pepper, oregano, Sriracha

VEGGIES: Onions, tomatoes, black/green olives, smoked beans, pineapple

NON-VEG: Grilled chicken, smoked ham

Of course, each individual item has its own price which gets added to a base price.

The subclassing approach, with just a few subclasses from the second layer shown.

We have two classes, ‘More cheese’ and ‘Less cheese’, which inherit from the Pizza class, but with their own cost() methods. Further, we will have another layer with added on toppings, which will contain pizzas like ‘More cheese with chilli flakes and black pepper’, ‘More cheese with oregano’ etc., each with their own cost()s. But we will also need to add in this layer, pizzas like ‘More cheese with tomatoes and grilled chicken’ to cater to people who might not want toppings but may want veggies and non-veg.

The third and fourth layers will have pizzas like ‘Less cheese with Sriracha, onions and black olives’ and ‘More cheese with oregano, chilli flakes, onions, tomatoes, and smoked chicken’ (sounds tasty, by the way!) respectively. If we count the number of subclasses in these two levels in the hierarchy, even after ignoring customers who may want to skip a layer, we get 31 x 30 = 930 and 3 x 930 = 2790 subclasses. So, with this approach:

• The number of subclasses is simply overwhelming, and maintaining the code is going to be a mountain of a task for the developer team. Just writing the cost() methods in each of these classes to overwrite that of their parent class is a huge task. This scenario is called a Class Explosion.
• Any modification to the price of any item will send shockwaves throughout the code, as the cost() methods of all the pizzas that contain this item will have to be modified again.
• Similarly, adding an item to a level, say Tomato Sauce to Toppings, is also going to be a big endeavour, as you’ll have to write a whole lot of classes and cost() methods.

Thus, this approach may be theoretically possible, but is extremely resource-intensive, not at all scalable and thus, NOT USEFUL AT ALL.

ENTER DECORATORS.

Decorators are a kind of wrapper for objects. They take the input, add functionality (if needed), pass it to the wrapped object, take output from the object, add functionality (if needed) and output to the environment.

The UML diagram for the Decorator Pattern (source: Wikipedia)

The ‘Component’ class is usually either an interface or an abstract class. ‘ConcreteComponent’ represents the instantiable class(es) which inherit(s) from ‘Component’.

Now we define a ‘Decorator’ class which also inherits from the ‘Component’. We pass the instance of ‘ConcreteComponent’ to be decorated to the Decorator. We want the user to feel as if they are working with the actual object and not the decorator (interacting with decorators instead of the expected object can complicate things from the user’s POV). This is why, in order to make the decorator transparent, the decorator inherits from the same class as the ‘ConcreteComponent’. Thus, a decorator both ‘is’ a ‘component’ (by virtue of having the same interface as the ‘ConcreteComponent’), and also ‘has’ a ‘component’ (the instance that is passed to it).

The decorator contains the same methods as the object (‘ConcreteComponent’) and these methods are overridden to forward the method calls to the method of the same name in the ‘ConcreteComponent’ instance passed to it. The ‘ConcreteDecorator’ is a subclass of the decorator class which implements specific add-on functionalities by inheriting from the decorator class.

So, in essence, decorators are like transparent wrappers for objects, in that they add functionality but look and feel like the original object to the outside environment. Since we pass only a specific instance of a class to the decorator, other objects from the same class are not affected.

Another example: the idea for one is taken from Design Patterns: Elements of Reusable Software by E. Gamma et al.

In the above example, we create a root class for handling Visual Displays which lets the user draw on the screen with the Draw() method, with a concrete implementation being a text document. Now in the decorator class, the Draw() method is overridden to call the Draw() method of the component that is passed to it. Then we implement this pattern into two ConcreteDecorators, a ScrollDecorator (which adds scroll bars) and a BorderDecorator (which adds a black border).

The other methods of ConcreteDecorator are not shown, but we see that the ConcreteDecorator Draw() calls its parent’s Draw() (in Python this can be done using super().Draw()) which in turn calls the component’s Draw(). Thus the user need not worry about using different method calls when the object is wrapped in a decorator, and can keep using it as the original TextDoc object. Thus the user can add/remove scrolls and borders whenever necessary.

Let us return to our pizza example.

Suppose a customer asks for a ‘More cheese with oregano, onions, and smoked ham’. You know that a More cheese pizza has a base cost of $10, and oregano, onions and smoked ham cost $1, $6, and $15 respectively. In the decorator approach, we define decorators of all the possible add-on items (Toppings, Veggies and Non-Veg) and have their cost() methods defined as

return self.cost + self.component.cost()

Here, the user (the cashier) enters the pizza name, and it is processed as

pizza = smoked_ham_decorator(onions_decorator(oregano_decorator(more_cheese_object)))

Now, the program calls the pizza.cost() method, which invokes the smoked_ham_decorator’s cost() method. Now, this decorator thinks that it contains a ‘Pizza’ (ConcreteComponent) object (because the onion_decorator, by design, has the Component (Pizza) interface, so it behaves as a Pizza object). So it calls the self.component.cost() method, which happens to be the onion_decorator.cost().

Similarly, onion_decorator.cost() is coded in the same way, and onion_decorator too thinks that it wraps a Pizza object when in reality, it is the oregano_decorator. These calls go on recursively, till we get to the more_cheese_object, which is in fact a Pizza object, and returns more_cheese_object.cost() = $10. Thus we get the price as:

PRICE = $ 15 + ($ 6 + ($ 1 + ($ 10))) = $ 32.

Thus, decorators help us:

• Add a functionality to an object multiple times. If a customer wants two layers of onions on his Less Cheese pizza, we can just have it decorated as

onion_decorator(onion_decorator(less_cheese_object))

• Add the same functionality to multiple objects, adhering to the paradigm of keeping the code DRY (Don’t Repeat Yourself).
• Not have objects depend on parameters that they don’t need.

Decorators offer an elegant solution to a number of problems in software design, while supporting flexibility, code reuse and division of labour within the code, making them, in my opinion, fundamental to object-oriented software design. Hopefully, after this introduction to decorators, you’ll understand what’s going on behind the scenes when you write an ‘@’!

(Migrated from Medium on 17 August 2026)