Stimulate (simulate?) Discussion

[Andrew Shafer]

Is anyone discussing OO, Patterns, UML or Refactoring?
Is it me, or does whichever forum is having the book giveaway start to resemble the meaningless drivel forum? (which I read all the time by the way)
Don't get me wrong, I want free books too. :P
I came to this forum with the pretense that I was interested in these topics right this minute and many a discussion would be waiting, but alas. Seeing how I can't bring myself to read another please-give-me-the-book post, I don't really want to write one.
A question for Andy (nice name) and Dave: I'm pretty familiar with UML (although I seldom use it as a design tool), I would estimate my understanding of OO at solid but there is always room for improvement and I'm starting to study and utilize design patterns. Right now I work as a one man show using primarily JSP/servlets and JDBC.
I know sometimes my time is not always spent in the most effective processes (for various reasons).
What would you consider the major benefits I would gain from reading your book?
Andrew Shafer

[Andy Hunt]

You'll become more productive.
You'll see things that you always *sort of* knew about, but hadn't ever articulated fully.
You'll roll your eyes and get a good laugh here and there.
At least, that's what a lot of people tell us. Read the reviews on amazon.com or borders.com and you'll see a very common thread.
Hope you enjoy the book,

/\ndy

[Dave Thomas]

Just to tack on to Andy's points.
Many people reading PragProg end up saying "I do that already", or "I never knew it was called that". In the same way that Design Patterns gives names to familiar design practices, PragProg gives names to development practices. Some are obvious, others are contentious, but most will get you thinking about them.
There are also some sleepers in there. One of my favorites is the DRY principle: Don't Repeat Yourself. Many people start off thinking we're saying "don't cut and paste code", but it's far more subtle than that. The DRY principle says that every piece of knowledge in your system should have one and only one definitive representation. That covers far more than code. Look at database schemas for example. Most schemas that we've seen contain massive amounts of duplication. And what happens: even the simplest change causes massive ripples through the system. Change a key from a number to a varchar, and all tables referencing that key change. All code that accesses that table changes. Much of the code that uses that code changes. It's a mess. With the DRY principle, you'd try to arrange things so that there's just a single place where the tpe of that column is stored: everything else would derive from that. Can you always achieve this? No, but the closer you get, the more flexible your systems. The book contains some practical examples of dealing with just these issues. (There's also a UML activity diagram showing how to make a Pina Colada)
Dave

[Sanjeev Arya]

Originally posted by Andrew Shafer:

Is anyone discussing OO, Patterns, UML or Refactoring?
Is it me, or does whichever forum is having the book giveaway start to resemble the meaningless drivel forum? (which I read all the time by the way)
Andrew Shafer

Right on target, Andrew. I posted a thread yesterday about a Decorator vs. Visitor issue from GoF, and it seems to be the only one with 0 replies yet! I have more questions about GoF patterns but am a bit reluctant to post after the deafening(!) response.

[Junilu Lacar]

Originally posted by Andrew Shafer:
Is anyone discussing OO, Patterns, UML or Refactoring?
Is it me, or does whichever forum is having the book giveaway start to resemble the meaningless drivel forum? (which I read all the time by the way)

Originally posted by Sanjeev Arya:
Right on target, Andrew.

Why don't you guys hang around after Carl gives out the free books. We were having quite a bit of good, meaningful activity here before the announcement was sent out. Just be patient, sift through the chaff and I'm sure you'll find a good nugget here and there.
Junilu

[Desai Sandeep]

Agree with Junilu, very interesting discussions were going on in this group, well before the free- giveaway books were announced.Hang in over here.It would great to share and learn in this forum .
-- Sandeep
[This message has been edited by Desai Sandeep (edited May 23, 2001).]

[Andrew Shafer]

The reason I made the original post was I kept coming and reading all the new posts in this forum and they seemed to be dominated by the C# and Book Giveaway posts.
Junilu,
After I made the post, went and read all the previous product/catalog/brittle coupling discussions and that was certainly thought provoking. (I'm still not confident with any of the answers though)
Desai,
I've read your posts before in other forums and they were always insightful, but I must admit, I'm glad you turned off that huge signature you had. :P
Dave/Andy,
I'm definitely intrigued with the DRY principle. Does your book discuss database schema? That has been a particular sticking point for me lately. You want to design the DB right the first time, but seems like you don't start to know what right is until you start having problems with your current design.

Andrew

[Dave Thomas]

Originally posted by Andrew Shafer:
I'm definitely intrigued with the DRY principle. Does your book discuss database schema? That has been a particular sticking point for me lately. You want to design the DB right the first time, but seems like you don't start to know what right is until you start having problems with your current design.

Databases are always troublesome. However, people also make them harder than they should be.
In the book we suggest a couple of simple rules:

• Always keep your schema representation in flat files, and arrange things so you can regenerate a database with a single command. For development databases, this normally means having a minimum of five scripts:
  
  
  
  1. a script to create the tables and other entities
     
  2. a script to add the constraints
     
  3. a script to drop the constraints
     
  4. a script to drop the tables
     
  5. a script to populate the database into its initial state
     
  
  Creating the initial database uses scripts 1, 2, and 5, while recreating it uses 3, 4, 1, 2, 5.
  This sounds complicated, but it means that you can always automate all your database actions: you're never left with a schema where some developer used sqlplus to alter a table online and forgot to tell everyone, as all schema changes are made via the scripts. (And obviously you keep these scripts under source code control...)
  
  6. The second issue is coordinating the schema with the code. There are a couple of obvious things (such as never using ``select *''), but we also recommend using tools to handle some of this for you. For example, you can use object-relational mapping products to create interfaces that are always up to date with your schema. You can also roll your own tools: Andy and I often write simple code generators that run off flat-file schema descriptions. My latest was a Ruby script that parsed the DDL for a complex schema and automatically created a set of triggers for updating versioning tables. This is in accordance with DRY: whenever a table changes, the trigger automatically gets updated to reflect that change.
     
  
  I don't think that you should necessarily put too much effort into getting the schema 100% right the first time around. Instead, work hard to decouple the schema from the rest of the code, so that changes are localized. This way, you'll be free to alter both the code and the schema without having to rewrite huge chunks of the system. A basic rule should be "there's no embedded SQL anywhere above the immediate database access layer". Business logic should deal with objects, not tables.
  Dave
  

[Desai Sandeep]

Originally posted by Andrew Shafer:
[..] but I must admit, I'm glad you turned off that huge signature you had. :P

I wish you would have told me earlier!!It is so bugging to click that checkbox again and again for the signature.Also I have to edit my posts again and again because, I donot like that -------(Line), above my name
Thanks,
Sandeep
[This message has been edited by Desai Sandeep (edited May 24, 2001).]