ITRampage

Аби було зрозуміліше, я зробив дуже простий приклад на Golang.

У прикладі ми бачимо реалізацію об’єкта, як структуру, що зберігає стан, зміни якого організуються у чергу (канал) і виконуються послідовно, що дозволяє безпечно використовувати об’єкт у конкурентній архітектурі.

package inc

import (
	"fmt"
)

type mKind = int

const (
	_ mKind = iota
	incMsg
	printMsg
	destructMsg
)

type Obj struct {
	counter  int64
	messages chan mKind
}

func receive(obj *Obj) {
	for m := range obj.messages {
		switch m {
		case incMsg:
			obj.counter++
		case printMsg:
			fmt.Printf("\n\t\tcounter: %d\n", obj.counter)
		case destructMsg:
			fmt.Printf("\n\tfinal counter: %d\n\n", obj.counter)
			return
		}
	}
}
func New(init int64) *Obj {
	obj := &Obj{
		counter:  init,
		messages: make(chan mKind),
	}
	go receive(obj)
	return obj
}

func (o *Obj) Inc() {
	o.messages <- incMsg
}
func (o *Obj) Print() {
	o.messages <- printMsg
}
func (o *Obj) Descruct() {
	o.messages <- destructMsg
}

З бенчмарків ми бачимо, що ОО код повільніший у 5 разів за код з мютексами, але це не означає, що ми не маємо користуватися подібними об’єктами в Golang чи інших мовах. Це лише означає, що приклад досить простий, аби об’єкти було доречно використовувати.

Зазвичай, об’єкти необхідні коли ми маємо декілька (можливо) взаємозалежних змінних. Крім того, об’єкти дозволяють додати функцію для перевірки інваріанту, яка перевіряє, чи новий стан валідний і лише тоді оновлює об’єкт.

Об’єктний підхід дозволяє зменшити складність та забезпечити коректну роботу в умовах конкурентної архітектури, проте використовувати такі об’єкти як основний блок для побудови, навпаки збільшить кількість коду, його складність та значно погіршить ефективність та швидкість обробки вхідних данних.

Посилання

Дещо про об’єкти