raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Tuesday, May 30, 2006
  Reg suffering from high-altitude hypoxia?


Respected Java and XML Guru Elliotte Rusty Harold has posted a very nice discussion of Eiffel's Design by Contract principles. Along the way, he makes a vicious ad hominem attack, accusing me of architecture astronautics (he actually stooped to using using the word "theorist," which means, someone who blogs when they should be coding). But I digress.

The World's Longest Single Arch Bridge

The gist of his post is that since we don't have language-level support for Design By Contract, we ought to use final to accomplish as much invariant enforcement as possible. He suggests that final should be the default choice, that interfaces should be rare and concrete classes plentiful in a design, and that support for polymorphism is less-important than enforcing invariants:
Preconditions, postconditions, and invariants are at the core of data encapsulation. They are the first and most important pillar of object oriented programming. Inheritance and polymorphism are second and third respectively, and are less important.
While controversial, this argument is cogent. I would say it is consistent with a specific kind of design philosophy, one that would be as at home in Ada or Modula as it is in Java. This is in marked opposition to the design philosophy of SmallTalk and Squeak, so I would say it is not very object oriented.

Is that a bad thing? I don't think so. Principles like data encapsulization, modularity, contract enforcement, and componentization are extremely valuable and can be realized in many different ways. For example, what do you think the Erlang programming language or the Linda communication and coördination frameworks are are all about? It's not just concurrency, dude.

The large-scale Java applications I've seen have been particularly devoid of true object orientation, and people seem perfectly happy with that. (Rough metric: the OO-ness of a Java application is congruent to the reciprocal of the number of public static methods in the source code).

So my conclusion is that if you want some advice on writing robust, large scale Java applications in a style that has been proven to be useful over the last several decades, you will find Rusty's post informative.

p.s. My tongue was in my cheek when I composed the title and suggested that one of the most socially conscious Java bloggers in the world was vicious. But you knew that.

p.p.s. If you feel that either Rusty or I can be correct but not both of us, please accept my condolences. How long has it been since imagination passed out of your life?

Labels:

 

Comments on “Reg suffering from high-altitude hypoxia?:
Wowza - he makes some rather interesting arguments.

To be honest however while I might agree with him in some ways I also am very happy for the fact that I can sub-class something and 'modify' the intent of the super class. Granted this is limited in scope, but a number of times I have been very very thankful that I had the ability to do this as I was capable of fixing a 'bug' in someone elses code (i.e. documented to do something x that it doesn't do despite the belife of the company that it should do x).

In all the cases that I can think of the places that I have used interfaces are more about making sure that any subclass implements a simple no argument item like executeMe() which doesn't return anything. I have used this many a time in "Command" structures. I also tend to use interfaces in DAO structures so that the underlying implementation can be swapped at will or at run time. Is this a 'best pratice' I dunno, but I have found that it is useful when the 'boss' says that he wants to support more then one Database or more then one back end system. I am not convinced that everything should be final by default - but in looking at the arguments I am starting to sway in that direction.
 
Hey, you asked us readers to point out typos. Is "encapsulization" a typo for "encapsulation", or does it really mean something (different?)
 
encapsulization?

Now that you mention it, encapsulation is the preferred term. Encapsulization is in fairly wide use, but not in the dictionary.

Even if it gets into the dictionary, it's probably a lot like the word utilize:

Never utilize encapsulization when you can simply use encapsulation.

Thanks!
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /