1

There is plenty of material about designing software for object oriented programming. Do you know of any good materials for pure structural programming? I am working purely in C and while I can use some experiences from object oriented programming I found out, that I know few tricks about good structural design.

gruszczy
  • 612
  • 3
  • 13
  • You could do, as an programming excercise, to take common classes from Java or C# that have static methods into modules with global functions. The String class is a good example. "O.O. String Class static methods" => "Structured Strings Library" – umlcat Mar 19 '11 at 19:18

3 Answers3

1

Hard to say. Back when I was learning, the main structured programming advice was basically "use block structures" and "don't use goto", which only takes you so far.

There was a technique called "Jackson Structured Programming" in which you would describe the structure of your input and output data, and the structure of your program was derived as the in-between thing. The diagrams weren't so terribly aweful as the overall method, which was AFAIK primarily targeted at COBOL and at fairly simple data processing tasks.

In other words, the specific advice that you can find for structured programming is often advice that you shouldn't follow in the real world - overly simplistic and pedantic, based on the assumption that programmers are incapable of thinking about such "complex" ideas as repetition without a pretty picture and a heavyweight methodology to help them.

What is perhaps useful is to point out that on the whole, the "design patterns" for structured programming were algorithms and data structures, or at least that's how things seemed in the 80s and 90s before the term "design pattern" had been popularised. Current non-OO developers will have larger-scale design patterns now, of course, but as a C++ programmer myself who hasn't used much C, Pascal or whatever for over a decade, I can't comment much on that.

A few idioms are also relevant, but let's just say that your object oriented programming experience will have already given you some idea of when and how to use a "parameter block" for instance - a class is in many ways the evolution of a parameter block, and I suspect (but don't know for sure) that many C++ object-oriented patterns have near-equivalent C parameter-block patterns.

Also, some object oriented design patterns are needed to some extent to work around data hiding issues. Abstraction is good design, but sometimes having a good abstraction is hard work where having a leaky abstraction permits much simpler solutions, at least in the short term.

  • I add modules / namespaces or "Modular programming", sometimes is consider the same as "Structured Programming" or teached with "Structured Programming", but sometimes is not. – umlcat Mar 19 '11 at 19:05
1

good design in C:

  • use typedefs for data structures
  • write functions to operate on data structures
  • group functions that operate on the same data structure into modules

oops!

Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
  • Downvoted: typedefs in C make the program more opaque. One never knows what the typedefed thing is -- struct, union, pointer, multiple pointer, primitive type.. – zvrba Dec 31 '10 at 16:10
  • Or: I consider that the only legitimate use of typedefs is defining portable primitive types, as C99 does with e.g. int16_t and others. – zvrba Dec 31 '10 at 16:12
  • @zvrba: ya gotta be kidding. you don't use typedefs for data structures? it's not being "opaque", it's encapsulation. – Steven A. Lowe Dec 31 '10 at 16:41
  • 1
    Encapsulation == Opaque. – compman Dec 31 '10 at 18:56
  • @user9521: hardly. see definition #4 http://dictionary.reference.com/browse/opaque "opaque" implies it's a bad thing; encapsulation is a good thing. I shudder to think about C programs of significant size/complexity that have no data structures. – Steven A. Lowe Dec 31 '10 at 19:21
  • No, I'm not kidding. In plain C, I always write out the struct/union keywords. Another thing I use typedefs is to simplify complex declarations, e.g., to define pointers to functions, and even then only if they're going to be used as arguments to other functions or if I'm going to make an array of pointers to functions. – zvrba Jan 01 '11 at 07:15
  • Example of opaqueness: `LARGE_INTEGER add64(LARGE_INTEGER x1, LARGE_INTEGER x2)`. What is `LARGE_INTEGER`? A struct, a pointer (and to *what*), a primitive type, a union? Without typedefs, you simply do not run into such doubts: `struct li add64(struct li li1, struct li li2)`. Yes, it is slightly more typing, but the program meaning is *vastly* clearer. Another advantage is that struct and union tags and variables are in different namespaces, so `struct li li` is a perfectly valid variable definition. Immensely useful, so you don't have to make up new names. – zvrba Jan 01 '11 at 07:22
  • 1
    @zvrba - seems to me that to compensate for the "struct" prefix, you've abbreviated "LARGE_INTEGER" to "li". Last time I used two-letter identifiers for something with a scope greater than a few lines, I think I was "working" in Commodore 64 Basic. "li" could mean pretty much anything. The "struct" prefix won't bother me, but I'd still want an identifier that tells me what it means. –  Jan 03 '11 at 00:24
  • 1
    @zvbra - OTOH, you're concern about opaqueness bothers me. Push it too far and writing functions is evil, because writing the code directly where needed instead of a call is more "transparent". I use the "moving the complexity to the call graph doesn't eliminate complexity" argument myself, but there's a balance. The typedef is more of the same - how much genuine need is there to emphasize that a particular type happens to be a struct in every reference to it? –  Jan 03 '11 at 00:30
  • @Steve: abbreviation is only due to character count limit in comments. The problem with typedef is that it can be misused to hide MUCH MORE (pointer, constness, signedness) than just "struct". – zvrba Jan 03 '11 at 14:35
  • 1
    @zvrba: at least you are actually using structs, despite the risk that a struct member could be hiding ANYTHING (pointer, integer, function pointer). ;-) – Steven A. Lowe Jan 03 '11 at 17:07
  • @zvrba: A random comment reminded me of your typedef phobia today, and I thought, 'why would you use a typedef'd type in your code whose definition you hadn't read?' - and I started laughing, realizing that the only way that a typedef'd type can truly be "opaque" is if you never read the typedef declaration! ;-) – Steven A. Lowe Jan 16 '11 at 04:38
  • @zvrba - What you call opaqueness is sometimes called abstraction. If I am a user of a library providing an `add64()` function on `LARGE_INTEGER` values, I don't want implementation details go in my way. What if the library is provided on 64-bit CPUs? Would it still use a `struct`? – mouviciel Jul 18 '12 at 12:34
  • @mouviciel Yes, it would most probably still use a struct in order to preserve source-compatibility. – zvrba Jul 19 '12 at 13:13
1

One of the best books on this is out of print, but still easy to find used (and rather cheaply): Reliable Software through Composite Design, by Glenford J Myers.

A much more expensive resource (but in print) is Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design.

Of course, the book on the C language itself is an excellent guide to programming. It doesn't talk about coupling the way Myers does, but you should definitely have K&R on your shelf. Note that many large C systems do use OO concepts, including dispatch tables to get many of the same features of polymorphism (such as extensibility).

Macneil
  • 8,223
  • 4
  • 34
  • 68