liveBook · Manning

Refactoring

As explained in Functional Design and Architecture: Examples in Haskell

Refactoring is the disciplined restructuring of existing code without intentionally changing its externally observable behavior.

Refactoring is the disciplined restructuring of existing code when complexity, tangled dependencies, unclear responsibilities, or changing requirements make further development unsafe. The practical trigger is recognizing that continuing to add functionality may leave the system impossible to change or maintain. section 4.1 section 1.2

A refactoring pass can address several related design problems:

  • Correct inconsistent domain models, such as moving measurement units from a component definition into the component class that actually identifies them. section 4.1.2
  • Replace magic constants, unclear abbreviations, and inconsistent naming with typed declarations and descriptive names. section 4.1.2
  • Reorganize modules and vendor namespaces so responsibilities and dependencies are easier to understand. section 4.1 section 4.1.2

Refactoring a hardware model

A hardware description initially allows a passport to identify one kind of component while its definition describes another. Refactoring makes the passport carry the component class and parameter, then exposes vendor-specific passports through structured declarations and qualified imports. The resulting model rejects invalid combinations earlier and gives client code clearer names. section 4.1.2

Listing 4.3 Refactored declarations
-- module Andromeda.Assets.Vendors.AAA.Common:
  
aaaInc :: Vendor
aaaInc = "AAA Inc."
  
-- module Andromeda.Assets.Vendors.AAA.Components:
  
aaaTemperature25Name :: ComponentName
aaaTemperature25Name = "AAA-T-25"
  
aaaPressure02Name :: ComponentName
aaaPressure02Name = "AAA-З-02"
 
aaaController86Name :: ComponentName
aaaController86Name = "AAA-C-86"
  
guid1 = "some_guid1"
guid2 = "some_guid2"
guid3 = "some_guid3"
  
aaaTemperature25Passport :: ComponentPassport
aaaTemperature25Passport =
  ComponentPassport (Sensors Temperature) aaaTemperature25Name guid2 aaaInc
  
aaaPressure02Passport :: ComponentPassport
aaaPressure02Passport =
  ComponentPassport (Sensors Pressure) aaaPressure02Name guid1 aaaInc
 
aaaController86Passport :: ComponentPassport
aaaController86Passport =
   ComponentPassport Controllers aaaController86Name guid3 aaaInc

The refactored declarations show how naming, vendor organization, typed values, and component passports can be improved together. section 4.1.2

How Functional Design and Architecture: Examples in Haskell covers it

How deep it goes
Descends from recognizing design decay to changing data types, declarations, names, and module boundaries, without detailing testing or behavioral verification.
Examples
Uses hardware descriptions, component passports, vendor declarations, magic constants, naming inconsistencies, and invalid component combinations.
What it assumes
Assumes familiarity with complex code, domain models, modules, and typed declarations while treating design inconsistency as the problem to expose.
What you can do after
Apply it via Haskell or Scala type systems and functional approaches to make substantial model and naming changes safer.
How it connects
Connects refactoring with software design, domain models, type systems, functional programming, module structure, and maintainability.

Also explained in

Compare how 22 books explain refactoring →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Functional Design and Architecture: Examples in Haskell. The section links point to the parts of the book it draws on.