A business associate asked me what design patterns ("Gang of Four") I
used in designing my software system.

Although I read the entire book about Design Pattern, I never
explicitly used any pattern in my design. For instance, when I design
my trading system, I have many instances of "Order" and "Execution". I
simply "new" each to create a new instance without labeling this as
"Factory" pattern.

I asked around my developer friends, no one explicitly has used any
design pattern in their work. Do I miss anything here? Shall I think
of using design patterns next time when I develop a new system?

Curious <fir5tsight@xxxxxx> wrote in news:9190855b-b317-41c1-8f25-
fa90e95a6a89@xxxxxx:


yes, I use patterns rather religiously.

> A business associate asked me what design patterns ("Gang of Four") I
> used in designing my software system.
>
> Although I read the entire book about Design Pattern, I never
> explicitly used any pattern in my design. For instance, when I design
> my trading system, I have many instances of "Order" and "Execution". I
> simply "new" each to create a new instance without labeling this as
> "Factory" pattern.

And you might only have one type of order and execution throughout your
entire process and not currently need the flexibility of a factory.

Where I routinely use factories is on communication type libraries.
Examples:

Short Url Library uses a factory to determine which short url site API
to use. Configured in the config file.

Data Access library has a factory for database type.

Even trickier, generic LINQ to SQL library (meaning uses generics) has a
factory to retrieve DataContext.

Another pattern I use often is a singleton. Almost every application has
some information that is only applicable once for all users. The
Singleton allows you to spin it up once and reuse.

> I asked around my developer friends, no one explicitly has used any
> design pattern in their work. Do I miss anything here? Shall I think
> of using design patterns next time when I develop a new system?

Possibly, but when you first get started you will be tempted to over
design pattern things, which can be just as bad. A better approach is
building in refactoring time and refactor to patterns (which is a great
book, btw).

Peace and Grace,


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

We're all using patterns whether we formalize them or not.

<snip />

On Aug 17, 8:46*am, Curious <fir5tsi...@xxxxxx> wrote:

> A business associate asked me what design patterns ("Gang of Four") I
> used in designing my software system.
>
> Although I read the entire book about Design Pattern, I never
> explicitly used any pattern in my design. For instance, when I design
> my trading system, I have many instances of "Order" and "Execution". I
> simply "new" each to create a new instance without labeling this as
> "Factory" pattern.
>
> I asked around my developer friends, *no one explicitly has used any
> design pattern in their work. Do I miss anything here? Shall I think
> of using design patterns next time when I develop a new system?

I use patterns all the time. Not all are necessarily from the GoF
book though. The .NET Framework has some of the GoF patterns
builtin. For example, events are an implementation of the Observer
pattern. The foreach loop is an implementation of the Iterator
pattern. I suspect you use formalized patterns more than you think.

"Hillbilly" <nobody@xxxxxx> wrote in news:O6PLvN7HKHA.4376
@TK2MSFTNGP03.phx.gbl:

> We're all using patterns whether we formalize them or not.
>
> <snip />
>

I may have to steal that quote. ;-)

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************