Clear Code
  • Introduction
    • About This Book
    • Timeline
    • Software Killers
    • Billion Dollar Mistakes
    • Clear Code Overview
    • Clear Code Rules
  • Data Processing
    • Separate Data Collection And Processing
    • Create Data Models
    • Separate Use Cases
    • Data Should Be Immutable
  • Examples
    • Separate Use Cases With Data Model
  • Maintenance Cost
    • Consider the Maintenance Cost
    • The Software Exists In Time
    • Don't Feed the Monsters
  • OOP
    • Separate Data And Procedures
    • Do Not Use Inheritance
    • When To Avoid Inheritance?
    • What Is The Problem With Abstract Frameworks?
  • VARIOUS
    • The Real Single Responsibility Principle
    • The problem with Clean Code's name
    • How To Handle Warnings
    • Do Not Create Constant Collection Classes
  • Externals
    • Links
    • Quotes
    • Funny
  • Technology
    • Git Tutorials
  • Clean Code
    • Clean Code Introduction
      • Origin & Overview
      • Advanced
      • Typical Issues
    • Clean Code Outline
      • Why Clean Code?
      • Clean Code
      • Clean Code Approaches
      • Specification & Design
      • Duplication
      • Refinement & Refactoring
      • Conventions
      • Names
      • Types
      • Methods
      • Nulls and Validity Checks
      • Comments
      • Dead Code
      • Error Handling
      • Classes
      • Code Formatting
      • Unit Tests
      • Special Cases
      • Object Oriented Programming
      • General Code Smells
    • Clean Code Links
    • Clean Code TOC
    • Effective Java TOC
Powered by GitBook
On this page
  • Two Types of Classes
  • Rules
  • Cohesion
  • Interfaces
  • Class Smells

Was this helpful?

  1. Clean Code
  2. Clean Code Outline

Classes

Two Types of Classes

Procedural

Business logic or Service

  • Stateless, singleton or static if possible

  • Instantiated mostly by the DI framework - Spring, Java EE

  • If stateful, create it from the code with new

Data structure

Entity, DTO (Data Transfer Object)

  • Only data members

  • No business logic

  • Always instantiated as new - by the database layer or with new from the code

  • Accessors/mutators are questionable - getters/setters

Rules

  • One reason to exist, change

  • "Small"

  • No "God" class - "Sack", "Blob"

  • Encapsulation (hiding, protection) decreases dependency - Other classes cannot depend on this

  • Tight cohesion

Cohesion

  • Implements the "one thing" rule

  • Contains only dependent members

  • Refactor to cohesive classes

  • There will be many small classes - Like a toolbox with drawers

  • Reduces amount, cost and risk of changes

Interfaces

  • Create interfaces for service classes -but not always paranoidly for everything

  • Prefer interfaces to parent classes

  • Create marker interfaces

Class Smells

No meaningful name

  • You cannot give a meaningful name - e.g. "Parent", "Common", "Processor", etc.

Unnecessary polymorphism

  • Polymorphic class is not used as polymorphic - never declared to parent type - see later

Does more things - Low cohesion

  • Many methods - "God" or "Blob" class

  • Methods of a class can be split into distinct call chains - they should be in separate classes

  • Test coverage is not visible or cheating

  • Refactor to composition + Facade pattern

Example: Refactoring low cohesion

Last updated 5 years ago

Was this helpful?