Impedance Mismatches among Relational tables, Objects, and XML Hierarchy

So often, we as software developers, try to map objects to a persistent relational database and run into difficulties because it just doesn't fit right. We end up working with ORM abstractions (e.g. Hibernate) that undo the damage done by normalizing the original object model into multiple tables.

With the object paradigm, you traverse objects via their relationships whereas with the relational paradigm you join the data rows of tables. Scott Ambler has a good discussion of the Object-Relational Impedance Mismatch. He also describes The Cultural Impedance Mismatch Between Data Professionals and Application Developers (e.g.  "Data professionals that claim that your object/component models must be driven by their data models"), Why Data Models Shouldn't Drive Object Models (And Vice Versa).

What about XML hierarchies and database tables. Here's a good article on storing trees in tables. How do you store a tree in a database table?  He discusses a couple of challenges with typical approaches and presents a novel approach.

Some issues in the XML to Objects mapping: Revealing the X/O impedance mismatch (Changing lead into gold). In general I love working with JAXB and it is now part of the JDK. It's a breeze to auto-generate classes from XML schema that can then be used to import and export XML from your code. Strangely, there's a lack of up-to-date tutorials on using xjc from Java 6 or later. I will add that to my todo list.

"I believe the fundamental problem with the database solution comes from the fact that it is often slapped on an application by default. “We need persistence.” “Well, let’s use a database [and the ORM]“. is a good quote from Best alternative to RDBMS and ORMs : Terracotta | Taranfx: Technology Blogbase [and the ORM]“.

Other links:

• Object-relational impedance mismatch - Wikipedia, the free encyclopedia
• ORM - The Leaky Abstraction
• Inheritance vs Relational Databases in RoR
• Implementing Type hierarchies "There are three common patterns for mapping type hierarchies to database tables. Martin Fowler uses the following names for these patterns: Single Table Inheritance, Class Table Inheritance, and Concrete Table Inheritance"
• How XML Threatens Big Data : Dataspora Blog "Data lives in relational databases or as data structures in programs. The common import and export formats of these environments do not resemble XML, so much effort is dedicated to making XML fit. When more time is spent on inter-converting data — serializing, parsing,translating — than in using it, you’ve created a data bureaucracy."

Impedance Mismatches: Relational, Objects, and XML Hierachical

So often, we as software developers, try to map objects to a persistent relational database and run into difficulties because it just doesn't fit right. We end up working with ORM abstractions (e.g. Hibernate) that often seem more trouble than they're worth. This is what we call impedance mismatch.

Part of the problem is often letting the

Lean Software Development

Zero Practices (These practices that must be in place before taking the first step):

• Source Code Management
• Scripted Build

Daily Standup

Automated Testing

Continous Integration

• Use a dedicated build machine
• Check code changes into the repository a minimum of once a day (per developer); once an hour or more is even better.
• Immediately address any failures in the build. Fixing the build takes precedence over further implementation.

Less Code

• Eliminate Unnecessary Code
• Use coding standards to write readable and understandable code.
• Design and implement code with design patterns, refactoring, and emergent design.

Short Integrations

• Use Customer Feedback
• Course correction

Customer Participation

• Requirements Prioritization
• Acceptance Tests
• Accessible Status
• Access To Product

OSGi Evangelism and OO Design Principles

OSGi adds a higher layer of granularity to OO abstraction, information hiding, design by contract, etc. I like this quote  from Modular Mind: "Software development has advanced in large part by increasing the granularity of the aggregations that we have to work with.". In this presentation, Module Systems and Architectures, on OSGI, Martin Lippert also shows another evolution that can be seen in OSGi:


Good Old Design Principles
DIP SOC LSP ADP TDA DRY AIP
ISP SCP OCP IHP SRP SDP

New Design Principles
Use services ---> Separate between interface and implementation
Use extensions ---> working but extensible

Here's a breakdown of Martin's shortlist of "good old design principles":

Class Design Principle

• Separation Of Concerns (SoC)
• Tell, Don't Ask (TDA)
• Don't Repeat Yourself (DRY)
• Dependency Injection Principle (DIP)
• Liskov Substitution Principle (LSP)
• Open Closed Principle (OCP)
• Single Responsibility Principle (SRP)
• Interface Segregation Principle (ISP)

Package Design Principles

Cohesion Principles: 

• Reuse/Release Equivalency Principle (REP)
• Common Reuse Principle (CRP) 
• Common Closure Principle (CCP)

Coupling Principles:

• Acyclic Dependencies Principle (ADP)
• Stable Dependencies Principle (SDP)
• Stable Abstractions Principle (SAP)

  Object-Oriented Reengineering - Principles of OOD - Radu Marinescu,
  OO Design Principles - Stefan Kluth,

Emergent Design

TODO:

• Tracer Bullet Development (see Ship It, ch. 4)

• do light-weight, up front design, create a system of mock objects, and add appropriate automated tests
• System Objects: Encapsulate and Separate 
• incrementally add functionality to the system  
• Incremental Improvements: Iterations
• benefits: scalability, encapsulation, decoupled code, parallel code development, flexible to requirements creep

Static Code Analysis, Defect Detection, Code Smells, Architecture Smells, Dependency Analysis

FindBugs Descriptions

• Bad Practice
• Correctness
• Experimental
• Malicious Code Vulnerability
• Multithreaded Correctness
• Performance
• Security
• Dodgy Practices

PMD Rulesets

Lint4J checks for

• Architectual problems
• Contracts defined in the Java core API
• Java Language Constructs
• Immature code
• Performance
• Code portability
• The Serialization and Externalization contracts
• Suspicious coding and likely bugs
• Java Synchronization and Scalability
• Coding patterns that impact readability and code size
• Violations of the EJB specification

JLint Program Checker

Coverity Static Analysis, Dynamic Analysis , Architectural Analysis

NASA's JPF (Java Path Finder)
Which defects can be found by JPF? Out of the box, JPF can search for deadlocks and unhandled exceptions (e.g. NullPointerExceptions and AssertionErrors), but the user can provide own property classes, or write listener-extensions to implement other property checks. A number of such extensions, like race condition and heap bounds checks are included in the JPF distribution 

Hammurabi Hammurapi is a code quality governance platform to mitigate risks of outsourcing* of software development.

Structure 101

OSGi For Modularizing Large Projects

OSGi helps establish good practices in software development by effectively applying at a macro level these good OO practices:

• hide implementation details (design by interface contract)
• minimize dependencies (high cohesion, low coupling)

Declarative programming and in particular declarative services promote:

• extensibility (e.g. wrapping a web server)
• writing POJOs and using in a larger context

Keeping the data model and visual representation separate promotes:

• not writing too much from scratch
• maintaining the reusability of core logic
• allowing different app versions per audience
• grow or shrink app

Messaging Patterns Used In CORBA

• Synchronous with Timeout Method Invocation (SMI) – the client is blocked until a response is received from the server or a timeout occurs (client might spawn a thread so main thread is not blocked)

• Asynchronous Method Invocation (AMI) – the client is not blocked but receives a callback from the server

• One-way Method Invocation (OMI) – like AMI except no callback is received

Presentation And Diagramming Links

• Presentation Zen : lots of whitespace, few pretty pictures, a presentation should be worthless without the presenter to explain it,...
• 10 Powerpoint Tips for Preparing a Professional Presentation No sentences, never read your slides, talk freely have a take away message,...
• Mindmapping: I find the PowerPoint SmartArt template "Horizontal Hierarchy" best.
• TimeLine: PowerPoint SmartArt has a good timeline template under "Process"
• Lovely Charts: web-based graphic builder
• Web Sequence Diagrams
  
• Gliffy, Online Diagramming 
• MindTools: Lots of good descriptions of visualizations for conveying ideas (e.g. fishbone, SWOT, affinity diagram, Gantt chart, PMI, grid analyis, etc.)

Programmer Productivity Tips

1. Use a modern IDE such as Eclipse.
2. Content Assist (or Code Completion, tab completion, Intellisense, etc.)  Content assist provides you with a list of suggested completions for partially entered strings. In Eclipse type something in the editor window and then ctrl-space. (e.g in Eclipse: Preferences->Java->Editor->Content Assist->Advanced)
3. Code Templates: For example, type sysout and then ctrl-space and it spits out System.out.println(); with the cursor in the right spot. Type "for" ctrl-space and get a for...loop, type "try" ctrl-space and get a try...catch block.  (Eclipse: Window->Preferences->Java->Editor->Templates) 
4. Code Generation: Faster Java coding in Eclipse Galileo (IBM), Useful Eclipse Shortcuts (SO) , Eclipse Shortcuts (Vogella)
5. Compiler Warnings: Using Eclipse Java Compiler Errors/Warnings – Improving your code quality, CheckStyle
   
6. Syntax Highlighting
7. Focus (i.e. turn off email, browser, im when possible)
8. Google
9. Dual Monitors
10. Synergy lets you easily share a single mouse and keyboard between multiple computers with different operating systems
11. Caffeine
12. Debugger Java Debugging With Eclipse (Vogella)
    
13. Sound isolating headphones
14. Design Patterns
15. XML Binding (no need to write DOM and SAX code any more)
    

Favorite Pragmatic Software Development Tips

From The Pragmatic Programmer: From Journeyman to Master
See them all here.

• DRY—Don’t Repeat Yourself
  
• Always Use Source Code Control
• Write Code That Writes Code
  
• Design with Contracts
• Refactor Early, Refactor Often
• Abstractions Live Longer than Details
• Don’t Use Manual Procedures
  
• Test Early. Test Often. Test Automatically.
• Use Exceptions for Exceptional Problems
  
• Minimize Coupling Between Modules
• Put Abstractions in Code, Details in Metadata
• Design Using Services
• Separate Views from Models
• Don’t Program by Coincidence
• Test Your Estimates
• Design to Test
• Find Bugs Once
• Build Documentation In, Don’t Bolt It On
  
  

First Code Smells, now Build Smells

Remove the smell from your build scripts

• IDE-only builds
• Copy-and-paste scripting
• Long targets
• Large build files
• Failing to clean up
• Hard-coded values
• Builds that succeed when tests fail
• Magic machines
• A lack of style

Agile Modeling Best Practices

From Scott Ambler

• Active Stakeholder Participation
• Architecture Envisioning. At the beginning of an agile project you will need to do some initial, high-level architectural modeling to identify a viable technical strategy for your solution.
• Document Late
• Executable Specifications
• Iteration Modeling
• Just Barely Good Enough (JBGE) artifacts
• Model a bit Ahead
• Model Storming
• Multiple Models
• Prioritized Requirements
• Requirements Envisioning
• Single Source Information
• Test-Driven Design (TDD)

Antipatterns (collected from wikipedia)

Antipatterns (retrieved 2-14-10). Also see programming bugs.
Organizational anti-patterns

• Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
• Cash cow: A profitable legacy product that often leads to complacency about new products
• Design by committee: The result of having many contributors to a design, but no unifying vision
• Escalation of commitment: Failing to revoke a decision when it proves wrong
• Management by perkele: Authoritarian style of management with no tolerance for dissent
• Moral hazard: Insulating a decision-maker from the consequences of his or her decision.
• Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure)
• Stovepipe or Silos: A structure that supports mostly up-down flow of data but inhibits cross organizational communication
• Vendor lock-in: Making a system excessively dependent on an externally supplied component

Project management anti-patterns

• Death march: Everyone knows that the project is going to be a disaster – except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang"). Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline.
• Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking.
• Smoke and mirrors: Demonstrating how unimplemented functions will appear
• Software bloat: Allowing successive versions of a system to demand ever more resources

Analysis anti-patterns

• Bystander apathy: When a requirement or design decision is wrong, but the people who notice this do nothing because it affects a larger number of people.

Software design anti-patterns

• Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
• Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
• Big ball of mud: A system with no recognizable structure
• Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
• Gas factory: An unnecessarily complex design
• Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
• Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
• Input kludge: Failing to specify and implement handling of possibly invalid input
• Interface bloat: Making an interface so powerful that it is extremely difficult to implement
• Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction.
• Race hazard: Failing to see the consequence of different orders of events
• Stovepipe system: A barely maintainable assemblage of ill-related components

Object-oriented design anti-patterns

• Anemic Domain Model: The use of domain model without any business logic which is not OOP because each object should have both attributes and behaviors
• BaseBean: Inheriting functionality from a utility class rather than delegating to it
• Call super: Requiring subclasses to call a superclass's overridden method
• Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
• Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
• Constant interface: Using interfaces to define constants
• God object: Concentrating too many functions in a single part of the design (class)
• Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
• Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
• Poltergeists: Objects whose sole purpose is to pass information to another object
• Sequential coupling: A class that requires its methods to be called in a particular order
• Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

Programming anti-patterns

• Accidental complexity: Introducing unnecessary complexity into a solution
• Action at a distance: Unexpected interaction between widely separated parts of a system
• Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
• Boat anchor: Retaining a part of a system that no longer has any use
• Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging
• Caching failure: Forgetting to reset an error flag when an error has been corrected
• Cargo cult programming: Using patterns and methods without understanding why
• Coding by exception: Adding new code to handle each special case as it is recognized
• Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message
• Expection handling: (a portmanteau of expect and exception) Using a language's error handling system to implement normal program logic
• Hard code: Embedding assumptions about the environment of a system in its implementation
• Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences[5][6]
• Loop-switch sequence: Encoding a set of sequential steps using a loop over a switch statement
• Magic numbers: Including unexplained numbers in algorithms
• Magic strings: Including literal strings in code, for comparisons, as event types etc.
• Soft code: Storing business logic in configuration files rather than source code[7]
• Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures

Methodological anti-patterns

• Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
• Golden hammer: Assuming that a favorite solution is universally applicable (See: Silver Bullet)
• Improbability factor: Assuming that it is improbable that a known error will occur
• Premature optimization: Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency
• Programming by permutation (or "programming by accident"): Trying to approach a solution by successively modifying the code to see if it works
• Reinventing the wheel: Failing to adopt an existing, adequate solution
• Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem
• Tester Driven Development: Software projects in which new requirements are specified in bug reports

Configuration management anti-patterns

• Dependency hell: Problems with versions of required products
• DLL hell: Inadequate management of dynamic-link libraries (DLLs), specifically on Microsoft Windows
• Extension conflict: Problems with different extensions to pre-Mac OS X versions of the Mac OS attempting to patch the same parts of the operating system
• JAR hell: Overutilization of the multiple JAR files, usually causing versioning and location problems because of misunderstanding of the Java class loading model

Pitfalls of Modern Software Engineering

Another good list from a forthcoming book.

Managerial pitfalls

• Using the wrong developers
• Using the wrong metrics (or none at all)
• Lying to yourself and others
• Not identifying and managing risks
• Adopting a technology or methodology without well-defined objectives
• Misjudging relatives costs
• Allowing new features to creep (or pour) in
• Allowing the specification to drift or change without agreement
• Attempting too much, too fast, too soon
• Abandoning good software engineering practices

Political pitfalls

• Not educating and enlisting management before the fact
• Underestimating the resistance
• Overselling the technology or methodology
• Not recognizing the politics of architecture
• Getting religious about the technology or methodology
• Getting on the feature release treadmill
• Betting the company on a given technology or methodology
• Picking the wrong horse

Conceptual pitfalls

• Adopting a new technology or methodology for the wrong reason
• Thinking a new technology or methodology comes for free
• Thinking a new technology or methodology will solve all your problems
• Confusing buzzwords with concepts
• Confusing tools with principles
• Confusing training with skill
• Confusing prototypes with finished products
• Confusing approach with results
• Asking the wrong questions

Some Programming Best Practices 2009

From Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies.

• Selection of programming languages to match application needs
• Utilization of structured programming practices for procedural code
• Selection of reusable code from certified sources, before starting to code
• Planning for and including security topics in code, including secure languages such as E
• Avoidance of “spaghetti bowl” code
• Minimizing cyclomatic complexity and essential complexity
• Including clear and relevant comments in the source code
• Using automated static analysis tools for Java and dialects of C
• Creating test cases before or concurrently with the code
• Formal code inspections of all modules
• Re-inspection of code after significant changes or updates
• Renovating legacy code before starting major enhancements
• Removing error-prone modules from legacy code

Agile Most Accepted Practices

(Scott Ambler survey 2009)

• Continuous Integration
• Daily Standup
• TDD
• Iteration Planning
• Code Refactoring
• Retrospectives
• Pair Programming
• Active Stakeholder Participation

Code Smells

From Martin Fowler's excellent book, Refactoring: Improving the Design of Existing Code. More descriptions can be found here.

• Duplicated Code
• Long Method
• Large Class
• Long Parameter List
• Divergent Change
• Shotgun Surgery
• Feature Envy
• Data Clumps
• Primitive Obsession
• Switch Statements
• Parallel Inheritance Hierarchies
• Lazy Class
• Speculative Generality
• Temporary Field
• Message Chains
• Middle Man
• Inappropriate Intimacy
• Alternative Classes with Different Interfaces
• Incomplete Library Class
• Data Class
• Refused Bequest
• Comments

• Duplicate code: identical or very similar code exists in more than one location.
• Large method: a method, function, or procedure that has grown too large.
• Large class: a class that has grown too large, see God object.
• Feature envy: a class that uses methods of another class excessively.
• Inappropriate intimacy: a class that has dependencies on implementation details of another class.
• Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by derived class. See Liskov substitution principle.
• Lazy class: a class that does too little.
• Duplicated method: a method, function, or procedure that is very similar to another.
• Contrived Complexity: forced usage of overly complicated design patterns where simpler design would suffice.

Checkstyle, PMD and FindBugs for Java, to automatically check for certain kinds of code smells.

Antipatterns In Software Development, Software Architecture, and Project Management

A collection of bad practices from AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. More detail is available here.

Software Development Antipatterns

• The Blob
• Continuous Obsolescence
• Lava Flow
• Ambiguous Viewpoint
• Functional Decomposition:
• Poltergeists
• Boat Anchor
• Golden Hammer
• Dead End
• Spaghetti Code
• Input Kludge
• Walking through a Minefield
• Cut-and-Paste Programming
• Mushroom Management

Software Architecture Antipatterns

• Autogenerated Stovepipe
• Stovepipe Enterprise
  
• Jumble
  
• Stovepipe System
  
• Cover Your Assets:
  
• Vendor Lock-In
• Wolf Ticket
  
• Architecture by Implication
  
• Warm Bodies
  
• Design by Committee
  
• Swiss Army Knife
• Reinvent the Wheel
  
• The Grand Old Duke of York
  

Project Management Antipatterns

• Blowhard Jamboree
• Analysis Paralysis
  
• Viewgraph Engineering
  
• Death by Planning
• Fear of Success
• Corncob
  
• Intellectual Violence
  
• Irrational Management
• Project Mismanagement
  
• Throw It over the Wall
  
• Fire Drill
  
• The Feud
  
• E-mail Is Dangerous
  

OO Best Practices

• The O/R Impedance Mismatch and Inheritance vs Relational Databases
• (Prefer) Composition versus inheritance
• SRP The Single Responsibility Principle A class should have one, and only one, reason to change.
• OCP The Open Closed Principle You should be able to extend a classes behavior, without modifying it.
• LSP The Liskov Substitution Principle Derived classes must be substitutable for their base classes.
• DIP The Dependency Inversion Principle (aka IoC) Depend on abstractions, not on concretions.
• ISP The Interface Segregation Principle Make fine grained interfaces that are client specific.
• (also in clean code smells) The LawOfDemeter specifies a style guideline: "Only talk to your immediate friends." one never calls a method on an object you got from another call nor on a global object.
• clean code (cc) Object/structure assymetry, data transfer object (DTO) active record is one example (don't put business logic in one)
• tell, don't ask
• Data professionals that claim that your object/component models must be driven by their data models

Miscellaneous Best Practices

• Program to an interface, not an implementation
• on par with DRY and KISS is YAGNI
• You have to be constantly scanning your code and design and looking for code smells creeping in and opportunities to create abstraction that remove duplication or create greater efficiencies.
• Eclipse errors/warnings settings: This should only be your first step, additional checks are provided by Findbugs and Checkstyles
• tests: throttle test, smoke test
• One of my favorite catch phrases is, "The difference between theory and practice is that, in theory, there is no difference, but, in practice, there is."
• Refactor Mercilessly

Continuous Integration

“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly” martinfowler.com

Steve McConnell wrote about doing this in 1996 in Daily Build and Smoke Test

• Maintain a code repository
• Automate the build
• Make the build self-testing
• Everyone commits every day
• Every commit (to mainline) should be built
• Keep the build fast
• Test in a clone of the production environment
• Make it easy to get the latest deliverables
• Everyone can see the results of the latest build
• Automate deployment

Benefits of CI

• CI allows you to develop software faster, better and cheaper.
• Faster: No integration points. Release builds become a non-event.
• Better: Tested early and often. Consolidated metrics though a CI Server.
• Cheaper: Identify defects earlier and fix when least costly.
• Easily repeatable testing.

Risks Of Not Doing CI

• Without CI the team can lack cohesion (incompatible conflicts, different libraries in use, “I thought you fixed that bug 3 months ago!”).
• Lack of Visibility: Not knowing when a build fails or your code coverage.
• Isolation: “It works on my machine!”.
• Integrating late means fixing bugs late, which is costly.

CI will not work if you want to use:

• Nightly Builds.
• Developer Branches.
• Scheduled Integration.
• Building via an IDE.

To get the most out of CI

• Commit early and commit often.
• Never commit broken code.
• Fix build failures immediately.
• Ensure your builds run fast, and fail fast.
• Avoid known CI Antipatterns below:

Continuous Integration: Improving Software Quality and Reducing Risk

• Infrequent check-ins, which lead to delayed integrations
• Broken builds, which prevent teams from moving on to other tasks
• Minimal feedback, which prevents action from occurring
• Receiving spam feedback, which causes people to ignore messages
• Possessing a slow machine, which delays feedback
• Relying on a bloated build, which reduces rapid feedback
• Waiting until the end of the day to commit changes, leading to Bottleneck Commits, which typically cause broken builds and frustrated developers
  
• A build consisting of minimal automated processes, which results in builds that never fail, leading to Continuous Ignorance and delaying integration problems
  
• Hindering build fixes through a preference for Scheduled Builds, rather than frequently building software with every code change
  
• Believing that code Works on My Machine, only to discover problems later in other environments
  
• Failing to remove old build artifacts, which leads to a Polluted Environment causing false positive and false negative error.

Here's a good article on creative alerting (e.g. SMS, blog update, a lighting orb) on automated build status.

Joe Wright on Continuous Integration

GoF Design Patterns

From the now-classic book Design Patterns: Elements of Reusable Object-Oriented Software.

Creational Patterns

• Abstract Factory: Creates an instance of several families of classes
• Builder: Separates object construction from its representation
• Factory Method: Creates an instance of several derived classes
• Prototype: A fully initialized instance to be copied or cloned
• Singleton: A class of which only a single instance can exist

Structural Patterns:

• Adapter: Match interfaces of different classes
• Bridge: Separates an object’s interface from its implementation
• Composite: A tree structure of simple and composite objects
• Decorator: Add responsibilities to objects dynamically
• Facade A single class that represents an entire subsystem
• Flyweight: A fine-grained instance used for efficient sharing
• Proxy: An object representing another object

Behavioral Patterns:

• Chain of Resp.: A way of passing a request between a chain of objects
• Command: Encapsulate a command request as an object
• Interpreter: A way to include language elements in a program
• Iterator: Sequentially access the elements of a collection
• Mediator: Defines simplified communication between classes
• Memento: Capture and restore an object's internal state
• Observer: A way of notifying change to a number of classes
• State: Alter an object's behavior when its state changes
• Strategy: Encapsulates an algorithm inside a class
• Template Method: Defer the exact steps of an algorithm to a subclass
• Visitor: Defines a new operation to a class without change

Software Engineering Antipatterns From CRC Press

A collection of bad practices from Antipatterns: Identification, Refactoring, and Management (Auerbach Series on Applied Software Engineering).

Management Antipatterns

• Absentee Manager
• All You Have is a Hammer
• Cage Match Negotiator
• Doppelganger
• Fruitless Hoops
• Golden Child
• Headless Chicken
• Leader Not Manager
• Manager Not Leader
• Managerial Cloning
• Metric Abuse
• Mr. Nice Guy
• Mushroom Management
• Plate Spinning
• Proletariat Hero
• Rising Upstart
• Road to Nowhere
• Spineless Executive
• Three Headed Knight
• Ultimate Weapon
• Warm Bodies

Environmental Antipatterns

• Ant Colony
• Atlas Shrug
• Autonomous Collective
• Boiling Frog Syndrome
• Burning Bag of Dung
• Buzzword Mania
• Deflated Balloon
• Divergent Goals
• Dogmatic about Dysfunction
• Dunkirk Spirit
• The Emperor’s New Clothes
• Fairness Doctrine
• Fools Rush In
• Founderitis
• French Waiter Syndrome
• Geek Hazing
• Institutional Mistrust
• Kiosk City
• Mediocracy
• One-Eyed King
• Orange Stand Economics
• Pitcairn Island
• Potemkin Village
• Process Clash
• Rubik’s Cube
• Shoeless Children
• Worshiping the Golden Calf

Software Architecture Patterns

Patterns from Pattern-Oriented Software Architecture Volume 1: A System of Patterns

Architectural Patterns

• Layers
• Pipes and Filters
• Blackboard
• Distributed Systems
• Broker
• Interactive Systems
• Model-View-Controller
• Presentation-Abstraction-control
• Adaptable Systems
• Microkernel
• Reflection

Design Patterns

• Whole-Part
• Organization of Work
• Master-Slave
• Access Control
• Proxy
• Management
• Command Processor
• View Handler
• Communication
• Forwarder-Receiver
• Client-Dispatcher-Server
• Publisher-Subscriber

Enterprise Design Patterns

Transaction Patterns

• Acid Transaction
• Composite Transaction
• Two Phase Commit
• Audit Trail
  

Distributed Architecture Patterns

• Shared Object
• Object Request Broker
• Object Replication
• Redundant Independent Objects
• Prompt Repair
• Mobile Agent
• Demilitarized Zone
• Process Pairs
  

Distributed Computing Patterns

• Object Identifier
• Registry
• Protection Proxy
• Publish-Subscribe
• Retransmission
• MailboxHeavyweight/Lightweight
• Heartbeat
• Connection Multiplexing

Concurrency Patterns

• Session Object
• Lock File
• Static Locking Order
• Optimistic Concurrency
• Thread Pool
• Ephemeral Cache Item
• Transaction State Stack
  

Temporal Patterns

• Time Server
• Versioned Object
• Temporal Property
  

Database Patterns

• Persistence Layer
• CRUD
• Stale Object
• Type Conversion
• IsDirty
• Lazy Retrieval