Command pattern and Flags – Part A Csharp OOP OOD

Before me and Copilot team up to extend on our protect <a simple book online order system>, I want to reflect on my flags, status and risks even.

My manager said something today about managing risk from a high level. It got me thinking about designing back-end systems, in a way to help minimize risk.

If A+B, trigger C. C could mean risk control teams to pay attention or investigate or stop something that potentially leads to high risk. 

Or, flipping status / flag in an unpaid shopping cart could easily help pull out data and target the correct client groups, which helps with customer journeys.

If A and not B, trigger email to customer and ask to pay.

Okay, without further due, Copilot and I will get into extend our simple book online order system. This time I want to apply command pattern concepts.

I added an interface class, ICommand, including execute(). Just keep it simple for now.

Here is the question that I had in my mind.

okay. I have interface ICommand class. Basically, for the command elements, I need order to be placed, cannot be null or invalid; I need shipping address to be valid; I need payment to be successful. These three elements AND logic to trigger the shipment happening. So, I am confused about how many child classes I should have Should I just have 1 child class and put these 3 elements in there with some bool attributes to flag status?

Copilot answer is:

You need to:

• Validate order is present and valid

• Validate shipping address is valid

• Validate payment is successful

• Trigger shipment once all above are okay

Copilot says if I put all attributes into 1 class:

Pros:

• Simple to implement initially.

• All related logic in one place.

Cons:

• Violates Single Responsibility Principle.

• Grows complex and hard to maintain as requirements grow.

• Difficult to unit test specific parts independently.

• Flags clutter the command.

If I put commands into different classes: Multiple commands with focused responsibilities (Recommended)

Break the process into smaller commands:

• ValidateOrderCommand

• ValidateShippingAddressCommand

• ProcessPaymentCommand

• TriggerShipmentCommand

Each command does one thing well.

Also, Copilot recommends an Orchestrator class to run commands, named OrderProcessor:

recommendation from Copilot and ChatGPT

I need to clear concepts on the definition between child command classes and Orchestrator class, such as what should be included in where.

1. Child command classes (individual commands)

2. Orchestrator class (workflow controller)

Child command classes

 What they should include:

• A clear, focused operation (e.g., validate order, process payment, etc.).

• Dependencies needed to perform the action (e.g., Order, PaymentService).

• Internal logic for that one action.

• Can optionally return status, flags, or throw on failure.

What they should not include:

• Sequence logic (like what comes before or after this step).

• Orchestration of multiple steps.

• UI or controller logic.

Orchestrator class (workflow controller)

What it should include:

• The full business use case workflow (e.g., "Place Order").

• The order and conditions under which each command should run.

• Error handling or rollback logic (optional but common).

• Dependencies injected as needed for commands.

What it should not include:

• Low-level business logic (keep that in commands).

• Data access logic (commands can use repositories).

I still need to implement it, but these child command class and orchestral class clear concepts and definition, I start to gain a better understanding! Now, let’s implemented!

I begun with make an interface class ICommand. To keep it simple, the contract only include Execute() for now. I will extend by adding such as cancel(), refund() and so so later.

Half way working through validate payment command class, i realized that I need to have a class that collect information about payment details. So I built make payment class.

Okay now, we moved on to the child classes of ICommand interface class. We need to give concrete implementation for execute(). What it does basically is to

• validate if an order is valid;

• validate if shipping address is valid;

• validate if payment is made successful; and

• flip status from false to true for each command to update status, enable easy tracking and data manipulation.

validate address command

validate payment command

validate order command

Now, as I am writing this, I realized something. So far, I have created list for book orders. But I have not done the same for address nor payment. Something to think about in future development.

Finally, because it is already a bit in this session, I will leave orchestral class development in part B.

Stay tuned!