What are the most important structured software design principles? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

Today I saw a job description that requires "significant experience coding in C++ and a thorough grounding in structured design principles", so I thought about what these principles are. First I felt it was a little odd to see C++ and "structured design" in one sentence, then I thought, OK C++ is a multi-paradigm programming language, so perhaps it's used like C. I also looked up the Wikipedia page and read about exception handling and state machines are anti structured design (no surprise), but I still feel like many things are missing. So I'm asking you, what开发者_JAVA百科 are the most important structured software design principles?

---

Structured programming and structured design wouldn't necessarily be the same thing. Structured design in general is going to focus on breaking things down into structured elements. There are a bunch of approaches that are equally valid here, but I would say that most of them focus on information hiding.

• Object Oriented Design obviously breaks things down into objects with operations and data held together in tightly bound classes related in hierarchies
• Abstract Data Types are essentially non-OO equivalents where the data and operations are held together but are not bound in quite the same sense as in object oriented design. Hierarchy and inheritance don't play a role with ADTs, at least not in those that I've seen.
• Metaprogramming focuses on building generic types and then specializing them appropriately for specific data types
• Programming to a contract focuses on avoiding direct inheritance. Typically it combines Contract Interfaces with implementation by composition of multiple classes.
• Design Patterns focus on high-level meta-designs (patterns) that can be implemented in almost any context, although they are most commonly seen in discussions of OO design.

Knowing how to structure programs in multiple paradigms is always going to be valuable knowledge. Knowing how to talk about the structure of a design is more finicky but ultimately even more valuable.

---

In the classic works on composite/structured design by Myers and by Yourdon and Constantine, the two most important principles are

• Coupling (how different modules relate to one another)

• Cohesion (how a module is structured internally)

I agree with Mike Burton that the author of the ad probably lacks a clue, but you can brush up on "module coupling" and "module cohesion" easily enough, and if you can get them at a library, the books are worth reading. I can find the original paper only at an IBM pay site.

---

What I always refer to is a ancient article in IEEE Micro Magazine October 1981 by G. D. Bergland of Bell Telephone Laboritories - belive it or not. It's about thirteen pages long and gives you most everything you need to know. Trouble is you may not be able to find it - even at IEEE & even if your a member.

You can find another very good (though old) book "Tutorial on Software Design Techniques" by Peter Freeman (Editor) at Amazon.

http://www.amazon.com/gp/offer-listing/0818605146/ref=dp_olp_0?ie=UTF8&redirect=true&condition=all