2.2. Вы никогда не использовали ООП

ООП не существует без классовой инкапсуляция

// пример #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)
  }
}

// пример #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. Плохая – вы не понимаете, что такое ООП

2. Хорошая – возможно все это время вы использовали нечто похожее на ФОП

Каноничная ООП методология

“Программа состоит из “объектов”, инкапсулирующих данные и поведение и общающихся сообщениями”

class User {
	// Для начала скрываем все свойства, потому что
	// публичные свойства в ООП – bad practise
	private id: string
	private password: string
	private emails: Email[]

	// Опять же, логику я не дописываю, но ее можно интуитивно понять
	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() {
		// ...
	}
}

Но почему мы так не делаем?

Мы не знали что так надо делать

Cross Cutting Concern

А возможно ли следовать каноничному ООП?

1. Вместо Model, тут используется понятие Агрегат (Aggregate), который является более строгой Model

2. Агрегат состоит из Сущностей (Entity), имеющих id, содержащие на другие Сущности (Entity) и неизменяемые Объекты значений (Value Object)

3. Самая верхняя Entity в Агрегате, содержащая другие Entity и Value Object, называется Root Entity

4. Вся логика приложения находиться в Агрегатах, который оперирует над Entity и Value Object

5. Агрегаты могут иметь ссылки друг на друга, но только по ID

6. Агрегаты не имеют право ссылаться на Entity и Value Object друг друга, только на Root Entity

7. 1 бизнес-процесс (считайте endpoint API) === 1 метод Агрегата

8. 1 метод Агрегата === 1 транзакций

9. Вы должны доставать Агрегат из БД полностью, перед тем, как производить логику и сохранять также полностью под конец логики

“А что тогда я все это время использовал?”

Ок, если каноничный ООП это умные «объекты», у которых все свойства приватные и все бизнес-процессы начинаются с вызова метода одного из них, то тогда что все это время использовал я и куча других разработчиков?

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) {
		// ...
  }
}

Ну а в чем проблема?

1. Использовать каноничный ООП

2. Воспользоваться гибридом ООП с каким-нибудь функциональным или процедурным программированием

3. Не использовать ООП вообще

Что дальше

Полезные ссылки

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