Do you suggest a beginner to use GoF patterns? Do we really need to GoF in embedded world?

Go To Last Post
43 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just were reading this page:

 

https://en.wikipedia.org/wiki/Design_Patterns

 

But before going to learn how to use "Design Patterns" I want to ask:

Do we really need to GoF in embedded world?

Do you suggest a beginner to GoF patterns?

Do you use them in your embedded projects?

 

 

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

Last Edited: Thu. Jul 6, 2017 - 04:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was using some of those design patterns even before they were given a name! So, yes, whether or not you use those names, you'll end up writing code that does it anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The GoF design patterns are good to know if for no other reason than that you will keep encountering them. Bear in mind, however, that many of them exist because the authors had to solve their problems at compile time. Most of the patterns become much simpler or even superfluous, when you write programs in a dynamic language such as Lisp, Smalltalk, Python or Ruby.

 

If you can, try to read some of the criticisms of the patterns, as you learn them. It is good practice for thinking about what you need to do to solve a problem versus what you have to do to satisfy your tools. Some days, you will find yourself mostly doing the latter!

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you use UML?

Do you have any example(project) that use patterns to create your project?

Would you show us and explain it to us, please?

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On AVR's and lots of other uC's C and increasingly C++ are still the most popular languages.

 

With C it's very easy to shoot yourself in the foot and with C++ on small uC's it even easier to hang, draw and quarter yourself.

https://en.wikipedia.org/wiki/Ha...

 

But this does not make them bad languages. Just sharp tools which you have to learn to apply correctly.

So after a "beginner" has written a few for loops, done some function() calls and has gotten comfortable with the basic syntax structure ist's getting time to learn how to apply the language correctly and efficiently to the problem at hand.

 

The "design patterns" book seems to be good attempt in generalising the different structures / styles in which code can be written.

There seems to be lots of high quality info there which I learned in bits and pieces over a period of 20 years or so.

 

So Yes, reading a few books about general progam design and code structure is a very good idea, especially for beginners.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's plenty of examples of code on the interwebs that is explained with the use of patterns. Try finding some web stuff where it is littered with this.
As for UML, i might use if it i need to do a presentation, but otherwise i use doxygen to illustrate the code structure. It also generates UML.
As my education predates the use of 'design patterns', i needed to get a working knowlege of terms when going for job interviews and in my employment, interacting with coworkers who were educated in the patterns. Using the many javascript franeworks for web, one frequently hits various design patterns.
As well, writing iphone apps comes with it's own terms that one needs comprehend - like 'delegates'.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Rohalamin!

 

Stop. Now. There is no quick'n'easy "fix" for Design Patterns.

 

There is one way I'm certain Design Patterns are not to be used, and that is as some kind of dogma, "sacred technique" or similar. Please don't take this personally - it is not meant that way - but the figure you attached is stupid. Plain stupid. Words like "sacred", "holy" and "faith" has nothing to do with Patterns - quite the opposite.

 

And no, I'm not talking about subjects that are not allowed here at 'freaks. I am talking about looking at Design Patterns as some kind of magic technique to create good code.

 

Here's what you should do:

 

1) Get a good book about patters. Read it. Think less about the specifics in every pattern, but more about how problems in general are solved using patterns.

 

2) Study a few patterns in somewhat more detail. Just three or  four. Some suggestions: Factory, Observer, Singleton, Decorator. Think again in the same way as for point 1 above (how, in general are they solving the problems?

 

3) Are there any common "higher order techniques and principles" involved? Since you know my answer to that is "yes" I'll tell you some of the principles I see involved:

 

- High "cohesion": Any object, function etc should do "one thing and one thing only".

 

- Low "coupling" : The dependencies between different objects, functions etc should only be the necessary ones.

 

- A pattern is general in the sense that it solves a "class of problems" (that "class" is not the "class" we talk about re e.g. C++), but specific in that it only solves that class of problems. I.e. at a certain abstraction level a Design Pattern is very well and precisely defined.

 

4) Study some more "intricate" patterns. Two suggestions: Strategy and Visitor.

 

5) Take a uni course in Computer Science that has Design Patterns as one of it's dominating subjects.

 

A person who's "had a look at" design patterns will with almost 100% certainty just make a mess. Being good at applying patterns might require years of experience.

 


Side-bar philosophy

 

I've met many programmers over the years who think that Design Patterns are some magic solution, and if they just read up on them for a few weeks then they will after that code bug-free, clear, maintainable and efficient programs. What many of them end up doing is applying design patterns without actually having understood them.

 

They suddenly have a hammer in their hands and everything starts looking like nails. Remarkably, a substantial part of the things they are looking at is actually screws, bottles of glue, rivets, welding material etc. Applying a hammer to any of those will make a mess in one way or another.


Do not try to apply design patters before you have mastered object oriented programming in general. There is no way around this. Period. (Asking about a "cheat sheet" for C++ object orientation and then ask about "patterns" is not a good combo IMO. Nail C++, or  Java, or C#, first.)

 

When you start utilizing patterns, do so under "supervision". The absolutely best thing is do it in a team where there are experienced and/or senior programmers and where there is a mandatory system of code review in place.

 

As for many disciplines, including coding in general, these are good (essential, if you ask me) habits:

 

- Read a lot (Read a lot of code, read a lot of applied design patterns). Choose good sources for your reading.

- Write a lot. Prepare to throw a lot away.

- Actively seek constructive critique.

- Accept code reviews as positive and constructive - not as derogatory.


Sidebar philosophy 2

 

Applying patterns is a lot like driving cars: The basics are learned. Then, with a fresh licence the driver starts applying on his own what he has learned. Initially this is a nervous and shaky experience. For someone with a fresh drivers license it takes a few weeks or months to get reasonably relaxed, but with that comes the real danger. Suddenly the driver (especially young'ish boys/men) think that they are excellent drivers. The outcome is that young drivers with a license that is, say, 0.5 to 5 years old are vastly over-represented in accident statistics. A car driver actually becomes a good driver after having had his licence for at least five years (generally speaking, and assuming that he drives regularly during that period).

 

The situation is similar for using design patterns. It just takes a lot of coding experience to use them "goodly".

 

I guess the bottom line is that every coder using patterns, but who learned about them less that two years back should have an "L sign" pinned to his back. ;-)


 

Now, go read up on the Observer pattern for a few days. The Wikipedia article is probably good. Google around. Read. Think. Come back here in a few days and tell what you think about it, and how you envision using it. Maybe you've seen the Observer pattern in a lot of code already, and can relate? Then we can have an interesting discussion. (-:

 

(I can assure you you've encountered something similar to Observer many times, but for the sake of the exercise I'll let you try to identify it/them yourself.)

 

 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. Jul 5, 2017 - 09:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
And no, I'm not talking about subjects that are not allowed here at 'freaks. I am talking about looking at Design Patterns as some kind of magic technique to create good code....

Found it on the net and put it on the first post to tell you what I'm talking about.

JohanEkdahl wrote:

5) Take a uni course in Computer Science that has Design Patterns as one of it's dominating subjects.

 

A person who's "had a look at" design patterns will with almost 100% certainty just make a mess. Being good at applying patterns might require years of experience.

Johan

I learn everything at home.

Yes, Agree that being good at applying patterns might require years of experince but I think you can become great with more practice. this is what happens in years to become great. you see problems and try to solve them. probably reading the stuff that some well-exprienced people write is a good idea.

JohanEkdahl wrote:

Do not try to apply design patters before you have mastered object oriented programming in general. There is no way around this. Period. (Asking about a "cheat sheet" for C++ object orientation and then ask about "patterns" is not  good combo IMO. Nail C++, or  Java, or C#, first.)

But I thought using patterns is a part of OO programming and we must use it when we are coding using OOP. I have no experience in OOP, Johan and as you and others said previously it's really different.

JohanEkdahl wrote:

When you start utilizing patterns, do so under "supervision". The absolutely best thing is do it in a team where there are experienced and/or senior programmers and where there is a mandatory system of code review in place.

 

As for many disciplines, including coding in general, these are good (essential, if you ask me) habits:

 

- Read a lot (Read a lot of code, read a lot of applied design patterns). Choose good sources for your reading.

- Write a lot. Prepare to throw a lot away.

- Actively seek constructive critique.

- Accept code reviews as positive and constructive - not as derogatory.

...

Is CodeReview a good one?

https://codereview.stackexchange.com/questions

 

 

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll repeat the most important advice given the knowledge level you have stated : Learn C++ first.
Taking on both C++ and Design Patterns at once will be counter-productive.
Spend a year or so with C++ first.
-----
If you are just curious about Design Patterns then start by reading the Wikipedia article on it. Then, as I said, read up on the Observer pattern - it is a good, not to complex, example. If you then want something more challenging, look at Decorator.
I am prepared to discuss what you read in the general Wikipedia article, and the two patterns I just mentioned, with you.
-----
But, again, you must have a good knowledge of C++ (or another OO language) before seriously studying Design Patterns.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Jul 6, 2017 - 06:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I was using some of those design patterns even before they were given a name!

Yes. As Rohalamin will discover when he starts reading, those patterns were not invented by GoF but rather "described and systemised" by them after the GoF studied a lot of recurring coding "memes" of a lot of experienced programmers in a lot of different projects.

 

So, while patterns can be a collection of actual concrete techniques applicable in certain relatively specific situations they are also (as a whole) an example of "how to think code" or "meta rules". IIRC there is, in the beginning of the GoF book, before they actually get into the catalog, text on general good principles. When patterns are used/studied in this perspective the risk of "have hammer, only see nails" is reduced and instead replaced with "understand contents of my toolbox, can apply tools to fitting problems - sometimes eve a bit exotic/inventive".

 

Oldies might recall the forerunner to GoFs - I think specifically of the 1980s and 1990s Software Engineering movement. Some principles established there (High Cohesion, Low Coupling, Encapsulation etc) are the foundation of (semi-)modern OO programming and Design Patterns. Sadly, this legacy is seldom credited..

 

Yes, good programmers used patterns before GoF coined the term.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Jul 6, 2017 - 06:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just now realized that I haven't given straight answers to the questions in the topic/heading. Well..

Do you suggest a beginner to use GoF patterns?

No. Period.

Do we really need to GoF in embedded world? 

"Need" as in "must": No. Period.

 

"Need" as in "can help solve some problems in a good way!: Yes.

 


 

Re the figure in the OP: Why is it organized to look like the periodic table of elements? What is the organization in rows and columns illustrating. My answers are "for no good reason" and "organization illustrates nothing".

 

The only thing I can see coming from that figure is possibly giving the illusion that if one learns that table one understands more about patterns. Nothing could be further from the thruth.

 

As I  said - that's just a plain stupid picture. For many reasons.

 


 

EDIT: Apart from having a good foundation in an OO programming language, it will also be very handy to have some knowledge about UML Class Diagrams, since patterns are often described/illustrated by using such diagrams. If you cant read UML Class Diagrams you will have a hard time understanding a lot of what is written re Design Patterns. Here's and example (actually the Observer pattern that I recommend as one of the first patterns to study):

 

 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Jul 6, 2017 - 06:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you Johan

I am much obliged to you for your helpful posts during the whole time I've been here. you always help me and show me the right way.

 

Johan

If I'm talking about "Design Patterns" that's just because I thought I must get familiar with them and the way I must use them to write code using OO languages. So far I've realized that it doesn't matter to know them but getting familiar with them is helpful. right?

Then I'm going to review my C++ book and do its exercises and problems and finding some C++ codes (on the net and other materials) and try myself to write 'em.

 

What's your opinion?

 

Any suggestion from other guys would be appreciated

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One more time then, since I obviously have not been clear:

No there is no "must use Pattern to write code using OO languages". It is my opinion that Patterns can not, and should not, be studied until you have a solid knowledge in the OO language of choice.

Learn C++ foundations first.

Anything else will most likely be counter-productive.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan, are you concerned that having the OP learn GoF design patterns so soon may turn him into a handbook engineer or, worse, a "cargo cult" programmer?

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jfiresto wrote:
GoF design patterns

Is there any distinctions between "GoF" Design Patterns and "non-GoF" Design Patterns?

 

Is there, necessarily, any requirement for Design Patterns to be Object-Oriented?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Those are good questions, tending toward the heart of my question.

 

Let us suppose a design pattern is a design pattern, with a GoF pattern being just as useful to know for your work as any other. What harm can come from learning those patterns first – don't they just codify common practice? – then learning the computer language in which you will use them?

 

 

 

 

 

 

 

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure about the meaning of "handbook engineer".

I fear "Have hammer, world is nails" syndrome.

I fear for missing the point because not enough real-world problems been seen.

 

No, Design Patterns does not crave an OO language, but it will make implementing them A LOT easier.

 

After all you can implement using OO  techniques using plain C. (And way back in the Uni days I read an article about an OO approach programming in assembler..).

 

-----

 

Look, Design Patterns come in part from (building) architecture, so lets use a (made up) example from, there... Suppose someone comes to you and say "I want to learn Architectural Patters!"

 

You go "OK, here's one:

Door should open in the direction of evacuation. When facing the door in the direction of evacuation - place the hinges on the other side."

 

Your student goes "Whats a hinge?"

 

You gotta learn about the elements of building houses first.

 

-----

 

But again, if Rohalamin (or anyone else) would like to have a discussion on Design Patterns then a good preparation is to read the introductory article on the subject on Wikipedia and then have a look at e.g. the Observer pattern. It's simple and straight-forward. If yo have a look at it, some of you will be surprised by that and say "B-b-but I've done that for years!". Yes, and that is why I think it's a good first example.

 

 

-----

 

The only distinction between "GoF Design Patterns" and just Design Patterns" that I can think of is that the former might refer explicitly and exactly to the patterns described in the Seminal GoF book (for anyone actually studying Patterns that book is a must, IMO.)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm with Johan...

 

You always need to learn nuts and bolts first, then how to apply them.
 

Bob.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did the beginning posts in this thread just get edited?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You mean the removal of the "stupid" figure?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure how much have been edited, but yes that is the obvious thing.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

Not sure how much have been edited, but yes that is the obvious thing.

Pardon me. Forgot to say.

Yes. I edited it when I was writing post #13. you said it's stupid then I edited it. 

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rohalamin wrote:
Yes. I edited it

That's really unhelpful when there are replies specifically referring to it!

 

For reference, I think this was the graphic:

 

Image result for GoF design pattern

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the user of a GoF chart a gofer?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

That's really unhelpful when there are replies specifically referring to it!

...

As I said:

Rohalamin wrote:

Found it on the net and put it on the first post to tell you what I'm talking about.

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are GoF patterns any more than formalized "best practices"?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Are GoF patterns any more than formalized "best practices"?

Depends on what you mean by that. And "any more than" sort of implies trivial, or not of much value.

 

Why not find out from real authorities on the subject. I'd recommend the Wikipedia articles as a start: https://en.wikipedia.org/wiki/De...https://en.wikipedia.org/wiki/So... , https://en.wikipedia.org/wiki/De... ...

 

Yes, the second one of those says

Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

 The "any more than" is in the details, IMO.  Note: "details" != ("trivial" | "minute")

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fully aware that "details" are not something trivial. The best system design can fail on inadequate implementation of the details. Software AND hardware!

 

While the original subject line did ask about whether or not GoF was "needed" in the embedded world, I noticed that at least some of the patterns have to do with interactions with the operating system and with graphical user interfaces. My personal experience is that these two things are often not part of an embedded system (and certainly not with anything I have worked on).

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I noticed that at least some of the patterns have to do with interactions with the operating system and with graphical user interfaces

I believe that you are misreading something there. Can you point/refer to some specific text?  

 

Some patterns are often occurring or are applicable in those areas but I know of no pattern, apart from MVC (Model-View-Controller) ant some variations thereof, that only occur in context of user interfaces - and none that occur only in context of OS interaction. 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm - I was reading here:  https://en.wikipedia.org/wiki/De...

 

And I think that I misinterpreted some of the use categories as being design patterns. Sorry for that.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim is it my impression or is your hairline receding since you started with C++? cheeky

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Probably  is receding, though the pic is 10 years old! Other things are going also, including the sanity that kept me from such hair-brained projects in the past!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the sanity

Groucho: Thats all right - that's in every contract. That's the sanity clause.

Chico: you can't fool me.  [etc... ]  

 

 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would think that embedded projects are too small to warrant the use of design patterns or even object oriented languages. I would have guessed C with some embedded assembler would be the norm. Am I mistaken?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Darrough: Have a look around here at AVRfreaks. Do some searches. (recommended search strategy here is to use Google with the addition " site:www.avrfreaks.net" at the end of your search term.

 

We've been through this for more times than we can count.

 

But if you insist, I'm your Huckleberry. In short:

 

Opinions vary.

 

Re OO languages it is my opinion that an efficient OO language can be contribute in positive ways to embedded programming. The "efficient OO language"  is named C++.

 

Re design patterns, how about reading (or re-reading) this whole thread - your question seems to suggest you haven't..

 

And could you please define "embedded projects"?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Opinions vary.
Johan could have said "Opinions vary greatly and cause innumerable vigorous argumen er... discussions."

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darrough wrote:

I would think that embedded projects are too small to warrant the use of design patterns or even object oriented languages. I would have guessed C with some embedded assembler would be the norm. Am I mistaken?

 

Only in the sense your question is too widely scoped. "Embedded" covers everything from a 512 byte 8 bitter that might be in a washing machine or shaver, all the way to 3GHz rack mount PCs, used in ATMs, car park ticket machines, motorway gantry signage, telephone exchangesm military radars etc etc.

 

Given that caveat, the use of C++ is quite significant among embedded projects. If OOP is designed to prevent spaghetti C, then I guess design patterns are an attempt to prevent "spaghetti classes". I think that careful use of OOP is highly appropriate even for "small" embedded projects, I've spent many an hour rewriting C code to handle multiple instances of objects, e.g. serial ports etc.

Bob.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

donotdespisethesnake wrote:
If OOP is designed to prevent spaghetti C, then I guess design patterns are an attempt to prevent "spaghetti classes".

LOL! We could argue about discuss the finer points in there, but I'll digress and just say that I loved that illustration! (-:

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was assuming embedded AVR microcontrollers. I can see how a 3GHz rack mounted PC would benefit. Anyway, I guess I was indeed mistaken on this point.

 

donotdespisethesnake wrote:
If OOP is designed to prevent spaghetti C, then I guess design patterns are an attempt to prevent "spaghetti classes".

 

I would not say OOP is designed to prevent spaghetti code. OOP is designed to allow the developer to think in terms of the entities of the problem domain and is separate from modular and structured coding. 

 

I would go along with patterns being an attempt to prevent spaghetti classes, but I would say that is the very issue with patterns. The relationship between objects should match the relationship between real world entities, however messy that is. Making the object model fit a pattern causes differences between it and the problem domain and that's generally a bad thing.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Darrough wrote:
I was assuming embedded AVR microcontrollers.

Amd the largest of them has how much flash and how much RAM?

 

ATmega1284: 128K flash, 16K RAM

 

Wait, there's the XMegas

 

ATXmega384C3: 384K flash, 32K RAM

 

Since we're in the AVRFreaks group of subforums I suppose we should include the 32.bit AVRs as long as they're alive? ;-)

 

AT32UC3A3128: 128K flash, 128K RAM

 

Now, let's play.. How big an application (in "lines of code" can we get into, say, 128K flash?

- Well, that is 128K bytes and an AVR instruction is 2 bytes, so that's 64 K instructions.

Very rough ballpark guess: One C/C++ source line generates 10 instructions on average.

That gives 6400 lines of code (6.4 KLOCs). How much is that? Well, if printed at 64 LPP it would of-course be 100 pages of code. 

 

And we're talking KLOCs of "real" code here. No comment lines. No blank lines.

 

So, is that big enough to warrant something more than "plain old C and some inline assembler"?

 

How small can a project be and still benefit from an OO language? IMO, the smallest possible. Just the better source format - thing.do() rather than doToThing(thing) - justifies it. You get that with no extra run-time cost at all.

 

A specific C++ feature we've been discussing lately is templates, and the example of a circular/ring buffer shows how to benefit from C++ templates. A ring buffer in C either needs to be type-specific, or macro-based. The former might be a disadvantage. The latter sucks, IMO. With a C++ template class you get something that can be neatly coded, and actually can be debugged in a reasonable manner. There will be no extra cost as compared to doing it in C.

 

So, a simple "Simon says" application using e.g. the UART and needing ring buffers will benefit. IMO.

 

I am now awaiting your "Oh, I meant only small AVRs!" ;-)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darrough wrote:
I would go along with patterns being an attempt to prevent spaghetti classes, but I would say that is the very issue with patterns. The relationship between objects should match the relationship between real world entities, however messy that is. Making the object model fit a pattern causes differences between it and the problem domain and that's generally a bad thing.

That is patterns applied wrong/badly. The whole (or half, see below) idea is to apply a pattern when it can fit the "real world". You're describing something akin to "Have hammer, searching for nail" or even "Have screwdriver, will try to drive nail". Of'course that's bad.

 

2nd, there is seldom one way to model the real world, so there is not "one fitting object model only and all others wrong/bad". Most everything fits an object model more or less good. And the real world here can very much be other things than vehicles, customers or some such, but rather something more technical.  Again, the observer pattern serves as an example. I've never seen it used as "a number of Persons needs to listen to and react to changes to a Phone". I've seen it used many times where a C program would have something akin to a callback function.

 

Re "half the idea": The other use for patterns is to look at it as an way of thinking and as examples of good design to learn from, rather than a collection of fixed recipes to apply. E.g. there are the principles/idioms/whatever that GoF established as being present in many of the patterns they found. One example here is their "Favor object composition over class inheritance".

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
I am now awaiting your "Oh, I meant only small AVRs!" ;-)

 

You have made your point. I am convinced.

 

JohanEkdahl wrote:
I've never seen it used as "a number of Persons needs to listen to and react to changes to a Phone".

 

I believe that is what GoF was recommending. That domain objects, like vehicles and customers, can be observers of each other. I have seen it many times. Visual programming comes to mind. (When you draw a connection from one object to another it becomes an observer of the other object). Note that I am not saying that this is a bad thing, just that I have seen it.

 

JohanEkdahl wrote:
The other use for patterns is to look at it as a way of thinking and as examples of good design to learn from

 

A good point.