The Church of Alvis

The constant struggle in our organization is the fact that Department of Justice constantly changes business rules and even what the business objects end up being.

After 11 years here, I've found that when I'm modeling a domain, I almost never code definite types for my business objects - I've been so accustomed to the constant redefinition that rather than modeling things at the level like having a class called "Assault" which inherits/implements "Offense" I just have a class called Offense which loads all of the necessary values from the database so that the records personnel can keep the system up to date with whatever lawmakers and the California and US Departments of Justice want to throw at us without me having to really modify any code. Some of this is also carryover from the legacy, COBOL system where things were just passed through byte arrays anyway.

However, I feel like this has leaked into ALL of my coding. As an example, I'm working on a side project for a friend that will allow him to manage membership status for his bar in Portland - basically if the customer drinks rums from this list, he gets promoted to some frequent drinker status, and that status can increase.

Anyway, the other day I was building my models and realized I had gone with the same dynamic approach. There is no "rum" - there's a spirit. There is no Bacardi 1909, there's a product. Granted, the products will be far more dynamic, so it makes sense to keep them data-driven, but spirit categories like Rum, Tequila, Whiskey, etc. aren't likely to change - so am I taking the wrong tack with that?

Thoughts? Jimer/Gando/Bulwark/OtherPeopleI'mNotMentioningThatKnowCoding?

Should there be a Product with a field of Spirit where the Spirit class just has fields of Name and maybe Description, or should it be that there's a Spirit base-class that Rum inherits from that can be in that field? Or am I just overthinking this and bothering you?

Just make everything of type String, and store all data as comma delimited text

Programming is a personal thing. If dynamic modeling is within your comfort zone and you enjoying coding that way then there is no issue keep doing it. Think of it as your programming signature.

If a menu of drinks has products, isn't class of spirit(whiskey, tequila,rum) just an attribute? Maybe I'm just think of it too much like a spreadsheet and not ina coding framework.

Sent from my SCH-I405 using Tapatalk 2

Blackferne wrote:If a menu of drinks has products, isn't class of spirit(whiskey, tequila,rum) just an attribute? Maybe I'm just think of it too much like a spreadsheet and not ina coding framework.

Sent from my SCH-I405 using Tapatalk 2

It could be, but this app isn't for cocktails, it's for spirits.

The idea being that I can go into Some Bar and sign up to be a Rum Club Member. At the novice level, I've tried no rums. To get to the Awesome level, I need to try (i.e. purchase) 5 rums from a list. Once I've tried the five rums, I'm Rum Club: Awesome. To get to Super Awesome, I need to complete the Awesome list, and then drink 5 MORE rums from the Super Awesome List. And so on.

I could leave this all very flat, but since the idea is that the members will want to review their history, etc., and see what rums they still need to try. Some will just care about the names, others will want to see descriptions like "Made in Puerto Rico by Bacardi Distilerias Limitadas, this rum is a blend of molasses-based and sugar cane juice based distillates, aged in used American Oak casks for 14 years before being urinated in by angels."

I figure I'll also give them the ability to rate the rums on a 5 star basis.

Then I change the terms and conditions and the privacy policy and sell all of that data to Facebook.

A little late to the party (so very busy lately), but I'll throw in my thoughts, as a rusty coder:

It's possible to get too attached to the structure of OOP classes as models, and it sounds like you've managed to avoid that, but that your concern is you're too loose with it. I think that on balance it's better to be loose than tight because data objects store data; you can (and should) use other techniques to enforce rules about that data. Unless you really need the inheritance and polymorphism features, a flatter class list isn't a bad thing. Code serves the task, not the system, if that makes sense.

In the end I'd rather have ugly but maintainable code than elegant but hard to modify code. Sometimes the most elegant class diagrams are simply gorgeous, the way a Jenga tower is when you first start the game. Clean, simple, completely without flaws, and ready to collapse the moment you try to change something.

Jimer Lins wrote:A little late to the party (so very busy lately), but I'll throw in my thoughts, as a rusty coder:

It's possible to get too attached to the structure of OOP classes as models, and it sounds like you've managed to avoid that, but that your concern is you're too loose with it. I think that on balance it's better to be loose than tight because data objects store data; you can (and should) use other techniques to enforce rules about that data. Unless you really need the inheritance and polymorphism features, a flatter class list isn't a bad thing. Code serves the task, not the system, if that makes sense.

In the end I'd rather have ugly but maintainable code than elegant but hard to modify code. Sometimes the most elegant class diagrams are simply gorgeous, the way a Jenga tower is when you first start the game. Clean, simple, completely without flaws, and ready to collapse the moment you try to change something.

Thanks Jimer. Sorry for not responding last week - I was in an architecture class being educated on how uneducated I am.