[workshop] abstractions

[Michal Wallace]

Someone asked me off-list about the "keep it separate" concept,
and whether it was really useful. I thought I'd share the answer
here and maybe get some discussion going.

(original message edited slightly for privacy):

> I agree that being able to change storage from one place is
> handy for architecture changes (like moving MySql to PostgreSql or
> something and only having to update your database class). However,
> the novice in me is crying out, "is all of this abstraction really
> necessary?" 


Well, in a corporate development shop, you often have
separate teams of DBA's, developers, and designers - so
that's one reason to separate the layers right there. And as
you said, the abstraction layer means you can switch databases
at a moments notice...

But what's the point if you're a one-man show and you don't
see any need to ever switch databases?

It's the rule of "Once And Only Once". For example, say you 
decide to use straight SQL, and you need a small app to 
add, edit, and delete records for each of three tables.

What do you do? Hard-code the INSERT, UPDATE, and DELETE
statements? That's certainly easiest, but it's also a lot 
of mindless work. 

Do you make one HTML form for adding records and 
a separate one for editing?

Actually, you'll probably move a lot faster if you do it
this way. You can even cut and paste. 

But what happens when you need to add a new column? You've
got to change it in the database, then update the code in
two different places (the INSERT and the UPDATE). If you
rename the table, you've got to change the DELETE statement, 
too.

But also... Is it really just a couple SQL statements 
we're dealing with here? No, you've got error-trapping code
to deal with. If you're dealing with strings, you've got to
check for single-quotes in the values so they don't mess up
your SQL. Plus, somewhere along the line, you've actually
got to open the connection and send the data.

Why repeat the same code over and over? When you see that
happening, it's time to refactor that logic into a function
or an object.


Here's a link for you, from my blog about 2 years ago. 
It doesn't really have much to do  with the database layer, 
but it shows how I abstracted out a generic form handler for 
my objects once I had them, and how it made the code a lot nicer:

   http://www.sabren.net/rants/2000/05/20000526a.php3


> At a certain point does all of this generic code become too generic? 
> So generic that it needs to be re-customized slightly for each project? 

That hasn't been my experience. I do make plenty of changes over
time, but it usually means that I'm adding features that now
improve all my apps at once. (Assuming I don't break compatability,
in which case I don't mind going back to update old apps - but then
I have test cases to point out what broke)


> Also, isn't it simpler to have your sql right in your code? 

I think it's simpler to write:

    db.delete("tablename", id) 

Rather than:

    $db->query("DELETE FROM tablename WHERE ID=$id")

But that's could just be a matter of taste.



> Wouldn't that make it easier to debug instead of trying to dig around 
> in class files to figure out where an error took place. 

Maybe, but... 

   - In python you get a nice stack trace so you see exactly 
     where it occurred

   - You're reusing the same code over and over again, so if
     an error does occur, you fix it ONCE, and you never have
     to worry about it again. (Especially if you write a test
     case for it)

     Heaven forbid you
     find an obscure error in the way you did it in one table
     and realize you've got to go back and fix it in ALL your
     queries.

   - You can debug and test it on its own. For example, my
     storage layer is backed up by test cases, which I can
     run just by typing a simple command. (Also, for the
     storage system I posted, the MySQLStorage tests subclass
     the MockStorage tests, so I didn't have to write extra
     code)


> Another issue I have is with code reuse in general. If you
> need to tweak a piece of reused code that is called from 
> several sites, it can be very dangerous if there is a bug
> or something.

So start from scratch each time? :)

You don't have to use the exact same files. Especially if you're
using a good version control system.

Also, if you have test cases for your stuff, it's easy to
see what broke. (And if something broke and you missed it,
you can just write another test case)


> For the most part I agree with centralized code and functions ...
> Plus I have a tiny library of functions I reuse all the time in all 
> my sites, but they're just little building blocks that I can stack 
> together. At a certain point it feels like all the classes exists 
> purely for their own sake. "There's a class to generalize all the 
> storage you do in a database which is called by the class that 
> figures out all of the datatypes in a table. This in turn
> is wrapped up in a class for setting up local variables..." and on 
> and on. It feels like more code than is needed. If I can see the 
> datamodel SQL file, then I don't need some abstraction that figures 
> out what's in my tables for me right?


---------
I didn't really respond to this below... But I no longer
try to figure out what's in the table by reading metadata.
I specify it explicitly in my object model, and make sure
the object model matches up exactly with the tables in my
database. It's much simpler, and it also paves the way for
generating your CREATE TABLES and whatnot automatically 
from the object model -- (though I haven't done that yet).
---------


If your abstractions are getting in your way, you need better 
abstractions. :) 

The important thing is to simplify the interface. If it's simple
to use, it probably doesn't matter how complex the pieces are --
until it comes time to change the pieces anyway :)

If it's not simple to use, why did you make it? :)

And no, you shouldn't have classes for their own sake.
Have classes when you need to encapsulate a certain set of 
behaviors - especially when you do the same thing over 
and over again.

Sincerely,

Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: michal@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.sabren.net/
--------------------------------------