Skip to main content

Single responsibility

Single responsibility

THINGS THAT BELONG TOGETHER SHOULD STAY TOGETHER


What we're really aiming for when we're talking about SOLID code is supple code, code that's pliable, code that you can shape into different forms and where you can change the shape if it turns out that the original shape that you had in mind doesn't really correctly address the problem at hand. And this is very important, because you almost never have all the requirements up front. Even if you think you have all the requirements up front for a piece of software that you're programming, requirements change as you go along, and the point of writing SOLID code is to make the code so supple, so pliable, that when requirements change, you can also change the code to fit the new requirements. The purpose of SOLID is to make you more productive by making the code more maintainable. If the design is rigid, it signifies that does not accept change.

We define a responsibility as a reason to change. So another way to put the Single Responsibility Principle is to say that a class should have only one reason to change. Another way to put this is to say that each class should do one thing and do it well.


The class above performs logging, reading writing and caching also.

Separating each concern. Logging. We create a new class that does the logging



Use the instance of the newly created class. Use DI.


Move all the functionalities to their respective classes and finally the solution will have all the concerns separated.



We have a message store that uses these 3 classes. All classes perform


Comments

Popular posts from this blog

App Role assignment to service principal --

 Using Ms Graph Rest API's Permissions One of the following permissions is required to call this API. To learn more, including how to choose permissions, see  Permissions . Permission type Permissions (from least to most privileged) Delegated (work or school account) AppRoleAssignment.ReadWrite.All and Application.Read.All, AppRoleAssignment.ReadWrite.All and Directory.Read.All, Application.ReadWrite.All, Directory.ReadWrite.All Delegated (personal Microsoft account) Not supported. Application AppRoleAssignment.ReadWrite.All and Application.Read.All, AppRoleAssignment.ReadWrite.All and Directory.Read.All, Application.ReadWrite.All, Directory.ReadWrite.All Create 2 app registrations. App role owner will contain the app role that will be assigned to a service principal. The  reader role in approleowner will be added to the approlesubscriber Setup postman to use the Oauth auth flow to get a token for MS Graph. ClientId:   Application (client) ID for approlesubscrib...

ASp.net core 3.1 identity

It is just an extension to cookie authentication. We get a UI, Tables, helper classes, two factor authentication etc. Even EF and its database constructs. So instead of writing code for all of this we can just use these in built features. Extending Default Identity Classes Add a class that inherits from    public class AppUser : IdentityUser     {         public string Behavior { get; set; }     } Also change the user type in login partial.cs under shared folder Then add migrations and update db using migrations. We can customize further.  services.AddDefaultIdentity<AppUser>(options =>              {                 options.SignIn.RequireConfirmedAccount = true;                 options.Password.RequireDigit = false;           ...

Get user groups

 string[] scopes = new string[] { "https://graph.microsoft.com/.default" };             string clientId = "";             string tenantId = "";             string secret = "";                        var options = new TokenCredentialOptions             {                 AuthorityHost = AzureAuthorityHosts.AzurePublicCloud             };             // https://learn.microsoft.com/dotnet/api/azure.identity.clientsecretcredential             try             {                 var clientSecretCredential = new ClientSecretCredential(                        ...