design patterns

Haskell - Monad myths

This page titled, “What I wish I knew when learning Haskell” has this interesting section on monads. I agree with his statement that there’s no sense in studying monads; you just need to write a lot of code, and then you’ll see when you need a monad. That is, studying monads is like studying OOP design patterns when you don’t need them; they’re interesting to learn, but until you need them and use them you won’t really understand them.

Java examples of the Law of Demeter

Summary: The Law of Demeter is discussed using Java source code examples.

Whenever you talk to a good, experienced programmer, they will tell you that "loosely coupled" classes are very important to good software design.

The Law of Demeter for functions (or methods, in Java) attempts to minimize coupling between classes in any program. In short, the intent of this "law" is to prevent you from reaching into an object to gain access to a third object's methods. The Law of Demeter is often described this way:

Design Patterns in Java

I've recently started writing a series of articles on Design Patterns in Java, i.e., Design Patterns explained using Java source code examples. Although it will take me a little while to create each design pattern example, this page will eventually contain links to all of those examples.

If you're not familiar with software design patterns, they're described on Wikipedia like this:

Chain of Responsibility Pattern in Java

The Chain of Responsibility Pattern is a design pattern whose intent is to avoid coupling the sender of a request to its receivers by giving more than one object a chance to handle a request. The Chain of Responsibility works like this: