نمط الحالة

جزء من قسم البرمجة كائنية التوجه في رحلة GO على Coddy. الدرس 95 من 107.

يسمح نمط State لكائن بتغيير سلوكه عندما تتغير حالته الداخلية، مما يجعله يبدو كما لو أن الكائن غيّر فئته. بينما يتحكم Template Method في خطوات الخوارزمية، يغلف State السلوك الخاص بالحالة في كائنات منفصلة ويفوّض المهام إلى الحالة current.

في Go، نُعرّف واجهة حالة وننشئ حالات ملموسة تنفّذ سلوكيات مختلفة:

type State interface {
    Handle(d *Document) string
}

type Document struct {
    state State
}

func (d *Document) SetState(s State) {
    d.state = s
}

func (d *Document) Publish() string {
    return d.state.Handle(d)
}

تحدّد كل حالة ما يحدث والحالة التي تأتي بعدها:

type DraftState struct{}

func (s DraftState) Handle(d *Document) string {
    d.SetState(ModerationState{})
    return "Draft submitted for moderation"
}

type ModerationState struct{}

func (s ModerationState) Handle(d *Document) string {
    d.SetState(PublishedState{})
    return "Moderation approved, now published"
}

type PublishedState struct{}

func (s PublishedState) Handle(d *Document) string {
    return "Already published"
}

ينتج استدعاء الطريقة نفسه نتائج مختلفة استنادًا إلى الحالة current:

doc := &Document{state: DraftState{}}

fmt.Println(doc.Publish())  // تم تقديم المسودة للمراجعة
fmt.Println(doc.Publish())  // تمت الموافقة على المراجعة، وهو منشور الآن
fmt.Println(doc.Publish())  // منشور بالفعل

تُعد الحالة مناسبةً للكائنات ذات أوضاع التشغيل المتميزة، مثل سير عمل معالجة الطلبات، أو مكونات واجهة المستخدم، أو معالجات الاتصال حيث يعتمد behavior بالكامل على current state.

التحدي

سهل

لنَبْنِ نظامًا لدعم التذاكر باستخدام نمط الحالة! ستنشئ تذكرة دعم تنتقل عبر مراحل مختلفة، بدءًا من فتحها، ثم العمل عليها، وصولًا إلى حلّها، مع تحديد كل حالة للإجراءات الممكنة وما سيحدث بعد ذلك.

ستنظّم التعليمات البرمجية عبر ثلاثة ملفات:

state.go: Define واجهة الحالة والحالات الملموسة التي تمثّل كل مرحلة من دورة حياة التذكرة.
أنشئ واجهة TicketState باستخدام طريقة Handle(t *Ticket) string التي تعالج التذكرة وقد تنقلها إلى الحالة التالية.

Implement ثلاث حالات:
- OpenState: عند handled، تنقل التذكرة إلى InProgressState وتعيد Ticket opened, assigning to support team
- InProgressState: عند handled، تنتقل إلى ResolvedState وتعيد Working on ticket, issue resolved
- ResolvedState: عند handled، تبقى في الحالة نفسها وتعيد Ticket already resolved
ticket.go: أنشئ بنية التذكرة التي تحتفظ بالحالة current وتفوّض behavior إليها.
أنشئ بنية Ticket باستخدام حقل ID (من النوع string) وحقل state (من النوع TicketState). أضف هذه الطرق:
- SetState(s TicketState) لتغيير الحالة current للتذكرة
- Process() string التي تفوّض إلى طريقة Handle الخاصة بالحالة current
أنشئ constructor ‏NewTicket(id string) *Ticket يعيد تذكرة تبدأ في OpenState.
main.go: وضّح كيف ينتج الإجراء نفسه نتائج مختلفة استنادًا إلى الحالة current للتذكرة.
اقرأ معرّف التذكرة وعدد مرات معالجة التذكرة. أنشئ تذكرة جديدة باستخدام ذلك المعرّف، ثم استدعِ Process() العدد المحدد من المرات، مع طباعة كل result في سطر منفصل.

سيتم توفير المدخلات التالية:

السطر 1: معرّف التذكرة
السطر 2: عدد مرات معالجة التذكرة

على سبيل المثال، عند إعطاء:

TKT-001
3

يجب أن يكون الناتج:

Ticket opened, assigning to support team
Working on ticket, issue resolved
Ticket already resolved

وعند إعطاء:

TKT-500
5

يجب أن يكون الناتج:

Ticket opened, assigning to support team
Working on ticket, issue resolved
Ticket already resolved
Ticket already resolved
Ticket already resolved

وعند إعطاء:

ISSUE-42
1

يجب أن يكون الناتج:

Ticket opened, assigning to support team

لاحظ كيف يؤدي استدعاء Process() على التذكرة نفسها إلى إنتاج نتائج مختلفة في كل مرة: يتغير behavior الخاص بالتذكرة أثناء انتقالها عبر الحالات. وبمجرد حلّها، تبقى resolved بغضّ النظر عن عدد مرات معالجتها. يبدو أن كائن التذكرة يغيّر behavior الخاص به، لكنه في الواقع يفوّض إلى كائنات حالة مختلفة!

جرّب بنفسك

package main

import (
	"fmt"
)

func main() {
	// قراءة المدخلات
	var ticketID string
	var numProcesses int
	fmt.Scanln(&ticketID)
	fmt.Scanln(&numProcesses)

	// TODO: أنشئ تذكرة جديدة بالمعرّف المعطى

	// TODO: عالج التذكرة العدد المحدد من المرات
	// واطبع كل نتيجة في سطر منفصل
}