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."

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,

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

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
  

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