When designing in Object Oriented Programming (OOP) the question I always ask myself when trying to figure out where some piece of code should go is, “Who does this behavior belong to?”.
If our class names are nouns, such as Orders, Books, ProductColors, ERPOrderSender, etc., then it is usually easy to figure out what behavior (or class method) belongs to which class.
Recently I had to add a condition to our order fulfillment workflow to look for suspected fraud orders, and stop them from being processed.
Originally, I had written a simple method to do this inside our ERPOrderSender Class, which is the class responsible for sending EDI order data to our ERP system.
After a while, these new suspected fraud orders start showing up in our “Stuck Orders” Report, and I needed a way to tell that report the reason these orders were stuck. Clearly the ERPOrderSender Class was no longer the right place to house the “Are you a suspected fraud order” code.
In this case I created a new class called OrderReview, and a new method called getReviewStatus(). The new framework now works equally well when called in the context of Order Fulfillment, and in Reporting.
OOP is great. It allows us to think in terms of system behavior. This makes our system easier to talk about in natural language. Which is just more fun – and makes our lives easier.