Adapter Design Pattern – A Real World Example

I think the simplest design pattern we’ve all used without really calling it a pattern, other than observer, is the adapter design pattern. The adapter design pattern is known more colloquially as a wrapper where you wrap a bunch of functionality from one or more classes into a single class because of incompatibilities between the […]

.

Read more

Observer and Command Design Patterns – A Real World Example

Up next in my series on ways you’ve probably used design patterns in real-life and may not have even known it, the Observer and Command design patterns. This continues on from my post Composite and Memento Design Patterns – A Real World Example. Command pattern is meant to actually decouple the GUI and back-end code. […]

.

Read more

Composite and Memento Design Patterns – A Real World Example

So you don’t need to know software design patterns. But, as I hope got across in my post, knowing and understanding patterns can only benefit you. I wanted to put together a real-life example of some of the instances where I’ve used patterns, even if the use of the patterns was unintentional. Hopefully you will […]

.

Read more

Binding a Dependency Property of a View to its ViewModel

UPDATE 07/30/2014:Please be sure to check out the second part to this at Binding a Dependency Property of a View to its ViewModel, part Deux which contains a working sample solution of the code here. I like MVVM in concept and I had prepared a long, off-topic rant about MVVM because of a bit of […]

.

Read more

SOLID – The Summary

Here is the list of all the posts in my series on SOLID. SOLID – Getting Started and Source MaterialSOLID – (SRP) The Single Responsibility PrincipleSOLID – (SRP) Ignoring the rules on the paint canSOLID – (OCP) The Open-Closed PrincipleSOLID – (LSP) The Liskov Substitution PrincipleSOLID – (ISP) The Interface Segregation PrincipleSOLID – (DIP) The […]

.

Read more

SOLID – (DIP) The Dependency Inversion Principle

Previous post in this series:SOLID – (ISP) The Interface Segregation Principle A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS. The Dependency Inversion Principle, Robert C. Martin The DIP is part and parcel with the OCP […]

.

Read more

SOLID – (ISP) The Interface Segregation Principle

Previous post in this series:SOLID – (LSP) The Liskov Substitution Principle CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE. When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all […]

.

Read more

SOLID – (LSP) The Liskov Substitution Principle

Previous post in this series:SOLID – (OCP) The Open-Closed Principle FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT. The importance of this principle becomes obvious when you consider the consequences of violating it. If there is a function which does not conform […]

.

Read more

SOLID – (OCP) The Open-Closed Principle

Previous post in this series:SOLID – SRP – Ignoring the rules on the paint can SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have […]

.

Read more

SOLID – SRP – Ignoring the rules on the paint can

Previous post in this series:SOLID – (SRP) The Single Responsibility Principle Some of my source links in the previous two posts may not have worked in FireFox (but worked fine in IE and Chrome). These links have been fixed. It was an issue with how google was handling the redirects to the source files. In […]

.

Read more
FormatException

928 East Plymouth Drive Asbury Park, NJ 07712