Programming With Structures

Programming with structures

Treats DataStructures as OpenEntities?. The result is that you accumulate functions that depend on a particular representation of a data object. If you decide to change the representation of a data structure that change propagates through all functions that use the DataStructure.

OO provides abstraction where functions get an interface that is guaranteed not to change.

Ron's comments, from when this was called StructuredProgramming:

I don't understand this assertion. If we define our data structure with, say, a C struct statement, changes to the struct require a recompile but no code changes that wouldn't change in a corresponding object implementation. Please give an example showing a structured implementation and an object implementation that necessarily differ by propagating more change in the structured version. Thanks. --RonJeffries

Or, on n-th thought, are you suggesting that the openness of the structure entices people to access it directly rather than through functions custom-made to hide the details? I could believe that ... but don't see why it's a necessary characteristic of StructuredProgramming. --rj

Yes. Exactly. This is a weakness of StructuredProgramming and ModularProgramming: With them, one does not associate code with structures; any code anywhere can access member variables any time they want. And they do. And there are no rules in StructuredProgramming or ModularProgramming to discourage people from doing this. -- JeffGrigg

But many dynamic or "scriptish" OO languages such as SmallTalk and Python don't have forced guarentees either. It is merely convention that permits "proper" accessors to be used under such language. Besides, I think structured programming techniques have grown "beyond" dedicated data structures, which some of us consider mostly archaic technology. The database is the better pairing under this viewpoint except maybe in embedded systems. Dedicated data structures are for smaller and smaller niches as the hardware better can handle RDBMS of some kind over time. RDBMS will replace dedicated structures the way that automatic garbage collection has superseeded manual pointer handling except in the embedded nich. Higher abstractions tend to penatrate the enbedded world last because higher abstraction requires more hardware. If you disagree, I shall respect that. But lets not reinvent those debates here. They already exist in topics such as: DedicatedStructuresVersusRdbms, AreTablesGeneralPurposeStructures, GateKeeper, IsEmbeddedBehind. Whether structured programming can be forced to respect ADT-like accessors such that the internals are not directly accessed, I don't know. I have not seen a lot of research on that. But I suspect such a result would resemble a database so much so that it would be silly not to just use a database. -- top

With sufficient discipline, you can write ObjectOrientedPrograms? using structures/records, even if the language is not OO. If the language supports FunctionPointers?, you can even have PolymorphicBehavior?.

However, neither StructuredProgramming nor ModularProgramming advocates associating code (methods) with the DataStructures (objects) that they modify. So, programs that use those methods (and not OO methods) will tend to access and modify structure member variables "all over the place" and "intermingled with other code." Thus a change to the data representation in a structure can have a direct impact on code in nearly any part of the system, even code that is primarily working with other data types / objects. There is no concept of "encapsulation" in such a system.

In theory, such willy-nilly access to other object's member variables could be done in the SmalltalkLanguage, as the language does not enforce PublicProtectedPrivateConventions?. But in practice this is not an issue, because commonly accepted Smalltalk programming conventions forbid it. -- JeffGrigg

Actually, the rules of StructuredProgramming And ModularProgramming dictate that the system be designed to maximize CohesionWithinModules? and and minimize CouplingBetweenModules?. Proper concern for coupling will cause one not to access random structures from everywhere in the system. [I make no claim that everyone actually does this.] If one actually applied these rules religiously, one would wind up with a small system of supporting functions "surrounding" each structure. In essence, one would have invented ObjectOrientedProgramming. -- RonJeffries

Oddly enough, WayneStevens?, one of the inventors and popularizers of StructuredAnalysis?, actually did this, exactly as Ron described, with one difference at the end. He recommended that every data element have an accessor function, so that you could trace the caller for any modification of the data element. And that you build the service (function call) graph outwards from there. But he vehemently detested OO, because it clustered together piles of functions that one would frequently not use together, hence yielding bloated software full of unused functions that would have to be maintained and tested. It was always interesting arguing with Wayne (he was extremely insightful, and would never admit he was wrong - the best I could hope for was to box in his area of legitimacy to a postage stamp). -- AlistairCockburn

Remind you of anyone here? -- RonJeffries