Yesterday I was working on a little Java program that, when given a table, a "possible" candidate key (which could be composite), and some non-key columns would check to see if the table was in
1st, 2nd, or 3rd normal form(s). One constraint is that this program needs to be procedural in style (or rather, all of my code must reside in the file that contains the
main() function).
I started out with the
pseudocode programming process in
psvm. My listing started to look like:
// validate the input args[]
// extract the table, "possible" candidate key, and non-keys
// validate that there are no duplicate columns in the "possible" candidate key and the non-keys
// validate the table exists
// validate the columns exist for the "possible" candidate key and the non-keys
...
// and so on
At that point, I decided to go ahead and start coding. Now, I wasn't using
TDD, since I have no clue how I might go about doing so other than to first code in different classes, and then migrate everything over to
main(). In that case, I figured there may very well be more bugs after migrating, rather than less. So, I just started coding.
Once I got down to having to hit the database table to verify it and the columns existed, I got stuck. I didn't know if I needed to test against an actual DBMS using JDBC or if I needed to check against a .CSV file, for example. I stayed stuck and thinking for a while, until I started thinking in objects (or more generally, and importantly, abstract data types). At that point I realized that whatever I did, I'd have to store it some how, and in doing so, I could "fake it" and implement that part later. All I needed was the interface, essentially.
Now, this is a technique you'll often use in
OOP and especially if you're following test driven development, but given the nature of the constraints, I didn't think about it immediately.
The point is that even if you
aren't programming with objects or using TDD, you can still think about abstraction, and use it to continue coding even when the detailed implementation-level requirements aren't fully specified. I'm not sure this is something I would have thought about when programming purely procedurally, so hopefully it will help someone out, as it certainly did for me.
Thoughts anybody?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Great point. Writing good programs is about writing layers of languages - from the bottom up (to encapsulate file or db operations) and from the top down (to describe "executable business requirements" that can then be implemented in some appropriate manner).
All in main()? Urrrggghhh :-<
Posted by
Peter Bell
on Mar 12, 2007 at 09:27 AM UTC - 5 hrs
Well, I'm free to write as many procedures as I want, but basically, it all needs to be in that file. That's how I understood it anyway - so I guess I could be wrong about it =).
I like that you took it even further - I remember reading you writing that before, but I didn't even think of how that might apply here.
Posted by
Sam
on Mar 12, 2007 at 09:47 AM UTC - 5 hrs
