2.2. You've Never Used OOP

OOP doesn't exist without class encapsulation

// example #1
class Email {
	public id: string
	public value: string
	public isActivated: boolean
	public main: boolean
}

class User {
	public id: string
	public password: string
	public emails: Email[]
}

class UserService {
	registerNewUser(password: string, email: string) {
		const mainEmail = new Email(
			new UUID(),
			email,
			false,
			true,
		)

		const user = new User(
			new UUID(),
			hashPassword(password),
			[mainEmail]
		)		

		return user
  }

	changeUserEmail(user: User, newEmail: string) {
		const oldMainEmail = user.emails.find(email => email.main)

		oldMainEmail.main = false

		const newMainEmail = new Email(
			new UUID(),
			newEmail,
			false,
			true,
		)

		user.emails.push(newMainEmail)
  }
}

// example #2
function Email (
	id: string,
	value: string,
	isActivated: boolean,
	main: boolean
) {
	const state = {
		id,
		value,
		isActivated,
		main
	}

	return {
		makeMain() {
			state.main = true
		},
		unmain() {
			state.main = false
		},
		isMain() {
			return state.main
		}
	}
}

function User = (
		id: string,
		password: string,
		emails: Email[],
) {
	const state = {
		id,
		password,
		emails,
	}

	const getMainEmail = () => {
		return state.emails.find(email => email.isMain())
	}

	return {
		changeUserEmail(email: string) {
			const oldMainEmail = getMainEmail()

			oldMainEmail.unmain()
	
			const newMainEmail = Email(
				new UUID(),
				newEmail,
				false,
				false,
			)

			newMainEmail.main()
	
			user.emails.push(newMainEmail)
	  }
	}
}

function registerNewUser = (password: string, email: string): User => {
	const mainEmail = Email(
		new UUID(),
		newEmail,
		false,
		false,
	)

	mainEmail.main()

	const user = User(
		new UUID(),
		hashPassword(password),
		[mainEmail]
	)		

	return user
}

1. Bad - you don't understand what OOP is

2. Good - perhaps all this time you've been using something similar to FOP

Canonical OOP Methodology

"A program consists of 'objects' that encapsulate data and behavior and communicate through messages"

class User {
	// First, we hide all properties because
	// public properties in OOP are a bad practice
	private id: string
	private password: string
	private emails: Email[]

	// Again, I'm not writing out all the logic, but it can be intuitively understood
	private getMainEmail() {
		// ...
	}

	static registerNewUser(password: string, email: string): User {
		// ...
  }

	changeUserEmail(user: User, newEmail: string) {
		// ...
  }
}

class Email {
	private id: string
	private value: string
	private isActivated: boolean
	private isMain: boolean

	makeMain() {
		// ...
	}

	unmain() {
		// ...
	}
}

But why don't we do it this way?

We didn't know that's how it should be done

Cross Cutting Concern

Is it possible to follow canonical OOP?

1. Instead of Model, the concept of Aggregate is used, which is a stricter Model

2. An Aggregate consists of Entities that have IDs, references to other Entities, and immutable Value Objects

3. The topmost Entity in an Aggregate, containing other Entities and Value Objects, is called the Root Entity

4. All application logic is in Aggregates, which operate on Entities and Value Objects

5. Aggregates can reference each other, but only by ID

6. Aggregates have no right to reference each other's Entities and Value Objects, only the Root Entity

7. 1 business process (consider it an API endpoint) === 1 Aggregate method

8. 1 Aggregate method === 1 transaction

9. You must retrieve the entire Aggregate from the database before performing logic and save it entirely at the end of the logic

"So what have I been using all this time?"

Okay, if canonical OOP means smart "objects" with all private properties and all business processes starting with a method call of one of them, then what have I and a bunch of other developers been using all this time?

class User {
	public id: string
	public password: string
	public emails: Email[]

	getMainEmail() {
		// ...
	}

	changeEmail(user: User, newEmail: string) {
		// ...
  }
}

class Email {
	public id: string
	public value: string
	public isActivated: boolean
	public main: boolean
}

class UserService {
	registerNewUser(password: string, email: string) {
		// ...
  }

	changeUserEmail(user: User, newEmail: string) {
		// ...
  }

	deleteUser(user: User) {
		// ...
  }
}

So what's the problem?

1. Use canonical OOP

2. Use a hybrid of OOP with some functional or procedural programming

3. Don't use OOP at all

What's Next

Useful Links

1. https://en.m.wikipedia.org/wiki/Anemic_domain_model

2. https://martinfowler.com/bliki/AnemicDomainModel.html

3. https://stackoverflow.com/questions/23314330/rich-vs-anemic-domain-model