Explanations should take around 50 words. Some slack will be given to explanations with more words (however, don't press your luck too many times on this); explanations a page or more long will lose five points.
i to indicate
an integer, a p to indicate a pointer, and an a to indicate an array
(so a pointer to an array of integers holding grades might be named
grades_iap under Hungarian Notation.
What your colleague doesn't understand is how Hungarian Notation can be considered good programming style with respect to information hiding, because it seems that Hungarian Notation reveals information - implementation details - that should be hidden. What explanation do you give your colleague?
To a large extent, you colleague is right; this is one of the arguments against Hungarian Notation. However, putting that contentious issue aside, what your colleague is forgetting is information hiding not only applies to the names of variables, but to the variables themselves. In the larger scheme of things, it doesn't make much difference what the variables are called because the variables are hidden away in whatever module encapsulates them.
While it is possible to conceive of an object-oriented design being implemented using either a top-down or a bottom-up approach, it is difficult to conceive of an argument that the two implementation approaches require an equivalent amount of effort (or, alternatively, it is difficult to conceive of a bottom-up implementation that is essentially different from a top-down implementation).
The culprit is inheritance and the usually high degree of coupling it induces among classes. Given a non-trivial, general object-oriented design, a bottom-up implementation starts at the leaf classes. But the leaf class implementations depend on their parent classes, the implementation of which depends on their parent classes and so on. Because of coupling, a bottom-up implementation either requires a test harness that essentially implements the rest of the object-oriented design, which requires more effort, or it is a top-down implementation in disguise.
A number of people answered this using the good-design bad-design approach, which isn't a bad answer, but leaves open the question of whether bottom-up implementation form an object-oriented design is appropriate.
Logical design specifies the behavior of individual modules. Pre- and post-conditions can be used to specify module behavior by describing the characteristics of the inputs to the module, which is the purpose of the pre-conditions, and the characteristics of the module output given the input, which is the purpose of the post-conditions. The value of pre- and post-conditions is that they're based on mathematical logic, which makes them concise, unambiguous, and independent of any particular implementation.
Most people answered this by indicating why logical design is important and then not indicating how pre- and post-conditions are different from, for example, a PDL.
Module cohesion is a measure of the interrelatedness of the module's functions; the more cohesive a module, the more interrelated are the functions performed by the module.
Because there are different types of cohesion, and because some types of cohesion are more desirable than other types of cohesion, it is important to know what type of cohesion applies to a module before making estimates. For example, a moderate degree of functional cohesion will almost always have greater influence than a high degree of random cohesion.
In the absence of any particular type of cohesion, the general rule of thumb is that a module with low cohesion will have more code than a module with high cohesion. A module with low cohesion contains code associated with a set of unrelated functions; any such module would be larger, by almost any size measure, than any module implementing the functions individually.
This page last modified on 23 March 2001.