Patterns: Reduction to the Inconsequential

Tony Morris

Abstract

This article is intended as a presentation for Queensland University of Technology (QUT) per request by Richard Thomas (BIT Course Coordinator).

Patterns are either indicative of programming language deficiency or are inconsequential and do not deserve elevated status. In this article, I examine two of the Gang-of-Four Design Patterns [Design Patterns] and two entries from Martin Fowler's Refactoring [Refactoring]. These are shown to be of either no significance and worthy of no mention or only applicable in a contrived environment, such as a deficiency in the expressiveness of a programming language.


Table of Contents

Introduction
Formalities
Ask Questions
Don't torture yourself instead
Computer Programming is a Fashion Industry
So What?
Design Patterns
Refactoring
Pervasive
Strategy Design Pattern
Definition[Strategy Design Pattern]
Java
Scala
Scala (still)
Scala Already Has First-class Thunk
What about Haskell?
Visitor Design Pattern
Definition[Visitor Design Pattern]
Java
Java (still)
Scala
Algebraic Data Types
Haskell
Replace Parameter With Method
Definition[Replace Parameter With Method]
No Curry
Partial Application
Haskell
Haskell (still)
Scala
Do we need Replace Parameter With Method?
Introduce Null Object
Definition[Introduce Null Object]
Remember OneOrNone?
You Betchya
Get or Else
C# has it
Scala
Nup
Flatten Then Map
Haskell
Discussion
Questions
Bibliography

Introduction

It is incredibly important to the survival of a non-concept for it to be ill-defined.