patterns-discussion AT lists.siebelschool.illinois.edu
Subject: General talk about software patterns
List archive
Re: [patterns-discussion] Using Design Patterns without dynamic memory allocation
Chronological Thread
- From: Linda Rising <risingl1 AT cox.net>
- To: Ralph Malph <ralph_malph AT yahoo.com>
- Cc: patterns-discussion AT cs.uiuc.edu
- Subject: Re: [patterns-discussion] Using Design Patterns without dynamic memory allocation
- Date: Tue, 29 Mar 2005 10:07:52 -0700
- List-archive: <http://mail.cs.uiuc.edu/pipermail/patterns-discussion>
- List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>
You might find that just a handful of patterns can help you make significant improvements. A little information hiding here and a single, focussed design decision there.... Good luck! Linda Ralph Malph wrote: Thanks, Linda. That describes me exactly. I am working on a quite large embedded system that was written by "senior" engineers at a research facility with minimal if any training in modern software design techniques. The software is a mess, and I'm starting to look at patterns as a way to restructure it. The entire code base is written in C++ without dynamic memory allocation, and from my initial pass through parts of the GoF book, it looked like dynamic memory allocation would be a requirement for using design patterns. I'll take a closer look at them. Andre --- Linda Rising <risingl1 AT cox.net> wrote: Hi Ralph, Just my opinion follows, but I think that somehow a lot of folks got the wrong idea about patterns because the GoF book (love all those authors!) just included examples in C++ and Smalltalk. Some of those folks (who got the wrong idea) were in the development community I knew best -- large, safety-critical, real-time, embedded, systems. Those folks took one look at the GoF book and said, "Nothing in here for me!" and dismissed it out of hand. This was unfortunate. A design pattern has nothing to do with dynamic memory allocation. Sure, many examples or implementations show this, but, for example, you can use a Mediator in FORTRAN!! Don't give up on design patterns, Ralph! They're an attempt on the part of well-meaning designers to share the best they know. We can all benefit regardless of our particular environment. Linda Ralph Malph wrote:Hello all, looking at archives I'm not sure how "alive" this list is, but someone out there mightbelistening. I'm interested in people's opinions as to whether design patterns would be useful if you could not dynamically allocate memory. I am new to patterns and find them quiteinteresting.I am considering putting in some effort tocomprehendthem, but my projects at work include embedded safety-critical real-time systems, and one of the things that we do not use is dynamic memory allocation. If anyone has an opinion as to whether I shoulddelveinto patterns for this type of software (i.e. youhaveconsidered doing them and/or done them in similar systems before) I'd be interested to hear it. Thanks! __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ _______________________________________________ patterns-discussion mailing list patterns-discussion AT cs.uiuc.eduhttp://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion-- Author of "Fearless Change: patterns for introducing new ideas" http://www.cs.unca.edu/~manns/intropatterns.html __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ -- Author of "Fearless Change: patterns for introducing new ideas" http://www.cs.unca.edu/~manns/intropatterns.html |
- Re: [patterns-discussion] Using Design Patterns without dynamic memory allocation, Ralph Malph, 03/29/2005
- <Possible follow-up(s)>
- Re: [patterns-discussion] Using Design Patterns without dynamic memory allocation, Ralph Malph, 03/29/2005
- Re: [patterns-discussion] Using Design Patterns without dynamic memory allocation, Linda Rising, 03/29/2005
Archive powered by MHonArc 2.6.16.