mike.mainguy

One of my beefs with Hibernate as an ORM is that it encourages anemic domain models that have no operations and are simply data structures. This coupled with java's verbosity tend to make code unmaintainable (when used by third party systems) as well as cause developers to focus in THINGS instead of ACTIONS. For example take the following class that represents a way to illustrate part of a flight booking at an airline: public class Flight { public Date start; public Date finish; public long getDuration() { return finish.getTime() - start.getTime(); } } This is the core "business" requirement for a use case in this model in terse java. Form an OO perspective, start and finish are attributes, and getDuration is an operation (that we happen to believe is mathematically derived from the first two fields. Of course, due to training and years of "best practices" brainwashing, most folks will immediately and mindlessly follow the java ...

After spending a considerable amount of time trying to figure out how to refactor some particularly hairly (hairy + gnarly) data access code, I thought I'd share some insight into a popular misconception about what coding to the interface actually means. Let's say we're writing a data access layer and we have something called the UserDAO. a simple implementation might be something like: public class User { public int id; public String name; } public class UserDao { public boolean save(User toBeSaved) { } } I'm going to dodge the issue of the user class not having getters and setters and thus not following the javabean spec and talk about the UserDao Interface. Yes, you heard me, the UserDao class effectively is an interface in this example. Sit down and just think about that for a minute, once you've done that, move to the next paragraph. A great (GREAT) many java developers might not get to this paragraph because they'll imme...

I read a recent article about the importance of writing physically . Fundamentally, the author says that "writing physically" means writing about things you can drop on your foot. This means a lot to me because when trying to write software, I'm constantly translating ideas into mental pictures of physical things. To this end, I think the Gang of Four have done a disservice to the software industry by pushing design patterns that have no representation in the real world. Worse than this, pushing UML as a way to represent and communicate software design leads to situations where everybody THINKS they agree, but they in fact all are thinking about completely different things. As a specific and very simple example, lets look at the Command pattern. Reading the explanation is very dense and rife with jargon that is specific to the particulars of Object Oriented programming languages. For folks who need to read the explanation, who typically are new to OO programmin...