I second this opinion. Design Patterns by Gamma et al is more of a specification that has really terse explanations of the patterns with no implementations or very little implementation. Design Patterns Explained by Alan Shalloway et al is a great book for getting your feet wet. It reads like a novel, gives you really basic UML and the explanation for it if UML isn't your forte. The examples, which are to-the-point but lengthy enough to get an idea, are useful. I've treated DP by Gamma et al as a reference and DPE as a book by a fellow programmer and this seems to work for me.

I was guessing at the rest of the software industry was probably like this. Especially if you are embedded into a corporation where the main line of business is not software. I'm sure MS and other old software houses mostly have their ducks in a row, but from my experience. No one cares unless the project adheres to a totally arbitrary date "in the sky". As for your data "store & recall", it's not a bad strategy. I always build a Facade over the database so I can ditch the database coupling if I need to reuse the business logic. The MS databinding idiom helps with this. Supply me the data you want something done with and I'll return you something that you want.

That's fabulous. That's the end point that I'm looking for. I don't retain rights to my software so I usually have to rebuild any toolkits that I create for a given client. Yep, I'm working on that. Right now my concentration is building abstracts/interfaces that any system I touch gets a copy of. That way I can have a lingua franca for all of them. Sooner or later, all those systems become very simple to do nifty dependency injection or other super cool tricks.

Actually, I'd like to hear this too. The Class Designer in VS2005 is a little on the weak side. Better tools are great. But to be honest, I don't want to have to pay 10K$ for one of these either. That seems to be more the case than anything for UML to code tools.

To be honest, I'm very design heavy. I often come up with solutions that is a bit of overkill. The reason why I do this is I want something for free after my given project is done. So if a control is needed, then I make sure that I push my assumptions out to some form of config file and then everything else is really general. That way, being the "lazy programmer" that I am, I get to take that control with me to other projects. Sooner or later, I look like a super star with a large bag of magical tricks. As for design tools, I use UML on paper (I like to write OO if available in the given language). I also use the internal tool in VS2005 that is quasi-UML. I think it's called class designer. As for conceptual models I use Design Patterns. Why should I have to come up with robust conceptual solutions when its already done for me :) ? I find a lot of the software industry in South-Western Ontario Canada (including TO), is focused more on time than on quality and reuseability. To me this seems ass-backward cuz if you write a giant, heavily-coupled, monolith you don't have anything to show for the next project and maintenance is a total pain. I could go on forever. Have fun.

reshi999 wrote:

I think it will be useful under certain circumstances (ie. high degree of customisation, small data sets) - but is unlikely to replace SQL and VFP in my frameworks, both are fast and tune-able.

Whats VFP dude? I might be missing something that could simplify my life.

What was wrong with facading the database and just using LINQ as a handy technology? Nobody is saying you *have* to pollute your business logic layer with schema produced classes. You just have to make sure that you don't couple the database in a logic layer which could possibly be ported to other apps later. Its all about managing expectations / assumptions / dependencies. Good Luck :)