What Is Modularity

Candidate definitions or features of "modularity"...

A system demonstrates modularity if it contains one or more identifiable units of code or data that are:

Some traits commonly associated with modules (but that do not define modules) include:

These are not necessarily full requirements nor mutually exclusive.

Modularity is the ability to take a banana (or other low hanging fruit) without dragging along the whole dependency-forest.

Disputed:

[Disputed by who? Cite an authority or put it back together, please]

Disputed by the contributors to this page, obviously.

[Well, I'm a contributor, and I'm going to put it back to normal]

These got moved down here because you put them above with nothing but your own authority. Unless you're aiming to have an EditWar, I suggest you don't move them back above until the dispute has been resolved.

[Then EditWar it is, bucko! How arrogant and hypocritical to believe that your "authority" is automatically better than others. This is obviously unfair.]

EditWar is unnecessary, especially as the entirety of this page is viewable at the twitch of a scrollbar. There used to be a tradition here of keeping disputed (the ThreadMess below is obvious evidence of a dispute) material distinct from the resolved bits, and it's standard operating procedure on WikiPedia and elsewhere. It isn't really a matter of authority or lack thereof, but the simple fact that there is a dispute, regardless of reason...

[But which dispute viewpoint decides what is up and what is down?]

Neither of them. Leave it for someone else to refactor, or wait until one of you agrees with the other.

[How about this compromise: we put a summary list at the top with no "hard" dividers, and the phrase "(disputed by some)" after those items. Then the discussion section is placed below that.]

I think keeping the disputed material here instead of moving it to WhatIsModularityDiscussion is already a fair compromise.

[Bullshit! You are just trying to elevate your opinions above mine. I'm not caving this time because it would encourage such later again. No deal!]

I have expressed no opinions on this page other than that regarding the dispute itself. (Please take note of the IP addresses involved. By now, they should be more familiar than human names. They certainly are to me.)

[It is relatively easy to have/use multiple IP addresses. Anyhow, I'm willing to leave this the way it is for about a month to see if we can think of a better approach by then.]

That sounds eminently reasonable. (Sadly, I recognise the multiple IP addresses involved too, but numbers have a meaning to me that names do not. I sometimes assign interesting numbers to my students when I can't remember their names.)

It is my observation after 20+ years of experience that any grouping of code larger than a single function or routine is called a "module" simply because there is no other common alternative (outside of "class"). There are sometimes language-specific terms, but switching these with "module" usually works.

How about we look at it from the back side to try to resolve the disputes: what grouping of functions/routines that actually occur in practice are NOT "modules"? Objective forms of grouping include file grouping (sometimes called "include files"), and formal groupings as found in a given programming language: 

 grouping_thing {
   function foo(...) {...}
   function bar(...) {...}
   subroutine blah(...) {...}
 }
-- top

I could name quite a few arbitrary groupings that aren't modules. Two static functions that just happen to be next to one another in a C file wouldn't qualify as module in any sense of the word. These 'occur in practice' all the time.

I thought I made it clear that there had to be some explicit grouping mechanism within the language or filing system, not just arbitrary groupings picked out by the observer. But perhaps it wasn't so clear after-all.

How about you look at your implicit assumptions: that there is a clear "grouping_thing" with definite insides and outsides, and a set of interface declarations that indicate how to tie relevant bits of the 'module' (and its implementation) into the larger project without re-implementing the content by hand.

Like I mentioned above, a file full of functions/routines is often called a "module" in practice. The "interface" was not an overriding factor, and mostly only existed at the function-to-function level. You are over-emphasizing the role of "interface" in my opinion.

You seem to believe that emphasizing interface means I think the interface needs to be 'special', whereas when I emphasize interface I only mean to emphasize that there needs to be one - there is no such thing as a module without an interface. Shared names in a shared namespace for functions/routines makes for a reasonable interface (and, even better, match almost all historical interfaces for modules).

That's a rather loose usage of "interface", and more along the lines of mere "access to".

No, "access to" is not the same. I could have "access to" a module in a manner that required me to hand-copy stuff out of the module and into my document, or that I include a great deal of specialized runtime metaprogramming in order to access it. The use of shared name based access is very much an "interface" - a declared and statically accessible way of accessing certain features of a module.

This is an awesome page -- thank you, whoever posted it. It describes in very few words that which I've been unable to address succinctly in past discussions.

I started it and I'll happily take the kudos because I've had a bad week and need kudos. -- top

{It's not awesome anymore, we turned it into a ThreadMess}

Yeah, it was truly awesome when it was just a bunch of statements from "the book" of almighty TopMind.

See, there's yet another insult from you. You have InsultTurrets?.

[Do you mean InsultTurrets?, InsultTourettes?, or both?]

InsultTourettes? aided by InsultTurrets?, a dangerous combo.

Perhaps a module can be defined in terms of GraphTheory whereby modules are groups of nodes which separate tightly-related nodes from loosely related nodes. In other words, module boundaries are where you snip such that the link cuts (which become interfaces) are as few as possible, yet produce a reasonable number size of resulting groups. For example, in the human brain, the parts of the brain related to vision probably have far more connections between them than do parts related to vision and parts related to sound do between each other. Finding the ideal cuts in an automated way probably is a form of the "traveling salesmen" class of problems such that in practice we rely on "domain instinct". Further, no cut is perfect, just a best compromise. "Cat" in the brain is probably stored under both vision areas and sound areas. Thus, modularizing by senses (sight and sound) splits cat-related info. Thus, modularizing by senses de-modularizes by the "cat" domain noun. --top

One could..., but why?

Actually, I take that back. With 3D structures you have more options than with typical linear source code. In the brain, you could have a "ladder" pattern: 

  V     S
  V     S
  *-Cat-*
  V     S
  V     S
  *-Dog-*
  V     S
  V     S
The "cat" grouping can closely integrate with both the vision module (V) and the sound module (S).

Huh? I'm curious what perceived problem you're trying to fix here.

One can modularize by visual issues, sonic issues (sound), and/or domain noun (cat). In source code often we have to sacrifice modularizing by one dimension in order to modularize by another because code is generally linear. A 3D structure like the brain is a bit more flexible. Somewhat related: SeparationAndGroupingAreArchaicConcepts.

Take an OOP model of mammals: 

  class cat inherits mammal
     method speak()
       playSound("meow.wav")
     end method
     ...
  end class
  class dog inherits mammal
     method speak()
       playSound("bark.wav", repeat:=3)
     end method
     ...
  end class
Here we are modularizing by animals. Their sounds are controlled by the method "speak". We are de-modularizing by sound in order to modularize by animal "type". If we modularized by sound, then perhaps we'd have a switch/case statement with a line for each animal "type". But this would de-modularize by animal type. We are making a modularization trade-off in the above design. - t

Are you saying you'd like to be able to (say) click a button to get a view of the source code that groups all the speak() method implementations together -- by 'mammal' or 'playSound', perhaps -- that displays the defining class name rather than being grouped by the defining class? If so, it sounds cute -- might even make an interesting PlugIn? for (say) EclipseIde -- but I still don't see what problem you're trying to solve. I've maintained applications in the several hundred thousand LOC range and a need for this never came up. At least, not that couldn't be solved with conventional "search" facilities...

Text searching may be "good enough" for most cases, but that's like arguing not to switch from COBOL because it's "good enough". And it's not just by classes or OO artifacts, but by aspects in general. See SeparationAndGroupingAreArchaicConcepts for examples. - t

Text searching is superior to what I understand of your idea.

Hang on -- are we talking at cross purposes here, folk? It seems to me that this discussion has mutated away from objects and towards characteristics. Organization along these lines of "animal" or "sound" looks more like relational database patterns rather than methods or object attributes. What is the actual base we are trying to define? --AnonymousDonor

I'm not sure I understand the question. Note that the topic is about modules, not necessarily OOP. I consider any chunking or grouping category to be at least a candidate for modularization. An OOP example was selected above mainly because it's a common training-book pattern that readers would more likely recognize. -t

[This topic is about modularity, not modules. 'Module' has operational definitions in various languages, similar to 'object'. One might reasonably question whether a particular decomposition into modules is actually modular.]

If the definition is defined by or depends on a particular programming language/tool, then there is no "universal" definition. It's just a fuzzy kind of notion that is clarified on a local scope per locality (a "working definition" within the tool). -T

[Being 'contextual' (i.e. specific to environment or scope) is not the same as being 'fuzzy'. Therefore, regardless of whether your conclusion is correct, your reasoning is invalid.]

Agreed, but it kicks the idea of a generic definition right in the knickers. Some of the above authors seem insistent it's clear and definite in a general sense, which I disagreed with. This tends to reinforce my relativistic viewpoint. -t

[If you admit your reasoning is invalid, then why do you believe it 'kicks' anything? And why would it reinforce your viewpoint?]

[I'm okay with relativistic viewpoints (just don't conflate 'relative' with 'fuzzy' or 'subjective'). But it would be incorrect to argue that 'modularity' is relative on the basis that 'module' is contextual. Modularity and module are very different (but obviously related) concepts. Modularity is relative, of course (otherwise we couldn't argue 'X is more modular than Y'). And modularity is even contextual (otherwise we couldn't speak of 'modularity with respect to property/feature P'). But it isn't because 'module' is contextual.]

Perhaps what I should have said is that the above implies modularity is arbitrary, because each language/tool defines it how it wants to, and any commonality is at best just a nebulous notion.

[Uh, no. Languages define "module" how they want. They don't define "modularity" how they want. This entire argument about modules was off-topic from the start.]

On "Grouping of Related Code", and defining "Related"

Re: "But you need to use logic to make assertions or claims about the usage [modularity can mean MentalIndexability]"

Exactly how would one go about that? We are talking about the human mind, not necessarily "logic". People are not necessarily logical in their term usage/creation, and no agreed-upon rule says usage has to be logical to create language or terms. Perhaps it would be possible to show a statistical relationship between the usage of "module" and other words or phrases. Would that satisfy your request for "logic" if such was available? - t

Surveying the actual use would indeed qualify as evidence (for or against depending on results) of the use of modularity as meaning MentalIndexability. So would surveys of working definitions. In fact, those are the standard methods of supporting an argument that a word means something. Note that for non-technical natural language use, the results of such surveys are readily available (and the answer in this particular case is that it does not mean MentalIndexability). Technical use requires a bit more leg work, but I have never encountered it used in that manner.

If you have no cited surveys, then we only have experience versus experience, or anecdotes versus anecdotes. I've seen the term used in different ways and see no single strong contender, by the way. The only commonality I see is that the parts in a "module" are somehow related by at least one factor. That factor(s) may correspond to something in the real world (domain), or to somebody's mental model of the domain.

So provide an example of it being used to mean MentalIndexability. That will at least establish that someone (besides you) uses it that way.

Sorry, I don't currently have any written linkable examples. I would note almost none of the other claims are backed with citations or links either. Most formal def's include something along the line of "a grouping of related code". However, they usually don't define "related". That comes from the WetWare.

If you want to know what related means, look it up in a dictionary.

There appears to be a misunderstanding here.

You claim here that most of the definitions you've seen for modularity included something along the lines of "a grouping of related code". You then said, in a manner that indicates that you find it to be a problem, that "related" isn't defined with it. In this case, "related" is being used with its standard English usage, which you can find in a dictionary. That's why I told you to go look it up.

My point is that "related" is often in the eye of the beholder. Categories are an artifact of the human mind(s); they are a UsefulLie. The stated relationship may appear to be very weak or useless to the domain or likely work patterns. But the person making the connections will sometimes say, "Well, it works for my mind". I don't necessarily disagree that their stated relationships exist in some form; but rather they are round-about to the point of appearing contrived, or at least unimportant. But if it fits one's personal model of the domain, no matter how strange it may appear to me, perhaps I have little room to argue other than state it may make the project difficult to hand off to future staff. How do I know my personal mental model of the domain is "better" than another, other than guessing the most common psychology/WetWare patterns in the IT population? Most of us are not trained in IT psychology, and have to guess based on experience with IT staff in general or of a particular organization.

Let's play with an extreme example. Suppose Mike grouped subroutines/functions (subs) in alphabetical groups where all subs that start with "A" are in "module_A.code", all subs that start with "B" in "module_B.code", etc. Is this "modularity"? Most will agree it's "poor" modularity, but definitions generally cover the existence of a trait and not the quality of it. A rotten potato is still a potato[1]. Thus, are these true "modules"? -t

If "module" is defined as "a grouping of related code", then those are modules, by that definition. If, as I have usually found to be the case, the definition of "module" requires that the relationship be functional (I.e. it has to be what the functions in the modules do that is related), then those are not modules, by those definitions. (Unless it just so happens that each letter that starts a function happens to split things up into functionally related groups.)

More generally, the definitions for "module", "modularity", etc. would not (nor should they) attempt to differentiate between "good" modules and "bad" ones. So I don't really see what your point has to do with the question of what is modularity.

I've later added that the "mental hash" has to "better than random" to qualify for my working def. Thus, I'm dismissing arbitrary chunkification, but am otherwise avoiding judging the quality of the hash (grouping criteria). Better than random can be tested by asking the creator of the criteria which module a given activity or result artifact is in. For example, "which module(s) affects how much butter goes on the food?", "Which module(s) affect the cooking time?". "Which module tells us if the bacon is burned". They should do better than random chance. -t

Example Grouping Criteria

Footnotes

[1] Until the point it becomes a "blob of mold"

CategoryDefinition, CategoryInfoPackaging, CategorySourceManagement, CategoryDefinition

EditText of this page (last edited August 1, 2013) or FindPage with title or text search