The Rotten Domain Model is dead; long live the Abstracted Domain Model

abstractMany years ago, back when OO was a new, exciting idea that appeared to offer a panacea solution to developing applications, Martin Fowler wrote an article entitled “Anemic Domain Model” (ADM), in which he argued that separating data from functionality, within the OO paradigm, is an anti pattern.

Twelve years later, things have moved on quite a bit. Many now recognise the benefits of such a split; yet some still, near-religiously, stick to the idea that the anaemic data model is somehow “not real OO”. Part of this stems from the (presumably deliberate) use of a negative term to describe that separation approach. It’s therefore time to fight back with new definition of the terms “RDM” and “ADM”, to help move us away from the antiquated view that separating data from functionality is an anti-pattern. It’s the RDM that has been shown to be the real bad design approach.
Continue reading “The Rotten Domain Model is dead; long live the Abstracted Domain Model”

Inheritance: just stop using it already!

no_inheritanceThere are certain constructs in programming languages that demonstrably lead to bad code in the vast majority of use-cases. There is a term for these constructs: anti patterns. An anti-pattern is a way of solving a problem that often appears quick and simple, but that leads to more work and more problems in the long run. Think of nailing two pieces of wood together, rather than drilling a guide hole and using a screw. The former is quicker, but the repair when the wood splits can be both costly and time consuming. Programming languages can enable, and sometimes even encourage, such anti-patterns. Whilst goto might be the best known, there are three other contenders for the worst anti-pattern of all: not writing automated tests, null and object-orientated (OO) inheritance. It’s the last that is the topic of this post. Continue reading “Inheritance: just stop using it already!”

Should programmers really stop calling themselves Software Engineers?

This post is in reaction to an article on the American publication website, The Atlantic, entitled “Programmers: Stop Calling Yourselves Engineers”. That article itself paints a rather silly, rose-tinted, picture of engineers and tries to argue that programmers don’t make the grade. This post isn’t (just) an attack on that article; it is an exploration of the various terms used to describe programmers and whether any are fit-for-purpose as a unifying term to describe those who code? Continue reading “Should programmers really stop calling themselves Software Engineers?”

Why we absolutely should never build software like we build houses

Image of a madly designed houseA few days ago, I read something truly depressing. It was a piece written by Leslie Lamport, “a computer scientist … member of the National Academy of Engineering and the National Academy of Sciences. [with a] Ph.D. and M.A. in mathematics from Brandeis University and B.S. from MIT [and he] works at Microsoft Research.” Yet for all these grandiose accolades, he demonstrates a depressingly clueless understanding of his subject matter: software. In his article, he argues that we should build software like houses. In this article, I’ll detail why attempting to create applications in the same way as building houses is a really bad idea, which held back software development for decades. Further, the reality is that these days, architects are more likely to design houses using techniques pioneered by the latest software development practices. Continue reading “Why we absolutely should never build software like we build houses”

Welcome to the Church of TDD

Church of TDD

“Test Driven Development (TDD) is great. TDD is awesome. TDD will give you 100% code coverage. TDD will give you clean code. TDD is your coding saviour. Evil sinners test after they code and their code is bad. ‘Test first’ is the only one true way. You are a professional developer only if you use TDD. All bow down and worship at the alter of TDD. Oh by the way, TDD isn’t a religion. Honest.”

The above is my précis of chapter 5 of The Clean Coder by Robert C Martin. Continue reading “Welcome to the Church of TDD”

This year, I’ve mostly been shaving yaks

Shaven yak imageHopefully you are all familiar with the term “shaving a yak”. If not, take a read of Seth Godin’s succinct description of it. I was discussing the state of my AS3 enums project with my friend and colleague Richard Johnson last week. He pointed out to me that I was indulging in a textbook example of yak shaving. Continue reading “This year, I’ve mostly been shaving yaks”

AS3, DTOs, getters/ setters and good practice

Yesterday I was adding some member variables (fields) to a simple AS3 Data Transfer Object (DTO). The existing fields were all marked private and there were public get/ set methods (properties) defined for them that did nothing but read and write to the fields. I really dislike using properties in this way. I can understand why one would do so in Java, as it lacks true properties and instead has getter and setter methods. Changing from a field to those methods changes a class’ interface, which necessitates rewriting any code that uses them. In AS3 though, this problem doesn’t occur. Continue reading “AS3, DTOs, getters/ setters and good practice”

Interfaces and abstract classes: it’s all about the inheritance

This article started out as a “Should we scrap interfaces?” follow up to my previous “Did we get OO Interfaces all wrong?” article. I have been struggling with interfaces for some time now as they just don’t seem right to me. They are useful, I’d not dispute that; and they enhance OO languages, especially those that lack multiple inheritance. They just strike me as a case of semantic salt, ie the computer language semantic equivalent of syntactic salt.

Instead of risking writing another “flame bait” post though, I’ve decided to take a different tack by trying to understand the opposite view to my own. Continue reading “Interfaces and abstract classes: it’s all about the inheritance”

Exception handling: some thoughts on good practices

stop signThis article is inspired in part by Mike Hadlow’s “The first rule of exception handling: do not do exception handling” article that he wrote last year. Whilst it is simply the eye-catching title of an otherwise well considered article, to my mind it also encompasses some bad advice often given on the topic. This article is born out of a desire to “set the record straight” and offer up what I see as some exception handling “good practice.” Continue reading “Exception handling: some thoughts on good practices”