other software architecture stuff:

Clean Architecture

Saw Brian Chen’s notes on this: https://chenbrian.ca/posts/clean-architecture-notes/

Same author of Clean Code


Will write notes on this.

Notice that hardware has drastically changed over the last half-century, but not software architecture:

the rules of software architecture are independent of every other variable.

When you look at the practice of programming, you realize that very little has changed in 50 years.

Part 1

Getting software to work is easy. This is what I have been doing for the past 7 years programming. But now, I need to focus on getting software right.


”… It requires a level of discipline and dedication that most programmers never dreamed they’d need. Mostly, it takes a passion for the craft and the desire to be a professional.

And when you get software right, something magical happens: You don’t need hordes of programmers to keep it working. You don’t need massive requirements documents and huge issue tracking systems. You don’t need global cube farms and 24/7 programming.”

Programming Hell is what?

“The low-level details and the high-level structure are all part of the same whole.”

Goal of Software Architecture

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

I always keep telling myself that if I write messy code, I can clean it up later. But rarely do we do that. That is a lie.

Writing clean code is always better.

“But it hurts productivity!” That is a lie.

Always stay CLEAN

Making messes is always slower than staying clean, no matter which time scale you are using.

The only way to go fast, is to go well.

If you want to do fast, you need to do it properly. How you do anything is how you do everything.

And so to understand how to write clean code, we need to start with the history of code.

If you think about it, a program is just data. The magical moment was when we figured out that a computer can program itself, and that we don’t have to manually do everything like a calculator. The Alan Turing movie showcased this.


See Science vs. Mathematics. The author argues that software development is a science, because we do TDD.

But I learned the mathematical way in SE212? We CAN prove Program Correctness, relative to the specification.

Wow, the book introduces how inheritance is actually implemented, and that you could achieve inheritance in C:

#include "point.h"
#include "namedPoint.h"
#include <stdio.h>
int main(int ac, char** av) {
	struct NamedPoint* origin = makeNamedPoint(0.0, 0.0, "origin");
	struct NamedPoint* upperRight = makeNamedPoint (1.0, 1.0, "upperRight");
		(struct Point*) origin,
		(struct Point*) upperRight));

What about the issues with Polymorphic Arrays?

This kind of trickery was a common practice of programmers prior to the advent of OO (still exists today if using C). Such trickery is how C++ implements single inheritance.

Wooo, my mind is going to be blown again. You can also do Polymorphism in C? Well yea I think so, from the previous example, you do like pointer Casting.

struct FILE {
void (*open)(char* name, int mode);
void (*close)();
int (*read)();
void (*write)(char);
void (*seek)(long index, int mode);
#include "file.h"
void open(char* name, int mode) {/*...*/}
void close() {/*...*/};
int read() {int c;/*...*/ return c;}
void write(char c) {/*...*/}
void seek(long index, int mode) {/*...*/}
struct FILE console = {open, close, read, write, seek};
extern struct FILE* STDIN;
int getchar() {
return STDIN->read();
  • function pointers??

Well yes, polymorphism is an application of pointers to functions. Wow, never thought about it that ways. We have the vtable.

So OO didn’t invent Encapsulation, nor Inheritance, nor Polymorphism. But it did make those uses a lot safer and less error-prone.

Pointer to Functions

“The problem with explicitly using pointers to functions to create polymorphic behavior is that pointers to functions are dangerous. Such use is driven by a set of manual conventions.”

Functional Programming


All the problems that we face in concurrent applications—all the problems we face in applications that require multiple threads, and multiple processors—cannot happen if there are no mutable variables.

The question you must be asking yourself, then, is whether immutability is practicable.

When immutability is practicable, go down Functional Programming.

The author gives a slightly ridiculous example of bank transactions. Instead of storing the account balances, you could try simply storing the transactions. Then, you don’t need to store the state informations about the balances for each individual, you would simply need to recompute every single time.

This is precisely the way our source control system works apparently??

Part 4: Components

Components have to be linked. At first, these were super slow. I didn’t write down this, but I think it might be important at some point to understand the low-level details.