Design Principles and Standards in Software Architecture by Andy Schwam || C# Corner Conference
Nov 21, 2023
Watch the third session of Software Architecture Virtual Conference as Andy Schwam discusses, "Design Principles and Standards in Software Architecture".
Watch Full Conference here: https://youtu.be/0m0Jvcp76sE
Conference Website: https://www.2020twenty.net/softwarearchitecture
C# Corner - Community of Software and Data Developers: https://www.c-sharpcorner.com
#csharpcorner #virtualconference #live #software #architecture #design #principles #standards
Show More Show Less View Video Transcript
0:00
My name is Andy Schwamm
0:05
I'm the AVP of Enterprise Architecture in an insurance company in the Philadelphia area
0:10
I'm a 10-time Microsoft MVP for developer technologies. I'm also a conference organizer
0:16
I organized a conference called Tech Bash. You can check it out at techbash.com
0:21
And then here's some other ways you can find me, right? On Twitter, I'm Schwammie
0:26
GitHub, you can see my repost, Schwami, LinkedIn, Andrew Schwamm. I have a blog
0:30
Schwami says, all this good stuff, right? In addition, I do live streaming Wednesdays at noon
0:38
noon Eastern time. And that's probably something, you know, we're an international audience here
0:43
today, but noon Eastern time, you can find me on Twitch, Mixer, and YouTube, where I build software
0:50
with all kinds of stuff that we're talking about here today with good architecture practices and
0:55
with DevOps and everything else and web application design and things like that
1:02
Another shameless plug I'm going to throw in real quick is I'm also a host of the Dev Talk Show
1:07
The Dev Talk Show is also on Wednesdays, Wednesdays at 8.30 p.m. Eastern
1:13
where Chris Gomez, Rich Ross, and myself, we talk about all kinds of things for software developers
1:20
We talk about architecture. We talk about design. We do live demos of writing code. We have guests. Mahesh was a guest recently, and that was great. And we talk about all kinds of things. And so if you're really interested in the whole spectrum of software development, it's a great show to check out, again, on Twitch, Mixer, and YouTube, slash the Dev Talk Show
1:42
And that's all my plugs for myself. And now looking forward to talking to you guys about design principles
1:50
So I want to start out by talking about why we need design principles
1:55
So spoiler alert here, really, this is the most important part of the whole thing
2:02
Understanding why is critical. There is lots of different design principles you can choose or not choose
2:10
But understanding why is a really important factor. And not only is it important that as an architect you understand why, but it's really important that you make sure your teams understand the why
2:26
Because if your teams understand the why, instead of you just saying, hey, this is what you need to do, really focus on building up that understanding with them
2:36
OK, and when they understand the why and when everyone embraces it, you really follow these principles
2:42
You really think about these principles and you really focus on them and take it in
2:47
So it's really important. So why? Well, building software is hard. This is not a simple thing to do. It is not a simple thing to do
3:00
And in the beginning, and we were talking about this earlier, if we don't build software correctly
3:05
we can overcomplicate it and we can make it even harder and we can make it even harder to work with
3:11
It's hard enough when we do it right, let's face it. But if we start off incorrectly and we build
3:17
poorly designed software, it's hard to work with. Maintaining and changing poorly designed software
3:25
is costly. And when I say costly, I don't just mean money. I mean, yes, I mean money
3:32
But I also mean costly in terms of time and in terms of missed opportunities
3:38
If you're fixing your software, if you're spending too much time maintaining your software, you're not adding the things that the business units or the business side of the software are looking for
3:49
We're not adding new features, right? We're not giving the customers what the customers need because we're busy working on it
3:55
So building software is hard. Changing software is hard. And if we design it poorly, we have fragile code
4:02
And fragile code leads to bugs. And bugs can be costly. Again, time, money, missed opportunities
4:10
And it's really important to focus on that and to embrace that and think about that
4:15
Changing bad code is really hard. We want to design quality software
4:21
And my mouse didn't even switch. Here we go. Switch. Come on
4:26
Oh, I know why. Because I had animations in here and I'm not used to having it. So it's going down the different items
4:31
Okay, so what do we want here? This is what we want to talk about. What do we want? Well, I know I want code that is less error-prone
4:39
I want code that is easier to maintain. I want code that is easier to read, less breakable, more reusable, and more decoupled, right
4:52
And if we follow good design principles, we can get to this place, right
4:58
So now we understand a little bit about why. We understand about what we want to get. And we're going to talk about some design principles
5:05
First, though, I find it interesting. A lot of times we misuse terminology. Right
5:12
And it's really great to have a ubiquitous language. So we're all talking about the same thing
5:17
So we're all using the same words for the same things. And sometimes design principles is one of those things where we talk about the wrong thing
5:24
Sometimes people use terms like standards or architectures or implementations and all these different words and principles sort of interchangeably
5:33
And they're not really. I mean, there are different things. So design principles are not implementations. Right
5:40
And design principles are not patterns either. OK. You may use patterns to implement design principles
5:49
But design principles aren't really specific about how you achieve the goal of the principle
5:54
Design principles are guidelines to have a good design. And when we look at the design principles, it will all make sense
6:03
But I will show examples of many of these of how you can achieve the goal
6:09
I might show a pattern that you might use or something like that. But the pattern is different than the principle
6:15
The principle isn't specific to how you solve the problem. Oh, and I talked to that, so there we go
6:21
Okay. There are lots of design principles. We're going to focus on a few. Now, I don't like to use the word easy and hard, but I don't have another word to replace it right now
6:30
So some of these concepts are easier to understand. And they're great for, you know, really working with your junior developers, your mid-level developers
6:39
You really want to focus on these with people that have some less experience
6:43
Some of these design principles really take time to master. And you have to sort of study them
6:51
You have to sort of practice and work with them a while. So we're going to go through a variety of them
6:57
And the first one we're going to talk about is, again, we're starting with the ones that are somewhat easier to grasp, I think
7:05
The first one is separation of concerns. A separation of concerns pretty much says don't mix things up
7:12
Don't mix things up that don't belong together. Don't mix up things that don't belong together
7:17
So what does that mean? Well you know there some examples we can use here You know a simple example with separation of concerns is that the UI and the database logic should be separated And that may seem obvious to us you know but it not always obvious
7:36
It's really easy to bleed some of these things together, believe it or not. Now, I've seen some really bad examples of what you should not do
7:42
For instance, I've seen a database where in the columns of the database where you'd expect to see just the data
7:49
there was HTML, right? You know, brackets, divs, and all kinds of things in there
7:55
with CSS in the data. And so when you query the data
7:59
you could easily display it in the UI because it had the UI right there
8:04
And someone thought that was a good idea at one point. The problem with that is how do I change the data
8:10
without running the risk of messing up the UI part? And how do I change the UI
8:16
without really dealing with all the data? As a matter of fact, if we change the data in this case, if we change the data, we have to add the UI into it right there
8:26
And it's really just sloppy and really just messy. So we don't want to do that
8:31
Another example of separation of concerns is the MVC pattern. And I'm pretty sure Joe's going to
8:36
be talking about that one later today. MVC pattern is really just designed around separation of
8:41
concerns separate the model which is the business logic and the data access and
8:47
all that kind of stuff the view is the UI the controller is the I should say
8:53
like the orchestration the sort of glue that makes it all run together to handle
8:58
the requests I'm not going to get into the details of MVC but the point is it's a whole pattern very much focused on separation of concerns so it's really
9:06
important to look at separation of concerns. Now the next one we want to talk about is DRY
9:15
There's lots of acronyms in here. DRY stands for don't repeat yourself
9:20
Now this one is something I think one of the few design
9:25
patterns that I feel like we're taught really early on in our software development experience
9:30
Don't repeat yourself. Repeating code all over your application is problematic. We know that. We don't want to change code when we want to make a change
9:38
We don't want to have to go looking in 15 different places and looking for it all over the place
9:42
It makes our applications harder to manage. And there's lots of ways to deal with dry
9:48
Certainly we can extract code out, put it into different methods and different classes and things like that to avoid repeating it
9:57
But this is, again, is one of those ones that I think we're sort of taught early on in our software development experience
10:03
So that's a good one. Next is another acronym, YAGNI. You ain't going to need it. Don't add complexity that you may not need to your applications. Skip the wouldn't it be cool features. Keep your architecture design simple
10:18
Now, this isn't as easy as it might seem, you know, and so easily I can just state don't add complexity that you may not need
10:25
But as architectures, we have to make tough decisions. As architects, we have to make tough decisions sometimes
10:31
We know that there are more features coming down the road and we think, well, if we're designing the first feature, if I do it in a maybe a more complex way than I need today, it will support the features we need in the future
10:45
And that's sometimes a good idea and sometimes a bad idea. And so this is where experience as an architect comes in handy
10:54
You really want to focus on trying to not build things we don't need
10:59
And that sort of goes along with the MVP, minimum viable product concept, goes along with agile and all those kind of things
11:06
But we really want to be careful to not build our applications more complicated than they need to be
11:12
And that brings us to KISS. Keep it simple, stupid. Now, of course, I didn't write that acronym
11:20
I'm not calling anybody stupid except myself because I've broken this plenty of times
11:25
Just as I've broken, by the way, I should say, there's nothing in this presentation
11:31
There are no points that I'm making here today that I haven't broken these rules in any time
11:38
in my career. I have. We all have, and that's okay. Being becoming an architect is about growth
11:44
It's about learning and doing more and doing things better all the time. By no means, when
11:50
you watch these presentations from myself and from the future architects that are going to speak
11:54
today, don't think, well, God, these guys never made mistakes. They all know this stuff, and I
12:00
don't know this stuff. Well, everyone had to learn it the first time. Anyway, let's get back to Keep
12:05
The best design is often a simple design. And just because you can make things more complicated doesn't mean you should
12:17
As an architect and as a developer, I'm more impressed by simple solutions
12:22
Looking at something, when someone can do something really simply, it's like, wow, that's great
12:27
You know, I wrote that with 10 lines of code and I had this whole big thing around and
12:32
someone said, you know, there's a feature built in. All you have to do is use this one line and beautiful, right
12:37
And that's keeping things simple and focusing on the easy ways to get things done
12:42
Now, one line of code isn't always the best way to go. And key here to think about is sometimes more lines of code is better than less lines of code
12:50
And sometimes less lines of code is better than more lines of code. You know, just because you can write a whole page as a single link statement doesn't mean you should
12:59
You really want to focus on what's going to be maintainable, what's going to be manageable
13:03
and what's going to be understandable and readable. There are all these factors that go into our code
13:08
And that brings us to dry, which is don't repeat yourself. Repeating code all over your application is problematic
13:15
And, of course, repeating slides over is problematic, too. And so that was my very lame sort of dad joke there that I have dry in there twice
13:24
I know. I know. This is the kind of humor you're going to get with me today. But I hope you can hang in there and appreciate that terrible joke
13:32
So let's move on to the solid principles of object-oriented and agile design
13:38
Now, this is where I think we're stepping things up a little bit, and it does get a little bit more complicated
13:45
And, by the way, I'm trying to monitor questions in case there's any. I do see some questions, you know, does that correspond to dependency separation
13:54
I don't recall when that question came in, but we're going to be talking about some of that stuff in the next couple of slides
14:00
So hopefully we get a good answer to that. And then if not, we can come back and answer that question
14:06
I am trying to monitor the questions, but it's kind of hard with all the screens. So I'm going to do my best
14:12
So these solid principles are what I would say sort of more complicated
14:18
Now, some of them are easier to grasp, and you really want to get more junior developers on board with them early
14:26
Some of them, again, some of these are a little bit more complicated. Now, these solid principles of object-oriented and agile design, these were basically made popular and famous by Robert Morton, well-known as Uncle Bob, Uncle Bob Morton
14:44
And if you not familiar with Uncle Bob I suggest you Google him or Bing him or whatever it is that you do and check out some of the things that he says because he says some really good smart stuff He a leader in our industry specifically when it comes to principles and patterns and things like that And so about the solid principles and he didn write each of the principles but sort of you know kind of put them together into this solid principle thing
15:13
So what Uncle Bob says is poor dependency management leads to code that is hard to change, fragile, and non-reusable
15:22
Okay? And that's not what we want. Okay? Now, on the other hand, when dependencies are well-managed
15:33
the code remains flexible, robust, and reusable. When the dependencies are well-managed
15:41
the code remains flexible, robust, and reusable. Now, that's what we said earlier. That's a lot of
15:49
what we're looking for. And so these principles are things that I just focus on day in and day
15:58
out while writing software. I am just so in love with these solid principles. And many developers
16:05
are. I really see it becoming so popular now. Dependency management is the key to the clean
16:12
design. So every time I try to go to the next slide, it doesn't work. Here we go. The first
16:18
solid is an acronym, S-O-L-I-D, and the first one is the single responsibility principle
16:26
which you might see referred to as SRP, another acronym. Now, the single responsibility principle
16:33
says that a class should have one and only one reason to change
16:41
Think about that for a second. A class should have one and only one reason to change
16:49
Now, when I first learned the single responsibility principle, when I first heard of it
16:53
I think I took a slightly different interpretation, like many people do, that says a class should only do one thing
16:59
But that's not really what it says. Now, those two things are close. but that's not exactly the same
17:06
Okay. One reason to change. Okay. Because when we change code, we run the risk of breaking it
17:14
Okay. When we change code, we run the risk of breaking it
17:18
And we run the risk of breaking all the code that calls that, that calls that
17:22
and it kind of cascades down. And so it is clearly simpler to have classes and methods that do one thing
17:31
Okay. That do one thing. However, they should only have one reason to change
17:36
And what does that part mean? One reason to change sounds kind of tricky. Now, I will go into examples for these
17:41
and I'll show you what we mean by one reason to change. But by following the single responsibility principle
17:47
we write code that is easier to test because it only does one thing, right
17:52
It only has one reason to change. It's easier to read, it's easier to maintain
17:58
That also means we introduce less side effects. we sort of automatically get separation of concerns, right
18:04
Because the code's only doing one thing. And on top of that, one of the bonuses
18:09
that I always like to mention to people is you have very little merge conflicts in source code, right
18:14
Because if you have small classes and they're only doing one thing
18:18
you don't have a lot of developers in there at the same time working on different things
18:22
So that's an added bonus. Let's take a look at the single responsibility principle
18:27
and we'll really focus on the single thing to do and the single reason to change
18:32
So I have some samples. Let me see if I can get that going there
18:37
Okay, now just a warning about my samples here. These are not necessarily
18:44
this is not a program that compiles. These are just some samples that I have. They're C Sharp files, but they don't actually compile
18:52
So there might even be a mistake in there or something like that. Don't panic on that
18:56
This is not a project or a solution. My samples, and I should say
19:00
I should take a minute here to say my samples are in C sharp, but these design principles, all these design principles
19:08
don't just apply to C sharp or even just a.net, or these can be applied across all kinds of software development
19:15
Whether you're writing JavaScript, whether you're doing different languages altogether, you can use these single responsibility principles all over the place
19:24
I try to apply them to SQL when I can. and I try to apply them all over the place
19:32
Now, I do see a question from Andrew. It says, doesn't one reason to change almost mean one method per class
19:39
Almost, but we'll talk about that a little bit. I think it's a really good question
19:44
and these are some of the first questions we ask as we're learning about this. You can take it to that extreme and have one method per class
19:52
and that would be sure. I don't think we need to go that far with it
19:56
and I've even seen Uncle Bob talk about that we don't really need to
20:04
If you want to, I don't think there's anything wrong with going further to the extreme
20:09
I like to be pragmatic with how I apply these principles and how I think about them
20:15
and how we apply them and how I ask teams to apply them because certainly having one method per class really does start to get a little crazy
20:24
but sometimes it's a great idea. Let's take a look, though, first at what is not the single responsibility
20:29
And so you can see I have this little class here called not single responsibility. These files, by the way, are in my GitHub repo
20:37
On GitHub, I'm Schwami. And you can see, I think it's called design principle samples or something like that
20:47
Anyway, so this is code that looks very much like code that I've written over my career
20:51
and maybe code that you've written. And at times, I would think this was great code
20:57
So I've kind of moved on, and I don't love this code so much anymore
21:02
But what happened? My light just went out. That's interesting. Let's see what happened with the light
21:07
Okay. So the first thing is I have this join method. Let's imagine this is part of a bigger application where you're trying to join
21:15
become a member of some kind of website, something like that. Now, so the method takes a username and a password
21:23
And what do I do next? And I think it's really important to see the bad examples and it really helps tell the
21:28
tale of what we should be doing. So what do I do next? I'm going to do some validation
21:32
Now keep in mind this validation is incredibly poor validation. It's just here for showing some examples
21:38
I don't think we would really have something that says the username must be five characters
21:42
to be valid, but let's just play along with my silly examples here
21:46
So I'm saying that I have to have a username that's five characters and the username has
21:50
to be an email address and my lame way to determine that in this simple example is
21:55
oh, hey, there's an at symbol. It's an email address. Cool. And then, and this is where
21:59
it gets even really bad, my password validation says that the password has to be five characters
22:04
or more to be a valid password. Yeah, pretty lame. But that's okay. I've got validation
22:09
logic in my join method. And then I go in and say, let's check to see if the member already exists
22:15
OK, and maybe I call this members members data access thing and find out if the user exists
22:24
And if not you know I move on and I add the user and then I go on to even more which is like oh let go down here and let build a message an email message and format it Now this isn exactly robust formatting but here it is
22:38
I put the text of the email message in there. I formatted it and then I'm using this SMTP client and I'm sending it
22:45
And I think we can all agree that this class does more than one thing
22:50
Right. It does more than one thing. But what about this more than one reason to change
22:55
Okay. Well, I might need to change this class because we add an additional validation rule
23:04
I might, right? We may say, hey, this password protection policy is pretty weak, admittedly
23:10
So let's put some more password protection logic in here. And when we do that, I run the risk
23:16
and I really do, as much as this sort of seems like a simple example, I run the risk of breaking
23:20
this application when I do that. Let's take a look at a different example. What if the marketing
23:25
department comes along and says, hey, Andy, this thanks for joining message here. Well, that's nice
23:32
but that's not exactly the message we want. How about we add some style in here and some colors
23:38
and we put a little bit more message in here, and we change that. And that's an important thing for
23:44
the marketing department. But I come in here and I change that. And what happens when I change that
23:49
is I run the risk of breaking a core feature of my application, the join method
23:54
So wouldn't it be great if I can get these things separated and split apart? That's what we're talking about with the single responsibility principle
24:02
Scanning just questions here. In my opinion, contextual to what class was created
24:09
Contextual to what that class was created. Class was created. I think saying that the feature that we're trying to do should be within the context of the particular class
24:27
And so we'll talk about that. I think that's what we're going to talk about. But anyway, so let's move on to how we would fix that
24:32
Well, how would we fix that? I have another file here basically called single responsibility
24:38
And in this case, we start out, we still need that join method, right
24:42
You have to have that. And so in this case, the join method has a single responsibility
24:47
People say, well, no, it has a bunch of responsibilities. It's doing all this stuff
24:52
And I would say, well, no, the join method here has a single responsibility
24:57
and its responsibility is to orchestrate the calling of other things. Somewhere along the line, this stuff needs to get put together
25:05
needs to be composed into something. And so the join method might call upon a validator class, right
25:13
that has a validate method, right, And a membership service that has an add method and a message formatter that has a format message method, et cetera, the notifier
25:23
And what do these look like? Now, for simplicity's sake, because I don't want to be clicking around so much during this demo, I've got these classes in here together
25:31
Okay. And so in here, I have a membership validator, and it has the validate user
25:36
Now, I didn't put the code in here, but it's really going to be that same code, right
25:40
we could just come right back to that other class and drop that same code in here, right
25:46
It's not necessarily about writing more code. It's about moving that code around to different places, right
25:50
I might have a membership service that does the ad. I might have the message formatter, and its job is to just build out that welcome message
25:58
and do whatever we want to do in there. Then I might have another class that does notification
26:05
Now, let's talk again about single responsibility. This membership class has this add method
26:13
Now, we talked about, like, is it one method per class? Not necessarily
26:17
I might have a remove method in the membership service. I might have an update method in the membership service
26:26
Because they definitely would still sort of have one reason to change, right
26:30
We're changing the logic around membership. It's a gray area. This is a very slippery slope
26:37
You don't want to add too much stuff. because it starts to get too complicated
26:42
And when we look at the amount of dependencies we start to add, right, this single responsibility join method has a bunch of dependencies, right
26:51
And if I can keep the dependencies short and my class starts to not look too complicated
26:56
I say, well, add and remove are very similar. They're both calling the same repo, maybe, something like that, right
27:04
Well, then there's really not much difference between them and my risk is low
27:07
But if I start to have lots of methods in these classes, if this membership class all of a sudden becomes something that has so many things, if my message formatter class, this is a better example, maybe I have something called membership message formatting and I put a few messages in there around formatting messages for joining and moving and stuff like that
27:28
But maybe I don't have other things that users might get responses to
27:33
Maybe I would put those into a different format or class. It's really up to your level of comfort and the level of complexity
27:40
And we really want to think about sort of those different things
27:44
And I'm just looking at the questions. Let's see. So the question from Tool, sometimes design patterns seem to contradict solid
27:56
while sometimes they support it. What is better in the case of conflict
28:01
I've read somewhere that no application can be fully solidified. Yeah. Listen, this is a great question
28:08
Thanks for asking that question and sharing that with us. Everything, in my opinion, is about balance, right
28:15
It's about being pragmatic and not being dogmatic, right? And I'll talk about that a little later when we talk about standards
28:22
But we have to make some decisions. And this is where I say, listen, in this case, I'm willing to put a few methods in the same class together. Right. But it's a it's a feel
28:33
It's something that as an architect you grow into and you start to learn where you can slip on one principle and maybe not slip in another
28:40
Now, if we had the ultimate time and the ultimate money, we could probably get all these things perfect
28:45
But we have a lot of constraints upon us. We have pressure from business and customers that we need to get things done
28:51
And so there is a balance that we need to do. Now, Andrew also says you would make interfaces for each and inject based on service provider configuration
29:03
So what Andrew is talking about, we're going to come back to that. But if you look at this here where I'm using these objects, right, I'm instantiating objects here
29:10
This is not a great design for this. This class demonstrates the single responsibility principle
29:16
We will cover what Andrew is talking about with a different principle and we'll come back to that
29:20
I'm going to keep going now and keep this thing moving. So let's take a look at the next principle because this is a lot of stuff to cover here
29:31
Let's cover the open-closed principle, which says that software entities, classes, modules, functions, et cetera
29:39
should be open for extension but closed for modification. Okay? Think about that for a second
29:45
software entities should be open for extension but closed for modification
29:54
now what does that mean what that means is Open for extension. We need to be able to change our classes. We have to make changes. We have to be able to add features. We have to change things. How can we do that in a way that's safe? We want to make our classes closed for modification. Now, of course, it's never really closed. Anybody can go in there and change it
30:18
But when we design it in a way where it's open for extension, we can extend the feature
30:24
we can extend the behavior of a class without going in and changing the class
30:29
We have to be able to do that. Let's talk about a simple example first
30:33
A simple example might be something like a connection string. We don't hardwire, hopefully, we don't hardwire our connection strings into our data access code
30:43
We put our connection string out in a config file. That means that our code, our feature, our application in some ways can change without
30:54
opening up the class that uses the configuration file and modifying the class
31:00
I don't have to recompile it. I don't have to make changes to it. I can change the connection string
31:04
That's a simple example of the open-closed principle. Let's look at a more code-based example
31:11
I jump to another slide, but that's okay. I'm jumping all over the place
31:16
Here we go. Let's take a look at open closed principle. Now I'm going to start off with not open closed principle
31:23
And if we look at this, we can look at our little validation type of thing that we had
31:27
from before. I have validate user. This time it takes an account
31:31
I switched it and the account just has a username and a password. And here's that same logic we saw before. Okay
31:38
Username, password, et cetera. And so we come along and we want to say, well, I want to add another rule
31:45
I want to add some real password validation to this, let's say, or who knows what we want to add to this
31:52
The only way I can change this now is I have to come in here and I have to make changes in here
31:57
I have to do this and I have to move things around and make changes or whatever it is I want to do
32:02
And what happens is I run risks of breaking other things. Right. I don't want to break other things. Right
32:10
Now, in this case, you could argue that that's not such a big deal. Right
32:15
This is what we talked about at the beginning, finding and using good design principles from day one
32:21
On day one, you might look at this and go, oh, come on. It's not that big a deal
32:25
I can come here and change this. But we don't know where this application is going
32:29
We don't know how complex it's going to go. And so by following good design principles from day one, we can get this right
32:36
It's also good practice to do things on the easier examples so we're ready for the harder examples
32:41
Let's take a look at an open example of this. In an open example, I have this membership validator, open membership, and it has the same method called validate root user
32:52
But in this case, when I declare my open membership validator, when I define it, I pass in a list of rules
32:59
I pass in a list of rules. And then the validate method, all it has to do is loop through each one of the rules, loop through them, and call their validate method
33:09
Simple as can be. And here's an example of the rules. I might have an abstract class or something like that, or an interface that has a validate method
33:17
There's a lot of ways you can do this. And then I might have a username length rule
33:23
And here's that username rule. Simple as that in its own little validate method
33:28
I might have the password length rule. Same little logic in its own validate method
33:33
Okay. And then all I do is when I set up my validator, I pass in the list of rules, as many as I want to do
33:41
and I can just call it. Now, if you want to change a rule, I'm open for extension
33:46
I can create as many rules as I want. I run no risk of breaking the additional rules the existing rules This is open for extension And wow it says I have 13 minutes And I thought I had a 45 presentation
34:01
So we're going to rock through this stuff. I thought I had a little bit more time
34:07
Let's keep rolling here. So let's look at the Liskov substitution principle
34:13
which says that functions that use pointers or references to base classes
34:18
must be able to use objects of derived classes without knowing it
34:23
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
34:31
You want to think about in your inheritance model, for example, we were always told to say, use an is a relationship
34:41
The class that I'm creating is a base class. It is one
34:45
But we really want to think about it differently. We want to think about, is it substitutable for it
34:50
And the classic example here of this is, and I'm going to move a little quicker through these
34:57
is the Liskov substitution principle here, which says we have a rectangle, which has a height and a width
35:03
and we have a square. And if I was focused on geometry, I would know that a square is a rectangle
35:11
It is, right? It is a rectangle in the world of geometry
35:14
But in terms of software, it is not because I might call down here and say, right, if I inherit rectangle into square, I can set the height and I can set the width
35:25
And quite frankly, this just introduces problems. Could it work? Yeah. You can be careful and you can set the height to be 100 and you can set the width to be 100
35:34
There's a lot of ways you can sort of fake your way into making this right. But the bottom line is it's not right
35:40
I can't use a square in the same way I could use a rectangle. So that's a quick one. I'm going to move past that and keep going because that's a, you know, I can sort of move on from that easy one there
35:53
Next is the interface segregation principle. And I think I can do this one pretty quickly, too
35:57
Clients should not be forced to depend upon interfaces that they don't need, that they don't use
36:04
What does that mean? Clients should not be forced to depend upon interfaces that they don't use
36:09
when we build our interfaces, here's an example of one. I might have a generic repository, and I have this IRepository interface
36:19
that my repository is going to implement. And if I build out my interface, I might have things like a find method
36:30
I might have a get method. And I might have an add, update, and delete method
36:35
Okay, sure. And I've written repositories like that many times with interfaces like that
36:41
But then you go and you say, hey, but some of the teams that are using that repository
36:45
they are read-only, right? They don't even change the data. So why should they have to implement I repository when they don't need add, update, or delete
36:54
So what if we have an I read-only repository, which has the find and the get
36:59
Okay, and you can break this down even more. You could have a find, I find
37:04
You could have an I get if you want. There's a lot of ways you can break these things down, right
37:08
But I'm showing a good example here. And then I might have this writable repository, and that one has add, update, or delete
37:15
Now, if I wanted to, and I don't have to, I could even say that the I writable repository
37:20
implements the read-only repository, because usually when you do writing, you're also doing reading
37:26
But you don't have to. I could take that off and then say you could do them any way you want
37:32
There's a lot of ways you could put this stuff together and compose these things
37:36
That is a quick example of the interface segregation principle. And last of the solid principles is the D right where it solid the dependency inversion principle And this dependency inversion principle says that high modules should not depend on low modules
37:57
Both should depend on abstractions. And it says abstractions should not depend on details
38:04
Details should depend on abstractions. Okay. So let's take a look at that, right
38:12
What that really means is we want to put the abstraction in the middle
38:18
If I look at my examples here, I have this earlier dependency inversion
38:26
Earlier here, we had this join method that had these dependencies. Now, in these cases, I'm implementing this class, this join method in this class
38:37
with a hard dependency on the membership validator, on all these things, on the message formatter
38:43
on the notification notifier. Why is that a problem? Well, the notifier may have a dependency
38:49
on something like SMTP mail, right? My membership service may have a dependency
38:54
on entity framework or something like that, right? Because this is hard coded
38:59
This is the way it's built. But if I want to have a way that I can, the problem with this now is if I change any of these things
39:07
I have to recompile everything, right? And maybe in a perfect world, we take these membership validators
39:13
and these services and all these things, and not only put them in different classes, but put them into different projects
39:18
Now, we put them in different projects, they get compiled separately. So let's say I take the interfaces of all these things
39:27
and I put them in their own DLL, and I put the implementation in separate DLLs
39:32
and now this implementation of this join method uses the interfaces, and now it's sort of like the interfaces in the middle
39:42
So here's my IA membership validator, my IA membership service, et cetera
39:46
We go down a line, and here's my version of join using dependency inversion
39:51
In this case, it's using interfaces, okay? And this project, the thing that my class here is in
40:00
doesn't care if I recompile or change the implementation of my SMTP mail to some other type of mail
40:09
whatever it is, it doesn't care about that because I put the interface in the middle
40:15
And those are the solid principles very quick at the end. And I hope I have a couple minutes here to talk very briefly about standards
40:23
And I can do this really quickly. Naveen earlier was talking about the role of an architect and how important standards are
40:30
It's really important to have standards to help solve problems, to help with collaboration
40:36
When you have great standards, and we're sort of shifting gears here, although following
40:40
good design principles can be one of your standards. The standards are great
40:47
It gives developers things to work on when they're doing code reviews. It gives them sort of a framework for code reviews and things like that
40:54
It can be super helpful for collaboration and team flexibility and onboarding
40:58
If you have a standard and you can hand a document to someone or point them in the right direction of the standards, then it's easy for onboarding
41:07
And it's great for saying, hey, we need some help on team A over here
41:12
Can somebody from team B come over? They're going to be able to look at that code within certain aspects of it
41:18
Not crazy, but they can look at aspects of that and say, yeah, I'm comfortable in this place because we have good standards
41:24
And the code looks similar. Okay. It looks similar. So I said earlier, be pragmatic
41:32
Don't be dogmatic. Think about standards that are reasonable for your developers
41:37
Don't be an ivory tower architect. Don be up there saying oh all developers you must do it in such a way right Explain to them why right Find standards that help them do their jobs and that make their jobs easier for them
41:55
and give them the room to be able to be creative still, right? And don't come up with principles
42:02
that are so rich and so hard that there's no room for flexibility
42:10
And I'm going to go right down this one. And also important to know your team, right
42:14
What do they need? What kind of help do they need? What will get in the way
42:18
Leave room for improvisation and innovation. And remember, what would you want
42:22
if you were the developer? Would you want the architect telling you how to write every line of code
42:26
Absolutely not. I know I would, right? I want to have standards that make sense
42:31
and you also want to think about how you would enforce your standards. We're going to skip that
42:35
We're going to come to a couple of quick examples, and I'm going to go through these. We have samples
42:40
Here's an example of a standard that we have. We don't say you have to write every line of code
42:45
We have some naming conventions. We have policies that say you must have code reviews
42:51
You might want to have solution project organizations. We're going to use a certain folder structure
42:57
for how we organize our files. That makes it really easy for when developers are swapping teams to come in and go, oh, I know where that stuff's going to be
43:05
I understand that. You might have a standard for logging, right? That's an important standard
43:10
I'm not telling you how to write every line of code, but I'm saying you need to log your exceptions into a central repository or we can find that information later
43:18
And then here's an example, a specific example of how I would write a standard. And I want you to just show, and this will be where I'll wrap up the standards
43:25
this will show sort of the sort of flexible approach and the way we try to approach it
43:31
We say, and this is down here at the bottom, for data access, we will use an ORM as a first choice
43:37
As a first choice. I don't say you have to use an ORM because if I do that, developers will come to me and say
43:43
yeah, but it's too slow. I have to use the stored procedure for something
43:47
And we have a standard that says I have to use an ORM. And my standard says use an ORM as a first choice
43:53
And this is a standard that works for my team, knowing the kind of code we write
43:56
It might not work for you. Don't use a standard because Andy says to use a standard
44:01
Use a standard. Find a standard that works for you. We say use an ORM as a first choice
44:07
And then if for some reason that's not working, go to the stored procedure, right
44:12
Maybe you need to do bulk inserts or something like that. That's where a stored procedure would be much better than an ORM, okay
44:18
And then the next line says, when using an ORM, your first choice will be Entity Framework
44:24
We choose a framework like that because our developers are familiar with it
44:28
Sure, some developers may know other ORMs and they may like another ORM
44:33
But what I say to them is, it's just not that big enough a reason to allow people to just use whatever ORM they want
44:41
The ORMs are generally pretty good. Entity Framework is a good ORM. And I need that ability to be able to have people come on and learn quickly
44:48
And if they have to keep learning new RMS all the time, it adds complexity
44:53
So, again, I'm choosing libraries. I'm choosing frameworks as part of my standards
44:58
And, again, it says first choice entity framework. It means if there's a reason, if there's a real good reason why you can't use it, come to me
45:05
Let's talk about it. Let's use the other one. And now I think that brings me back to just that wrap-up slide
45:15
I don't know if we're going to talk or not, but this is just in case people want to remember how to contact me
45:19
Thank you. Sorry I was going really fast at the end. I think we're a little short on time. But I am I see Magnus joining in. Hello, Magnus. I see Mahesh. Mahesh is on mute
45:32
Thanks. I hope that was fun. I hope you enjoyed that. I had a good time
#Web Design & Development
#Skins, Themes & Wallpapers


