DEV Community: Vlad Ogir

Django Proxy Models: The Secret Weapon for Cleaner, Simpler Code

Vlad Ogir — Fri, 16 May 2025 08:02:05 +0000

We store data to record the state: A password change, an order made, an order delivered and etc. Such things can be seen as stand-alone events or, in many cases, they are part of a step in a process. And, it's common to see those things be chucked into a single table.

All those columns can result in models that bloat to 1000s of lines. When looking at a model like that, you may have an urge to group all columns and methods to make sense of what is going on. It's tiring enough doing it once, but it becomes a bigger issue when you and others have to go through the same process each time.

In situations like this, proxy models can become invaluable! They can enable you to split columns in models into targeted sections.

In this article, I will:

Share the basics of what proxy models are
Why should we use them
Give practical examples

Throughout the article, I will use an imaginary Post model that got too big. The focus will be to partition the Post model by state into proxy models.

What are proxy models?

Proxy models are there to "decorate" existing Django models. This is very similar to what Python's decorators do or the Decorator pattern, except we apply decoration on a model.

Proxies are also similar to model abstraction. The Proxy model inherits the data and base methods from the parent model, but without affecting the underlying table that the model represents. This removes the ability to make any changes to the underlying table structure via proxy models.

You can learn more about proxies in Django's docs.

Why use proxy models?

Models can easily get to the point where they become bloated quickly, and this can lead to difficulties in understanding the purpose of the model and when methods should be used. In the end, the code can end up being overcomplicated.

With proxies, we can resolve these problems by simply extracting code specific to the state into the proxy model. As a result, you end up with smaller, targeted models that are easier to understand and to maintain.

Example Usage

Let's imagine we are working on a blog, and as part of the process, all posts have to go through a review.

When a post is created, we don't need to know things like the performance of a post or the review process. These things are only applicable once the post is in a certain state.

Now, imagine we have a bloated Post model. With the help of proxies, we can create classes that encapsulate specific states and have state-specific functionality. In the example below, I demonstrate exactly that by encapsulating Draft and Published states:

from django.db import models

class Post(models.Model):
    subject = models.CharField(max_length=30)
    content = models.TextField()

class DraftPost(Post):
    # custom defaults for class properties can be defined
    type = BLOG_TYPE_DRAFT

    class Meta:
        proxy = True

    def complete_state(self):
      self.status = STATUS_READY_FOR_REVIEW
      self.save()

class PublishedBlog(Post):
    # we can override base object with a custom manager
    objects = PublishedBlogManager()

    type = BLOG_TYPE_PUBLISHED

    class Meta:
        proxy = True

    # we can have our own custom methods or override parent's methods
    def performance(self):
      ...

By doing this, we have:
✅ Improved visibility of states
✅ Proxy classes can now be used as type hints
✅ State-specific methods are within their own class
✅ We have definition of how to transition to the next state
✅ We limit scope of QuerySet of each proxy using custom managers

Now it's a lot clearer and safer to work with data.

Proxy model resolver: turning Model into Proxy equivalent

One downside to using proxies is that Django doesn't auto resolve the parent model to a proxy model when retrieving data from a database. So when using DraftPost proxy to retrieve data, Django will return Post models back.

To resolve this problem, we can create a function that will turn Post models into a correct proxy model. To achieve this, we need a column (or a combination of columns) that determines the current state. For simplicity, I will use the status column for this purpose.

The code below demonstrates how this can be accomplished by:

Create a mapper that maps status to a proxy class.
Then create a method that will turn a class into a proxy representation, based on the current status.

from django.db import models

class Post(models.Model):
  # Mapper that maps status to a proxy class
  POST_STATUS_FLOW = {
    STATUS_DRAFT: DraftPost,
    ...
  }

  # Method that turns class into a relevant proxy class
  def resolve_proxy_model(self) -> Post:
      proxy_class = MAPPER.get(self.status)
      self.__class__ = proxy_class

      return self

...

# usage
proxy_model = post.resolve_proxy_model()

💡 You can also automatically resolve the proxy model without manually calling the resolver method.

Conclusion

Proxy models can be a very useful tool to separate concerns. It allows you to encapsulate all the relevant logic for the state in one single class. Afterwards, you can create custom methods, query managers and transition-related requirements for that single state.

Additionally, this technique will improve the visibility of different states and make it easier for other engineers to understand the intended flow of the whole process.

But, proxies shouldn't be seen as a solution for a lack of database design. Since well-defined data would avoid the need for proxies to begin with!

So, why wait? Pick some models and start refactoring today!

I'd love to hear your thoughts! Please share your questions and insights in the comments below or contact me directly.

Attacking the Furthest Enemy in Range (Tower Defence)

Vlad Ogir — Fri, 06 Dec 2024 21:50:40 +0000

In the previous article, I demonstrated how to efficiently track the furthest enemy using a max heap. In this article, we’ll see how to integrate that into a game mechanic.

Event-Driven Approach

The existing implementation uses an event-driven architecture. For this article, we will focus on the Enemy events. Those events will trigger spin-off actions.

Each enemy can experience various events. Below is an example of a life cycle that the enemy may go through:

For the article, I am interested in the two events:

enemyMoved: Fired when an enemy's position changes.
enemyRemoved*: Fired when an enemy is removed from the game (e.g. defeated).

(* I plan to adjust event names in the future since an enemy can be removed for different reasons.)

Plan

I created an Event Model diagram to visualise how different events interact. This helps with understanding how things connect.

For every event, I have a command that triggers it. (So, an event is the outcome of a command.) In some cases, as a result of an event, we will need to update data (green sticky notes depict this). A combination of all three together is a vertical slice.

My focus will be on the green sticky note "Enemies within tower's range". We will create a test first and then implement the code.

Implementation

The goal is for us to update available enemies whenever an enemy is within the tower's range and remove them if not.

We will be working with a tower class. In this class, we have a variable to store enemies.

export class Tower implements ITower {
    public enemies = new MaxHeap()

    constructor(id: number, coords: Coordinate) {
        this.id = id
        this.coords = coords

        // listeners will go here...
    }
}

Placing event listeners in the Tower class centralises the logic, reducing the need to maintain mappings between towers and enemies. While this adds some complexity to the class, it ensures better encapsulation and simplifies debugging, which is an easier direction to take for now.

Action: Adding Enemies Within Range

Test: Adding an Enemy

First, we’ll write a test to verify that an enemy within range is added to the tower's enemies heap:

it('should add an enemy to the tower when enemy is within range', () => {
    const tower = new Tower(1, { col: 0, row: 1 });
    const enemy = new TinyEnemy();
    enemy.currentPosition = { col: 0, row: 0 };

    triggerEnemyMovedEvent(enemy);

    expect(tower.enemies.length()).toBe(1);
});

triggerEnemyMovedEvent is a helper method that dispatches an event.

Implementation: Adding an Enemy

Here’s the corresponding implementation:

window.addEventListener("enemyMoved", event => {
    const enemy: Enemy = event.detail.enemy;

    if (enemyWithinRange(this, enemy)) {
        this.enemies.insertOrUpdate(enemy.id, enemy.distanceTraveled);
    }
});

Whenever enemyMoved is triggered, we will check if an enemy should be added to the heap. I already have enemyWithinRange function, it's a matter of adding insertOrUpdate call.

Action: Prevent Adding Out-of-Range Enemies

Test: Ignoring Enemies Out of Range

Next, we ensure that enemies outside the tower's range are not added:

it('should not add an enemy to the tower if enemy is out of range', () => {
    const tower = new Tower(1, { col: 0, row: 1 });
    const enemy = new TinyEnemy();
    enemy.currentPosition = { col: 0, row: 99 };

    triggerEnemyMovedEvent(enemy);

    expect(tower.enemies.length()).toBe(0);
});

Implementation: Ignoring Enemies Out of Range

This scenario is already covered by our earlier check using enemyWithinRange, so no additional code is required.

Action: Removing Enemies Out of Range

Test: Removing an Out-of-Range Enemy

Now we test that enemies leaving the range are removed from the tower's visibility:

it('should remove an enemy from the tower when it moves out of range', () => {
    const tower = new Tower(1, { col: 0, row: 1 });
    const enemy = new TinyEnemy();
    enemy.currentPosition = { col: 1, row: 1 };

    // enemy within range
    triggerEnemyMovedEvent(enemy);
    expect(tower.enemies.length()).toBe(1);

    // enemy outside of the range
    enemy.currentPosition = { col: 1, row: 99 };
    triggerEnemyMovedEvent(enemy);

    expect(tower.enemies.length()).toBe(0);
});

Implementation: Removing an Out-of-Range Enemy

window.addEventListener("enemyMoved", event => {
    const enemy: Enemy = event.detail.enemy;

    if (enemyWithinRange(this, enemy)) {
        this.enemies.insertOrUpdate(enemy.id, enemy.distanceTraveled);
    } else if (this.enemies.hasEnemy(enemy.id)) {
        this.enemies.deleteEnemy(enemy.id);
    }
})

If the enemy used to be within the range then we can remove it.

Action: Removing an Enemy from the Game

Test: Handling `enemyRemoved` Event

Lastly, we ensure that enemies removed from the game are also removed from the tower's heap:

it('should remove an enemy from the tower when the enemy is removed', () => {
    const tower = new Tower(1, { col: 0, row: 1 });
    const enemy = new TinyEnemy();
    enemy.currentPosition = { col: 0, row: 0 };

    triggerEnemyMovedEvent(enemy);
    expect(tower.enemies.length()).toBe(1);

    triggerEnemyRemovedEvent(enemy);

    expect(tower.enemies.length()).toBe(0);
});

Implementation: Handling `enemyRemoved`

window.addEventListener("enemyRemoved", event => {
    const enemy: Enemy = event.detail.enemy;

    if (this.enemies.hasEnemy(enemy.id)) {
        this.enemies.deleteEnemy(enemy.id);
    }
});

Whenever an event is triggered, if the enemy is within the range then we can remove them.

Conclusion

By combining an event-driven approach with a max heap, we achieved an efficient way for towers to prioritise enemies dynamically. The implementation ties seamlessly into the game's event system, ensuring real-time updates and responsiveness.

Additionally, when it comes to testing, using an event-driven approach removes the need to tie internal code to test. Hence making tests less brittle. We can refactor code behind behaviour in whatever way we want, and as long as events/listeners are set up correctly, tests should still pass.

This implementation can now pave the way to:

Adding attack functionality (now that we know who to attack)
Swapping how data for enemies is stored

Feel free to adapt this approach for your own tower defence games.

Tracking Furthest Enemy in a Tower Defence Game using Max Heap

Vlad Ogir — Sat, 23 Nov 2024 21:55:20 +0000

We have multiple enemies on the map, but which enemy should a tower focus on?

Looking at a map as a player, it's an easy question to answer — the furthest enemy within tower range. But it’s not a simple thing to code!

In this article, I will explain how to use the max heap to track the furthest enemy on the map. The answer to this question is the building block towards enabling towers to track enemies more effectively.

This article is part of a larger series of articles where I explore the development of a tower defence game.

Current Implementation

In the existing implementation, whenever an enemy moves on the map, I trigger an event called EnemyMoved. This event then triggers an update of the enemy's position on the map. The code below is for the update function:

function updateAvailableEnemyStore(enemy: Enemy): void {
    if (enemy.getPrevPosition()) {
        const prev_position_key  = `${enemy.getPrevPosition().row}${enemy.getPrevPosition().col}`
        enemySpatialGrid[prev_position_key][enemy.id] = false
        delete enemySpatialGrid[prev_position_key][enemy.id]
    }

    if (enemy.getPosition()) {
        const current_position_key = `${enemy.getPosition().row}${enemy.getPosition().col}`
        enemySpatialGrid[current_position_key][enemy.id] = enemy
    }
}

I used an array enemySpatialGrid that tracks enemies in each cell on the map. This way, I can see what enemies are present within any cell.

Towers also use this array to locate enemies to attack within their range.

This implementation does the job, but there is a key issue: we don’t know if an enemy we pick from a cell is the furthest and within the tower’s range. This is because enemies within cells are in no particular order.

Why Max Heap?

Max Heap can enable us to do the following:

Return the furthest enemy with a time complexity of O(1).
Computing the furthest enemy when a new enemy is added or distance updated with a complexity O(logN).
Removing enemies from the heap at O(logN) time complexity.

Alternatives

A simple alternative is to sort enemies within a cell by distance. Afterwards, a tower can loop through enemies in a cell and get the first enemy within its range.

There are issues with this approach:

Sorting items generally takes O(N logN), this is slower than max heap.
Enemies that we loop through might not be within the tower’s range. It’s quicker to grab the first element from the max heap.

There are other approaches. One example is a balanced binary search tree. However, I will not be covering those.

Intuition

We can tell which enemy is the furthest by looking at the map. But, how can we achieve the same using code?

One way is to measure the distance the enemy travelled. Then we can compare distances between enemies. The enemy with the longest distance is the furthest.

Implementing Heap

To implement a heap we need an array (the heap) and a dictionary (the positions). The heap will be used to store enemy distances [4,3,2,1]. The positions mapper will map enemies to the indexes in the heap { 1:0, 2:1, 3:2, 4:3 }. This will help us keep distances for each enemy up to date. When the enemy moves, we will update both the heap and positions.

This is how both heap and positions can be demonstrated using a tree and a table:

This is our base class for max heap, with the methods that we will implement:

class MaxHeap {
    heap: [number, number][] = [];
    positions: { [key: number]: number } = {};

    constructor() {
        this.heap = [];
        this.positions = {};
    }

    public insertOrUpdate(enemy_id: number, distanceTravelled: number): void;
    public deleteEnemy(enemy_id: number): void;
    public peek(): number;
}

export default MaxHeap;

1. Implementing “adding an enemy”

To add an enemy, we need to do three things:

Add the enemy’s distance to the heap.
Map the enemy to the index in the heap.
Bubble the enemy’s position in the heap by comparing the enemy’s distance to its parent.

When adding an enemy to the heap, we will insert both distance and enemy ID. (This way we will know what enemy distance belongs to.)

The code below shows how an insert can be implemented:

public insertOrUpdate(enemy_id: number, distanceTravelled: number): void {
    const id = enemy_id;

    if (id in this.positions) {
        // TODO: enemy needs to be updated
    } else {
        // add distance to the heap
        const array_length = this.heap.push([enemy_id, distanceTravelled]);

        // map enemy to the index
        const index = array_length - 1;
        this.positions[id] = index;
    }

    // bubble enemy up
    this.bubbleUp(index);
}

Bubbling up distance is a little bit harder. We need to compare the added distance to its parent. If a parent is of lower value, we need to swap a parent with a child.

Below is a visual example of going through the process, building from Figure 2. In the example below we will add a new enemy with id 5 that travelled a distance of 3.5.

1 - Add a new enemy to the back and map the enemy position to index in the heap.

2 - Check if bubble-up is possible against its parent. A parent needs to be smaller than a child.

3 - Yes, bubble-up is possible, do the swap!

4 - Now, we must go back to step 2 until the parent is greater than the child.

This is the code for the bubble-up:

protected bubbleUp(index: number): void {
    while (index > 0) {
        const parentIndex = Math.floor((index - 1) / 2);

        if (this.heap[parentIndex][1] < this.heap[index][1]) {
            this.swap(parentIndex, index);
            index = parentIndex;
        } else{
            break
        }
    }
}

A parent is stored at the position floor((index — 1)/2). In array [1,2,3], 1 is a parent of both 2 and 3.

We then compare the parent value to the value at the index. If a parent is less than a child, do the swap.

The code for the swap is below:

protected swap(index1: number, index2: number): void {
    [this.heap[index1], this.heap[index2]] = [this.heap[index2], this.heap[index1]];

    this.positions[this.heap[index2][0]] = index2
    this.positions[this.heap[index1][0]] = index1
}

2. Implementing “update enemy position”

An update is done similarly to adding a new enemy. Except we need to know the enemy’s position in the heap. After that, we need to update the distance travelled in the heap and bubble up.

public insertOrUpdate(enemy_id: number, distanceTravelled: number): void {
    const id = enemy_id;

    if (id in this.positions) {
        const index = this.positions[id];
        this.heap[index] = [enemy_id, distanceTravelled];
    } else {
        // previous code for adding enemy here...
    }

    // bubble enemy up
    this.bubbleUp(index);
}

3. Implementing “deleting an enemy”

Generally, items are popped from the heap, but in the game, enemies might be killed before reaching the top.

To achieve deletion, we need to take three steps:

Swap element to be deleted with the last element in the heap.
Pop the last element from the end of the heap.
Bubble down swapped element.

The code for the delete functionality:

protected deleteEnemy(enemy_id: number): void {
    const index = this.positions[enemy_id];

    // swap enemies
    this.swap(index, this.length() - 1);

    // delete enemy
    this.heap.pop();
    delete this.positions[result[0]];

    // bubble down swapped element
    this.bubbleDown(index);
}

In the example below I will take you through visuals of deleting the furthest item in the heap, as shown in the Figure 7.

1 - We swap the first element with the last element.

2 - Delete the last element

3 - Bubble the enemy down if necessary by comparing the parent to its children. If any of the children are smaller than the parent, bubble down the parent, by swapping the parent with the largest child.

4 - Keep repeating step 3 until bubble down is not possible.

This is the code for the bubble down:

protected bubbleDown(index: number): void {
    while (index < this.length() ) {
        const leftChildIndex = 2 * index + 1;
        const rightChildIndex = 2 * index + 2;

        const leftVal = this.heap[leftChildIndex] ? this.heap[leftChildIndex][1] : -Infinity;
        const rightVal = this.heap[rightChildIndex] ? this.heap[rightChildIndex][1] : -Infinity;

        const targetIndex = leftVal > rightVal ? leftChildIndex : rightChildIndex;
        const target = this.heap[targetIndex]

        if (target && target[1] > this.heap[index][1]) {
            this.swap(targetIndex, index);
            index = targetIndex;
        } else{
            break
        }
    }
}

We get indexes for the left and right child. Afterwards, we grab the largest child of the two and compare it to the parent. If the child is greater than the parent, swap values.

4. Implementing “peek”

This is the simplest thing to implement. Since the heap is already sorted, we just need to grab the first element in the heap:

public peek(): [number, number] {
    return this.heap[0];
}

Start using Heap!

Now that we have implemented the heap, we can integrate it into the code!

The original code, within updateAvailableEnemyStore, can now be swapped for a one-liner:

const furthest_enemies = new MaxHeap()

function updateAvailableEnemyStore(enemy: Enemy): void {
    furthest_enemies.insertOrUpdate(enemy.id, enemy.distanceTravelled)
}

There is also an event responsible for the removal of enemies from the maps. This is where heap delete will go.

window.addEventListener("enemyRemoved", event => {
    const enemy: Enemy = event.detail.enemy

    furthest_enemies.deleteEnemy(enemy.id)
});

You can see the outcome of this in the video below:

Conclusion

There it is. We implemented a max heap and then applied it to the game.

Max heap successfully solved the problem. Now we know the furthest enemy on the map. Additionally, the max heap is more performant than the existing implementation.

Lastly, its implementation paves the way to integrating it with towers. This will make it easier for towers to know what enemy to attack next.

DEV Community: Vlad Ogir

Django Proxy Models: The Secret Weapon for Cleaner, Simpler Code

What are proxy models?

Why use proxy models?

Example Usage

Proxy model resolver: turning Model into Proxy equivalent

Conclusion

Attacking the Furthest Enemy in Range (Tower Defence)

Event-Driven Approach

Plan

Implementation

Action: Adding Enemies Within Range

Test: Adding an Enemy

Implementation: Adding an Enemy

Action: Prevent Adding Out-of-Range Enemies

Test: Ignoring Enemies Out of Range

Implementation: Ignoring Enemies Out of Range

Action: Removing Enemies Out of Range

Test: Removing an Out-of-Range Enemy

Implementation: Removing an Out-of-Range Enemy

Action: Removing an Enemy from the Game

Test: Handling enemyRemoved Event

Implementation: Handling enemyRemoved

Conclusion

Tracking Furthest Enemy in a Tower Defence Game using Max Heap

We have multiple enemies on the map, but which enemy should a tower focus on?

Current Implementation

Why Max Heap?

Alternatives

Intuition

Implementing Heap

1. Implementing “adding an enemy”

2. Implementing “update enemy position”

3. Implementing “deleting an enemy”

4. Implementing “peek”

Start using Heap!

Conclusion

Test: Handling `enemyRemoved` Event

Implementation: Handling `enemyRemoved`