QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnAnother issue IMO is much programming work is programming in the smallWe miss the forest for the trees?The classic problem is 'inheriting' an undocumented C++ class library, 6 deep with multiple inheritance.Indeed! Over-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior. The challenge is in balancing the KISS principle at the level of lines of code per module versus numbers of modules in the total system. Sometimes the solution really does require some complexity -- the devil in the details may require some fiendish code.But how to KISS? Really, really, really?Really.It's KISS in the sense of: does one minimize the number of lines of code per module (the "simple modules" strategy) or does one minimize the total number of modules (the "simple architecture" strategy).How? I mean the criteria.Are you asking about the criteria for simplicity?If so, there's always the old favorites of lines of code (which has many flaws) or function points. Of course, the algies and the loopers disagree on what is simple.KISS may be like beauty, art, or porn - you know it when you see it.No, I mean criteria for decomposing a system into subsystems. Simplicity is a by-product, nice to have of course.Tricky!It depends on:1. Language: decomposition is different for OOP vs. non-OOP languages (or functional vs. procedural ones).2. The OS and off-the-shelf libraries: Mandatory or convenient voluntary APIs will surely affect the atoms of the system.3. Programmer (or team) experience: As with item #2, certain structures might be easier to adopt because they already exist and are well understood.4. System covariations: One could imagine doing some kind of notional PCA on the cross-correlation matrix between all possible inputs and the set of corresponding required outputs. Highly covariant things belong together and non-covariant things may be separated.David Parnas ..QuoteWe have tried to demonstrate by these examples thatit is almost always incorrect to begin the decompositionof a system into modules on the basis of a flowchart.We propose instead that one begins with a list ofdifficult design decisions or design decisions which arelikely to change. Each module is then designed to hidesuch a decision from the others. Since, in most cases,design decisions transcend time of execution, moduleswill not correspond to steps in the processing. Toachieve an efficient implementation we must abandonthe assumption that a module is one or more subroutines,and instead allow subroutines and programsto be assembled collections of code from variousmodules.Received August 1971; revisedInformation Hiding, really.Another criterion is potential concurrency (just think of a graphics hidden surface removal/renderer pipeline).
Last edited by Cuchulainn
on April 10th, 2016, 10:00 pm, edited 1 time in total.