No bullshit guide to SOLID and DI in V

[Molochnikov]

No bullshit guide to SOLID and DI in V

Refactoring

Refactoring is the process of restructuring existing computer code without changing its external behavior. Refactoring wastes programmer's time (and someone's money) in efforts to improve code readability and reduced complexity. Careless refactoring can create new bugs and errors, accidentally changes in code behavior. Diffs in version control system are chaotic and big in every "Refactoring" commit that you can't even explain with one commit message. You can't even merge without conflicts if you are refactoring some code which actively developed by others. If refactoring is so hard why programmers do it?

Changes is the answer. Code always develops with new business requirements. Some things and rules that yesterday was rock-solid today seems wrong. Because something already written we need to save existing right behaviour with having ability to add new functionality.

Can we write our code to be ready for any new requirement and any new change without refactoring any piece of old code?

Yes we can. SOLID is the answer.

SOLID

SOLID is a set of principles that programmers can use if they want to minimize refactoring procedures for their already written code.

Here is SOLID priciples modified for V language for clarity:

1. Single-responsibility principle: There should never be more than one reason for a struct and its functions to change.
2. Open–closed principle: Interfaces, structs and functions should be open for extension, but closed for modification.
3. Liskov substitution principle: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it (original formulation).
4. Interface segregation principle: Structs should not be forced to implement interfaces that they do not use.
5. Dependency inversion principle: Depend upon interfaces, not structs.

DI and CQRS

Dependency injection (DI) is a possible implementation of the Dependency inversion principle. DI assumes that you create instances of your structs and substitute them for interfaces (compose them) only in one place of your program that called composition root. Composition root is some place in your program that is very close to the program start. In this guide it will be content of main() function. Structs called dependencies and interfaces called abstractions. You injecting dependencies in abstractions and compose overall behaviour of your program at the composition root.

Command and Query Responsibility Segregation (CQRS) is a possible implementation of the Interface segregation principle for CRUD (Create,Read,Update,Delete) interfaces like for example database repositories with their database transfer objects (DTOs). CQRS goal is to make them more predictable and maintanable by splitting them to:

• more universal query (read) interfaces like get_all_filtered_sorted_paged[T](filter Filter, sort Sort, page_num int, page_size int) []T and get_by_id[T](id string) T that return results but not changing state of the system;
• mupltiple specific command (create, update, delete) interfaces like register_car_owner(cod CarOwnerDTO) or calculate_car_tax(car CarDTO) or delete_sold_cars(sc SoldCarDTO) that changing state but not return results.

Practice

Let's start our program with first simple business requirement:

• animals like cats and dogs can growl, speak and sleep on a soft colored pillow.

Here is the code:

import v.reflection

interface Animal {
	speak(msg string) string
	growl(msg string) string
	sleep(pillow Pillow) string
}

struct Pillow {
	color string
}

struct Dog {}
fn (d Dog) speak(msg string) string {
    return '${msg}. Woof, woof!'
}
fn (d Dog) growl(msg string) string {
    return '${msg}. Grrrrr!'
}
fn (d Dog) sleep(pillow Pillow) string {
    return 'Sleeping on ${pillow.color} ${reflection.type_of(pillow).name}. Zzzz...'
}

struct Cat {}
fn (c Cat) speak(msg string) string {
    return '${msg}. Meow, meow!'
}
fn (c Cat) growl(msg string) string {
    return '${msg}. Shhhh!'
}
fn (c Cat) sleep(pillow Pillow) string {
    return 'Sleeping on ${pillow.color} ${reflection.type_of(pillow).name}. Zzzz...'
}

p := Pillow{color: 'red'}

d := Dog{}
println(d.growl('I\'m a dog'))
println(d.speak('I\'m a dog'))
println(d.sleep(p))

c := Cat{}
println(c.growl('I\'m a cat'))
println(c.speak('I\'m a cat'))
println(c.sleep(p))

Dependency inversion principle

Cool! It works. Everyone is happy. So whats the problem? After a week you received next business requirement:

• animals can sleep not only on a colored pillows but on grass too.

Your code needs refactoring. It is because you violated dependency inversion principle. See here:

interface Animal {
	speak(msg string) string
	growl(msg string) string
	// DIP violation! Animal depends on struct not interface.
	sleep(pillow Pillow) string
}

If you has written your code with DIP in mind it will not needed to be refactored. You just need to implement new dependency and inject it to abstraction in composition root:

interface Soft {
	color string
}

interface Animal {
	speak(msg string) string
	growl(msg string) string
	sleep(soft Soft) string // replaced with abstraction
}

struct Pillow {
	color string
}

// in new version added this. Nothing more has changed except composition root new injected dependency
struct Grass {
	color string = 'green'
}
//

struct Dog {}
fn (d Dog) speak(msg string) string {
    return '${msg}. Woof, woof!'
}
fn (d Dog) growl(msg string) string {
    return '${msg}. Grrrrr!'
}
fn (d Dog) sleep(soft Soft) string { // replaced with abstraction
    return 'Sleeping on ${soft.color} ${soft.type_name()}. Zzzz...'
}

struct Cat {}
fn (c Cat) speak(msg string) string {
    return '${msg}. Meow, meow!'
}
fn (c Cat) growl(msg string) string {
    return '${msg}. Shhhh!'
}
fn (c Cat) sleep(soft Soft) string { // replaced with abstraction
    return 'Sleeping on ${soft.color} ${soft.type_name()}. Zzzz...'
}


// main() function is the composition root
// where we are injecting all dependencies
// to abstractions.
// All other functions and structs in our program uses abstractions (interfaces)
// instead of implementations (structs).
fn main() {
	//p := Pillow{color: 'red'} // old version dependency
	p := Grass{} // new version dependency
    	d := Dog{} // dependency
	c := Cat{} // dependency

	println(d.growl('I\'m a dog'))
	println(d.speak('I\'m a dog'))
	println(d.sleep(p)) // injecting to abstraction

	println(c.growl('I\'m a cat'))
	println(c.speak('I\'m a cat'))
	println(c.sleep(p)) // injecting to abstraction
}

Single-responsibility principle

New business requirement on the way:

• dogs can sleep on their backs

Now you need to refactor sleep() code for dogs. But if you has splitted responsibility to sleep from responsibilities to make noices you never need to refactor this:

interface Animal {
	speak(msg string) string
	growl(msg string) string
	// again this lines has SRP violation!
	// Animal responsibilities to make noices and sleep must be splitted to a new abstractions
	sleep(soft Soft) string
}

Let's go. This is the code you must has started with:

interface IMakeNoice {
	speak(msg string) string
	growl(msg string) string
}

interface ICanSleep {
	sleep(soft Soft, a Animal) string
}

interface Soft {
	color string
}

interface Animal {
	speaker IMakeNoice
	sleeper ICanSleep
}

struct Pillow {
	color string
}

struct Grass {
	color string = 'green'
}

struct Sleep {}
fn (s Sleep) sleep(soft Soft, a Animal) string {
    return 'Sleeping on ${soft.color} ${soft.type_name()}. Zzzz...'
}

// in new version added this. Nothing more has changed except composition root
struct SleepOnBack {}
fn (s SleepOnBack) sleep(soft Soft, a Animal) string {
    return 'Sleeping on back on ${soft.color} ${soft.type_name()}. Zzzz...'
}
//

struct MakeCatNoice {}
fn (mn MakeCatNoice) speak(msg string) string {
    return '${msg}. Meow, meow!'
}
fn (mn MakeCatNoice) growl(msg string) string {
    return '${msg}. Shhhh!'
}

struct MakeDogNoice {}
fn (mn MakeDogNoice) speak(msg string) string {
    return '${msg}. Woof, woof!'
}
fn (mn MakeDogNoice) growl(msg string) string {
    return '${msg}. Grrrrr!'
}

struct Dog {
	speaker IMakeNoice
	sleeper ICanSleep
}

struct Cat {
	speaker IMakeNoice
	sleeper ICanSleep
}

fn main() {
	sob := SleepOnBack{} // added in new version
	s := Sleep{}

	cn := MakeCatNoice{}
	dn := MakeDogNoice{}

	p := Pillow{color: 'red'}
	g := Grass{}
	
    	d := Dog{
		speaker: dn
		sleeper: sob // changed in new version from s to sob
	}

	c := Cat{
		speaker: cn
		sleeper: s
	}

	println(d.speaker.growl('I\'m a dog'))
	println(d.speaker.speak('I\'m a dog'))
	println(d.sleeper.sleep(g, d)) // injecting to abstraction

	println(c.speaker.growl('I\'m a cat'))
	println(c.speaker.speak('I\'m a cat'))
	println(c.sleeper.sleep(p, c)) // injecting to abstraction
}

Interface segregation principle

Next please!

• some animals like mouses can't growl

Wow! We already splitted our resposibilities. But it seems that we forced all animals to growl. If it is not possible to know what interfaces will be segregated in the future because of changing requirements how we can even know what to write at the begining of development?

My recommendation is: use no more than one function with group of semanticly related fields for any interface.

This recommendation works well with CQRS too. On all commands you can make generic interface with one function that will use any DTO as the parameter:

struct Car {
	id string
	model string
	color string
}

struct Person {
	id string
	name string
}

struct RegisterCarDTO {
	car Car
	car_owner Person
}

struct DeletePersonDTO {
	person Person
}

// one interface to rule them all!
interface ICommand[T] {
	execute(t T) !
}

struct RegisterCarCommand {}
fn (rcc RegisterCarCommand) execute(t RegisterCarDTO) ! {

	// registering code ...

	// if ...
	return error('Car with id ${t.car.id} not found')
	// if ...
	//return error('Person with id ${t.car_owner.id} not found')
}

struct DeletePersonCommand {}
fn (rcc DeletePersonCommand) execute(t DeletePersonDTO) ! {

	// deleting code ...

	// if ...
	return error('Person with id ${t.person.id} not found')
}

fn main() {
	web_request_uri := '/persons'
	web_request_method := 'DELETE'

	if web_request_uri == '/persons' && web_request_method == 'DELETE' {
		cmnd := ICommand[DeletePersonDTO](DeletePersonCommand{})
		dump(cmnd)
		// cmnd.execute(...)
		// ...
	}
}

To return to our example let's think about right way to not violate ISP. Firstly we need to separate interface:

interface ICanSpeak {
	speak(msg string) string
}

interface ICanGrowl {
	growl(msg string) string
}

interface ICanSleep {
	sleep(soft Soft, a Animal) string
}

interface Soft {
	color string
}

interface Animal {
	speaker ICanSpeak
	sleeper ICanSleep
	growler ICanGrowl
}

struct Pillow {
	color string
}

struct Grass {
	color string = 'green'
}

struct Sleep {}
fn (s Sleep) sleep(soft Soft, a Animal) string {
    return 'Sleeping on ${soft.color} ${soft.type_name()}. Zzzz...'
}

struct SleepOnBack {}
fn (s SleepOnBack) sleep(soft Soft, a Animal) string {
    return 'Sleeping on back on ${soft.color} ${soft.type_name()}. Zzzz...'
}

struct MakeCatNoice {}
fn (mn MakeCatNoice) speak(msg string) string {
    return '${msg}. Meow, meow!'
}

struct MakeCatGrowl {}
fn (mn MakeCatGrowl) growl(msg string) string {
    return '${msg}. Shhhh!'
}

struct MakeDogNoice {}
fn (mn MakeDogNoice) speak(msg string) string {
    return '${msg}. Woof, woof!'
}

struct MakeDogGrowl {}
fn (mn MakeDogGrowl) growl(msg string) string {
    return '${msg}. Grrrrr!'
}

// in new version added this
struct MakeMouseNoice {}
fn (mn MakeMouseNoice) speak(msg string) string {
    return '${msg}. Peeeew!'
}
//

struct Dog {
	speaker ICanSpeak
	sleeper ICanSleep
	growler ICanGrowl
}

struct Cat {
	speaker ICanSpeak
	sleeper ICanSleep
	growler ICanGrowl
}

// in new version added this
struct Mouse {
	speaker ICanSpeak
	sleeper ICanSleep
}
//

fn main() {
	sob := SleepOnBack{} 
	s := Sleep{}

	cn := MakeCatNoice{}
	gc := MakeCatGrowl{}

	dn := MakeDogNoice{}
	gn := MakeDogGrowl{}

	mn := MakeMouseNoice{} // added in new version

	p := Pillow{color: 'red'}
	g := Grass{}
	
	m := Mouse { // added in new version
		speaker: mn
		sleeper: s
	}

    	d := Dog{
		speaker: dn
		sleeper: sob
		growler: gn
	}

	c := Cat{
		speaker: cn
		sleeper: s
		growler: gc
	}

	println(d.growler.growl('I\'m a dog'))
	println(d.speaker.speak('I\'m a dog'))
	println(d.sleeper.sleep(g, d))

	println(c.growler.growl('I\'m a cat'))
	println(c.speaker.speak('I\'m a cat'))
	println(c.sleeper.sleep(p, c))

	println(m.speaker.speak('I\'m a mouse')) // added in new version
	println(m.sleeper.sleep(p, m))
}

Liskov substitution principle

Secondly we have a problem now. Mouse is not an Animal. In our Animal interface we defined that all animals must growl. Suppose its too late and all our clients already uses that interface and we can't change it. The first obvious solution of this problem to really make Mouse an Animal and to throw error if some clients want to use its growl. Like this:

struct MakeMouseGrowl {}
fn (mn MakeMouseGrowl) growl(msg string) !string {
    return error('I can\'t growl!')
}

But this violates next principle that i want to discuss.

My interpretation for LSP for V language: you can't subtitute structs for interfaces that are not fully behaviorally correct.

Example from source paper on C++:

void g(Rectangle& r)
{
	r.SetWidth(5);
	r.SetHeight(4);
	assert(r.GetWidth() * r.GetHeight()) == 20);
}

If Square implements Rectangle then SetWidth and SetHeight method for Squares sets all sides to the same value. Then we have 4 * 4 = 16 not 20 and clients operations can be failed. But it will be failed also if an error will be raised for one of the SetWidth and SetHeight methods.

The only right solution is to add all possible combinations of Animal interface methods to their own interfaces and give clients only thinnest interfaces they needed from the start of our developing. This is the foundations of true DI architecture. Interface embedding in V greatly helps with that:

interface ICanSpeak {
	speak(msg string) string
}

interface ICanGrowl {
	growl(msg string) string
}

interface ICanSleep {
	sleep(soft Soft, a SleepingAnimal) string
}

interface Soft {
	color string
}

interface SpeakingAnimal {
	speaker ICanSpeak
}

interface SleepingAnimal {
	sleeper ICanSleep
}

interface GrowlingAnimal {
	growler ICanGrowl
}

interface AnimalThatSpeaksAndSleep {
	SpeakingAnimal
	SleepingAnimal
}

interface AnimalThatSpeaksAndGrowl {
	SpeakingAnimal
	GrowlingAnimal
}

interface AnimalThatSleepAndGrowl {
	SleepingAnimal
	GrowlingAnimal
}

interface AnimalThatSpeaksAndSleepAndGrowl {
	SpeakingAnimal
	SleepingAnimal
	GrowlingAnimal
}

struct Pillow {
	color string
}

struct Grass {
	color string = 'green'
}

struct Sleep {}
fn (s Sleep) sleep(soft Soft, a SleepingAnimal) string {
    return 'Sleeping on ${soft.color} ${soft.type_name()}. Zzzz...'
}

struct SleepOnBack {}
fn (s SleepOnBack) sleep(soft Soft, a SleepingAnimal) string {
    return 'Sleeping on back on ${soft.color} ${soft.type_name()}. Zzzz...'
}

struct MakeCatNoice {}
fn (mn MakeCatNoice) speak(msg string) string {
    return '${msg}. Meow, meow!'
}

struct MakeCatGrowl {}
fn (mn MakeCatGrowl) growl(msg string) string {
    return '${msg}. Shhhh!'
}

struct MakeDogNoice {}
fn (mn MakeDogNoice) speak(msg string) string {
    return '${msg}. Woof, woof!'
}

struct MakeDogGrowl {}
fn (mn MakeDogGrowl) growl(msg string) string {
    return '${msg}. Grrrrr!'
}

struct MakeMouseGrowl {}
fn (mn MakeMouseGrowl) growl(msg string) !string {
    return error('I can\'t growl!')
}

struct MakeMouseNoice {}
fn (mn MakeMouseNoice) speak(msg string) string {
    return '${msg}. Peeeew!'
}

struct Dog {
	speaker ICanSpeak
	sleeper ICanSleep
	growler ICanGrowl
}

struct Cat {
	speaker ICanSpeak
	sleeper ICanSleep
	growler ICanGrowl
}

struct Mouse {
	speaker ICanSpeak
	sleeper ICanSleep
}

fn main() {
	sob := SleepOnBack{} 
	s := Sleep{}

	cn := MakeCatNoice{}
	gc := MakeCatGrowl{}

	dn := MakeDogNoice{}
	gn := MakeDogGrowl{}

	mn := MakeMouseNoice{}

	p := Pillow{color: 'red'}
	g := Grass{}
	
	m := Mouse { // added in new version
		speaker: mn
		sleeper: s
	}

    	d := Dog{
		speaker: dn
		sleeper: sob
		growler: gn
	}

	c := Cat{
		speaker: cn
		sleeper: s
		growler: gc
	}

	println(d.growler.growl('I\'m a dog'))
	println(d.speaker.speak('I\'m a dog'))
	println(d.sleeper.sleep(g, d))

	println(c.growler.growl('I\'m a cat'))
	println(c.speaker.speak('I\'m a cat'))
	println(c.sleeper.sleep(p, c))

	println(m.speaker.speak('I\'m a mouse'))
	println(m.sleeper.sleep(p, m))
}

So we started our practice with 45 lines. Now there are 162 but we added some new requirements and a whole bunch of interfaces. Finally our code true SOLID. Or SLID?

Open–closed principle

Now after we introduced all other principles i want to show you my second formulation of OCP for V language: you should not modify or delete any dependency or abstraction ever written in any source file with the only exception of composition root.

Why? Because this is what refactoring is! Rewriting old code and creating huge cryptic error prone commits and merges with lost of old functionality!

And here we have the real power of V for this principle: your structs (dependencies) are not tied in source code to the interfaces (abstractions) in V. You can always implement new interfaces or structs on the fly without modifying anything already written.

And because it is the last principle it will be unfair if we not start again with the first business requirement and will test it against any changes:

• animals like cats and dogs can growl, speak and sleep on a soft colored pillow.

Here is the starting SOLID listing:

interface ICanSpeak {
	speak(msg string) string
}

interface ICanGrowl {
	growl(msg string) string
}

interface ICanSleep {
	sleep(soft Soft, a SleepingAnimal) string
}

interface Soft {
	color string
}

interface SpeakingAnimal {
	speaker ICanSpeak
}

interface SleepingAnimal {
	sleeper ICanSleep
}

interface GrowlingAnimal {
	growler ICanGrowl
}

interface AnimalThatSpeaksAndSleep {
	SpeakingAnimal
	SleepingAnimal
}

interface AnimalThatSpeaksAndGrowl {
	SpeakingAnimal
	GrowlingAnimal
}

interface AnimalThatSleepAndGrowl {
	SleepingAnimal
	GrowlingAnimal
}

interface AnimalThatSpeaksAndSleepAndGrowl {
	SpeakingAnimal
	SleepingAnimal
	GrowlingAnimal
}

struct Pillow {
	color string
}

struct Sleep {}
fn (s Sleep) sleep(soft Soft, a SleepingAnimal) string {
    return 'Sleeping on ${soft.color} ${soft.type_name()}. Zzzz...'
}

struct MakeCatNoice {}
fn (mn MakeCatNoice) speak(msg string) string {
    return '${msg}. Meow, meow!'
}

struct MakeCatGrowl {}
fn (mn MakeCatGrowl) growl(msg string) string {
    return '${msg}. Shhhh!'
}

struct MakeDogNoice {}
fn (mn MakeDogNoice) speak(msg string) string {
    return '${msg}. Woof, woof!'
}

struct MakeDogGrowl {}
fn (mn MakeDogGrowl) growl(msg string) string {
    return '${msg}. Grrrrr!'
}

struct Dog {
	speaker ICanSpeak
	sleeper ICanSleep
	growler ICanGrowl
}

struct Cat {
	speaker ICanSpeak
	sleeper ICanSleep
	growler ICanGrowl
}

fn main() {

}

Now if this code is true SOLID i even don't need to show you full listing again on every new requirement! I need to show only changes in our main() composite root and new dependencies/abstractions. Let's do this! The party's just getting started:

• cats can sleep on dogs

You didn't expect that. Huh?😉

//under previous listing except main() function

struct ColoredAndSoftDog {
	color string
	speaker ICanSpeak
	sleeper ICanSleep
	growler ICanGrowl
}

fn main() {
	//...previous listings main() code here and it works...
	d := ColoredAndSoftDog{
		color: 'brown'
		sleeper: Sleep{}
		speaker: MakeDogNoice{}
		growler: MakeDogGrowl{}
	}
	c := Cat {
		sleeper: Sleep{}
		speaker: MakeCatNoice{}
		growler: MakeCatGrowl{}
	}
	println(c.sleeper.sleep(d,c))
}

• cats and dogs can sleep together

//under previous listing except main() function

interface ICanSleepTogether {
	sleep(soft Soft, a SleepingAnimal, b SleepingAnimal) string
}

interface SleepingTogetherAnimal {
	tog_sleeper ICanSleepTogether
}

struct SleepTogether {}
fn (s SleepTogether) sleep(soft Soft, a SleepingAnimal, b SleepingAnimal) string {
    return '${a.type_name()} sleeping with ${b.type_name()} on ${soft.color} ${soft.type_name()}. Zzzz...'
}

struct LoyalDog {
	speaker ICanSpeak
	sleeper ICanSleep
	tog_sleeper ICanSleepTogether
	growler ICanGrowl
}

struct LoyalCat {
	speaker ICanSpeak
	sleeper ICanSleep
	tog_sleeper ICanSleepTogether
	growler ICanGrowl
}

fn main() {
	//...previous listings main() code here and it works...
	dd := LoyalDog {
		sleeper: Sleep{}
		tog_sleeper: SleepTogether{}
		speaker: MakeDogNoice{}
		growler: MakeDogGrowl{}
	}
	cc := LoyalCat {
		sleeper: Sleep{}
		tog_sleeper: SleepTogether{}
		speaker: MakeCatNoice{}
		growler: MakeCatGrowl{}
	}
	g := Pillow {
		color: 'red'
	}
	println(cc.tog_sleeper.sleep(g,cc,dd))
}

• ...on the other dog

//under previous listing except main() function

fn main() {
	// ...previous listings main() code here and it works...
	gg := ColoredAndSoftDog{
		color: 'brown'
		sleeper: Sleep{}
		speaker: MakeDogNoice{}
		growler: MakeDogGrowl{}
	}
	ddd := LoyalDog {
		sleeper: Sleep{}
		tog_sleeper: SleepTogether{}
		speaker: MakeDogNoice{}
		growler: MakeDogGrowl{}
	}
	ccc := LoyalCat {
		sleeper: Sleep{}
		tog_sleeper: SleepTogether{}
		speaker: MakeCatNoice{}
		growler: MakeCatGrowl{}
	}
	println(ccc.tog_sleeper.sleep(gg,ccc,ddd))
	println(ddd.tog_sleeper.sleep(gg,ddd,ccc))
}

• our pillows will NEVER-NEVER have color again. but now they have softness

//under previous listing except main() function


//very trustful but solid programmer write that...

interface SoftRating {
	softness int
}

interface ICanSleepWithSoftRating {
	sleep(soft SoftRating, a SleepingAnimal) string
}

interface ICanSleepTogetherWithSoftRating {
	sleep(soft SoftRating, a SleepingAnimal, b SleepingAnimal) string
}

struct SleepWithRating {}
fn (s SleepWithRating) sleep(soft SoftRating, a SleepingAnimal) string {
    return 'Sleeping on ${soft.softness} ${soft.type_name()}. Zzzz...'
}

struct SleepTogetherWithSoftRating {}
fn (s SleepTogetherWithSoftRating) sleep(soft SoftRating, a SleepingAnimal, b SleepingAnimal) string {
    return '${a.type_name()} sleeping with ${b.type_name()} on ${soft.softness} ${soft.type_name()}. Zzzz...'
}

struct UncoloredPillow {
	softness int
}

struct PillowCriticDog {
	speaker ICanSpeak
	sleeper ICanSleepWithSoftRating
	growler ICanGrowl
}

struct PillowCriticCat {
	speaker ICanSpeak
	sleeper ICanSleepWithSoftRating
	growler ICanGrowl
}

struct PillowCriticJustSoftDog {
	softness int
	speaker ICanSpeak
	sleeper ICanSleepWithSoftRating
	growler ICanGrowl
}

struct PillowCriticLoyalDog {
	speaker ICanSpeak
	sleeper ICanSleep
	tog_sleeper ICanSleepTogetherWithSoftRating
	growler ICanGrowl
}

struct PillowCriticLoyalCat {
	speaker ICanSpeak
	sleeper ICanSleep
	tog_sleeper ICanSleepTogetherWithSoftRating
	growler ICanGrowl
}

• ...they sended us red ink! COLOR FOR PILLOWS! NOW!

//under previous listing except main() function


//same solid programmer but now a bit experienced...

interface ColorSoft {
	SoftRating
	Soft
}

interface ICanSleepOnColorSoft {
	sleep(soft ColorSoft, a SleepingAnimal) string
}

interface ICanSleepTogetherOnColorSoft {
	sleep(soft ColorSoft, a SleepingAnimal, b SleepingAnimal) string
}

struct SleepOnColorSoft {}
fn (s SleepOnColorSoft) sleep(soft ColorSoft, a SleepingAnimal) string {
    return 'Sleeping on ${soft.softness} ${soft.type_name()} which is ${soft.color}. Zzzz...'
}

struct SleepTogetherOnColorSoft {}
fn (s SleepTogetherOnColorSoft) sleep(soft ColorSoft, a SleepingAnimal, b SleepingAnimal) string {
    return '${a.type_name()} sleeping with ${b.type_name()} on ${soft.softness} ${soft.type_name()} which is ${soft.color}. Zzzz...'
}

struct ColoredSoftPillow {
	softness int
	color string
}

struct ColorPillowCriticDog {
	speaker ICanSpeak
	//...other sleep compatibility required interfaces...
	sleeper ICanSleepOnColorSoft
	growler ICanGrowl
}

struct ColorPillowCriticCat {
	speaker ICanSpeak
	//...other sleep compatibility required interfaces...
	sleeper ICanSleepOnColorSoft
	growler ICanGrowl
}

struct ColorPillowCriticColoredAndSoftDog {
	color string
	softness int
	speaker ICanSpeak
	//...other sleep compatibility required interfaces...
	sleeper ICanSleepOnColorSoft
	growler ICanGrowl
}

struct ColorPillowCriticLoyalDog {
	speaker ICanSpeak
	sleeper ICanSleep
	//...other sleep compatibility required interfaces...
	tog_sleeper ICanSleepTogetherOnColorSoft
	growler ICanGrowl
}

struct ColorPillowCriticLoyalCat {
	speaker ICanSpeak
	sleeper ICanSleep
	//...other sleep compatibility required interfaces...
	tog_sleeper ICanSleepTogetherOnColorSoft
	growler ICanGrowl
}

• actually all requirements after Nth was a joke

// WITH SOLID CODE YOU DON'T NEED TO CHANGE ANYTHING! ONLY ADD NEW! BYE!

[Ddiidev]

That would be interesting to be on the blog

[savage-demon]

This is the best thing I've ever read about SOLID!

[leon-arndt]

Great stuff have you thought about making a small repo showing a practical example where the animals are split across files to show project structure?