IddateWhat is your business?What is your job in the development lifecycle?How often are you using design pattern?How are you documenting the use of pattern in actual projects?Are you collecting self developed design pattern?How are you documenting the collected pattern?What is your profit of using pattern?Comments
004.03.04, 17:56Software DevelopmentDeveloperin every projectIn a comment in source and in technical docs, just referring to the well-recognized name of the pattern.  Better and faster communication with those who know patterns.In general, I do not look for patterns while developing. I just design and develop, founding later that some pattern was used. Then I look its name in a catalog (GoF). In other words, patterns are not a reusable components for me in the sense that I do not sit with the catalog: "hmm... this one looks nice, I'll try to shove it into my project". Patterns are pieces of architecture that are named *after* being used, which ensures that I use only those patterns that are needed.
104.03.04, 17:59Software DevelopmentDesignerin every projectMostly the patterns come up when discussing a problem. Documentation is mainly of the sort "this solution is based on the X pattern (see ref GOF)".  Mostly understanding each other when talking about the design of a system. Also as an inspiration to solving common problems. Most of the time complex problems are solved by a mix of basic patterns, which would have been tricky to find and understand without knowing the patterns behind it. Introduction of patterns at both architectual and implementation levels have proved very fruitfull. Especially when new people come into the projects. The lack of Ada-based pattern books and descriptions make it a bit tricky to implement, though. It would seem that some GOF-patterns can't be implemented in Ada without modifications.
204.03.04, 18:02Software DevelopmentDeveloperfrom time to timeyes  maintenance, designdp are nothing but common sense of a designer
304.03.04, 19:06Software DevelopmentDeveloperin every projectnotes on diagrams and comments in source code, naming the pattern used, with. ref. to literature.  All developers know and understand the same catalog of standard patterns, under common names. This gives great communication.
Also, studying patterns raises your skill level.		The GOF patterns book is the most important software engineering book of the 90's. And I'm not the only one to think so.
404.03.04, 19:44Software DevelopmentDeveloperused it once     
504.03.04, 20:55Software DevelopmentProj. Managerin every project     
604.03.04, 20:59
Software Development
Developer
in every project
comments + cvs logs		 

easier to recognise		 
704.03.04, 21:43Software DevelopmentDesignernever     
804.03.04, 23:13Software DevelopmentDesignerin every project     
904.03.04, 23:14Software DevelopmentDesignerin every projectOccasional comments  simplicity, clarityThe GOF book was a real revelation! Like - "wow thats what I have been trying to do all this time"
1004.03.04, 23:14Software DevelopmentDesignerin every projectyesYesyesefficiency, quality 
1104.03.04, 23:21Software DevelopmentDesignerin every project     
1204.03.04, 23:22Software DevelopmentDesignerin every project     
1304.03.04, 23:23Software DevelopmentDesignerin every project     
1404.03.04, 23:23Software DevelopmentDesignerin every project     
1504.03.04, 23:23Software DevelopmentDesignerin every project     
1604.03.04, 23:23Software DevelopmentDesignerin every project     
1704.03.04, 23:23Software DevelopmentDesignerin every project     
1804.03.04, 23:23Software DevelopmentDesignerin every project     
1904.03.04, 23:23Software DevelopmentDesignerin every project     
2004.03.04, 23:23Software DevelopmentDesignerin every project     
2104.03.04, 23:23Software DevelopmentDesignerin every project     
2204.03.04, 23:23Software DevelopmentDesignerin every project     
2304.03.04, 23:23Software DevelopmentDesignerin every project     
2404.03.04, 23:23Software DevelopmentDesignerin every project     
2504.03.04, 23:23Software DevelopmentDesignerin every project     
2604.03.04, 23:23Software DevelopmentDesignerin every project     
2704.03.04, 23:23Software DevelopmentDesignerin every project     
2804.03.04, 23:23Software DevelopmentDesignerin every project     
2904.03.04, 23:23Software DevelopmentDesignerin every project     
3004.03.04, 23:23Software DevelopmentDesignerin every project     
3104.03.04, 23:23Software DevelopmentDesignerin every project     
3204.03.04, 23:23Software DevelopmentDesignerin every project     
3304.03.04, 23:23Software DevelopmentDesignerin every project     
3404.03.04, 23:23Software DevelopmentDesignerin every project     
3504.03.04, 23:23Software DevelopmentDesignerin every project     
3604.03.04, 23:23Software DevelopmentDesignerin every project     
3704.03.04, 23:23Software DevelopmentDesignerin every project     
3804.03.04, 23:23Software DevelopmentDesignerin every project     
3904.03.04, 23:23Software DevelopmentDesignerin every project     
4004.03.04, 23:23Software DevelopmentDesignerin every project     
4104.03.04, 23:23Software DevelopmentDesignerin every project     
4204.03.04, 23:23Software DevelopmentDesignerin every project     
4304.03.04, 23:23Software DevelopmentDesignerin every project     
4404.03.04, 23:23Software DevelopmentDesignerin every project     
4504.03.04, 23:23Software DevelopmentDesignerin every project     
4604.03.04, 23:23Software DevelopmentDesignerin every project     
4704.03.04, 23:23Software DevelopmentDesignerin every project     
4804.03.04, 23:23Software DevelopmentDesignerin every project     
4904.03.04, 23:23Software DevelopmentDesignerin every project     
5004.03.04, 23:23Software DevelopmentDesignerin every project     
5104.03.04, 23:23Software DevelopmentDesignerin every project     
5204.03.04, 23:23Software DevelopmentDesignerin every project     
5304.03.04, 23:23Software DevelopmentDesignerin every project     
5404.03.04, 23:23Software DevelopmentDesignerin every project     
5504.03.04, 23:23Software DevelopmentDesignerin every project     
5604.03.04, 23:23Software DevelopmentDesignerin every project     
5704.03.04, 23:23Software DevelopmentDesignerin every project     
5804.03.04, 23:23Software DevelopmentDesignerin every project     
5904.03.04, 23:23Software DevelopmentDesignerin every project     
6004.03.04, 23:23Software DevelopmentDesignerin every project     
6104.03.04, 23:23Software DevelopmentDesignerin every project     
6204.03.04, 23:23Software DevelopmentDesignerin every project     
6304.03.04, 23:23Software DevelopmentDesignerin every project     
6404.03.04, 23:23Software DevelopmentDesignerin every project     
6504.03.04, 23:23Software DevelopmentDesignerin every project     
6604.03.04, 23:23Software DevelopmentDesignerin every project     
6704.03.04, 23:23Software DevelopmentDesignerin every project     
6804.03.04, 23:23Software DevelopmentDesignerin every project     
6904.03.04, 23:23Software DevelopmentDesignerin every project     
7004.03.04, 23:23Software DevelopmentDesignerin every project     
7104.03.04, 23:23Software DevelopmentDesignerin every project     
7204.03.04, 23:23Software DevelopmentDesignerin every project     
7304.03.04, 23:23Software DevelopmentDesignerin every project     
7404.03.04, 23:23Software DevelopmentDesignerin every project     
7504.03.04, 23:23Software DevelopmentDesignerin every project     
7604.03.04, 23:23Software DevelopmentDesignerin every project     
7704.03.04, 23:49Software DevelopmentDesignerin every project     
7804.03.04, 23:49Software DevelopmentDesignerin every project     
7904.03.04, 23:49Software DevelopmentDesignerin every project     
8004.03.04, 23:50Software DevelopmentAnalystin every project     
8104.03.04, 23:55ConsultantDesignerin every projectI use design patterns implicitly, with intensive JavaDocs. Much like J2SDK api documentation looks like.Yeslike mentioned aboveMy profit is that by implementing specific patterns a solution to a type of problem is thought out once and can be coded easily, errors will show up earlier and therefore coding speed and quality rises. 
8204.03.04, 23:57Software DevelopmentDesignerin every projectWe're not. We just use them and give them intention-revealing names.  Less time thinking about how to solve something then wondering if I did it right. If a pattern applies I only need to wonder if I identified the right pattern. Bigger blocks to play with.There are too many patterns. Popular kludges are not patterns--they're just popular kludges. Currently, the best patterns for Smalltalkers are in Kent Beck's Smalltalk Best Practice Patterns.
8305.03.04, 00:50Software DevelopmentDeveloperin some projectsNo.YesFiles with code, the code is documented...It's reusable, devellops faster when you're used to it, ...No :-)
8405.03.04, 01:17ConsultantDesignerin every projectClass and method naming indicate what patterns are used, to knowledgable developers. In this corporate environment, we find that we never really learn from our mistakes. ...or our successes.Improved code organization. Better communication of technical information -- largely through more expressive code. Less time and confusion in discussions (and arguments), as patterns help people come to a common understanding. 
8505.03.04, 02:12Software DevelopmentDeveloperin every projectIn no way  Time saving 
8605.03.04, 02:18Software DevelopmentDesignerfrom time to timenot, or in 1 line of comment nope, that is, not consiously.
I do remember what I wrote before of course, and try to map new problems onto old solutions		very little, in my opinion patterns are used in the 2nd or 3rd iteration, even if they are not made explcit.
Also, my problem domain is very wide, in lots of different languages, many of them not object-oriented, so patterns are not very useful then		you seem to assume in your questions that patterns are good/useful. I am not convinced that that is always the case.
(feel free to email me: a.t.hofkamp@tue.nl)
8705.03.04, 02:19Software DevelopmentDesignernever     
8805.03.04, 02:57Software DevelopmentDesignerin every projectInternal/external docs, uml  Easy Scallability, but remember the cost of developing software using DP's is initially higher. See the "Unified Process vs Extreem Programming arguments". The study of AntiPatterns is also usefull.A mathematical/statistical proof could be cool.
8905.03.04, 03:08Software DevelopmentDeveloperin every project     
9005.03.04, 04:50ConsultantAnalystin every projectUMLYesteam trainingstandardization, communicationIn today's egalitarian shops developers are often desginers, analysts, testers, and programmers.
9105.03.04, 05:15Software DevelopmentDeveloperin some projectsnot formally documented. Implemented in the code when applicable n/areusability; understanding 
9205.03.04, 06:38Software DevelopmentAnalystnever    I think the pattern movement is bogus. Use the database instead of code to manage diverse and changing relationships rather than hard-wire them into code. OO patterns are for people who don't "get" databases.
9305.03.04, 07:39Software DevelopmentDesignerin every projectYes. I use standard GOF terms as applicable, and a quick description in code and a brief tech documentation.  DPs help me by giving me ideas on how to solve a problem, and giving me extra forsight about consequences.DPs help me define my projects from an architectual level down to small details. I use Dylan Programming language which has many (16) DPs which are inherent or invisible. I am not creating new DPs as far as I know.
9405.03.04, 08:26Software DevelopmentDesignerin every project     
9505.03.04, 08:26Software DevelopmentDesignerin every project     
9605.03.04, 08:26Software DevelopmentDesignerin every project     
9705.03.04, 08:26Software DevelopmentDesignerin every project     
9805.03.04, 08:26Software DevelopmentDesignerin every project     
9905.03.04, 08:27Software DevelopmentDesignerin every project     
10005.03.04, 08:27Software DevelopmentDesignerin every project     
10105.03.04, 08:27Software DevelopmentDesignerin every project     
10205.03.04, 09:18Software DevelopmentDeveloperin every projectby giving classes and method names that suggest the use of the pattern to those who know the pattern. If the project requires documentation, the names will be reflected there. YesI don't. But i do support patterns through frameworks. Using those frameworks requires following the patterns. Sometimes i do document how to use the frameworks.making better designed code in less time. (Better design=more functionality with less code, more flexible). My notion of patterns is kind of vague, maybe i do not follow patterns but just reuse designs. But i do make abstractions. At some point i may read about a pattern and think "hey, i have used that for .." and from then on i may use the official names.
10305.03.04, 09:22Software DevelopmentDesignerin every projectReference to the GOF and implementation details in Software Design Document  Easy CommunicationWe also use some home made patterns (not collected but intentionally build)
Those are also documented in the SDD
10405.03.04, 10:06Software DevelopmentDeveloperfrom time to timeUsually not. I read patterns books for inspiration.

OTOH some things like "factory" are usually encoded in the object names.		  Mostly inspiration and a method to start breaking up a problem into subparts. 
10505.03.04, 14:46Software DevelopmentDesignerin every projectI try to use commonly used pattern names  Better understanding of code. It really feels better. 
10606.03.04, 04:18Software DevelopmentDeveloperin every projectRarely document the use of them outside of code. Usually document them in comments in the code, or by naming classes using the name of the pattern.Yeshttp://www.xmlpatterns.com- better communication of concepts
- easier to think about design in bigger "chunks"		 
10706.03.04, 11:38ConsultantDevelopernever    I am sorry that I am of no help to you.
Please send me your survey results,
as I am interested in this topic.
Thanks.
joecamel@cogeco.ca
10807.03.04, 00:36Software DevelopmentDevelopernever     
10908.03.04, 10:01Software DevelopmentDeveloperin some projectsI'm referring to the names in the book "Design Patterns" (ISBN 0-201-63361-2). I've not managed to learn more patterns.  Less time to explain and less to write. 
11009.03.04, 06:22Software DevelopmentDesignerfrom time to timeJust refer to it by name  I know the solution is well thought and works.
I have a common language to use about the solution and don't need to deeply document it.		 
11109.03.04, 08:58Software DevelopmentDeveloperfrom time to timei don't  functionality, readability, last but not least:
it solves problems.		 
11209.03.04, 09:05Software DevelopmentOtherin every projectComments and well-chosen variable and method names.  Good design leads to good software faster and cheaper 
11309.03.04, 09:19Software DevelopmentAnalystin every projectShort note with name. We only use GoF patterns

Note that we use only a very short list of patterns, like object factories		  Solutions for wellknown situations. 
11409.03.04, 09:22Software DevelopmentDeveloperin every projectIn Smalltalk the best documentation is the code itself.YesComments concerning the pattern of a set of classes I usually put into the class-comments, but as most patterns are already very known and well documented in the gang-of-four book that it is not necessary to loose time on this.- reusability
- understandablilty
- communication with other programmers
 
11509.03.04, 09:55Software DevelopmentDesignerin every projectnot at allYesclassic GoF text stylequality, clarity 
11609.03.04, 10:23Software DevelopmentDesignerin every projectnot doing this at all unfortunately we are not collecting patternsnone 
11709.03.04, 11:05Software DevelopmentDesignerin some projectsName of class, eg. XObserver is an observer of X
Mentioned in class headers, if any		  Easier to communicate with other people what the intention is 
11809.03.04, 11:35OtherOthernever     
11909.03.04, 11:36OtherOthernever     
12009.03.04, 11:36OtherOthernever     
12109.03.04, 11:36OtherOthernever     
12209.03.04, 11:36OtherOthernever     
12309.03.04, 11:36OtherOthernever     
12409.03.04, 11:36OtherOthernever     
12509.03.04, 11:36OtherOthernever     
12609.03.04, 11:36OtherOthernever     
12709.03.04, 11:36OtherOthernever     
12809.03.04, 11:37OtherOthernever     
12909.03.04, 11:37OtherOthernever     
13009.03.04, 13:32Software DevelopmentOtherfrom time to timenot  more robust code 
13109.03.04, 16:47Software DevelopmentDeveloperin every projectThey are just part of the "normal" project technical docs.  Err ... To do the things in the right way from the beginning by reusing the design.

It was not until I read about the patterns I really get some insight in object oriented sw development.		I was not sure about your definition of Designer/Developer
13209.03.04, 17:47OtherOtherin every projectUsing my own documentation standard, which can be extracted from the source code and added to the design documents.YesUsing my own documentation standard, which can be extracted from the source code and added to the design documents.Saves much time which would be spend on design issues if no patterns were used 
13309.03.04, 17:52Software DevelopmentDesignerin some projectsin design documentsYesusing javadoc in code, and having additional doc for collected patternsmore code reusability. Faster development. More standardized codepatterns are nice to use, but don't overuse them.
13409.03.04, 18:08Software DevelopmentDesignerin every projectHih level UML, unit tests and class comments  Productivity, consistency and using well studied solutions to common design problemsI'm not sure what statistical relevance you hope to get from such a short surbey
13509.03.04, 19:21Game DevelopmentProj. Managerfrom time to timeWe use Emacs to write documentation, and grep to search through it.YesSame as above.Vast. I can't imagine doing it any other way.Since you're insistent on spamming the newsgroup with your silly survey here's something to waste YOUR time. The above answers are completely made up.
13609.03.04, 19:52Software DevelopmentDesignerin every projectnot notCommucation between developers 
13709.03.04, 21:31Software DevelopmentDeveloperin some projectsNo special-case documentation. No one must be aware that this is pattern, that's OO encapsulation as I see it No collecting. I don't think of developing my own patterns, my bits of code just don't seem to be too genericSpeed of development is increased 
13809.03.04, 22:50Software DevelopmentDesignerin every project- naming convention: naming an interface ITaxCalculationStrategy is self documented.

- In class/method comments. This is very handy.
example:
//The IObjectStore interface defines the operation to read and write objects to the database. The interface is made to be used with a Proxy. Two classes implement this interface in SqlStore is the real implementation (stub) and the RemoteStore is a proxy that forward the calls to stub throug web services.

- uml stereotypes. in a class diagram where I use the composite pattern, I may add a uml stereotype <> to the classes. We also use uml notes sometimes.

- In textual descriptons in design documents.

YesWe have a document template similar to the structure of the GOF's book. We always include code exemples into the documentation.Reusing ideas is easier and more flexible than reusing code or components.
When we can't reuse code or components, we use design patterns.		Hope this helps!
13910.03.04, 00:43ConsultantDesignerin some projectsPrimarily UML class diagrams, although we have outlined the patterns used, along with links to dofactory.com (et al) to show what pattern is being used where. YesPrimarily by including in the documentation of the framework component (meaning our custom framework) or in standards docs for common patterns.Greatly accelerated development and creation of a common framework across numerous applications. 
14010.03.04, 02:28Software DevelopmentDesignerin every projectBy design-spec and via notes in UML  - using common solutions which I don't have to provide
- using patterns as a coarse grained vocabulary, so that other developers don't have to worry about each (finer grained) class		 
14110.03.04, 12:22Software DevelopmentDeveloperin every projectIf there is time, I write down a section about the different patterns and why they are used. Otherwise I just use UML diagrams and let it be up to the reader of the docs to recognize the patterns.  The biggest profit for me is that the patterns I use is already well tested in my area of work. Less worries for a relatively fresh developer. 
14210.03.04, 20:57Software DevelopmentDeveloperused it onceno   Design patterns are nothing but a statement of common sense.
14311.03.04, 02:13Software DevelopmentDeveloperin every projectIn source code document.   - It makes things easier to understand when I revisit an old piece of code.
- The recurrence of patterns in the code improves productivity.		 
14411.03.04, 06:38Software DevelopmentDesignerfrom time to timeMost of the times, the pattern name for GoF is mentioned in the documentation of a module. An example would be:
"This class is an adaptation of the Singleton pattern described in GoF"
  Tired of documenting data structures again and again. 
14511.03.04, 07:06OtherDeveloperin every projectUML diagrams and accompanying notes  Avoid problems that patterns were intended to address, decrease the time that other developers need to understand design.Invaluable tool to have in the toolkit!
14611.03.04, 08:50Software DevelopmentDesignerin every projectFactory method [GoF], or Visitor pattern [GoF]YesIn my memory, e.g. if you make a decision always write down why you made this particular choice and not another alternative choice.Ease of communicationIf I write two phase commit in memory like MTS or XAResource does, nobody understands it and I have to explain and explain and explain, while writing syncronized mediator [GoF] with automatic callback - everyone just accepts it - how come?
14711.03.04, 17:55Software DevelopmentDeveloperin every projectmostly using names: ie. FooVistor, BarVistee etc.  reuse, decoupling 
14812.03.04, 01:59Software DevelopmentDesignerin every projectUML-chart where I use a note to map the classes and methods to the one in the "Design Patterns" book.  It is a solution to problem, why inventing the wheel again. It is also a very good way to describe a complex solution to a complex problem in an easy way.To really benefit from Design patterns, the language has to support inheritance. In the LabVIEW case -> use GOOP Inheritance Toolkit from Endevo (www.endevo.se)
14912.03.04, 03:36Software DevelopmentDeveloperin every project     
15012.03.04, 06:08ConsultantProj. Managerin every projectComments in the code. Where applicable, the class documentation makes note of the patterns being used so that people familiar with design pattern terminology can understand how the class works and/or is to be used.YesText files, to be marked up and posted on the web and perhaps in a book.Design patterns are methods that occur repeatedly in designing things. Taking advantage of existing patterns---and documenting ones that arise in development---creates a recipe book of "best practices" for solving certain recurring problems. Having this as a reference (and using it) saves time and mental effort in the long run.Your questions are rather simplistic. I hope your methods are sufficient for your task.
15112.03.04, 22:30Software DevelopmentDeveloperin every projectWhen using standard patterns i write a comment refering to the Design Pattern Book (GoF).
Additionally i use Doxygen.
YesDoxygenprograms are:
- easier to maintain
- easier to understand for other developers
- A clean seperation between GUI and implementation is almost a side effect
All comments based on experience with C++.
15213.03.04, 17:26Software DevelopmentDeveloperin every project     
15314.03.04, 08:18OtherDeveloperin every projectDiagrams w/ notesYesDiagrams w/ notes on my home PCMakes the design easier to overlook, and more recognizable for others. Seperates the code, which makes debugging easier.  
15414.03.04, 09:18Software DevelopmentDesignerin every project     
15516.03.04, 03:54Software DevelopmentDevelopernever     
15616.03.04, 07:05Game DevelopmentTesterfrom time to timeSmetimes I make a comment in my codeYesSometimes I tell someone about itIt ames fun. Best pattern is to copy methods to another class. Guarantees reproducability and quality.I just love this site.
15717.03.04, 04:02ConsultantDeveloperin every projectInline comments, design documents, wikis  Avoiding mistakes by using tested successful methodologies 
15817.03.04, 04:59OtherAnalystin every project     
15917.03.04, 06:50Software DevelopmentDesignerfrom time to timeWe don't document them. In the future I will add comment with the name of the design pattern and a reference to the description in the book by Erich Gamma n.a.Design Patterns are proven solutions to complicated OO problems.Last year I went to an UML course where half a day was spend on design patterns. At that time I noticed that we were using some.
The lecturer recommended to read the book by Erich Gamma. I have the book but no time to read it.
16018.03.04, 17:53Software DevelopmentDesignerin every projectlittle to none    
16122.03.04, 01:51Software DevelopmentOtherin every projectIn shallow disguise. As design patterns are not very well known outside some teams, I basically explain the patterns themselves whenever I feel it is beneficial to the project at hand.    Using anti-patterns to localize profitable areas for refactoring is also nice.

powered in 0.15s by baseportal.com
Get your own Web Database - for FREE!