49 lines
		
	
	
		
			3.5 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
		
		
			
		
	
	
			49 lines
		
	
	
		
			3.5 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| 
								 | 
							
								---
							 | 
						||
| 
								 | 
							
								title: Design Patterns
							 | 
						||
| 
								 | 
							
								---
							 | 
						||
| 
								 | 
							
								## Design Patterns
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Programmers and software architects use design patterns to solve **common, recurring problems** in software architecture. The patterns provide a language-agnostic approach to **object-oriented programming** that helps developers follow principles of good application design.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								### Why Design Patterns?
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Developing by design patterns offer several advantages:
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								* It's easier to follow good programming principles such as the **<a href='https://www.youtube.com/watch?v=XzdhzyAukMM' target='_blank' rel='nofollow'>SOLID</a> <a href='https://medium.com/@cramirez92/s-o-l-i-d-the-first-5-priciples-of-object-oriented-design-with-javascript-790f6ac9b9fa' target='_blank' rel='nofollow'>principles</a>.**
							 | 
						||
| 
								 | 
							
								* It keeps code chunks smaller so code is easier to **test** and **debug**
							 | 
						||
| 
								 | 
							
								* It helps keep code loosely coupled so code is easier to **re-use** and **update** for new applications
							 | 
						||
| 
								 | 
							
								* It makes code easier to **understand**, so new contributors can **ramp up quickly**
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Using design patterns incurs some trade-offs, and developers new to the practice should remember the following:
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								* There are **no silver bullets** in programming, and design patterns are not an exception
							 | 
						||
| 
								 | 
							
								* Design patterns add a **layer of abstraction** to code which increases initial design and development effort
							 | 
						||
| 
								 | 
							
								* Over-use of design patterns or forcing them to fit makes code **harder** to understand
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								### Language Support
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Design patterns originated from the world of statically-typed languages like C++, Java, and C#. Most resources about development by design pattern are based in one of these languages. 
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Nonetheless, design patterns are just that: patterns. They are **not implementations**, like classes or interfaces, and are **not constrained to any one language**. 
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								When learning design patterns within a dynamic language, if particular patterns seem needlessly complex or counter-intuitive, recall their origins. Developers in dynamic languages can still use and benefit from following design patterns, although more research may be required to fully understand them. 
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								### Uses
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Design patterns are excellent at solving foundational coding problems in a simple and repeatable fashion. Broadly, they fall into three categories: 
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								* **Creational** patterns describe how to create new objects
							 | 
						||
| 
								 | 
							
								* **Structural** patterns describe how to compose objects out of other objects
							 | 
						||
| 
								 | 
							
								* **Behavioral** patterns describe how objects communicate with each other
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								These tasks can all be performed without design patterns, but design patterns **reduce the risk** that you will violate good practices and create code that is hard to maintain.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								#### More Information:
							 | 
						||
| 
								 | 
							
								<!-- Please add any articles you think might be helpful to read before writing the article -->
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								* Kamran Ahmed's <a href='https://github.com/kamranahmedse/design-patterns-for-humans' target='_blank' rel='nofollow'>Design Patterns for Humans</a> is an excellent introduction to the specific patterns
							 | 
						||
| 
								 | 
							
								* <a href='https://en.wikipedia.org/wiki/Design_Patterns' target='_blank' rel='nofollow'>Design Patterns</a> is the book that started this practice
							 | 
						||
| 
								 | 
							
								* Martin Fowler's <a href='https://martinfowler.com/eaaCatalog/' target='_blank' rel='nofollow'>Patterns of Enterprise Application Architecture</a> provide a suite of more sophisticated patterns for enterprise applications
							 | 
						||
| 
								 | 
							
								* Sourcemaking provides an <a href='https://sourcemaking.com/design_patterns' target='_blank' rel='nofollow'>online resource</a> with additional examples and information about design patterns
							 |