The Single Responsibility Principle
Hello this is Steve Smith, and welcome to this Pluralsight video, on one of the Software Fundamentals. The Single Responsibility Principle. We'll begin by defining The Single Responsibility Principle, demonstrating what some of the problems are when classes have to many responsibilities, and then we'll look at an example in code, that shows how a typical a e-commerce application might be worked out, that exposes a problem with responsibilities. We'll refactor this sample application to apply SRP, making it so that it has a better and more maintainable design, and then we'll describe some related fundamentals that you can look to for additional learning.

The Open / Closed Principle
Hi this is Steve Smith, welcome to this Pluralsight video on one of the software Fundamentals. The Open/Closed Principle, which represents the "O" in the solid. The outline for this module will include a definition of Open/Closed Principle; we'll look at the problem that the principle represents and solves, we'll see an example of what happens when one does not follow the Open/Closed principle. And then we'll examine what's wrong with that example and finally we'll refactor in order to apply the Open/Closed Principle to that example. Finally we'll have a quick summary and we'll look at some related fundamentals.

The Liskov Substitution Principle
Hello, my name is Steve Smith and in this Pluralsight on demand video we'll be discussing the Liskov Substitution Principle. One of the software fundamentals and the "L" in the solid principles of object oriented development. In this brief course we are going to define what the Liskov substitution principle means. We'll identify the problem that it intends to solve, we'll show some examples of how violations of this principle can become problematic in your code. And then we'll refactor this problem so that we are able to apply this principle and eliminate these problems. Finally we'll look at some related fundamentals and additional resources; let's get started.

The Dependency Inversion Principle
Hi, this is Steve Smith, and in this Pluralsight On-Demand! video we're going to take a look at the Dependency Inversion Principle, the D in the solid principles of object-oriented design. The Dependency Inversion Principle is one of the most important principles of building object-oriented software, and we're actually going to have to split this module into two parts because there's quite a lot to cover. We're going to start off by defining the dependency inversion principle. We'll outline some of the issues that occur in software that does not follow this principle. I'll further demonstrate that with an example, in which we'll see how these problems arise and then we'll analyze that problem and figure out a way to refactor it in order to apply this principle. And then we'll have a look at some related fundamentals that apply as well along the way.

The Dependency Inversion Principle, Part 2
Hi, this is Steve Smith, and this is going to be part 2 of the Dependency Inversion Principle, one of the principles of object-oriented design and a software fundamental, part of the solid principles of object-oriented programming. In this module, we're going to talk about Project Dependencies in our Microsoft Visual Studio applications. We'll look at the problem that occurs when we have dependencies flowing in such a way that the infrastructure and low-level concerns of our application are depended upon by all the other projects in our app. We'll go through an example that shows this particular type of architecture, which is very common, and the problems that arise when one uses it, and then we'll refactor this design, applying the dependency inversion principle at the solution level so that we can improve the design and maintainability of our application. Finally, we'll wrap up with some related fundamentals.

The Don't Repeat Yourself Principle, Part 1
Hi, this is Steve Smith. Welcome to this Pluralsight on-demand module on The Don't Repeat Yourself Principle. The Don't Repeat Yourself Principle or DRY is one of the fundamentals of object-oriented design and software engineering, and personally I think that this is one of the most important principles for every developer to learn. In this module, we'll start out by defining the Don't Repeat Yourself Principle and then we'll go through a demo showing how misuse of this principle results in Spaghetti code that's very difficult to maintain. After a little bit of analysis, we'll go through a series of demos showing how we can refactor such code to DRY it up and make it much easier to maintain and continue to use. We'll briefly look at some Code Generation options before moving on to show what repetition in your process can do and how it adds to the waste of your process. And then we'll show a quick demo on how we can automate our process to apply DRY as well. Finally, we'll wrap up with a summary and related fundamentals.

The Don't Repeat Yourself Principle, Part 2
Hi, this is Steve Smith, and this is part 2 of the Don't Repeat Yourself Principle, one of the software fundamentals and part of the Principles of Object-Oriented Design course. In part 1, we defined the Don't Repeat Yourself Principle, we went through a number of demos showing how there was repetition in our code, we analyzed the code and looked for ways that we could improve it, and we made a checklist of problems that we found. We went through a number of refactorings to apply the Don't Repeat Yourself Principle and we didn't get through them all, so in part 2 we're going to continue with those and with this part we're going to have an emphasis on testability. So at the end of this section, we'll have our code refactored to a state where we can easily apply Unit Tests to it and we'll also examine some testing concepts such as mocking. Next, in part 3, we'll talk a little bit about Code Generation, some tools that you can use to eliminate repetition in your code and to discover repeat blocks of code, as well as how you can use automation to eliminate repetition in your software design and development processes.

The Don't Repeat Yourself Principle, Part 3
Hi, this is Steve Smith, and this is Part 3 of the Don't Repeat Yourself Principle. I feel like I'm repeating myself a little bit with these title slides. This is one of the software fundamentals and it's the final module in the Principles of Object-Oriented Design that's related to the Don't Repeat Yourself Principle. In Part 1, we went through the definition and a bunch of demos on refactorings, we did some analysis of our code and we cleaned it up a bit. In Part 2, we continued that process with an emphasis on testability and adding tests and using Mocks to make it so that our code was easily tested in isolation. Now in Part 3, we're going to focus here on a couple of aspects, specifically Code Generation and automation of our processes so that we can eliminate repetition in those areas as well, which will result in a more consistent build, and better quality software that we're going to be able to deliver more consistently and frequently.