Skip to main content

Chapter 10: Classes Class Organization To Classes Should Be S

This page is a generated reference surface for selective reading. It exists to keep the learner apps guide-first while still preserving source access.

Learning objectives​

  • Explain the main ideas and vocabulary in Classes Class Organization To Classes Should Be S.
  • Work through the source examples for Classes Class Organization To Classes Should Be S without depending on raw chunk order.
  • Use Classes Class Organization To Classes Should Be S as selective reference when learner modules point back to Clean Code.

Prerequisites​

  • Earlier prerequisite concepts leading into Chapter 10: Classes Class Organization To Classes Should Be S.

Module targets​

  • module-03-clean-code

AI companion modes​

  • Explain simply
  • Socratic tutor
  • Quiz me
  • Challenge my understanding
  • Diagnose my confusion
  • Generate extra practice
  • Revision mode
  • Connect forward / backward

Source-of-truth note​

This unit is anchored to Clean Code and the source chapter "Chapter 10: Classes Class Organization To Classes Should Be S". Use external resources only to clarify, extend, or modernize details without replacing the chapter's conceptual spine.

External enrichment​

No chapter-specific enrichment resources are curated yet. Add them in the unit manifest when a source clearly improves learning.

Source provenance​

  • Primary source: Clean Code
  • Source chapter 10: Chapter 10: Classes Class Organization To Classes Should Be S
  • Raw source file: 040-chapter-10-classes-class-organization-to-classes-should-be-s.md

Merged source​

Chapter 10 Classes Class Organization To Classes Should Be S​

Chapter 10: Classes: Class Organization to Classes Should Be Small!

Class Organization​

Following the standard Java convention, a class should begin with a list of variables. Public static constants, if any, should come first. Then private static variables, followed by private instance variables. There is seldom a good reason to have a public variable. Public functions should follow the list of variables. We like to put the private utilities called by a public function right after the public function itself. This follows the stepdown rule and helps the program read like a newspaper article.

Encapsulation​

We like to keep our variables and utility functions private, but we're not fanatic about it. Sometimes we need to make a variable or utility function protected so that it can be accessed by a test. For us, tests rule. If a test in the same package needs to call a function or access a variable, we'll make it protected or package scope. However, we'll first look for a way to maintain privacy. Loosening encapsulation is always a last resort.

Classes Should Be Small!​

The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that. No, we're not going to repeat the exact same text from the Functions chapter. But as with functions, smaller is the primary rule when it comes to designing classes. As with functions, our immediate question is always "How small?" With functions we measured size by counting physical lines. With classes we use a different measure. We count responsibilities.1

Listing 10-1 outlines a class, SuperDashboard, that exposes about 70 public methods.

Most developers would agree that it's a bit too super in size. Some developers might refer to SuperDashboard as a "God class."

Listing 10-1

Too Many Responsibilities
public class SuperDashboard extends JFrame implements MetaDataUser
   public String getCustomizerLanguagePath()
   public void setSystemConfigPath(String systemConfigPath)
   public String getSystemConfigDocument()
   public void setSystemConfigDocument(String systemConfigDocument)
   public boolean getGuruState()
   public boolean getNoviceState()
   public boolean getOpenSourceState()
   public void showObject(MetaObject object)
   public void showProgress(String s)
  1. [RDD].

Listing 10-1 (continued)

Too Many Responsibilities
   public boolean isMetadataDirty()
   public void setIsMetadataDirty(boolean isMetadataDirty)
   public Component getLastFocusedComponent()
   public void setLastFocused(Component lastFocused)
   public void setMouseSelectState(boolean isMouseSelected)
   public boolean isMouseSelected()
   public LanguageManager getLanguageManager()
   public Project getProject()
   public Project getFirstProject()
   public Project getLastProject()
   public String getNewProjectName()
   public void setComponentSizes(Dimension dim)
   public String getCurrentDir()
   public void setCurrentDir(String newDir)
   public void updateStatus(int dotPos, int markPos)
   public Class[] getDataBaseClasses()
   public MetadataFeeder getMetadataFeeder()
   public void addProject(Project project)
   public boolean setCurrentProject(Project project)
   public boolean removeProject(Project project)
   public MetaProjectHeader getProgramMetadata()
   public void resetDashboard()
   public Project loadProject(String fileName, String projectName)
   public void setCanSaveMetadata(boolean canSave)
   public MetaObject getSelectedObject()
   public void deselectObjects()
   public void setProject(Project project)
   public void editorAction(String actionName, ActionEvent event)
   public void setMode(int mode)
   public FileManager getFileManager()
   public void setFileManager(FileManager fileManager)
   public ConfigManager getConfigManager()
   public void setConfigManager(ConfigManager configManager)
   public ClassLoader getClassLoader()
   public void setClassLoader(ClassLoader classLoader)
   public Properties getProps()
   public String getUserHome()
   public String getBaseDir()
   public int getMajorVersionNumber()
   public int getMinorVersionNumber()
   public int getBuildNumber()
   public MetaObject pasting(
MetaObject target, MetaObject pasted, MetaProject project)
   public void processMenuItems(MetaObject metaObject)
   public void processMenuSeparators(MetaObject metaObject)
   public void processTabPages(MetaObject metaObject)
   public void processPlacement(MetaObject object)
   public void processCreateLayout(MetaObject object)
   public void updateDisplayLayer(MetaObject object, int layerIndex)
   public void propertyEditedRepaint(MetaObject object)
   public void processDeleteObject(MetaObject object)
   public boolean getAttachedToDesigner()
   public void processProjectChangedState(boolean hasProjectChanged)
   public void processObjectNameChanged(MetaObject object)
   public void runProject()

Listing 10-1 (continued)

Too Many Responsibilities
   public void setAçowDragging(boolean allowDragging)
   public boolean allowDragging()
   public boolean isCustomizing()
   public void setTitle(String title)
   public IdeMenuBar getIdeMenuBar()
   public void showHelper(MetaObject metaObject, String propertyName)
   // ... many non-public methods follow ...
}

But what if SuperDashboard contained only the methods shown in Listing 10-2?

Listing 10-2

Small Enough?
public class SuperDashboard extends JFrame implements MetaDataUser
    public Component getLastFocusedComponent()
    public void setLastFocused(Component lastFocused)
    public int getMajorVersionNumber()
    public int getMinorVersionNumber()
    public int getBuildNumber()
}

Five methods isn't too much, is it? In this case it is because despite its small number of methods, SuperDashboard has too many responsibilities. The name of a class should describe what responsibilities it fulfills. In fact, naming is probably the first way of helping determine class size. If we cannot derive a concise name for a class, then it's likely too large. The more ambiguous the class name, the more likely it has too many responsibilities. For example, class names including weasel words like Processor or

Manager or

Super often hint at unfortunate aggregation of responsibilities. We should also be able to write a brief description of the class in about 25 words, without using the words "if," "and," "or," or "but." How would we describe the SuperDashboard? "The SuperDashboard provides access to the component that last held the focus, and it also allows us to track the version and build numbers." The first "and" is a hint that SuperDashboard has too many responsibilities.