We flew into Salt Lake last night at around midnight and slept until about noon today. I'm still WAY tired, but there's still a lot of work to do, both for the home and for Chef Helper, so I guess I'll rest when I'm dead. So here we go...
One thing I've been having a really hard time with on this project is avoiding scope creep. Well, more scope change with a little creep mixed in. As I've coded some of these connections, I've realized that they would work better re-factored a bit. For example, I created the food types class to group food by its general type (i.e. dairy, meats, vegetables, etc) with the thought that I can group the shopping lists based on these types. The way I've explained it to people, this is to make shopping easier, going from section to section. But as I've built the relationships, I've realized that it's not as good of a grouping as I'd originally thought. A better grouping would be specifically based on shopping area. Let me explain - one of the food types is 'vegetables'. It's a good type, trying to keep them all together, but the more I think about it, the more I realize there are actually three or four places in a supermarket where you'll find vegetables: fresh, frozen, canned, and perhaps even dried. I have this insane urge to re-factor my system to take this into account, but I don't have the time to do so. Instead I have to make do and hope that making-do doesn't suck up more time than re-factoring would.
That being said, the recipe classes in the logic layer are almost complete. I have ways to add to the various parts, update them, and list/iterate through them for manipulation. I've written the classes so that each component handles its own and only its own updates. I'm thinking of this as a bottom-up model because you start with the smaller components and build them up into the overall components. Again I have this scope-creep option nagging at me to allow top-down transactions, so you can make changes at the recipe level and it will pass the work down to the smaller components. Again I don't have time to build this level of logic into the system and have to just ignore the urge to creep.
All this leads me to my current predicament - now that I have add, modify, and iterate/list capacities, I need to add delete capacities to each class. That's what is on the docket for today and I'm hoping to finish it. My major concern going into this is how to handle foreign key constraint issues. I'm debating between having each class check the master lists before allowing a deletion and strictly denying such a delete or providing a cascade delete option to wipe out all dependent objects as well. I know SQL databases have ONUPDATE and ONDELETE capacities, but I'm really not familiar enough with them to trust that they'll behave as I expect.
Okay, so I didn't get to work on this yesterday and totally forgot to post it, so even though this post says today, it was really yesterday. Yup, you heard it here, folks, this was yesterday. And don't let anyone tell you different.
No comments:
Post a Comment