Design Patterns - when/when not to use them?

Rej

Hi all,

I am working on a research project at for the past number of years, mainly using a combination of matlab & c++/c#. with more of a get it done, than do it right kind of an attitude if im honest....

Recently we have been in discussions about commercialisaion of our software. As it stands I reckon it would be a nighmare to support or maintain so I am trying to sort it out.

I have been reading up on design patterns but am unclear about when they should be applied. Any advice on when/when not to apply design patterns?

Thanks in advance
Rej

Pygmalion

What do you mean by "design patterns".
Every piece of software should be designed well according to some kind of design pattern, or are you talking about something more specific?

Sparks

Design patterns aren't things to use so much as they're a language to describe what you've already built, a kind of verbal shorthand for when you're talking to another developer (and I mean talking, rather than emailing, though they're useful there as well). Though a lot of people will abuse them to the point where they think they're immutable "blocks" to plug together

voxpop

Design patterns aren't things to use so much as they're a language to describe what you've already built, a kind of verbal shorthand for when you're talking to another developer (and I mean talking, rather than emailing, though they're useful there as well).

What!! :eek:


Design patterns are ways of solving common problems encountered when building software - they are there to promote good software.

Example: If you are creating a number of objects of a particular type within you program - you can use the factory or abstract factory
pattern.

You are probably using a number of pattern already but dont know about it, as alot of them are common sense. eg factory,observer,facade,singleton,etc


It all started here with the Gang of Four book

Sparks

That's my point voxpop - people have a habit of reading the gang of four book and then thinking they "must" bolt patterns together to build a solution - in fact, it's the other way around (sortof). A good solution can be described in terms of patterns. There's the point that language shapes thought, so if you're familiar with patterns, you may choose one to build the solution, but patterns were never intended to be a straitjacket for the mind, just a lexicon to aid discussion of design.

Read the original text (which was for civil engineering, not computer engineering). Even its title explains the idea well - "A Pattern Language".

cornbb

Rej wrote: »

I am working on a research project at for the past number of years, mainly using a combination of matlab & c++/c#. with more of a get it done, than do it right kind of an attitude if im honest....

Recently we have been in discussions about commercialisaion of our software. As it stands I reckon it would be a nighmare to support or maintain so I am trying to sort it out.

Ouch. Alarm bells. I was involved in a project which involved moving from a prototype/research project to a commercial product. It started with a house-of-cards codebase, involved over 2 years of refactoring and firefighting, and ended in redundancies. Approach with extreme caution.

Rej

cornbb wrote: »

Ouch. Alarm bells. I was involved in a project which involved moving from a prototype/research project to a commercial product. It started with a house-of-cards codebase, involved over 2 years of refactoring and firefighting, and ended in redundancies. Approach with extreme caution.

Wow... sounds like a bit of an ordeal alright. I might just put together a demo, sell it and run so In the past I have also worked on product that turned into a product and didnt enjoy that at all either.

ressem

Keep in mind that I'm making lots of faulty assumptions about your project from the paragraph you've written.

You're only starting with this stuff, so go easy. I guess that this is a small project. You're acting as architect and programmer?

I'd suggest writing down where you think the problems are currently.
Is the system fragile (might break with a matlab/c# update)? Undocumented? Performance-critical / realtime requirements which might not be met? People changing stuff and deploying without testing?

At this point, reading up on development anti-patterns might be useful to you. Afraid I don't know of a C# version, but Tate's Bitter Java (available from Manning as a PDF) is pretty short and applicable in a number of areas, e.g when to replace a group of chatty interfaces with a facade, elementary scalable topologies for systems that may need to get large, or get reliable. Setting up performance methodologies for testing and recording problems and how a built system is affected by changes...

You won't be allowed to start from scratch so...
you've to sort out high risk areas first. So read up, write out what you think these areas are, assign a risk likelihood. Ask colleagues to to the same, and argue for an hour.

But whether patterns should be applicable to your project at this stage is just too specific to your requirements.

I might be reading too much into the "get it done, than do it right kind" comment but if you want to go commercial or you plan on doing a load of refactoring, I hope you've got a sourcecode versioning repository and automatic build and testing.

JimmyCrackCorn!

Design patters are one of the fundamental building blocks of OOP.
They are solutions to everyday problems and an exercise in decoupling code.

One of my pet grievances was getting my degree with 0 mention of them all through college and only discovering them a year or so later.

While they are important to know its also very important to understand why/how they solve problems.

As for when you should use them there's a caveat. The old adage of when you have a hammer everything looks like a nail. You have to use your better judgement at the time as to what fits your needs don't try an shoe horn something in just for the hell of it.

matlab & c++/c#. with more of a get it done, than do it right kind of an attitude

As for the situation your in with the get it done now, I can guarantee it will bite you in the ass. As a minimum id raise a concerns with management.

Sparks

JimmyCrackCorn! wrote: »

Design patters are one of the fundamental building blocks of OOP.
They are solutions to everyday problems and an exercise in decoupling code.

Argh.
No, they're not.
They're how you describe those solutions, they are not the solutions themselves.
For example, Singletons (the single most widely understood and widely abused of the patterns in the gang of four book). A singleton is a design, not an implementation. It's higher-level than code or even a functional spec. It's like "Car" isn't the same as "1998 Ford Mondeo in powder blue with the automatic gearbox and the 2 litre engine with the sunroof and the CD changer".
We don't design systems at anything lower than the 40,000 feet view using design patterns, but with other tools. They're more an analysis tool than a synthesis tool - in synthesis they can be (ironically) a development anti-pattern.

One of my pet grievances was getting my degree with 0 mention of them all through college and only discovering them a year or so later.

We don't mention them in undergrad courses for a bloody good reason - namely that people introduced to them first tend to think there's only ever one way to implement the pattern, which is the very antithesis of what they're meant to do. You show someone how to do const global variables and static final class data members and #defines and other such implementations, and then you tell them about Singletons.
Do it the other way round and they learn bad habits.
Not to mention that the patterns in the gang of four book were only meant as an initial list - courses seem only to teach those patterns and students seem to learn that anything not fitting those patterns is wrong. Which is just bad all round really.