191 reputation
2
bio website
location United Kingdom
age 39
visits member for 3 years, 10 months
seen Aug 13 at 22:40

I'm a Senior Software Engineer, currently based near Newcastle (England) and working remotely for a company based in Fife (Scotland).

I've been programming professionally since 1997 in the usual variety of languages (C, C++, C#, Java, Python, VB, HTML/CSS, etc) working on everything from low-level bit-bashing device drivers and microprocessor-based firmware for safety-critical medical devices, up to full Windows applications and enterprise systems.

I hate cucumbers.

If you're interested then here is my linkedin.com profile.


Feb
18
comment When should I use—and not use—design patterns?
@luis.espinal: as I said at the start, forcing code into a pattern is bad, so is treating patterns as cookie cutters or magic hammers. But, perhaps because of these bad practises, there are a people here trying to distance themselves by claiming they "don't use design patterns" when they clearly do. You can call it a "protocol" if you like, but if you use your experience to recognise a design situation you've seen before, apply a solution you've used before, and refer to your approach by a name that your team understand then that is using a design pattern. Even if it isn't in GoF!
Feb
18
awarded  Nice Answer
Feb
18
comment When should I use—and not use—design patterns?
@Michael: what I'd want is for them to recognise they need a stack and use the language/library implementation, not write their own buggy MyLiFoDataTypeThing from scratch and then later realise it is just a stack. So likewise I'd rather someone recognised an Observer pattern and used a standard library implementation, rather than write their own ad hoc version.
Feb
18
comment When should I use—and not use—design patterns?
@Nemanja: "In your example, I would just write an observer the same way I did before the GoF book was even published" - you are aware of the pattern, when to use it and a standard implementation. Plus you would use it as shorthand to describe the code to other people. So basically you are using design patterns then - even if your own pride refuses to admit it. :)
Feb
18
awarded  Teacher
Feb
18
comment When should I use—and not use—design patterns?
@Geoffrey: yes, my point exactly, well said. Also many pattern sceptics actually use them all the time, but just don't give them names.
Feb
18
comment When should I use—and not use—design patterns?
@Namanja: I'm just not convinced that approach makes sense. For example, say I want to write an object that has a state and other objects that may be interested when that state changes. A coder that knows patterns will immediately start thinking: "Does the Observer pattern fit well here?". If it does then they have a well-known implementation and probably supporting library classes to use. Meanwhile Mr KISS Approach will still be handcrafting a bespoke design that probably couples all the classes together and leaves them in a tight tangle that is difficult to unit test later.
Feb
18
comment When should I use—and not use—design patterns?
@El Ronnoco: I didn't mean to imply that they are only used verbally. They could equally be used in design documents, class/object names, or comments in the code. The point is that design patterns are primarily a communication tool and they are successful when they enhance understanding within the team.
Feb
18
comment When should I use—and not use—design patterns?
While I agree that code should never be "forced" into patterns, I disagree that code should be written first and Design Patterns applied as an afterthought. A good working knowledge of the patterns will actually help to KISS, as it saves inventing your own homebrew (probably broken) solutions to well-known problems. To me it is analogous to abstract data types: every coder should know what a stack, list and queue are and recognise when it is appropriate to use them - I wouldn't expect them to write code first and then say "Oh I could have just used a Stack there."
Feb
18
comment When should I use—and not use—design patterns?
GoF is very dry and quite dense. Sad to say, but the "Head First Design Patterns" is a far better introduction to the subject (despite its "For Dummies" aesthetic).
Feb
18
answered When should I use—and not use—design patterns?