At my company, we are considering rewriting our business logic and database to have a better architecture after years of organic and unforeseen growth, leading to the inevitable maintenance nightmare.
The business model is one where a, let’s say, cookie flows through multiple steps, changing states along the way. It is received raw, gets cooked, and is potentially split into two or more smaller cookies depending on the order. At this point, one of two things could happen: one, the cookie or cookies are considered finished and sent out to the customer, or two, the cookies requires outside processing (adding icing, adding food coloring, cutting to a design (there is no theoretical limit to an outside processing change to a cookie but it always changes the physical properties)), from which it is sent straight to the customer or back to us for shipment. The customer can reject the cookies if they don’t find them to their standards, and we can then store and attempt to resell the cookies to a less discerning customer and/or send them to outside processing again as per the customer’s whim.
The way our system currently works is initially assigning it a Raw Cookie number, then baking and/or cutting it and assigning the resulting cookie(s) a Finished Cookie number, one for each cookie. However, there is no common ground between any types of Cookies, resulting in a lot of extra code.
I’m trying to propose an object-oriented approach. I am fresh out of college while my coworkers are close to 30 or more years older than me; they know little about it and some are hesitant to change, so my model has to be pretty solid. I have worked with it academically, but never practically, and especially not when monitoring the form of a flow of a specific object. I may be a bit off in my understanding, but I believe OO is the best choice for this problem.
I have a UML diagram showing my proposed class hierarchy. Each kind of cookie that can be instantiated has access to a function that turns it into the next step’s cookie. Is this a correct way of doing it? Would it be better to have these toCookie() functions accessed through the static abstract Cookie class?
Don’t worry too much about inherited method placement, I’m just trying to understand how objects transform here.
1
Generally I would not burden the cookies with responsibilities for managing their subsequent state (in your own words: “a function that turns it into the next step’s cookie”).
Instead split the design into:
- business objects (cookies of different types)
- these would be passive data containers, e.g. something to store in DB
- business process steps (cookie factories to transform cookies)
- A RawCookieFactory that creates raw cookies from thin air
- A FinalCookieFactory that creates one (or more) final cookies fron a raw cookie
- An OutSideCookieProcessor adding embellishments to a final cookie
- etc.
- business process controller (at least one …)
There should be plenty of frameworks available to implement something like that (depending on implementation language, etc.) …
3