This continues my series on ways you’ve probably used design patterns in real-life and may not have even known it. The previous post was on the Adapter Design Pattern.This is a kind of “catch-all” post where I want to talk not only about the Iterator Design Pattern but also custom enumerators for Parallel.ForEach and ensuring […]
. Read more
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
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
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
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
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
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
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
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
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