In a recent blog on I received a comment from Wojciech SoczyĆski about how the “strategy” pattern can be used to enforce the Single Responsibility Principle (SRP) when using Tell Don't Ask (TDA). At some point I plan to discuss this further, but first thought that it would be a good idea to define the Strategy Pattern using the ShoppingCart example that I used a couple of weeks ago in my Tell Don’t Ask and its follow up Disassembling Tell Don’t Ask blogs:
Java tips, observations, bugs and problems from the world of Spring, Weblogic, Oracle, MySQL and many other technologies...
Tuesday, 27 March 2012
Thursday, 22 March 2012
A Ranking Order for Coding Priorities
In my previous blog I light-heartedly asked whether or not you should tailor your coding style to suit the business domain that you’re working in. The idea is that different business domains will demand different things from their software in terms of coding style. For example, software written for the defence market must be robust as a crash my cost lives, whilst software written for a market that under goes constant legislative changes, such as taxation, must be written for maintainability, and in advertising, where the projects and software lifespan are short then software should be written to be reusable.
Labels:
Agile,
Process,
Single Responsibility Principal (SRP),
SOLID
Tuesday, 20 March 2012
Horses For Courses
Over the years I've worked on projects in various problem domains including electricity metering, defence, taxation and banking and, if you've followed my blog over the last year or more then you may have realised that I currently work for an advertising company. In working in the advertising domain the main thing that I've noticed about projects is that they usually have shorter development timescales for a given set of functionality and, once completed, the software's natural lifespan is also fairly short. All of this got me thinking...
Labels:
Design
Thursday, 15 March 2012
Integrating Spring Into Legacy Applications
One of the things that all Spring developers like to do is to shoehorn Spring into any application they work on - it’s one of my guilty pleasures in life: you see some code, think it’s rubbish because it contains several well known anti-patterns and then think how cool it would be if this app was a Spring app.
When working with legacy code, you can’t convert it into a fully fledged Spring app over night, that takes time. What you need to do is to add Spring code a little at a time: piece by piece and there’s one good way of doing that.
When working with legacy code, you can’t convert it into a fully fledged Spring app over night, that takes time. What you need to do is to add Spring code a little at a time: piece by piece and there’s one good way of doing that.
Labels:
ApplicationContext,
Java,
Legacy,
Object Orientation,
OO,
Pattern,
Spring
Tuesday, 13 March 2012
Disassembling Tell Don't Ask
In my last blog I defined Tell Don’t Ask (TDA) using a simple shopping cart example. In it the shopping cart was responsible for working out the total cost of the items in the cart as opposed to the client asking for a list of items and then calculating the total cost itself. The TDA example is shown below:
Thursday, 8 March 2012
Defining Tell Don't Ask... well almost...
I’ve been wanting to write about ‘Tell Don’t Ask’ for some time now, mainly because it’s often espoused as the ‘right’ way to design a program and I've seen lots of Java code that doesn't use it. ‘Tell Don’t Ask’ isn’t a new idea, it’s been around for some time under other guises: in the OO world I’ve seen it called “Objects Do Things” and a long time ago when I was a Windows SDK C++ programmer it was called “Objects Aren’t structs”.
The big idea is that object A tells object B what to do and object B tells C as shown in the diagram below:
The big idea is that object A tells object B what to do and object B tells C as shown in the diagram below:
Labels:
Java,
Object Orientation,
OO,
Tell Don't Ask
Tuesday, 6 March 2012
Using Maven's -U Command Line Option
In my experience when working on a multi-model project, the developers on that project tend to grab hold of all the project’s source code and build it all using some kind of Maven build-all POM project. You know the sort of thing I mean: a build-all module is a module that contains a list of other modules that get built is a specific order. I use one to build the CaptainDebug github samples and it looks like this:
Labels:
Maven
Thursday, 1 March 2012
Configuring the Maven Tomcat Plugin
My last blog explained the relationships between Mavan life-cycles, build phases and goals from a height of about 3 miles. In explaining Maven’s goals I mentioned the tomcat:redeploy goal without really defining where it came from. Well, the answer is that the tomcat:redeploy goal isn’t a default goal or part of the default Maven installation, it’s part of the tomcat-maven-plugin.
Labels:
Integration Tests,
Maven,
POM,
Tomcat
Subscribe to:
Posts (Atom)