Pattern Abuse

Hi folks,

I do not want to start a language war; therefore, the story I am telling is not about Java in general, but about the process by which things mature Java into an enterprise solution platform.

I feel guilty, because as a pattern promoter (let's say the second generation) and author I helped many others getting the pattern hype. This allowed many developers to create better -- but often also far more complex -- solutions to their problems.

KentBeck tells us that SimpleDesign is important, but simple is not easy; it is very hard.

What I observed over the past couple of years is the way that the Java platform is extended over and over, losing all its simplicity and elegance. Many people contribute specifications and libraries that do not follow a consistent usage pattern, except that they are complicated to use. The structure and often strong typing of interfaces is horrible for a client programmer, who is urged to use the things going on.

This AccidentalComplexity (a term Doug Schmidt introduced to me) explodes within things like J2EE specifications (more than 1000 pages if printed).

Why does every thing in the specification require an AbstractFactory or ManagerPattern? or both?
Why are so many properties not represented as PropertyList? or Anythings but by feature specific classes?
Why do designers specify interfaces without getting the experience of being a victim of their interfaces (XpTesting? might help here in the future)
Why do developers/designers not read the fine print i.e. the consequences of the patterns they apply?
Why are the specifications not created by the FrameworkRule? of ThreeKnownUses??
Why does everyone think distribution of components is inherently good, even if it should be avoided if possible?
Why do so many people think that logical layers should equal physically distributed tiers?

Help me with my feelings. I think we intended to produce a curative drug with patterns and now everybody is taking overdoses. Will we have to have a FDA taking care of patterns, so that negative consequences have to be put on every pattern box in double size print?

Any comments are appreciated.....

-- PeterSommerlad

The answer is the generalism of the APIs and interfaces. Take JavaMail? for example: of course it is possible to do SMTP and POP3 much easier, but if you want a general interface system for messaging you have to deal with abstract factories.

Programmers (as users of APIs) should have a right to get consistent and simple APIs. Programmers (as producers of APIs) should have the obligation to produce consistent and simple APIs. IMO the only way towards this goal is to develop a common language for programming. This language should express the *meaning* of the interfaces more explicitly and more completely than is common practice now. This language should be independent of special programming language features and should allow programmers to express meaning similarly in different programming languages. If such a language would prescribe a function interface: e.g. string=UrlRetString(url) then no library should ever use a different prototype and no programmer using any language should ever need to think about this twice.

-- HelmutLeitner

I do not believe that language features or technology can solve the issue. It is a social and economic problem driven also by marketing. Therefore we need a force that has to drive a lot of people, otherwise we will continue to lament over bad interfaces and ugly solutions (as I do). However, you can even make money from that. We do some review projects that we nicknames ItFuneralServices. -- PeterSommerlad

With Java, API design is definitely motivated by economics and marketing. Sun wants Java to become a widely supported platform. To do so they need to gain support for the Java platform from other vendors. To get support, it must be possible for other vendors to make money from the Java platform by selling services that plug into it, beneath the standard APIs. This is why all the APIs are divided into the PublicInterface and PrivateImplementation? classes that are usually loaded as ParameterClasses specified by system properties.

There are certain APIs in which this is a definite advantage. The crypto APIs are an example. It is imperative that user are able select trusted implementations of algorithms and different users will place different levels of trust in the same implementation. Applications must be shielded from the user's selection of implementation. Therefore the JCE (Java Cryptography Extension) uses ParameterClasses and the BridgePattern to allow the user to select from different implementations of the same crypto algorithms.

-- NatPryce

Would you mind terribly moving the content of this page to one with a more appropriate title? Maybe PatternAbuseInJava?? I just moved it from GuiltyOrInnocent to here -- GeorgePaci

Well the title isn't perfect, but it is a recurring theme not bound to what happens with Java. It is observable in many places. Getting rid of complexity is not where the majority are heading to. -- PeterSommerlad

You don't get a simple design in a hurry. It takes refactoring. First you make something that works, then you figure out how to do it simpler, and simpler, and simpler. Short proofs are usually discovered after longer proofs. It is the same process. Most people are in a hurry, and don't have time to build simple systems. You are right; Java is just like everything else. -- RalphJohnson

I think j2ee is not overall bad. After all things like JDBC or JNDI can't be expressed to much differently anyway. The major thing that's flawed (well, IMHO flawed) is EJB. Maybe someone will address the issue and try to create and argument a different type of pattern. How do you organize this whole mess as an industry? Somebody (who?) writes some specs, but doesn't provide any reasonable argument why that spec is good or good in a particular situation. Then there are the marketing guys trying to sell no matter what. Then there are the masses of developers trying to implement and/or follow. Only after a long time somebody maybe discovers antipatterns (like where do you see applets on Web sites now?). Maybe the whole process can be organized differently. -- CostinCozianu

See WhenIsTheUseOfDesignPatternsNotAppropriate, PatternBacklash

CategoryPattern