Introduction

Mô hình State Machine là một trong những mô hình truyền thống trong khoa học máy tính. Nó là một trong những mô hình tác động ảnh hưởng tới cuộc sống hàng ngày của tất cả chúng ta thông qua các phần mềm khác nhau. Nó không phải là một quá trình xây dựng mã nguồn hướng theo mô hình thiết kế(design pattern), nhưng nó là khối hệ thống hướng, hồ hết sử dụng model xoay quanh các trường hợp nghiệp vụ.

Bạn Đang Xem: State Machine Design pattern

What is a State Machine in laymen terms

Hãy xem xét một tình huống đời thường rất cơ bản về việc đặt một chiếc taxi thông qua Uber:

1. Trước tiên bạn mở App, trang chủ screen xuất hiện, bạn đưa vào điểm đến lựa chọn trong thanh tìm kiếm.
2. Một khi điểm đến lựa chọn chuẩn xác được tìm thấy, Uber đưa ra đề xuất về hành trình dài cho bạn lựa chọn giống như Pool, Primier, UberGo, Uber XL,… cùng với một giá nếu có thể.
3. Một khi chúng ta chọn phương thức tính sổ và nhấn vào “Confirm” button với đề xuất về thời kì cho hành trình dài nếu yêu cầu, chuyến du ngoạn được xác nhận, tài xế nhận yêu cầu.
4. Uber hiện giờ đưa ra cho bạn một map, nơi chúng ta có thể theo dõi tài xế của mình.

Trong trường hợp này, screen một là độc lập, nó là màn hình hiển thị trước tiên được đưa ra cho tất cả những users. Screen thứ hai phụ thuộc vào screen 1, nếu không được cung cấp tài liệu có hiệu lực từ screen 1, bạn không thể vận chuyển tới screen 2. Hơn nữa, screen 3 phụ thuộc vào screen 2 và screen 4 phụ thuộc vào screen 3. Một khi hành trình dài của bạn được xác nhận và không có việc bạn hay tài xế hủy hành trình dài, bạn duy trì screen 4, bạn không thể đặt bất kỳ hành trình dài mới nào cho tới lúc hành trình dài ngày nay kết thúc.

Hiện tại, giải sử mưa nặng hạt, và không có bất kỳ tài xế nào gật đầu hành trình dài của bạn, hoặc không có tài xế được tìm thấy trong khu vực của bạn nhằm thỏa mãn hành trình dài của bạn, như vậy một thông điệp lỗi thông tin cho bạn biết là không có tài xế, và bạn vẫn được giữ lại ở screen 3. Cho tới khi chúng ta có thể di truyển về screen 2 rồi screen 1, chúng ta có thể trở về màn hình hiển thị trước tiên bằng bất kỳ các thức nào.

Nếu khách hàng lưu ý một cách cẩn thận ở đây, bạn đang vận chuyển thông qua các trạng thái khác nhau của một quá trình đặt xe taxi, chúng ta có thể vận chuyển tới các trạng thái tiếp theo chỉ khi một hành động đã kiên cố thành công ở trạng thái ngày nay. Ví dụ: Khi chúng ta đang ở screen 1, bạn không thể vận chuyển tới screen 2 nếu như bạn cung cấp một điểm đến lựa chọn sai, tương tự bạn không thể vận chuyển tới screen 3 mà không chọn một hành trình dài ở screen 2, trừ khi hành trình dài của bạn đã được đặt, bạn luôn có thể vận chuyển lại trạng thái trước đó. Tất cả chúng ta đã phá vỡ quá trình đặt xe taxi thông qua một loạt các hành động phía bên trên ví dụ nơi hành động là có thể hoặc không thể có khả năng gọi tới một hành động khác phụ thuộc vào trạng thái ngày nay của quá trình đặt xe. Điều này cái mà state machine được sử dụng cho mô hình. Về ý tưởng, tất cả những trạng thái là các tình huống độc lập, một trangjt hái có thể gọi tới trạng thái khác chỉ khi cái ngày nay được hoàn thành thông qua cả success và failure.

State Machine in Technical Terms

State Machine mang đến cho tất cả chúng ta sự tự do phân tích một công việc lớn, phức tạp thành một chuỗi các công việc nhỏ, độc lập khác giống như ví dụ ở phía bên trên – Quá trình chia nhỏ các hành động đặt xe thành nhiều trạng thái nhỏ hơn. Các công việc nhỏ hơn được liên kết với mỗi cái khác thông qua các events, sự chuyển đổi từ trạng thái này sang một chiếc khác, thông thường tất cả chúng ta thực hiện một vài hành động cái thực hiện một số công việc như ví dụ phía bên trên – Quá trình đặt xe thực tế ở back-end, quá trình sinh ra một hóa đơn, lưu trữ tài liệu phân tích người dùng, ghi lại tài liệu quá trình đặt xe trong kho lưu trữ, kích hoạt quá trình tính sổ khi hành trình dài kết thúc và rất nhiều cái khác nữa. Một hình thức thông thường cho một state machine là:

Why & When do we need State Machine

Nếu khách hàng có khả năng phân tích công việc lớn, phức tạp thành một số thành phần độc lập, nhỏ hơn, một state machine có thể giúp tất cả chúng ta hình dung và quản lý các đơn vị đó một cách trừu tượng hơn nơi tất cả chúng ta chỉ việc cấu hình khi nào một state có thể vận chuyển qua một sate khác và tất cả chúng ta tập trung vào quá trình khái niệm cái gì sẽ xẩy ra khi một quá trình chuyển đổi xẩy ra. Sau quá trình cấu hình, tất cả chúng ta không cần quan tâm tới làm thế nào quá trình chuyển đổi đó xẩy ra. Tất cả chúng ta chỉ tập trung vào khi nào và cái gì mà không phải là làm ra sao. Cũng như State Machine giúp tất cả chúng ta hình dung về toàn bộ quy trình của khá nhiều states một các dễ dàng dự đoán, một khi quá trình chuyển đổi được cấu hình tất cả chúng ta không cần qua tâm một cách hoàn toàn tới việc quản lý sai hoặc chuyển đổi sai giữa các states, sự chuyển đổi states sai chỉ có thể xẩy ra nếu tất cả chúng ta cấu hình state machine sai cách.

Tất cả chúng ta có một chiếc nhìn trọn vẹn về states, transitions(quá trình chuyển đổi) trong một state machine. Nếu tất cả chúng ta không sử dụng bất kỳ state machine nào, cũng như tất cả chúng ta không thể hình dùng về khối hệ thống của mình thông qua các states có thể khác nhau hoặc biết hay là không biết về việc dàng buộc chặt chẽ của khá nhiều components của mình với những cái khác, hoặc tất cả chúng ta đang viết rất nhiêu ĐK if-else nhằm tương thích với những trạng thái chuyển đổi cái tuần tự làm cho kiểm thử đơn vị(unit tests) và kiểm thử tích hợp(integration tests) trở thành khó hơn bởi vì tất cả chúng ta phải đảm bảo việc viết tất cả những test cases nhằm kiểm tra khả năng của tất cả những ĐK và nhánh được sử dụng.

Benefits of State Machine

1. Bạn thoát khỏi việc các ĐK cứng nhắc trong mà nguồn của mình. State Machine trừu tượng hóa tất cả logic liên quan đến states và transitions thay cho bạn. Trong phần tiếp theo, tất cả chúng ta sẽ khám phá một vài các thức khác ngoài State Machine nhằm tạo ra state hướng khối hệ thống, các bạn sẽ thấy các vấn đề trong các khối hệ thống đó.
2. Trong thực tế, sate machines thường có một số lượng giới hạn các states và các transitions rõ ràng được khái niệm trong các states đó, do đó nó dễ dàng trong việc theo dõi cái transition/data/sự kiện gây ra ĐK ngày nay từ một request.
3. Các nhà phát triển có thể tập hợp một cách chuẩn xác dưa trên quá trình khái niệm các actions và ĐK tiền đề sau thời điểm một state machine được cấu hình. Với quá trình kiểm tra ĐK và các ĐK tiền đề một cách chuẩn xác, sate machine tránh khỏi những hoạt động không thể xẩy ra. Như trong ví dụ về Uber, một tài xế không thể nhận được khoản tính sổ trừ khi hành trình dài kết thúc.
4. State machines có khả năng matain cao. các hành động logic được thực hiện trong lúc mỗi transition là độc lập so với cái khác. Do đó các mảnh code tương ứng có thể là độc lập.
5. Thông thường, state machines là ổn định và ít tập trung vào sự thay đổi. Do đó các trường hợp sử dụng ở ngày nay và tương lai là rất rõ ràng ràng, nó trở thành dễ dàng để maintain so với toàn bộ khối hệ thống.

Disadvantages with State Machines

1. Thông thường, state machines được đồng bộ trong tự nhiên. Do đó nếu bạn phải các quá trình thực thi dị đồng bộ của việc thực thi gọi APIs ngầm, chúng ta có thể cần xem xét nhằm lựa chọn chuẩn xác cái tốt nhất.
2. Mã nguồn có thể dễ dàng trở thành kềnh càng. Bởi vì state machines là phía tài liệu, phụ thuộc vào sự khác nhau của tài liệu và các thông số nguồn vào, đội xây dựng sản phẩm của chúng ta có thể yêu cầu bạn thực hiện các transitions khác nhau từ cùng một trạng thái. Do đó, với những yêu cầu loại này còn có thể gây ra việc có vài transitions với một vài ĐK kiểm tra ban sơ không rõ ràng. Nó hoàn toàn phụ thuộc vào sản phẩm và quá trình triển khai của state machine.
3. Nếu có yên cầu so với các thể hiện cân bằng tải của state machine, chọn cái có khả năng lưu trữ lâu dài(database – persistence data), ngoài ra chúng ta có thể cần thêm vào lớp này cùng với những đơn vị kiểm tra sự chuẩn xác của tài liệu nguồn vào do đó rất nhiều yên cầu hướng tới sự khác nhau của khá nhiều thể hiện state machine có thể nhận được một kết quả thích hợp.
4. Không có nhiều tài nguyên hoặc cộng đồng sẵn sàng cho việc triển khai các state machine khác nhau, do đó sự tương trợ có thể không được tốt một khi chúng ta lựa chọn một thư viện riêng biệt.

Things to take care when using State Mahines

Về mặt ý tưởng, nếu như bạn đang sử dụng state machine hoặc workflow system, bạn nên có hai thành phần logic trong khối hệ thống của mình.

1. Cái thứ nhất đó chính là State machine/workflow system.
2. Cái thứ hai là business logic của bạn được đóng gói trong một hoặc nhiều service. State machines/Workflow system có thể được hình dung như hạ tầng cái hướng tới sự dịch chuyển của khá nhiều trạng thái(State transition), nó xác thực tính hiệu lực của việc thay đổi từ một trạng thái sang một trạng thái khác, nó yên cầu hành động cấu hình trước/trong/sau một quá trình dịch chuyển(transition), nhưng nó không nên biết chuẩn xác business logic được thực hiện trong các hành động đó, nó là trách nhiệm của khá nhiều services của bạn. Do đó về cơ bản nó là một kế hoạch thực hiện tốt nhằm tách rời state machine khỏi các business logics nền tảng bằng phương pháp tạo sự trừu tượng phù hợp nếu không chúng sẽ tiến vào địa ngục của việc quản lý mã nguồn. Tất cả chúng ta có thể sử dụng if else thay cho việc sử dụng một state machine nhằm vận chuyển từ trạng thái này tới trạng thái khác khi trạng thái ngày nay đã kết thúc. Nhưng quá trình xử lý này là rất khó cho việc quản lý và một thiết kế tồi có thể phối hợp chặt chẽ vào khối hệ thống và có thể cung cấp ít nhất sự linh hoạt.

Real Life User Cases

Trong thế giới thực, rất nhiều vấn đề có thể được mô hình hóa xoay quanh state machine hoặc workflow system. Một số ví dụ:

1. Quá trình đặt hàng từ một trang thương nghiệp điện tử: Khi chúng ta đặt một số mặt hàng, quá trình đặt hàng đi qua các trạng thái khác nhau như: Đặt hàng, đóng gói, vận chuyển, hủy bỏ, nhận hàng, tính sổ, hoàn trả,…. Quá trình chuyển đổi xẩy ra một các tự động hóa khi mặt hàng dịch chuyển qua kho chứa hoặc các quá trình sắp xếp phục vụ hầu cần và quét qua các trạng thái khác nhau khi người dùng hủy bỏ hoặc yêu cầu trả lại,….
2. Quá trình đặt thực phẩm cũng trải qua các vòng lặp tương tự.
3. Trip booking(đặt xe) cũng luôn tồn tại luồng tương tự.
4. Mobile UI nhưng Android UI Activities, iOS Swift Activities cũng luôn tồn tại thể xem xét xoay quanh các states và transitions. Giống như ví dụ Uber, state machine có thể xác định screen nào được shown và show khi nào phụ thuộc vào tương tác và những tài liệu nguồn vào từ người dùng. Chúng ta cũng có thể trừu tượng hóa các screen activities của mình nhằm ẩn đi một số tài liệu, hoặc kéo qua tài liệu logic, vv,… trong một màn hình hiển thị riêng biệt và state machine có thể điều phối luồng đó.
5. React cũng cung cấp khả năng sử dụng state machine.
6. Micro-service deployment cũng luôn tồn tại thể được mô hình hóa xoay quanh các workflow và states.

Real Life State Machine / Workflow systems

Xem Thêm : Giới thiệu về ba càng là gì – Cách đánh lô 3 càng như thế nào luôn chiến thắng

Nếu khách hàng đã xác định sử dụng khái niệm về state machine, bạn được tự do lựa chọn cả đống các quá trình triển khai sẵn có. Ở chỗ này là một số khác biệt giữa State Machine và Workflow:

1. Spring State Machine: Nếu khách hàng không được thoải mái sử dụng một workflow system phụ hợp do lý do này nọ, chúng ta có thể sử dụng Spring State Machine để mô hình hóa các use cases. Nó tốt cho dự án nhằm khai mạc thu về những khả năng của một State Machine. Cụ thể hơn, các khả năng đó có thể được tìm thấy ở đây. Thông thường các start-up với những luồng nghiệp vụ không thật phức tạp có thể tiến tới sử dụng project này. Bạn phải cấu hình state, transitions, actions,… trong chính mã nguồn, hơn nữa, không có UI sẵn có nhằm tạo ra một workflow cho UI.
2. Activiti: Activiti là một Business Process Management Engine(BPMN) mã nguồn mở cái được ưu thích sử dụng cho những workflow phức tạp liên quan tới những trường hợp sử dụng trong các khối hệ thống doanh nghiệp. Nó cung cấp rất nhiều khả năng nâng cao nhưng querying service, monitoring, cloud ready service, vv,…. Nó lưu lại các workflow metadata trong chính database của mình. nếu như bạn có những workflow phức tạp hoặc một vài doanh nghiệp cần tự động hóa hóa các nghiệp vụ phức tạp, activiti có thể được xem xét như thể một lựa chọn. Alfresco cấp phép cho những người dùng các dụng cụ xây dựng một cách thân thiện trên cùng của nền tảng activiti cái có thể dễ dàng được sử dụng để tạo và quản lý các workflows.
3. Apache Airflow: Airflow(Thuở đầu là một Airbnb project) là một khối hệ thống workflow mã nguồn mở hướng Python. Nó có khả năng mở rộng, đóng gói module và thông điệp hướng hệ thông cao. Nó tạo ra sự dễ dàng trong việc khái niệm các task và các phần phụ thuộc dựa vào nó. Nếu khách hàng có những khối hệ thống viết bằng python hoặc chúng ta có thể có đủ khẳ năng viết một dedicated workflow management system/micro service với Python, bạn kiên cố có thể sẽ để ý đến Apache Airflow. Nó là một khối hệ thống được sử dụng rất rộng rãi. Tôi có thấy các đơn vị ETL(Đơn vị thu thập và tích hợp tài liệu) sử dụng khối hệ thống này để mô hình hóa các công việc xoay quanh quá trình xử lý bigdata.

Expectations from a Real life State Machine oriented system

Tôi đã sử dụng state machine trong một vài khối hệ thống. Do đó tôi diễn đạt theo ý riêng về một vài kịch bản trong thế giới thực cái tất cả chúng ta kì vọng được xử lý một các phù hợp khi sử dụng state machine trong khối hệ thống của mình:

1. State Machine không chỉ là về states, transitions, và actions. Nó cũng luôn tồn tại khả năng nhằm khái niệm một ranh giới giữa một state transition(sự dịch chuyển trạng thái). Giống như trong một số trường hợp, một quá trình chuyển đổi có thể thành công chỉ khi nó được kích hoạt bởi một khối hệ thống xác thực hoặc người dùng. Có thể có một số ĐK như vậy. Do đó tất cả chúng ta nên có khả năng khái niệm các logic nhằm bảo vệ một cách chuẩn xác việc enable/disable một quá trình chuyển đổi trạng thái(state transition).
2. Trong rất nhiều trường hợp, tất cả chúng ta có rất nhiều luồng công việc được kết thúc liên quan tới cùng một thực thể nghiệp vụ cái có thể được thực hiện song song. Trong những trường hợp này, một workflow không khóa các workflows khác, chúng có thể hoặc không thể được kích hoạt cùng nhau nhưng chúng có thể thao tác làm việc cùng lúc với nhau, workflow thứ hai nhận được thông điệp kích hoạt từ một trong các states được chọn và thao tác làm việc một cách độc lập. Điều này giảm bớt trường hợp bị tóm gọn buộc hoàn toàn bởi nghiệp vụ, rất nhiều nghiệp vụ có thể được giảm bớt các use cases.
3. Về mặt lý thuyết, workflow systems là độc lập với vùng nghiệp vụ. Do đó nhiều workflows hoàn toàn không liên quan tới các thực thể nghiệp vụ có thể được cấu hình một các tương tự trong workflow system, nó cung cấp một chiếc nhìn toàn cảnh về tất cả những quá trình xử lý logic nghiệp vụ thông qua các thực thể nghiệp vụ khác nhau trong khối hệ thống. Điều này cũng phụ thuộc vào các trường hợp nghiệp vụ cụ thể, các workflows có thể sử dụng các trạng thái san sẻ chung.

Problem Statement

Hãy xem xét một phiên bản đơn giản của ví dụ về vòng đời đặt xe của Uber. Vòng đời này tồn tại những states và transitions phía bên dưới được mô tả bằng một image. Hãy tìm hiểu những cách thức khác nhau để xây dựng khối hệ thống hướng trạng thái này(state oriented system).

The basic Approach

Một cách tiếp cận trực quan xuất phát trước tiên trong tâm trí là xử lý các states và transitions thông qua những khối ĐK if… else… đơn giản. Nhưng phương pháp này khó mở rộng, với mỗi state/transitions eddition/deletion mới, bạn phải phải thay đổi một lượng tương đối lớn các khối if… else …/ switch cái điều phối toàn bộ logic. Tham khảo mã nguồn phía bên dưới để thấy mã nguồn trông rối rắm ra sao và chỉ việc hình dung về cái gì xẩy ra thôi đã thấy mỏi mệt rồi. Phương pháp này còn có thể thao tác làm việc với những states, transitions rất ít thay đổi(tĩnh), những thay đổi là rất hiếm. Bạn nên tránh phương pháp này bởi vì nó sẽ tốn một ngân sách bảo trì khổng lồ. Ví dụ:

void manageStatesAndTransitions(Sự kiện sự kiện, InputData data) { State nextState = getNextState(sự kiện, data); switch(nextState) { case State.TRIP_REQUESTED: handleTripRequest(sự kiện, data); break; case State.PAYMENT: handlePayment(sự kiện, data); break; case State.DRIVER_ASSIGNED: handleDriverAllocation(sự kiện, data); break; case State.DRIVER_CANCELLED: handleTripCancellationByDriver(sự kiện, data); break; case State.CUSTOMER_CANCELLED: handleTripCancellationByCustomer(sự kiện, data); break; } } void handleTripRequest(Sự kiện sự kiện, InputData data) { if(sự kiện == Sự kiện.trip_requested) { // Check pre-conditions // do some work if needed… manageStatesAndTransitions(Sự kiện.payment_requested, data); } else if(sự kiện == Sự kiện.payment_failed) { showBookingError(); } } void handlePayment(Sự kiện sự kiện, InputData data) { if(sự kiện == Sự kiện.payment_requested) { Payment payment = doPayment(data); if(payment.isSuccess()) { manageStatesAndTransitions(Sự kiện.payment_success, data); } else { manageStatesAndTransitions(Sự kiện.payment_failed, data); } } else if(sự kiện == Sự kiện.payment_failed) { manageStatesAndTransitions(Sự kiện.payment_failed, data); } else if(sự kiện == Sự kiện.payment_success) { manageStatesAndTransitions(Sự kiện.driver_assigned, data); } }

State Pattern Approach

State patterm là một trong những mô hình thiết kế hành vi được đề xuất bởi Gang of Four. Trong partem này, đối tượng người dùng liên quan giữ các trạng thái cục bộ cái có thể thay đổi và các hành vi của đối tượng người dùng cũng thay đổi theo một cách tương ứng.

Charactoristics(Đặc trưng):

1. State chỉ ra các hành vi được khái niệm trong các lớp khác nhau và đối tượng người dùng ban sơ ủy nhiệm quá trình thực thi của hành vi cho quá trình triển khai đối tượng người dùng của state.
2. Các States gây ra sự chuyển đổi state từ một chiếc qua một chiếc khác.
3. Tất cả những state triển khai cùng một interface cái khái niệm tất cả behaviours/actions có thể.

Hãy mô hình hóa tất cả những states của quá trình đặt xe Uber phía bên trên thông qua mô hình phía bên dưới:

1. Tất cả chúng ta khái niệm một interface, cái thay mặt đại diện cho những hiệp ước của state. Tất cả những states sẽ triển khai những phương thức này, cái tuân theo hành vi của đối tượng người dùng ở một trạng thái cụ thể. Nếu một phương thức không được ứng dụng cho một state cụ thể, state sẽ bỏ qua quá trình khái niệm bất kỳ hoạt động trong phương thức này.

interface State { void handleTripRequest(); void handlePaymentRequest(); void handleDriverCancellation(); void handleCustomerCancellation(); void completeTrip(); // Driver completes trip, Unassign the driver. void endTrip(); // After driver is unassigned, do driver & customer rating, take feedback etc. }

1. Tất cả chúng ta sẽ thực hiện việc triển khai cụ thể cho những states khác nhau. TripRequested state: Đây là state ban sơ khi customer yêu cầu cho một chuyến du ngoạn. Nó thực hiện phương thức handleTripRequest và sau thời điểm hoàn thành quá trình khởi tạo ban sơ, nó thiết lập trạng thái thành Payment. Do đó state này gọi trực tiếp tới Payment state.

class TripRequested implements State { UberTrip context; public TripRequested(UberTrip ctx) { this.context = ctx; } @Override void handleTripRequest() { if(!context.tripStarted()) { context.setState(context.getPaymentRequestedState()); } } @Override void handlePaymentRequest() { System.out.println(“This state just handles initiation of trip request, it does not handle payment”); } @Override void handleDriverCancellation() { System.out.println(“This state just handles initiation of trip request, it does not handle cancellation”); } @Override void handleCustomerCancellation() { System.out.println(“This state just handles initiation of trip request, it does not handle cancellation”); } @Override void completeTrip() { System.out.println(“This state just handles initiation of trip request, it does not handle trip completion”); } @Override void endTrip() { System.out.println(“This state just handles initiation of trip request, it does not handle ending trip.”); } }

Payment state: Nó xử lý yêu cầu thành toán, các trạng thái failure hoặc success. Với trường hợp success, nó thiết lập trạng thái hành trình dài thành DriverAssigned, nếu failure, nó thiết lập trạng thái hành trình dài thành TripRequested.

Xem Thêm : Chỉ số IRR là gì? Công thức tính, Ý nghĩa và Mối quan hệ với NPV

class Payment implements State { UberTrip context; public PaymentRequested(UberTrip ctx) { this.context = ctx; } @Override void handleTripRequest() { System.out.println(“Payment state does not handle trip initiation request.”); } @Override void handlePaymentRequest() { Payment payment = doPayment(); if(payment.isSuccess()) { context.setState(context.getDriverAssignedState()); // Call driver assigned state. } else { context.setState(context.getTripRequestedState()); // Call trip requested state } } @Override void handleDriverCancellation() { System.out.println(“Payment state just handles payment, it does not handle cancellation”); } @Override void handleCustomerCancellation() { System.out.println(“Payment state just handles payment, it does not handle cancellation”); } @Override void completeTrip() { System.out.println(“Payment state just handles payment, it does not handle trip completion”); } @Override void endTrip() { System.out.println(“Payment state just handles payment, it does not handle ending trip.”); } }

DriverAssigned state: Khi người tài xế đã được giao cho một hành trình dài hủy hành trình dài đó, trạng thái của hành trình dài được thiết lập thành TripRequested do đó một trip request mới được khai mạc một cách tự động hóa. Khi driver hoàn thành hành trình dài, trạng thái của hành trình dài được thiết lập thành DriverUnAssigned.

class DriverAssigned implements State { UberTrip context; public DriverAssigned(UberTrip ctx) { this.context = ctx; } @Override void handleTripRequest() { System.out.println(“Driver Assigned state does not handle trip initiation request.”); } @Override void handlePaymentRequest() { System.out.println(“Driver Assigned state does not handle payment request.”); } @Override void handleDriverCancellation() { context.setState(context.getTripRequestedState()); // If driver cancels, go back to trip requested state & try again. } @Override void handleCustomerCancellation() { System.out.println(“Driver Assigned state does not handle customer cancellation.”); } @Override void completeTrip() { context.setState(context.getDriverUnAssignedState()); // Call driver unassigned state } @Override void endTrip() { System.out.println(“Driver Assigned state does not handle ending trip.”); } }

CustomerCancelled state: Khi khách hàng hủy bỏ hành trình dài, một hành trình dài mới không được đặt một cách tự động hóa, thay vào đó, trạng thái được thiết lập thành DriverUnAssigned.

class CustomerCancelled implements State { UberTrip context; public CustomerCancelled(UberTrip ctx) { this.context = ctx; } @Override void handleTripRequest() { System.out.println(“Customer Cancelled state does not handle trip initiation request.”); } @Override void handlePaymentRequest() { System.out.println(“Customer Cancelled state does not handle payment request.”); } @Override void handleDriverCancellation() { System.out.println(“Customer Cancelled state does not handle driver cancellation.”); } @Override void handleCustomerCancellation() { context.setState(context.getDriverUnassignedState()); // If customer cancels, umassign the driver & related stuffs. } @Override void completeTrip() { System.out.println(“Customer Cancelled state does not handle trip completion.”); } @Override void endTrip() { System.out.println(“Customer Cancelled state does not handle ending trip.”); } }

Ngoài ra, trạng thái DriverUnAssigned có thể được xử lý theo quá trình nhìn nhận và đánh giá, phản hồi về customer/driver và vận chuyển tới trạng thái TripEnd. Nó không được trình bày trong mã nguồn ở đây.

UbserTripClass: Lớp này mô tả tất cả những hành động có thể về một hành trình dài. Nó quản lý một internal state(trạng thái nộ bộ) cái được thiết lập là trạng thái độc lập của đối tượng người dùng. UberTrip ủy nhiệm các hành vi cho những đối tượng người dùng trạng thái độc lập.

class UberTrip { State tripRequestedState; State paymentState; State driverAssignedState; State driverUnassignedState; State customerCancelledState; // CurrentState State state; public UberTrip() { tripRequestedState = new TripRequested(this); paymentState = new Payment(this); driverAssignedState = new DriverAssigned(this); driverUnassignedState = new DriverUnAssigned(this); customerCancelledState = new CustomerCancelled(this); } public setState(State st) { this.state = st; } public getState() { return this.state; } public void requestTrip() { state.handleTripRequest(); } public void doPayment() { state.handlePaymentRequest(); } public void driverCancelled() { state.handleDriverCancellation(); } public void customerCancelled() { state.handleCustomerCancellation(); } public void completeTrip() { state.completeTrip(); } }

Pros & Cons of State Patern

Không có transition được khái niệm rõ ràng trong khối hệ thống này. Transition được xử lý bởi chính state của nó. Các states khái niệm các kiểm soát dựa trên một số thông số nhằm xác nhận cái có thể được gọi cho state tiếp theo hay là không. Đây là một phương pháp khá là xấu, mã nguồn khá rối nhằm xây dựng một khối hệ thống hướng trạng thái, quá trình transitions vẫn bị xiết chặt, ràng buộc khá chặt vào các states, và các states chịu trách nhiệm gọi tới các state tiếp theo bằng phương pháp thiết lập trạng thái tiếp theo trong context object(ở đây là UberTrip object). Do đó về mặt logic một đối tượng người dùng state xử lý cả những hành vi của nó lẫn các transitions có thể => Đóng rất nhiều vai trò, với nhiều trách nhiệm khác nhau. Với nhiều states và transitons mới thêm nữa sẽ làm cho mã nguồn trở thành phức tạp và khó kiểm soát. Cũng như tất cả những đối tượng người dùng state phải implement các hành vi chung thông qua một interface cái được xem là không cấp thiết và làm mở rộng công việc trong thế giới thực của quá trình phát triển phần mềm. Mô hình này là tốt hơn phương pháp cơ bản dựa trên if… else…/ switch cái bạn nghĩ đến ở đây về việc phân tích quá trình xử lý các states của mình và phân tích các hành vi thành nhiều các states, nhưng bởi vì transitions được xử lý bởi chính states nên phương thức này khá khó mở rộng và trong thế giới thực chúng ta có thể vi phạm nguyên tắc **Open Closed — Open for extension & closed for Modification **

Source

https://medium.com/datadriveninvestor/state-machine-design-pattern-why-how-example-through-spring-state-machine-part-1-f13872d68c2d https://medium.com/datadriveninvestor/state-machine-design-pattern-part-2-state-pattern-vs-state-machine-3010dd0fcf28

Reference

https://projects.spring.io/spring-statemachine/ https://docs.spring.io/spring-statemachine/docs/2.0.3.RELEASE/reference/htmlsingle/ https://www.activiti.org/

Phường/S

Những bài đăng trên viblo của mình nếu có phần Source thì đây là một bài dịch từ chính nguồn được dẫn link tới bài gốc ở phần này. Đây là những nội dung bài viết mình chọn lựa + tìm kiếm + tổng hợp từ Google trong quá trình xử lý issues khi làm dự án thực tế + có ích và thú vị so với bản thân mình. => Dịch lại như một nội dung bài viết để lục lọi lại khi cấp thiết. Do đó khi đọc nội dung bài viết xin mọi người lưu ý:

1. Các chúng ta có thể vận chuyển đến phần source để đọc bài gốc(extremely recommend).

2. Nội dung bài viết được dịch lại => Không thể tránh khỏi được việc hiểu sai, thiếu xót, nhầm lẫn do sự khác biệt về tiếng nói, văn cảnh cũng như sự hiểu biết của người dịch => Rất mong các chúng ta có thể để lại comments nhằm làm hoàn chỉnh vấn đề.

3. Bài dịch chỉ mang tính chất tham khảo + mang đúng ý nghĩa của một translated article được request từ phía cty mình.

4. Hy vọng nội dung bài viết có chút giúp ích cho những bạn(I hope so!). =)))))))