Problem

Many organisations operate in product mode, optimising for execution and delivery instead of learning. Delivery cadence often has a slow feedback loop, and engineering and marketing work in silos [p. 34]. Teams may not run typical Agile, and their sprints may become task batches inside a larger delivery cycle, which means they ship without fast validation. They may now have meetings that involve the whole team, but still not operate as a truly cross-functional team. Individual experiments can be encouraging, but the real challenge is scaling that experimentation process across the company and making it a consistent cross-functional habit.

Solution

The shift is from input-driven delivery to outcome-driven growth. A growth engineering operating model uses a single, weekly growth cycle that prioritises experiments against clear metrics such as activation, retention, and revenue, and then scales what works.

• Growth meeting: A weekly growth meeting happens on a fixed day each week. The main focus of the team switches from sprints to weekly growth cycles.
• Product delivery moves to longer planning cycles: Typical sprint rituals align to the broader product delivery cycle, creating 4+ week long cycles.
• Standup: Standup remains the same format, but is unblocker focused.
• Focus on outcomes: All work ties to target metrics; decisions are made on expected impact and measured results.
• Deploy to prod: To facilitate weekly experiment turnaround, deploy small changes via production. Keep larger product delivery cycles deploying upstream.

Experiment Cycle

All experiments move through the following process:

Analyse -> Ideate -> Prioritise -> Test

The experiment starts with a written idea that lives in the idea backlog. Ideas are prioritised using the ICE framework. Ideas are written and prioritised async. Ideas are tested and analysed in a growth cycle.

The Idea [p. 120]

Ideas are logged in the idea backlog and have the following form:

• Name
• Description (like an executive summary, who, what, when, where, why, how)
• Hypothesis (no broad strokes)
• Metrics to be measured (most should measure more than one)

Prioritise [p. 124]

Prioritise the idea backlog asynchronously using the ICE framework:

• Impact (out of 10)
• Confidence (out of 10)
• Ease (out of 10)
• Average (out of 10)

Roles

A growth team consists of the following roles. Everyone contributes to the idea backlog.

• Growth lead [p. 38]
  • Part manager, part product owner, part scientist
  • Chooses the core focus area and objectives for the team to work on
  • Ensures the metrics are appropriate for the growth goals established
• Product manager [p. 39]
  • The CEO of the product
  • Oversees how features and designs are brought to life
  • Responsible for breaking down silos between engineers and marketing
• Engineers [p. 40]
  • Writes the code for product features that the team experiments on
  • Should be involved in the ideation process, not just task delivery
• Marketing [p. 40]
  • Required in a growth team for optimal results
  • Cross-pollinates their experience with engineering
• Data analyst [p. 41]
  • Ensures that experiments are well statistically designed and rigorous
  • Ensures user data and analytics are accessible through the analytics database
  • Mines for deep insight in the data

Growth meeting [p. 134]

The growth meeting is a weekly meeting that happens at a fixed time each week. It is run by the growth lead and kept on time to schedule. Everything covered in the growth meeting is planned and decided ahead of time. What is decided in the growth meeting is which experiments are going to be run this cycle, based on prior prioritisation, and who is going to own each one.

• 15 mins: metrics review and update focus area
• 10 mins: review last week's testing activity
• 15 mins: key lessons learned from analysed experiments
• 15 mins: select growth tests for current cycle and assign owners
• 5 mins: check growth of idea pipeline

The Transition Week

The first growth meeting should be used to loop everyone into the process and explain how it is going to work [p. 114]. The following week, team members take time to percolate ideas for what experiments to run in their first growth cycle, adding ideas to the idea backlog [p. 116].

Before starting the first experiment, it is a requirement to have the "Aha" moment defined, data tracking in place, the fundamental growth equation defined, and the goal defined.

The "Aha" moment [p. 63, 84] is the moment at which the user truly experiences the core value of the product, the instant at which the product clicks for them. For Dropbox, for example, it was when files had been synced across devices and the user realised they could access them from anywhere.

The fundamental growth equation [p. 91, 116] is the simplest way to express what drives a company's growth. It describes the company's core metrics and how they interact with each other to drive growth. For example:

amount of growth = number of installs
                 * number of monthly active users
                 * number of purchasers
                 * average order size
                 * repeat purchase rate

The goal should be a single clear target, adapted to the organisation. For example: 3000 paid monthly active users by the end of the year.

I've been a builder for 10 years, and I've built products that went nowhere because they were either too complex or had no identity. These are the constraints that I landed on after making those mistakes.

One page or it doesn't get built

This constraint limits complexity and ambiguity.

Write a one pager for all of your ideas. Your one pager captures your north star. It's non-negotiable, precise, ambitious, and lean. Once your one pager is written, it is applied to all different types of communication. Share it as a memo for investors, contributors, team members, friends, or family. Working collaboratively on a product, there will always be contention points and conflict, it can sometimes be difficult to know what battles to pick. If it's not in the one pager, then it's either not worth fighting over, or the one pager ought to be amended to include the thing. Not only is a one pager useful for communication, it's useful for organising your own thoughts. If you can't fill one page, don't fill the gaps with fluff, it means you're not ready to build. First research, plan, prototype, then write the one pager again. Iterate. If it requires more than one page, it's too complex, don't build it.

The core tech must be separable from the product

This constraint limits you to ideas that have real leverage and originality.

Develop a core piece of technology that supports your product and is not the product itself. The core tech is a method, skill, tool, or even product that supports what you're doing today but must survive without it. It's a type of reusable IP. Why? Separating the core tech forces you to think beyond the product that you're building. Products pivot in direction all the time, while your core tech is constant and compounding. Compounding efforts have non-linear gains over longer time horizons. Linus Torvalds developed git to improve the Linux kernel development workflow. HashiCorp has HCL (HashiCorp Configuration Language). Google has Kubernetes. But you don't need big tech resources to build core tech, it could be a library that you extract from your codebase, or even a methodology that you refine and commit to. Your core tech is your long term commitment. It is independent of your product's direction. However, it must be aligned with you or your company's long term vision. If your idea doesn't enable core tech, then it isn't high enough leverage.

One defining constraint must shape the product

This constraint limits feature creep and forces identity.

Define your own constraint that is front and centre to your product. That means the user sees and interacts with it all the time. It is obvious and it is what gives your product identity. A good constraint gives your product a feel, it permeates through all parts of the user experience. Minecraft is built entirely from blocks. IKEA is flat-pack, self-assembly furniture. The constraint that you choose limits scope by reducing your decision space, enabling you to concentrate on the problems that really make the difference. If you don't choose a constraint, or choose a bad constraint, you will build a bloated product that will try to do everything. The design of your product will "fall out" of a well-designed constraint. Like in your product, your constraint must be front and centre in your one pager.

Closing Rule

When it comes to deciding what to build, if it fails any of these constraints, then I don't build it.

Okay so this might seem like a bit of a strange article. But trust me. I've had this burning idea recently to combine retro computer components to create something a bit different. In this case, it's an emulation of a ZX Spectrum display wired up with a 6502 processor. What makes this strange is that the ZX Spectrum uses a Z80 processor, not a 6502. This will be part of a series of articles where I'll combine retro and modern technology together in weird and wonderful ways to create experiments. There is a lot of support for the 6502 processor thanks to the worldwide popularity of systems like the Commodore 64 and the Nintendo Entertainment System.

There is something special about the ZX Spectrum. It was released in the UK in 1983 for £125, taking the domestic home computer market by storm. It almost instantly took off as a kind of game console of its day, birthing the likes Manic Miner, Knight Lore and Atic Atac. Being an incredibly cheap machine of its day, a lot of corners were cut. One corner most notable was its graphics capability.

The graphics of the ZX Spectrum consist of a 256x192 bitmapped screen, with 8x8 pixel attribute blocks. Now, the most striking thing here is that each attribute blocks could only have two colours. Those attribute blocks were fixed to a grid. This was unlike other machines at the time, which had support for more than two colours and even native sprites. In a way, it was like the ZX Spectrum was actually monochrome, with a sprinkle of colour added to its monochromatic display to give the illusion of colour. The result - a breadth of games that had an unusual, unpolished, but undoubtedly unique ZX Spectrum look to it.

How does it work?

The display itself is memory mapped into two main sections. The pixel data is written from addresses 0x4000 to 0x57FF. The attribute data written from 0x5800 to 0x5AFF. This meant that the pixel data has 6144 bytes, while each byte of the attribute corresponded to its respective 8x8 block.

Pixel Data

Let's look at the pixel data specifically for now. It's a 256 pixel width (32 columns), with 192 pixels height (24 rows). That is further broken down into 3 areas. Each area is 8 rows and 32 columns, conveniently totaling 2048 bytes each. Something to note about areas, each line in the 8 rows are interleaved. So if setting the first line of your block is done at address 0x4000, the second line is set at 0x4100, the third at 0x4200.

For demonstration sake, let's set the first 256 bytes to 0xFF, from address 0x4000 to 0x40FF. This will show the interleaved nature of the areas.

Attribute Data

The attribute data is what defines an 8x8 block's colour. The attribute block is broken town into two components, the least significant 3-bits which are used for storing the 'ink', the next least significant 3-bits for the 'paper'. Then the 7th most significant bit for whether the colours are bright or not. Finally the most significant bit is for the 'flash'. The 'paper' dictates how the 0 bits are coloured, the 'ink' dictates how the 1 bits are coloured.

The ZX Spectrum used a GRB colour scheme instead of a RGB one. Looking at each 3-bit colour, here is the table by bit breakdown.

The example below shows each block incremented one at a time. So the first attribute block would be binary %00000000 (black paper, black ink), %00000001 (black paper, blue ink) and so on.

Useful functions

Let's try a more interesting example. Let's say we want to draw a pixel at the mouse cursor. We're going to memory map the mouse X and Y positions relative to the screen to addresses 0x3FFE and 0x3FFF respectively.

In order to draw the mouse position on the screen, we have to calculate a few different things. We have to calculate the row, column, line and area that we'd like to draw onto. As well as calculating the individual byte itself.

The row is calculated by taking the mouse y position, masking it against 00111000 and bit-shifting twice to the left.

mouse_row:
    .byte $00
update_mouse_row:
    LDA mouse_record_y
    AND #%00111000
    ASL
    ASL
    STA mouse_row
    RTS

To get the column, we take the mouse x position and bit-shift right three times. abcdefgh -> 000abcde.

mouse_column:
    .byte $00
update_mouse_column:
    LDA mouse_record_x
    ROR
    CLC
    ROR
    CLC
    ROR
    STA mouse_column
    RTS

For the line, we're going to mask the first 3 bits. abcdefgh -> 00000fgh.

mouse_line:
    .byte $00
update_mouse_line:
    LDA mouse_record_y
    AND #%00000111
    STA mouse_line
    RTS

To calculate the area, take the most significant 2 bits. In this example, we just bit-shift three times to make it easier to calculate the final address where we're going to draw to the screen.

mouse_area:
    .byte $00
update_mouse_area:
    LDA mouse_record_y
    AND #%11000000
    ROR
    ROR
    ROR
    STA mouse_area
    RTS

Having the row, column and area is only good enough to draw to a specific byte on the screen. However, we also want to draw to a specific pixel. To achieve this we have to bit-shift a single pixel right n number of times. We calculate n by masking the least significant 3 bits from the mouse's x position.

mouse_byte:
    .byte %10000000
update_mouse_byte:
    LDA mouse_record_x
    AND #%00000111
    TAX
    INX
    SEC
    LDA #%00000000
loop_update_mouse_byte:
    ROR
    DEX
    BNE loop_update_mouse_byte
    STA mouse_byte
    RTS

Finally to draw, we have to calculate the address, then write the byte to that address in memory in order to draw to the screen. Fortunately, the address is two bytes, so the calculation can be broken down into two separate ones.

Let's calculate the offsets. For the least significant byte of the offset we do column + row, simple!

LDA mouse_column
    ADC mouse_row
    STA draw_pixel_offset

For the most significant byte of the offset, we do line + area. Also simple! Although, figuring this out by hand is usually quite tedious.

LDA mouse_line
    ADC mouse_area
    STA draw_pixel_offset + 1

Then finally you just add the bitmap address (0x4000) to the offset to get the bitmap address you're actually going to write to.

We're not going to stop there, we also want the attribute offset so that we can write the background colour too. Fortunately, that's also relatively simple. I'm going to leave the assembly below for demonstration. Basically, it involving bit masking and bit-shifting to achieve the desired final address offset. the assembly below makes it look a lot more complex than it actually is.

attribute_offset:
    .word $0000
update_attribute_offset_from_mouse:
    LDA mouse_record_x
    AND #%11111000
    ROR
    ROR
    ROR
    STA attribute_offset
    LDA mouse_record_y
    AND #%00111000
    ASL
    ASL
    ORA attribute_offset
    STA attribute_offset
    LDA mouse_record_y
    AND #%11000000
    ROR
    ROR
    ROR
    ROR
    ROR
    ROR
    STA attribute_offset + 1
    RTS

I think that just about wraps it up. The article started by introducing the ZX Spectrum, a little bit of history, then moved onto describing the memory layout of the ZX Spectrum's display. Finally, we finished with an example of how pixel and attribute coordinates can be calculated by using a virtual memory mapped mouse for an example. There are more subtleties involved with the ZX Spectrum's graphics that I've decided not to go into in this article. In future articles I'll be exploring more in-depth graphics programming with 8-bit computers! While also tying that with more modern technology. Happy hacking!

References and Acknowledgements

• jywlewis' 6502 Emulator
• kktos' 6502 Assembler

Objects

Objects are the key data structures in object-oriented programming. C has the struct data type to create, what basically are, objects.

Here is an example:

// Declaration
typedef struct RectangleTag Rectangle;

struct RectangleTag {
    float width;
    float height;
};

// Instantiation
Rectangle rect;

rect.width = 4;
rect.height = 2;

As you can see, this behaves very similar to an object in other object-oriented programming languages, such as Java. Let's just call it an object, for ease of understanding. However, there are a few problems. For it to be object-oriented, we'll need methods that are assigned to the object. Let's start by creating a "constructor" function.

Constructors and Destructors

A constructor is a type of function that is specifically used to create an object. In Java and many other object-oriented programming languages, you invoke the constructor with the new keyword. In the previous example, we created an object that was allocated to the stack. This isn't helpful. The details aren't important as to why, for now. Instead we are going to allocate the object on the heap. Then a pointer to that object will be returned from the constructor function. The C standard library has a function for allocating memory on the heap; it's called malloc.

Here is an example of a constructor function for Rectangle:

#include <stdlib.h>

// Constructor
Rectangle *Rectangle_new(float width, float height)
{
    // Allocate memory to object
    Rectangle *self = malloc(sizeof(Rectangle));

    // Default parameters
    self->width = width;
    self->height = height;

    // Return pointer to object
    return self;
}

Creating an instance of Rectangle using the constructor function:

Rectangle *rect = Rectangle_new(2, 2);

When you're allocating memory on the heap, it isn't deallocated when you go out of function scope, like it does for objects allocated on the stack. Therefore, a "destructor" function has to be created, in order to deallocate the object. The C standard library has a function for cleaning up memory allocated on the heap; it's called free. As shown below:

#include <stdlib.h>

// Destructor
void Rectangle_destroy(Rectangle *self)
{
    // Free the memory
    free(self);
}

Although it may seem pointless to have a destructor function if free is just going to be called, it is important to have a destructor function because objects may need to clear up more objects that are on that object, if that makes sense?

Methods

Methods are very important to object-oriented programming. In Java and many other object-oriented languages, methods associated with an object reference the object with the this keyword. In C++, the object's properties are all in the method's scope. In C, we are going to take the Java approach as it is easiest to implement. A slight tweak: we'll use self instead of this, since this is a reserved keyword in C++, which may harm cross compatibility.

To do this, our function's first parameter will take a pointer to its object. Below is a sample method for calculating the Rectangle's area.

float Rectangle_get_area(Rectangle *self)
{
    return self->width * self->height;
}

This is used as below. The area variable should be equal to 4.

Rectangle *rect = Rectangle_new(2, 2);

float area = Rectangle_get_area(rect);

Just for reference, here is an example of a method for calculating the perimeter.

float Rectangle_get_perimeter(Rectangle *self)
{
    return (self->width * 2) + (self->height * 2);
}

There are a few issues with this. The main issue is it is not polymorphic. We don't have a method that can be called for all Shapes to calculate that Shape's area. On another Shape, the width and height properties may not exist; the method would fall over when it was called with a Shape.

Dynamic Methods

There are a few issues with our previous method of implementing methods. There is no method dispatching. No way to decide what method to call depending on the type of object. We have to do that manually. However, polymorphism is achievable in C. We must use function pointers on the structs themselves.

Let's redeclare our Rectangle struct to have the methods declared on the struct itself:

typedef struct RectangleTag Rectangle;

struct RectangleTag {
    float width;
    float height;

    float (*get_width)(Rectange *self);
    float (*get_perimeter)(Rectange *self);
};

Then the Rectangle constructor has to be updated to assign the static function (defined earlier) to the *get_width and *get_perimeter function pointers.

// Constructor
Rectangle *Rectangle_new(void)
{
    // Allocate memory
    Rectangle *self = malloc(sizeof(Rectangle));

    // Default parameters
    self->width = 2;
    self->height = 2;

    // Methods
    self->get_width = Rectange_get_width;
    self->get_perimeter = Rectange_get_perimeter;

    return self;
}

Now the methods can be called dynamically from the object itself.

Rectangle *rect = Rectangle_new(2, 2);

float area = rect->get_area(rect);

In this example, rect->get_area(rect) would return 4.

Inheritance

In C, it's pretty simple to do object composition, where one object is referenced from inside of another. But how to do we do struct-based inheritance? There isn't a built in way to do it in C.

Let's say we want to have a Cube struct that extends the Rectangle struct, adding the depth property. It's not possible to do that with structs. We could do this:

typedef struct RectangleTag Rectangle;

struct RectangleTag {
    float width;
    float height;
};

typedef struct CubeTag Cube;

struct CubeTag {
    float width;
    float height;
    float depth;
};

However, it's not a good idea to copy to properties over. In addition, you can't tell that Cube is actually inheriting from Rectangle.

We are going to solve this problem with macros. Consider this example:

#define RECTANGLE_PROPS\
    float width;\
    float height;

typedef struct RectangleTag Rectangle;

struct RectangleTag {
    RECTANGLE_PROPS
};

#define CUBE_PROPS\
    RECTANGLE_PROPS\
    float depth;

typedef struct CubeTag Cube;

struct CubeTag {
    CUBE_PROPS
};

Here Cube is inheriting from Rectangle using macros and adding the depth property. Although it's a little messy, it's clear that Cube is inheriting from Rectangle. All that needs to be created is constructors for each struct.

Sometimes you want to call the parent struct's constructor. This is done with the super method in Java. However, in C, if we call the Rectangle_new function to create a new Cube. It's going to only allocate enough memory for the Rectangle. The depth property won't be allocated. This can cause a segmentation fault. I like to solve this problem by creating an apply method. This behaves like a constructor but doesn't allocate any memory. It just takes a pointer to the object and assigns its properties appropriately. In fact, the constructor will call its respective apply method.

void Rectangle_apply(Rectangle *self, float width, float height)
{
    self->width = width;
    self->height = height;
}

Rectangle *Rectangle_new(float width, float height)
{
    Rectangle *self = malloc(sizeof(Rectangle));

    Rectangle_apply(self, width, height);

    return self;
}

void Cube_apply(Cube *self, float width, float height, float depth)
{
    Rectangle_apply((void *)self, width, height);

    self->depth = depth;
}

Cube *Cube_new(float width, float height, float depth)
{
    Cube *self = malloc(sizeof(Cube));

    Cube_apply(self, width, height, depth);

    return self;
}

Yes, the function pointers could have been added onto the Rectangle and Cube structs. However, the power of that, and proper implementation, you are about to be shown.

Polymorphism

Polymorphism is a massive aspect of object-oriented programming. It is possible to use polymorphism in C, even though inheritance isn't natively supported. It's achieved by having structs with the same memory layout and using casts to cast a child struct to its parent struct.

Let's implement an "abstract class" or "interface", as they're called in other languages. An "interface" is a type of class that isn't implemented by itself, but rather by its child classes. In C, interfaces can be thought of as a template for all child structs to conform to.

A good example of this, using the previous example of Rectangle, is to create a Shape which is going to behave as our interface.

#define SHAPE_PROPS(self_t)\
    float (*get_area)(self_t *self);\
    float (*get_perimeter)(self_t *self);

typedef struct ShapeTag Shape;

struct ShapeTag {
    SHAPE_PROPS(Shape)
};

As you can see, the Shape has the get_area and get_perimeter methods. But it doesn't actually implement, like we would do with a constructor. It's important that the macro used for an interface is a macro function. This way, the type can be passed into the function. Allowing for inheritance of methods.

Now let's create a Rectangle which is going to inherit from this Shape "interface".

#define RECTANGLE_PROPS(self_t)\
    SHAPE_PROPS(self_t)\
    float width;\
    float height;

typedef struct RectangleTag Rectangle;

struct RectangleTag {
    RECTANGLE_PROPS(Rectangle)
};

Then the Rectangle constructor must be created, as demonstrated earlier.

void Rectangle_apply(Rectangle *self, float width, float height)
{
    self->get_area = Rectangle_get_area;
    self->get_perimeter = Rectangle_get_perimeter;

    self->width = width;
    self->height = height;
}

Rectangle *Rectangle_new(float width, float height)
{
    Rectangle *self = malloc(sizeof(Rectangle));

    Rectangle_apply(self, width, height);

    return self;
}

For demonstration purposes, we're going to create a Circle which will also conform to the Shape interface.

#define CIRCLE_PROPS(self_t)\
    SHAPE_PROPS(self_t)\
    float radius;

typedef struct CircleTag Circle;

struct CircleTag {
    CIRCLE_PROPS(Circle)
};

Then the circle's get_area and get_permieter methods.

#include <math.h>

float Circle_get_area(Circle *self)
{
    return M_PI * pow(self->radius, 2);
}

float Circle_get_perimeter(Circle *self)
{
    float diameter = self->radius * 2;

    return M_PI * diameter;
}

And finally the constructor:

void Circle_apply(Circle *self, float width, float height)
{
    self->get_area = Circle_get_area;
    self->get_perimeter = Circle_get_perimeter;

    self->width = width;
    self->height = height;
}

Circle *Circle_new(float width, float height)
{
    Circle *self = malloc(sizeof(Circle));

    Circle_apply(self, width, height);

    return self;
}

Now let's create a method which prints the area of any Shape to the console. Thanks to polymorphism and inheritance, this is easy.

void print_area(Shape *shape)
{
    float area = shape->get_area(shape);

    printf("Area: %f\n", area);
}

This method can be called with any type that implements the Shape interface. This is the power of polymorphism. Now let's actually call print_area. Make sure to cast your types, otherwise the compiler will warn you.

Rectangle *rect = Rectangle_new(2, 2);
Circle *circle = Circle_new(3);

print_area((void *)rect); // Prints "Area: 4.000000"
print_area((void *)circle); // Prints "Area: 28.274334"

Dynamic dispatching in action, in C! What more could anyone want?

Dependency Injection

Dependency injection is key to decoupling. Test driven development normally isn't easy in C, with everything depending on concretions. However, using the techniques we have just learnt, it's very easy.

Let's say we had an interface which specified a canvas for a game. It's job is to draw players. It's most likely not practical, but good for demonstration purposes.

#define CANVAS_PROPS(self_t)\
    void clear_screen(self_t *self);\
    void draw_player(self_t *self, Player *player);\
    void clear_player(self_t *self, Player *player);\
    void update_score(self_t *self, Score *score);

typedef struct CanvasTag Canvas;

struct CanvasTag {
    CANVAS_PROPS(Canvas)
};

Now this canvas can be implemented however we want. We could implement it to draw the game like NetHack does. Or perhaps draw it in 3D, as long as we're using the correct library.

We've got our Game struct. Let's inject Canvas into the constructor of Game.

#define GAME_PROPS(self_t)\
    Canvas *canvas;\
    // Other methods and properties can go here

typedef struct GameTag Game;

struct GameTag {
    GAME_PROPS(Game)
};

void Game_apply(Game *self, Canvas *canvas)
{
    self->canvas = canvas;
    // Assign other properties and methods here
}

// Constructor
Game *Game_new(Canvas *canvas)
{
    Game *self = malloc(sizeof(Game));

    Game_apply(self, canvas);

    return self;
}

In any Game method, self->canvas->method_name(...) can be called. Yet, it doesn't matter how Canvas is implemented, as long as we pass a Canvas derived object that does implement Canvas. It doesn't affect our code in Game. It also makes Game much easier to unit test. This is because mocked objects of Canvas, instead of proper implementations, can be injected into Game. That is beyond the scope of this article.

Classes

Time for a more complete example.

You may have thought earlier, with regards to the destroy method, that it could be attached to each object. This is an interesting idea. It would mean that all structs, that are meant to be classes, should derive from an interface stating the destroy method. The beauty of this pattern is that you can modify it however you want. We could even create a clone method which clones the object! Let's do that.

// Class.h
#define CLASS_PROPS(self_t)\
    void (*destroy)(self_t *self);\
    self_t *(*clone)(self_t *self);

typedef struct ClassTag Class;

struct ClassTag {
    CLASS_PROPS(Class)
};

That way all of our classes can inherit. They must implement destroy. I'm going to show the Rectangle example from earlier. First we'll have to redeclare Shape. But this time, we are going to state that Shape has coordinates. So it will have a property for Coords.

// Shape.h
#define SHAPE_PROPS(self_t)\
    CLASS_PROPS(self_t)\
    Coords *coords;\
    float (*get_area)(self_t *self);\
    float (*get_perimeter)(self_t *self);

typedef struct ShapeTag Shape;

struct ShapeTag {
    SHAPE_PROPS(Shape)
};

Then redeclare Rectangle.

// Rectangle.h
#define RECTANGLE_PROPS(self_t)\
    SHAPE_PROPS(self_t)\
    float width;\
    float height;

typedef struct RectangleTag Rectangle;

struct RectangleTag {
    RECTANGLE_PROPS(Rectangle)
};

Rectangle *Rectangle_new(Coords *coords, float width, float height);
void Rectangle_apply(
    Rectangle *self, Coords *coords, float width, float height);
void Rectangle_destroy(Rectangle *self);
Rectangle *Rectangle_clone(Rectangle *self);
float Rectangle_get_area(Rectangle *self);
float Rectangle_get_perimeter(Rectangle *self);

Finally reimplement Rectangle.

// Rectangle.c
#include <stdlib.h>
#include "Class.h"
#include "Shape.h"
#include "Rectangle.h"

Rectangle *Rectangle_new(Coords *coords, float width, float height)
{
    Rectangle *self = malloc(sizeof(Rectangle));

    Rectangle_apply(self, coords, width, height);

    return self;
}

void Rectangle_apply(Rectangle *self, Coords *coords, float width, float height)
{
    self->width = width;
    self->height = height;
    self->coords = coords;

    self->get_area = Rectangle_get_area;
    self->get_perimeter = Rectangle_get_perimeter;
    self->clone = Rectangle_clone;
    self->destroy = Rectangle_destroy;
}

void Rectangle_destroy(Rectangle *self)
{
    self->coords->destroy(self->coords);

    free(self);
}

Rectangle *Rectangle_clone(Rectangle *self)
{
    Rectangle *clone = malloc(sizeof(Rectangle));

    Coords *coords_clone = self->coords->clone(self->coords);

    return Rectangle_new(coords_clone, self->width, self->height);
}

// Definition of `Rectangle_get_area` and `Rectangle_get_perimeter` here

Then creating an instance of Rectangle and destroying it, you know it's going to work. It's pretty self explanatory how Coords would work, so I'm not going to go into the implementation of it.

// main.c
#include "Rectangle.h"
#include "Coords.h"

int main()
{
    Coords *coords = Coords_new(15, 10);
    Rectangle *rect = Rectangle_new(coords, 2, 2);
    Rectangle *rect_2 = rect->clone(rect);

    float area = rect_2->get_area(rect);

    printf("%f\n", area); // Will print 4

    rect->destroy(rect); // Will call `coords->destroy`
    rect_2->destroy(rect); // Do the same as above but to rect_2 object

    return 0;
}

Conclusion

It's a fantastic exercise implementing object-orientation in C. It better helps you understand polymorphism with regards to memory management. It better helps you understand destructors. It better helps you understand constructors. It also better helps you understand where the this object comes from. With C being low level, it shows how object-oriented code works at the low level.

There are many drawbacks to this style though. For one, it takes a lot of boiler plate, just to create a simple class. In addition, C++ has all of these features, and more, with "nice", or rather quick, easily written syntax. Maybe this is one of the issues with C++ the fact that it has too much.

I have written this connect-four program, which is a simple command-line program using the principles stated in this article. It also is totally developed using test-driven development. That's something that this paradigm allows.

Anyway, I'd like to think that implementing object-oriented programming, in C even if it isn't that practical, is a great way to get a better understanding of object-oriented code. It certainly was the case for me.