Showing posts with label patterns. Show all posts
Showing posts with label patterns. Show all posts

Sunday, 19 June 2016

Anti-If: The missing patterns

Anti-If: The missing patterns: "If statements usually make your code more complicated. But we don’t want to outright ban them. I’ve seen some pretty heinous code created with the goal of removing all traces of if statements. We want to avoid falling into that trap.

For each pattern we’ll read about I’m going to give you a tolerance value for when to use it.

A single if statement which isn’t duplicated anywhere else is probably fine. It’s when you have duplicated if statements that you want your spider sense to be tingling.

At the outside of your code base, where you talk to the dangerous outside world, you are going to want to validate incoming responses and change your beahaviour accordingly. But inside our own codebases, where we behind those trusted gatekeepers, I think we have a great opportunity to use simple, richer and more powerful alternatives."



'via Blog this'

Friday, 17 June 2016

Don't Get Obsessed With Design Patterns - Simple Programmer

Don't Get Obsessed With Design Patterns - Simple Programmer:



"The cost of adding a design pattern

There are many different design patterns, but most of them have something in common: when you apply them, you need to lay out some structure. In other words, you need to add classes and/or interfaces to the code.

In the first example, this structure consists of an abstract class extended by two children classes. What’s more, in order for the old code to use these new classes, you also need to make some updates not directly related to the design pattern itself.

The moral of the story is: if you’re thinking about applying a design pattern, consider the cost of doing so and the potential benefit. Doing it only for the sake of doing it will make your code more complex than it needs to be."



'via Blog this'

Wednesday, 4 May 2016

Gang of Four Patterns in a Functional Light: Part 2 | Voxxed

Gang of Four Patterns in a Functional Light: Part 2 | Voxxed: "In this second part, we will continue this process and revisit two other widely used GoF patterns: the Template and the Observer patterns, which can both be reimplemented through the Java 8 Consumer interface."



'via Blog this'

Wednesday, 20 May 2015

State and Strategy patterns

http://en.wikipedia.org/wiki/State_pattern

The state pattern, which closely resembles Strategy Pattern, is a behavioral software design pattern, also known as the objects for states pattern. This pattern is used incomputer programming to encapsulate varying behavior for the same object based on its internal state. This can be a cleaner way for an object to change its behavior at runtime without resorting to large monolithic conditional statements[1]:395 and thus improve maintainability.