Has anyone used design patterns in his/her C#.NET project?

[Curious]

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?

 

[Gregory A. Beamer]

(e-mail address removed):


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! |
*******************************************

 

[Gregory A. Beamer]

You should learn how to use one of these two patterns.

http://en.wikipedia.org/wiki/Model-view-controller
http://en.wikipedia.org/wiki/Model_View_Presenter

I never have had any use for factory patterns that I have rolled my
own on. I have used factory patterns in a framework like CSLA, which
is the only time I have seen factory patterns in use, in many years of
doing object oriented programming.

I believe this is possible, but nearly every Enterprise application I
have worked on needs some form of branching. If you are building the
branch every time you use an object, you are wasting a lot of code, as a
factory does it better.

And coding a factory is not that time consuming, especially if you use
contract first development or heavily invest in Test Driven Development
(or even Unit Tests with the TDD approach). If you test in units, not
implementation, you end up having to code interfaces.

Believe it or not, you probably use factories a lot more than you think,
as many of the frameworks out there, including the .NET framework,
utilize factory patterns rather liberally.


Peace and Grace,

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

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

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

 

[Mr. Arnold]

I believe this is possible, but nearly every Enterprise application I
have worked on needs some form of branching. If you are building the
branch every time you use an object, you are wasting a lot of code, as a
factory does it better.

And coding a factory is not that time consuming, especially if you use
contract first development or heavily invest in Test Driven Development
(or even Unit Tests with the TDD approach). If you test in units, not
implementation, you end up having to code interfaces.

Believe it or not, you probably use factories a lot more than you think,
as many of the frameworks out there, including the .NET framework,
utilize factory patterns rather liberally.

I use MBunit, Gallio, and Reshaper for DDD and TDD. I do functional
tests. I consider unit tests not to give the bang for the buck, for the
time and for the effort.

 

[Hillbilly]

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

<snip />

 

[Brian Gideon]

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.

 

[Gregory A. Beamer]

I use MBunit, Gallio, and Reshaper for DDD and TDD. I do functional
tests. I consider unit tests not to give the bang for the buck, for
the time and for the effort.

I use IoC rather heavily (sometimes Dependency Injection frameworks, but
almost always interfaces). using this methodology, I can easily move
from a mock to an implementation test without writing any additional
code (just a minor change), so I am heavily reusing my work to set up
implementation tests from the unit tests.

If you do not employ this type of system, then it might be best to have
other testing.

When I have a QA department, I will often show them how to use my tests
for some of their tests (changing objects), or even set up
implementation libraries (regression primarily) for them to use. It does
not negate other QA testing, but it sure helps determine problems when
bugs are found.

Peace and Grace,


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

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

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

 

[Gregory A. Beamer]

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! |
*******************************************