The document discusses refactoring applications using SOLID principles. It covers how software can deteriorate over time through duplication, excess coupling, quick fixes, and hacks. It advocates using preventative maintenance through refactoring to eliminate duplication and simplify design, as well as automated tests to verify correctness and avoid regressions. The document outlines the refactoring process and introduces characterization tests. It then covers each SOLID principle - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion - and provides examples of how to apply them through various refactorings.
Refactoring with SOLID Principles (FalafelCon 2013)Steven Smith
We’ve all heard about well-designed software projects, where things aren’t (yet) a big ball of mud that’s painful to work with, but many of us aren’t lucky enough to work on these. Nor is it an option for us to get to start a brand new “greenfield” project, where we can leave behind the legacy of spaghetti code and technical debt our current project might have.
But there is hope! By applying refactoring steps based on SOLID principles of object oriented design, we can reduce the technical debt of our existing application, improve our code quality, and hopefully make our application more enjoyable and productive to work with.
In this session, we’ll briefly introduce the SOLID principles and several design patterns, and then we’ll apply these principles and patterns by improving the design of an existing application through several refactoring steps.
Breaking Dependencies to Allow Unit Testing - DevIntersection Spring 2016Steven Smith
Unit testing software can be difficult, especially when the software wasn't designed to be testable. Dependencies on infrastructure concerns and software we don't control are one of the biggest contributors to testing difficulty. In this session, you'll learn the difference between unit tests and other kinds of tests, how to recognize and invert dependencies, and how to unit test your code's interactions with these dependencies without testing the infrastructure itself.
Improving the Quality of Existing SoftwareSteven Smith
Given at DogFoodCon 2016 in Columbus, Ohio
As developers, most of our time is spent working on existing software – even if it’s just the software we wrote ourselves, yesterday. And over time, software rots. If were not diligent, our beautiful code can degrade into a worthless mess. Keeping our code in working condition is no different than changing the oil in our car “ its preventive maintenance. In this session, Steve will cover some common places to look for signs of degradation in existing applications, and describe the steps we can take to improve our code. Examples will use C# and primarily ASP.NET.
The document provides an overview of the Spring framework and instructions for setting up a simple Spring example project in Eclipse. It introduces the core concepts of Spring including dependency injection and inversion of control. It then demonstrates a simple example where two shape classes (Rectangle and Circle) implement a Shape interface and are configured as Spring beans in an XML file. A driver class loads the configuration file and retrieves the shape objects by name to loosely couple the code from the specific shape implementations.
Improving the Quality of Existing Software - DevIntersection April 2016Steven Smith
How do you improve the quality of your existing software, while continuing to add value for your customers? What are some heuristics and code smells you can look for, and principles and patterns you can use to guide you, as you make your software better over time instead of worse? How can we improve our skills and techniques so that writing high quality software becomes our default, fastest way of working?
Waaaaay back in the mid-2000s I did a bunch of presentations on unit testing, test driven development, and so on. I offer this slide deck in memory of those days (and ah the relative simplicity of those Powerpoint themes, mine anyway). You might still find this useful.
Improving the Quality of Existing SoftwareSteven Smith
How do you improve the quality of your existing software, while continuing to add value for your customers? What are some heuristics and code smells you can look for, and principles and patterns you can use to guide you, as you make your software better over time instead of worse?
I used this small slide deck on July 3 2018 for my Ask TOM Office Hours session on dynamic SQL. You can watch the recording here: https://devgym.oracle.com/pls/apex/dg/office_hours/4486
Refactoring with SOLID Principles (FalafelCon 2013)Steven Smith
We’ve all heard about well-designed software projects, where things aren’t (yet) a big ball of mud that’s painful to work with, but many of us aren’t lucky enough to work on these. Nor is it an option for us to get to start a brand new “greenfield” project, where we can leave behind the legacy of spaghetti code and technical debt our current project might have.
But there is hope! By applying refactoring steps based on SOLID principles of object oriented design, we can reduce the technical debt of our existing application, improve our code quality, and hopefully make our application more enjoyable and productive to work with.
In this session, we’ll briefly introduce the SOLID principles and several design patterns, and then we’ll apply these principles and patterns by improving the design of an existing application through several refactoring steps.
Breaking Dependencies to Allow Unit Testing - DevIntersection Spring 2016Steven Smith
Unit testing software can be difficult, especially when the software wasn't designed to be testable. Dependencies on infrastructure concerns and software we don't control are one of the biggest contributors to testing difficulty. In this session, you'll learn the difference between unit tests and other kinds of tests, how to recognize and invert dependencies, and how to unit test your code's interactions with these dependencies without testing the infrastructure itself.
Improving the Quality of Existing SoftwareSteven Smith
Given at DogFoodCon 2016 in Columbus, Ohio
As developers, most of our time is spent working on existing software – even if it’s just the software we wrote ourselves, yesterday. And over time, software rots. If were not diligent, our beautiful code can degrade into a worthless mess. Keeping our code in working condition is no different than changing the oil in our car “ its preventive maintenance. In this session, Steve will cover some common places to look for signs of degradation in existing applications, and describe the steps we can take to improve our code. Examples will use C# and primarily ASP.NET.
The document provides an overview of the Spring framework and instructions for setting up a simple Spring example project in Eclipse. It introduces the core concepts of Spring including dependency injection and inversion of control. It then demonstrates a simple example where two shape classes (Rectangle and Circle) implement a Shape interface and are configured as Spring beans in an XML file. A driver class loads the configuration file and retrieves the shape objects by name to loosely couple the code from the specific shape implementations.
Improving the Quality of Existing Software - DevIntersection April 2016Steven Smith
How do you improve the quality of your existing software, while continuing to add value for your customers? What are some heuristics and code smells you can look for, and principles and patterns you can use to guide you, as you make your software better over time instead of worse? How can we improve our skills and techniques so that writing high quality software becomes our default, fastest way of working?
Waaaaay back in the mid-2000s I did a bunch of presentations on unit testing, test driven development, and so on. I offer this slide deck in memory of those days (and ah the relative simplicity of those Powerpoint themes, mine anyway). You might still find this useful.
Improving the Quality of Existing SoftwareSteven Smith
How do you improve the quality of your existing software, while continuing to add value for your customers? What are some heuristics and code smells you can look for, and principles and patterns you can use to guide you, as you make your software better over time instead of worse?
I used this small slide deck on July 3 2018 for my Ask TOM Office Hours session on dynamic SQL. You can watch the recording here: https://devgym.oracle.com/pls/apex/dg/office_hours/4486
Refactoring Applications using SOLID PrinciplesSteven Smith
We’ve all heard about well-designed software projects, where things aren’t (yet) a big ball of mud that’s painful to work with, but many of us aren’t lucky enough to work on these. Nor is it an option for us to get to start a brand new “greenfield” project, where we can leave behind the legacy of spaghetti code and technical debt our current project might have.
But there is hope! By applying refactoring steps based on SOLID principles of object oriented design, we can reduce the technical debt of our existing application, improve our code quality, and hopefully make our application more enjoyable and productive to work with.
In this session, we’ll briefly introduce the SOLID principles and several design patterns, and then we’ll apply these principles and patterns by improving the design of an existing application through several refactoring steps.
Improving the Design of Existing SoftwareSteven Smith
The document discusses improving the design of existing software by following principles like DRY, SOLID, and refactoring code using techniques such as extracting classes, methods, and interfaces. It emphasizes writing characterization tests to preserve existing behavior when refactoring, and improving code quality by reducing duplication, dependencies, and complexity over time through preventative maintenance and refactoring.
Improving The Quality of Existing SoftwareSteven Smith
Presented at DevReach 2013.
As developers, most of our time is spent working on existing software. Sure, occasionally we get the chance to fire up a new Solution in Visual Studio, and that can be exciting. But after the first day, we find ourselves once more having to deal with the work we did yesterday. And today, we know more than we did yesterday, so there are things we’d do differently, if we had it to do over.
Over time, software rots. If we’re not diligent, our beautiful code can degrade into a worthless mess. Keeping our code in working condition is no different than changing the oil in our car – it’s preventive maintenance. In this session, Steve will look at some common places to look for signs of degradation in existing applications, and steps to take to improve the code. Examples will use C# and primarily ASP.NET.
Improving the Quality of Existing SoftwareSteven Smith
The document discusses techniques for improving the quality of existing software, including reducing technical debt, following principles like DRY and SOLID, using characterization tests to preserve behavior during refactoring, and improving skills to write higher quality code faster. It covers topics like refactoring, test-driven development, dependency inversion, and design patterns. The goal is to maintain and enhance application code quality over time through refactoring and preventing technical debt.
Design patterns provide common templates for solving similar problems. They also provide a higher-level language for software developers to use to describe approaches they might choose when designing part of an application. This session introduces and applies several patterns useful to web application developers. Examples will primarily use C#/.NET.
Design Pattern Mastery - Momentum Dev Con 19 Apr 2018Steven Smith
Design patterns help developers and teams solve problems using proven approaches. In this talk, you'll learn how to solve a series of real world problems by applying patterns. Not only do patterns help individual developers solve particular problems, but they also enable teams to discuss design decisions using a richer, more descriptive language. By the end, you'll have some concrete tools you can apply, and hopefully the desire to master more patterns as you continue to improve!
This document discusses object oriented design principles. It begins with an introduction and agenda. It then covers several object oriented design principles including the open-closed principle, single responsibility principle, interface segregation principle, Liskov substitution principle, and dependency inversion principle. Examples are provided for each. It also discusses bad designs, anti-patterns, and some "evil stuff" to avoid like singletons. The document concludes with a review of key principles like encapsulation, composition over inheritance, programming to interfaces, and loose coupling.
The document discusses Clean Architecture, an architectural pattern for software design. It aims to facilitate maintainability, technical agility, and independent development. Clean Architecture prescribes separating an application into distinct layers - entities, use cases, interfaces, and entry points. This separation aims to make codebases independent of frameworks and easily testable. The document outlines principles like SOLID and DRY, and patterns like layered architecture and MVC that influence Clean Architecture. It provides tips for migrating existing applications to this architecture.
The document provides an overview of Spring concepts including annotations, MVC, dependency injection, bean management, and unit testing. It also covers Spring modules, inversion of control, bean scopes, wiring beans, Spring MVC, form validation, pre-populating models, and Spring Security. Code examples demonstrate CRUD operations using Spring, Hibernate and MySQL as well as Spring Security configuration. The document concludes with exercises on bean scopes and annotations.
This document discusses the principles and structure of Clean Architecture for ASP.NET Core applications. It recommends separating an application into projects for the core domain logic, infrastructure implementation, and user interface. The core project defines interfaces that outer projects implement, avoiding direct dependencies. This allows for independence of frameworks, databases, and user interfaces. The document provides examples of project structure and responsibilities, and resources for further learning clean architecture principles.
How to ace your .NET technical interview :: .Net Technical Check TuneupBala Subra
This session is just not a brain dump of a technical interview on Microsoft technologies. It will be refresher on various pieces of the .NET, Database, OO, Process world. It will serve as a caution for interviewers to red flag their questions which are circulated on the webdom. For all the inquisitive and MCP certified brains, this will serve as a ‘whodunnit’ challenge. It will be a useful reference for the rest of us. The talk is divided into four sections. We will cover the typical BrainBench type questions to start with. Then we will attack the common problems encountered on the field and ideal solution paths to each of them. Third part will be about architectural trade-offs and ‘it depends’ scenarios. Finally, there will be discussion on best practices, books needed for interview preparation and open Q&A among the participants.
I gotta dependency on dependency injectionmhenroid
Satisfy your desire to be a better software developer by learning how to implement Dependency Injection (DI) in your application. Dependency Injection is one of the more popular implementations of Inversion of Control (IoC) that helps to increase modularity and extensibility of software. In this lecture, we'll discuss the benefits of DI, methods for implementing and refactoring existing code to use DI, adding unit tests using MSTest and Moq, popular DI frameworks like Unity, Ninject, and Castle Windsor, as well as alternative IoC patterns and anti-patterns.
This slide deck is about the production-readiness of software. First it explains why production-ready is more important than just feature-complete.
Then it takes a quick detour to DevOps. It explains the core ideas of DevOps and how this talks relates to the concepts of DevOps (by simulating the feedback loop from ops to dev while the wall between dev and ops still exists).
After this detour the needs of the administrators from the ops department are briefly described and the challenges that arise from that for developers who want to provide production-ready software.
Based on those challenges a selection of design principles are described (mostly in terms of topics to take care of in the design and implementation process). While not being complete by far, taking care of the topics described on these slides are a huge step towards production-ready software based on my experience.
Of course all the information from the voice track is missing, it is slides only. Even though the slides just carry a fraction of the information, I hope they will still contain some good pointers for you that help you to create better production-ready software.
Linear layouts are more efficient than relative or absolute layouts for list items. Relative layouts are more flexible but also more expensive to render. Developers should use tools like LayoutOpt and TraceView to optimize layout hierarchies and identify performance bottlenecks. ProGuard can also help by removing unused code and optimizing code size.
Breaking Dependencies to Allow Unit TestingSteven Smith
Unit testing software can be difficult, especially when the software wasn't designed to be testable. Dependencies on infrastructure concerns and software we don't control are one of the biggest contributors to testing difficulty. In this session, you'll learn the difference between unit tests and other kinds of tests, how to recognize and invert dependencies, and how to unit test your code's interactions with these dependencies without testing the infrastructure itself.
Common ASP.NET Design Patterns - Telerik India DevCon 2013Steven Smith
This document provides an overview of common ASP.NET design patterns, including Singleton, Strategy, Repository, Proxy, Command, and Factory patterns. It discusses the intent, structure, and usage of each pattern. Code examples and references are also provided. Real-world examples are discussed to demonstrate how design patterns can be used to address issues like tight coupling and improve code quality during refactoring or initial design.
Machine Learning is increasingly being used by companies as a disruptor or providing a USP. This means that Machine Learning models need to cope with being a critical part of solutions and if those solutions use PCI-DSS or PII then the models must be highly secure.
In addition, if a Machine Learning model is part of your USP then you will want to protect it. Also, the EU AI Regulation and UK AI Strategy means that AI is becoming increasingly regulated. This means you need to be able to prove what model made a prediction and why it made it by providing auditability and explainabilty.
In this talk we go over these issues and how to address them including using AWS and how to implement development best practices.
Lublin Startup Festival - Mobile Architecture Design PatternsKarol Szmaj
This document discusses mobile app development architecture and design patterns. It covers the out-of-the-box approach using code behind, the model-view-viewmodel (MVVM) pattern, inversion of control (IOC), and command query responsibility segregation (CQRS). It also discusses tools like Fody, Polly, and Cimbalino Toolkit. Tips are provided on using universal apps, Windows 10 XAML, and developing cross-platform with Xamarin. The presentation ends with an invitation for questions.
The document discusses object-oriented design principles and patterns. It covers topics like encapsulation, inheritance, polymorphism, the open-closed principle (OCP), dependency inversion, and architectural patterns like layered architectures and domain-driven design. Examples are provided to illustrate concepts like dependency injection and inversion of control. The conclusion emphasizes applying principles pragmatically based on user needs while aiming for maintainable code.
Clean architecture with asp.net core by ArdalisSteven Smith
Clean Architecture with ASP.NET Core
ASP.NET Core provides better support for clean, testable, maintainable architectures than any of its predecessors. Learn the underlying principles that apply to project/solution organization, how best to arrange your projects to support clean code, and how to refactor existing solutions toward this architecture. Examples will use ASP.NET Core but the principles covered apply to all languages and platforms.
About Steve
Steve Smith (@ardalis) is an entrepreneur and software developer with a passion for building quality software as effectively as possible. Steve has published several courses on Pluralsight, covering DDD, SOLID, design patterns, and software architecture. He’s a Microsoft ASP.NET MVP and Insider, a frequent speaker at developer conferences, an author, and a trainer. Steve works with companies that want to avoid the trap of technical debt by helping their teams deliver quality software, quickly. Steve and his team have been described by clients as a “force multiplier”, amplifying the value of existing development teams. Steve’s client list includes Microsoft, Quicken Loans, Celina Insurance, and many other satisfied customers.
Finding Patterns in the Clouds - Cloud Design PatternsSteven Smith
The document discusses the evolution of web application architectures from single server deployments to modern cloud-native microservice architectures. It covers how early web apps faced challenges as demand grew that led to adopting caching, load balancing, and the cloud. It then discusses how further scaling issues were addressed through containers, microservices, and patterns like API gateways and circuit breakers. Key lessons are around adopting cloud-native patterns to improve performance, scalability, resilience and developer productivity for applications.
More Related Content
Similar to Refactoring with SOLID - Telerik India DevCon 2013
Refactoring Applications using SOLID PrinciplesSteven Smith
We’ve all heard about well-designed software projects, where things aren’t (yet) a big ball of mud that’s painful to work with, but many of us aren’t lucky enough to work on these. Nor is it an option for us to get to start a brand new “greenfield” project, where we can leave behind the legacy of spaghetti code and technical debt our current project might have.
But there is hope! By applying refactoring steps based on SOLID principles of object oriented design, we can reduce the technical debt of our existing application, improve our code quality, and hopefully make our application more enjoyable and productive to work with.
In this session, we’ll briefly introduce the SOLID principles and several design patterns, and then we’ll apply these principles and patterns by improving the design of an existing application through several refactoring steps.
Improving the Design of Existing SoftwareSteven Smith
The document discusses improving the design of existing software by following principles like DRY, SOLID, and refactoring code using techniques such as extracting classes, methods, and interfaces. It emphasizes writing characterization tests to preserve existing behavior when refactoring, and improving code quality by reducing duplication, dependencies, and complexity over time through preventative maintenance and refactoring.
Improving The Quality of Existing SoftwareSteven Smith
Presented at DevReach 2013.
As developers, most of our time is spent working on existing software. Sure, occasionally we get the chance to fire up a new Solution in Visual Studio, and that can be exciting. But after the first day, we find ourselves once more having to deal with the work we did yesterday. And today, we know more than we did yesterday, so there are things we’d do differently, if we had it to do over.
Over time, software rots. If we’re not diligent, our beautiful code can degrade into a worthless mess. Keeping our code in working condition is no different than changing the oil in our car – it’s preventive maintenance. In this session, Steve will look at some common places to look for signs of degradation in existing applications, and steps to take to improve the code. Examples will use C# and primarily ASP.NET.
Improving the Quality of Existing SoftwareSteven Smith
The document discusses techniques for improving the quality of existing software, including reducing technical debt, following principles like DRY and SOLID, using characterization tests to preserve behavior during refactoring, and improving skills to write higher quality code faster. It covers topics like refactoring, test-driven development, dependency inversion, and design patterns. The goal is to maintain and enhance application code quality over time through refactoring and preventing technical debt.
Design patterns provide common templates for solving similar problems. They also provide a higher-level language for software developers to use to describe approaches they might choose when designing part of an application. This session introduces and applies several patterns useful to web application developers. Examples will primarily use C#/.NET.
Design Pattern Mastery - Momentum Dev Con 19 Apr 2018Steven Smith
Design patterns help developers and teams solve problems using proven approaches. In this talk, you'll learn how to solve a series of real world problems by applying patterns. Not only do patterns help individual developers solve particular problems, but they also enable teams to discuss design decisions using a richer, more descriptive language. By the end, you'll have some concrete tools you can apply, and hopefully the desire to master more patterns as you continue to improve!
This document discusses object oriented design principles. It begins with an introduction and agenda. It then covers several object oriented design principles including the open-closed principle, single responsibility principle, interface segregation principle, Liskov substitution principle, and dependency inversion principle. Examples are provided for each. It also discusses bad designs, anti-patterns, and some "evil stuff" to avoid like singletons. The document concludes with a review of key principles like encapsulation, composition over inheritance, programming to interfaces, and loose coupling.
The document discusses Clean Architecture, an architectural pattern for software design. It aims to facilitate maintainability, technical agility, and independent development. Clean Architecture prescribes separating an application into distinct layers - entities, use cases, interfaces, and entry points. This separation aims to make codebases independent of frameworks and easily testable. The document outlines principles like SOLID and DRY, and patterns like layered architecture and MVC that influence Clean Architecture. It provides tips for migrating existing applications to this architecture.
The document provides an overview of Spring concepts including annotations, MVC, dependency injection, bean management, and unit testing. It also covers Spring modules, inversion of control, bean scopes, wiring beans, Spring MVC, form validation, pre-populating models, and Spring Security. Code examples demonstrate CRUD operations using Spring, Hibernate and MySQL as well as Spring Security configuration. The document concludes with exercises on bean scopes and annotations.
This document discusses the principles and structure of Clean Architecture for ASP.NET Core applications. It recommends separating an application into projects for the core domain logic, infrastructure implementation, and user interface. The core project defines interfaces that outer projects implement, avoiding direct dependencies. This allows for independence of frameworks, databases, and user interfaces. The document provides examples of project structure and responsibilities, and resources for further learning clean architecture principles.
How to ace your .NET technical interview :: .Net Technical Check TuneupBala Subra
This session is just not a brain dump of a technical interview on Microsoft technologies. It will be refresher on various pieces of the .NET, Database, OO, Process world. It will serve as a caution for interviewers to red flag their questions which are circulated on the webdom. For all the inquisitive and MCP certified brains, this will serve as a ‘whodunnit’ challenge. It will be a useful reference for the rest of us. The talk is divided into four sections. We will cover the typical BrainBench type questions to start with. Then we will attack the common problems encountered on the field and ideal solution paths to each of them. Third part will be about architectural trade-offs and ‘it depends’ scenarios. Finally, there will be discussion on best practices, books needed for interview preparation and open Q&A among the participants.
I gotta dependency on dependency injectionmhenroid
Satisfy your desire to be a better software developer by learning how to implement Dependency Injection (DI) in your application. Dependency Injection is one of the more popular implementations of Inversion of Control (IoC) that helps to increase modularity and extensibility of software. In this lecture, we'll discuss the benefits of DI, methods for implementing and refactoring existing code to use DI, adding unit tests using MSTest and Moq, popular DI frameworks like Unity, Ninject, and Castle Windsor, as well as alternative IoC patterns and anti-patterns.
This slide deck is about the production-readiness of software. First it explains why production-ready is more important than just feature-complete.
Then it takes a quick detour to DevOps. It explains the core ideas of DevOps and how this talks relates to the concepts of DevOps (by simulating the feedback loop from ops to dev while the wall between dev and ops still exists).
After this detour the needs of the administrators from the ops department are briefly described and the challenges that arise from that for developers who want to provide production-ready software.
Based on those challenges a selection of design principles are described (mostly in terms of topics to take care of in the design and implementation process). While not being complete by far, taking care of the topics described on these slides are a huge step towards production-ready software based on my experience.
Of course all the information from the voice track is missing, it is slides only. Even though the slides just carry a fraction of the information, I hope they will still contain some good pointers for you that help you to create better production-ready software.
Linear layouts are more efficient than relative or absolute layouts for list items. Relative layouts are more flexible but also more expensive to render. Developers should use tools like LayoutOpt and TraceView to optimize layout hierarchies and identify performance bottlenecks. ProGuard can also help by removing unused code and optimizing code size.
Breaking Dependencies to Allow Unit TestingSteven Smith
Unit testing software can be difficult, especially when the software wasn't designed to be testable. Dependencies on infrastructure concerns and software we don't control are one of the biggest contributors to testing difficulty. In this session, you'll learn the difference between unit tests and other kinds of tests, how to recognize and invert dependencies, and how to unit test your code's interactions with these dependencies without testing the infrastructure itself.
Common ASP.NET Design Patterns - Telerik India DevCon 2013Steven Smith
This document provides an overview of common ASP.NET design patterns, including Singleton, Strategy, Repository, Proxy, Command, and Factory patterns. It discusses the intent, structure, and usage of each pattern. Code examples and references are also provided. Real-world examples are discussed to demonstrate how design patterns can be used to address issues like tight coupling and improve code quality during refactoring or initial design.
Machine Learning is increasingly being used by companies as a disruptor or providing a USP. This means that Machine Learning models need to cope with being a critical part of solutions and if those solutions use PCI-DSS or PII then the models must be highly secure.
In addition, if a Machine Learning model is part of your USP then you will want to protect it. Also, the EU AI Regulation and UK AI Strategy means that AI is becoming increasingly regulated. This means you need to be able to prove what model made a prediction and why it made it by providing auditability and explainabilty.
In this talk we go over these issues and how to address them including using AWS and how to implement development best practices.
Lublin Startup Festival - Mobile Architecture Design PatternsKarol Szmaj
This document discusses mobile app development architecture and design patterns. It covers the out-of-the-box approach using code behind, the model-view-viewmodel (MVVM) pattern, inversion of control (IOC), and command query responsibility segregation (CQRS). It also discusses tools like Fody, Polly, and Cimbalino Toolkit. Tips are provided on using universal apps, Windows 10 XAML, and developing cross-platform with Xamarin. The presentation ends with an invitation for questions.
The document discusses object-oriented design principles and patterns. It covers topics like encapsulation, inheritance, polymorphism, the open-closed principle (OCP), dependency inversion, and architectural patterns like layered architectures and domain-driven design. Examples are provided to illustrate concepts like dependency injection and inversion of control. The conclusion emphasizes applying principles pragmatically based on user needs while aiming for maintainable code.
Clean architecture with asp.net core by ArdalisSteven Smith
Clean Architecture with ASP.NET Core
ASP.NET Core provides better support for clean, testable, maintainable architectures than any of its predecessors. Learn the underlying principles that apply to project/solution organization, how best to arrange your projects to support clean code, and how to refactor existing solutions toward this architecture. Examples will use ASP.NET Core but the principles covered apply to all languages and platforms.
About Steve
Steve Smith (@ardalis) is an entrepreneur and software developer with a passion for building quality software as effectively as possible. Steve has published several courses on Pluralsight, covering DDD, SOLID, design patterns, and software architecture. He’s a Microsoft ASP.NET MVP and Insider, a frequent speaker at developer conferences, an author, and a trainer. Steve works with companies that want to avoid the trap of technical debt by helping their teams deliver quality software, quickly. Steve and his team have been described by clients as a “force multiplier”, amplifying the value of existing development teams. Steve’s client list includes Microsoft, Quicken Loans, Celina Insurance, and many other satisfied customers.
Finding Patterns in the Clouds - Cloud Design PatternsSteven Smith
The document discusses the evolution of web application architectures from single server deployments to modern cloud-native microservice architectures. It covers how early web apps faced challenges as demand grew that led to adopting caching, load balancing, and the cloud. It then discusses how further scaling issues were addressed through containers, microservices, and patterns like API gateways and circuit breakers. Key lessons are around adopting cloud-native patterns to improve performance, scalability, resilience and developer productivity for applications.
Introducing domain driven design - dogfood con 2018Steven Smith
DDD provides a set of patterns and practices for tackling complex business problems with software models. Learn the basics of DDD in this session, including several principles and patterns you can start using immediately even if your project hasn't otherwise embraced DDD. Examples will primarily use C#/.NET.
Introducing Domain Driven Design - codemashSteven Smith
DDD provides a set of patterns and practices for tackling complex business problems with software models. Learn the basics of DDD in this session, including several principles and patterns you can start using immediately even if your project hasn't otherwise embraced DDD. Examples will primarily use C#/.NET.
Given at DogFoodCon 2016 in Columbus, Ohio
Domain Events, a Domain-Driven Design (DDD) pattern, provide a way to decouple your code. Rather than hard-coding a series of steps that must be completed in response to a particular action a user takes, that action can raise an event. Handlers for an event can be added without changing the code responsible for raising the event, resulting in a more extensible design. Coupled with SignalR or push notifications in the UI layer, domain events can trigger live updates, even to web-based applications and mobile apps.
ASP.NET 5 has been redesigned with an emphasis on speed, composability, and cross-platform support. The new ASP.NET is leaner, faster, open source, and fixes many of the inconsistencies and problems present in ASP.NET today.
Domain Events, a Domain-Driven Design (DDD) pattern, provide a way to decouple your code. Rather than hard-coding a series of steps that must be completed in response to a particular action a user takes, that action can raise an event. Handlers for that event can be added without changing the code responsible for raising the event, resulting in a more extensible design. Coupled with SignalR in the UI layer, domain events can trigger updates to the application without the user having to refresh the application.
My 2004 deployment to Iraq and missions as a combat engineer platoon leader in support of EOD missions. Presented to Ravenna, Ohio Daughters of the American Revolution chapter 18 October 2014
This document discusses Domain-Driven Design (DDD) and how it can be applied to ASP.NET MVC projects. It covers DDD concepts like ubiquitous language, bounded contexts, entities, value objects, domain services, and domain events. It also discusses how to structure an MVC project to separate the domain model from the rest of the application using patterns like layered architecture and ports and adapters. The document argues that DDD can provide benefits like flexibility, manageable complexity, and centralized business logic, though it may require more time and effort to implement.
Breaking Dependencies to Allow Unit TestingSteven Smith
Unit testing software can be difficult, especially when the software wasn't designed to be testable. Dependencies on infrastructure concerns and software we don't control are one of the biggest contributors to testing difficulty. In this session, you'll learn the difference between unit tests and other kinds of tests, how to recognize and invert dependencies, and how to unit test your code's interactions with these dependencies without testing the infrastructure itself.
Presented at FalafelCON 2014, San Francisco, September 2014
Common asp.net design patterns aspconf2012Steven Smith
This document discusses common ASP.NET design patterns. It provides an overview of several design patterns including singleton, factory, repository, dependency injection, and MVC. It also demonstrates these patterns in code examples and discusses when to use certain patterns over others. Real world examples are given and it encourages the use of design patterns to reduce coupling and improve code organization, testability, and maintenance.
Pair programming involves two programmers working together at one computer. One person acts as the driver who types code while the other navigates and reviews. It has benefits like catching mistakes earlier, improving design quality, transferring knowledge between partners, and creating a stronger sense of team. While there is initially a 15% overhead in time, studies show this is outweighed by fewer defects and a more flexible system in the long run. Effective pair programming requires collaboration, respect, communication and regularly alternating roles.
The document discusses anti-patterns and worst practices in software development. Some examples covered include static cling pattern, flags over objects, premature optimization, copy-paste-compile, and reinventing the wheel. It also shares lessons learned from experiences, such as being mindful of date times across time zones, avoiding building SQL from untrusted inputs, and not being too cute with test data. Overall, the document aims to help developers learn from the mistakes of others and adopt better practices.
5. Refactoring Process
• Verify existing behavior
• Write Characterization Tests if none exist
– Find test points
– Break dependencies
• Apply Refactoring
• Confirm existing behavior is preserved
Follow me at twitter.com/ardalis
6. Characterization Tests
Process
1. Write a test you know will fail
2. Use the output of the failing test to
determine the existing behavior to assert
3. Update the test with the new
value/behavior
4. Run the test again – it should pass
Follow me at twitter.com/ardalis
10. Principles of OO Design
0. Don’t Repeat Yourself (DRY)
1. Single Responsibility
2. Open/Closed
3. Liskov Substitution
4. Interface Segregation
5. Dependency Inversion
Follow me at twitter.com/ardalis
11.
12. Don’t Repeat
Repeat Yourself
• Duplication in logic calls for abstraction
• Duplication in process calls for
automation
Follow me at twitter.com/ardalis
13. Common Refactorings
• Replace Magic Number/String
• Parameterize Method
• Pull Up Field
• Pull Up Method
• Replace Conditional With Polymorphism
• Introduce Method
Follow me at twitter.com/ardalis
14. Role Checks
if(user.IsInRole(“Admins”)
{
// allow access to resource
}
// favor privileges over role checks
// ardalis.com/Favor-Privileges-over-Role-Checks
var priv = new ContentPrivilege(user, article);
if(priv.CanEdit())
{
// allow access
}
Follow me at twitter.com/ardalis
15.
16. Single Responsibility Principle
The Single Responsibility Principle states that every object
should have a single responsibility, and that
responsibility should be entirely encapsulated by the
class.
Wikipedia
There should never be more than one reason for a class to
change.
Robert C. “Uncle Bob” Martin
Follow me at twitter.com/ardalis
17. Example Responsibilities
• Persistence
• Validation
• Notification
• Error Handling
• Logging
• Class Selection / Construction
• Formatting
• Parsing
• Mapping
Follow me at twitter.com/ardalis
18. Dependency and Coupling
• Excessive coupling makes changing
legacy software difficult
• Breaking apart responsibilities and
dependencies is a large part of working
with existing code
Follow me at twitter.com/ardalis
19. Common Refactorings
• Extract Class
• Move Method
Follow me at twitter.com/ardalis
20. Heuristics and Code Smells
• Visual Studio Metrics
Follow me at twitter.com/ardalis
21. Code Smell: Regions
More on Regions: http://ardalis.com/regional-differences
Follow me at twitter.com/ardalis
22.
23. Open / Closed Principle
The Open / Closed Principle states that software entities
(classes, modules, functions, etc.) should be open for
extension, but closed for modification.
Wikipedia
Follow me at twitter.com/ardalis
24. Open / Closed Principle
Open to Extension
New behavior can be added in the future
Closed to Modification
Changes to source or binary code are not required
Dr. Bertrand Meyer originated the OCP term in his 1988
book, Object Oriented Software Construction
Follow me at twitter.com/ardalis
25. Common Refactorings
• Extract Interface / Apply Strategy Pattern
• Parameterize Method
• Form Template Method
Follow me at twitter.com/ardalis
28. OCP OK
private IEnumerable<ICustomerRule> _rules;
public bool IsSpecialCustomer(Customer c)
{
foreach(var rule in _rules)
{
if(rule.Evaluate(c) == false) return false;
}
return true;
}
Follow me at twitter.com/ardalis
29.
30. Liskov Substitution Principle
The Liskov Substitution Principle states that
Subtypes must be substitutable for their
base types.
Agile Principles, Patterns, and Practices in
C#
Named for Barbara Liskov, who first
described the principle in 1988.
Follow me at twitter.com/ardalis
31. Common Refactorings
• Collapse Hierarchy
• Pull Up / Push Down Field
• Pull Up / Push Down Method
Follow me at twitter.com/ardalis
32. Liskov Substitution Fail
foreach(var employee in employees)
{
if(employee is Manager)
{
Helpers.PrintManager(employee as Manager);
break;
}
Helpers.PrintEmployee(employee);
}
Follow me at twitter.com/ardalis
33. Liskov Substitution OK
foreach(var employee in employees)
{
employee.Print();
// or
Helpers.PrintEmployee(employee);
}
Follow me at twitter.com/ardalis
34.
35. Interface Segregation Principle
The Interface Segregation Principle states that
Clients should not be forced to depend on
methods they do not use.
Agile Principles, Patterns, and Practices in C#
Corollary:
Prefer small, cohesive interfaces to “fat” interfaces
Follow me at twitter.com/ardalis
37. ISP Fail (sometimes)
public IRepository<T>
{
T GetById(int id);
IEnumerable<T> List();
void Create(T item);
void Update(T item);
void Delete(T item);
}
Follow me at twitter.com/ardalis
38. ISP OK (for CQRS for example)
public IRepository<T> : IReadRepository<T>,
IWriteRepository<T>
{ }
public IReadRepository<T>
{
T GetById(int id);
IEnumerable<T> List();
}
public IWriteRepository<T>
void Create(T item);
void Update(T item);
void Delete(T item);
}
Follow me at twitter.com/ardalis
39.
40. Dependency Inversion Principle
High-level modules should not depend on low-level
modules. Both should depend on abstractions.
Abstractions should not depend on details. Details
should depend on abstractions.
Agile Principles, Patterns, and Practices in C#
Follow me at twitter.com/ardalis
41. Dependency Inversion Principle
• Depend on Abstractions
– Interfaces, not concrete types
• Inject Dependencies into Classes
• Structure Solution so Dependencies Flow
Toward Core
– Onion Architecture
Follow me at twitter.com/ardalis
43. Compile Time
Data Access Evolution Runtime
No separation of concerns:
User Interface
Data access logic baked directly into UI
ASP.NET Data Source Controls
Classic ASP scripts
Data access logic in UI layer via codebehind
ASP.NET Page_Load event
ASP.NET Button_Click event
Database
Follow me at twitter.com/ardalis
44. Data Access : Helper Compile Time
Classes Runtime
Calls to data made through a
utility
User Interface
Example: Data Access
Application Block (SqlHelper)
Helper Class
Logic may still live in UI layer
Or a Business Logic Layer may
make calls to a Data Access
Layer which might then call the
helper Database
Follow me at twitter.com/ardalis
45. What’s Missing? Compile Time
Abstraction! Runtime
No way to abstract away
data access User Interface
Tight coupling
Leads to Big Ball of Mud Core Infrastructure
system IFooRepository SqlFooRepository
Solution:
Depend on interfaces, not
concrete implementations
What should we call such Database
interfaces? Repositories!
Follow me at twitter.com/ardalis
47. Common Dependencies
• Framework See also responsibilities:
• Third Party Libraries • Persistence
• Validation
• Database • Notification
• File System • Error Handling
• Email • Logging
• Web Services • Class Selection /
Construction
• System Resources (Clock) • Formatting
• Configuration • Parsing
• The new Keyword • Mapping
• Static methods
• Thread.Sleep
• Random
Follow me at twitter.com/ardalis
48. Common Refactorings
• Extract Class
• Extract Interface / Apply Strategy Pattern
• Extract Method
• Introduce Service Locator / Container
Follow me at twitter.com/ardalis
Note that characterization tests, though they should be automated, are often not what we would think of as unit tests, or perhaps even integration tests. For instance, you could dump a log file showing the relevant state of the application, and then use that as the basis for your characterization test by comparing against it after your changes.
Avoid creating a big ball of mud system, where tracing through your code and its dependencies is like trying to unwind a tangled mess of spaghetti.
A very common source of repetition of code is role checks. These often describe different scenarios in different circumstances. For instance, maybe administrators can do anything, but managers can access resources within their division, etc. Encapsulating the logic of CanView, CanCreate, CanEdit, etc. in privilege objects makes these rules explicit, easier to test, and gives them a single location to live in the application.
Visual Studio can quickly analyze a project and show statistics for the classes and methods in the project. The maintainability index, cyclomatic complexity, and lines of code are all great metrics to pay attention to. The ideal maintainability index is 100, but don’t expect to hit that with any code that’s doing real work. However, you should certainly able to keep it above 50.
I’m not a fan of regions. They mainly exist because at one time they were a reasonable means of hiding generated code, before we had support for partial classes and other language features to deal with this. The worst offense with regions is when they’re used within a method, like this:(click)They’re also bad when used at the class level for “standard” formatting of code, making it impossible to actually see what the code does, like this:(click)Can someone tell me what this class does?(click)I have a whole article devoted to why using regions is a bad habit, anti-pattern, code smell, whatever you prefer. It includes some survey results on the most common ways people use them as well. (click)
What happens when we need to add another country?What happens when we must add another rule?How can we refactor this so this method no longer needs to change?
Define a type to describe a rule. Move each rule into its own type. Create a collection of rules to apply and apply them.Pass the set of rules into the IsSpecialCustomer() method’s class (or even the method itself).
Any time you find that you need to check the type of an object within a polymorphic block of code (such as a foreach), this is a sign that you are breaking LSP.
This is anextemely common example of the Repository design pattern. In fact, I use this exact pattern in quite a few production applications today. There’s nothing inherently wrong with this implementation on its own. However, sometimes it does violate ISP if you need to separate Commands from Queries
You can create small interfaces and compose the larger interfaces from the smaller ones if you control all of the code and you can’t simply do away with the larger interfaces. In this case, the separation of interfaces would allow us to do something like implement caching only on the read operations, and implement delayed writes using some kind of queue or message bus for the write operations.
Extract interfaceImplement interface with tightly coupled original code