SEVEN PEAKS SPEAKS

.NET Summer Meetup

SOLID Pattern in .NET

26.07.22

SEVEN PEAKS SOFTWARE

​

​

Cloud & Backend Team

Giorgio

Dinand

Korn

Nicolas

Siw

Bank

Khoa

Massimo

Mean

Phu

Steven

Thiha

Bond

Tanvi

Fir

Mredhul

Amit

Nazmul

Deepa

SEVEN PEAKS SOFTWARE

Giorgio Desideri

Senior cloud lead who have been working in IT since 2006.

​

I covered all the roles from System Engineer / Administrator until Project Manager, step through Development, Software Architecture, Integration, and Admin roles.

​

Certified cloud architect for AWS and Azure.

Why I am here ?

Let me explain why I present this subject today

Why am I here ?

Reason

• I was born on the 19th of June 1982 ( 40 years ago )
• These concepts was new for me
• These are the basics concepts for development
• IF ( I can consider myself OLD )
• THEN these concepts are old
• THEN they are always new for whom is starting now ( aka “the sky is blue” )

​

MOREOVER …

Why am I here ?

Reason

I found myself in several situations which raised these questions:

• Why the developers don’t know them ?
• Why the developers ignore them ?
• What are the obstacles / walls which block so much the developers ?

​

SO …

LET ME EXPLAIN THEM AGAIN !

Reason

Principles

Let’s Begin !

Principles

SOLID Acronym

SRP - Single Responsibility Principle

Principle #1

• In OOP, It states that “a class should have one and only one reason for the change” (*)

(*) Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445.

SRP - Single Responsibility Principle

Principle #1

• In OOP, It states that “a class should have one and only one reason for the change” (*)

​

• It is understood as “every module, class, function should have a responsibility over a single part of the software functionality”

(*) Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445.

SRP - Single Responsibility Principle

Principle #1

https://www.c-sharpcorner.com/article/single-responsibility-principal-srp/

OCP - Open Closed Principle

Principle #2

• In OOP, it states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”

OCP - Open Closed Principle

Principle #2

https://www.c-sharpcorner.com/UploadFile/pranayamr/open-close-principle/

OCP - Open Closed Principle

Principle #2

static class MyClassExtension

{

static void MyNewMethod(this MyClass mc)

{

// Do here what is new for you !

​

Console.WriteLine(“Hi Master,

I am here to serve you !”);

}

}

LSP - Liskov Substitution Principle

Principle #3

• Introduced by Barbara Liskov in 1988 as

​

Subtype Requirement:

Let ϕ ( x ) be a property provable about objects x of type T.

Then ϕ ( y ) should be true for objects y of type S where S is a subtype of T.

LSP - Liskov Substitution Principle

Principle #3

https://www.c-sharpcorner.com/article/solid-principles-in-c-sharp-liskov-substitution-principle/

LSP - Liskov Substitution Principle

Principle #3

// Dependency Injection

service

.AddTransient<ISavingAccount, SalaryAccount>();

​

​

// Facade, Proxy, Connectors

ISendEmailFacade sems =

new GmailSendEmailProxy(...);

new GenericSmtpFacade(...)

​

​

​

ISP - Interface Segregation Principle

Principle #4

• In OOP, it states ”that no code should be forced to depend on methods it does not use”

​

• Here you could hear the word “contract”
• “Contracts” could be
• an interface,
• or an abstract class

ISP - Interface Segregation Principle

Principle #4

• Patterns:
• Adapters
• Decorator
• Commander
• Remember
• “S” principle
• “I” principle

DIP - Dependency Inversion Principle

Principle #5

• Last but not least !
• It states (*)
• High-level modules should not import anything from low-level modules. Both should depend on abstractions
• Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

(*) Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. pp. 127–131. ISBN 978-0135974445.

DIP - Dependency Inversion Principle

Principle #5

DIP - Dependency Inversion Principle

Principle #5

DIP - Dependency Inversion Principle

Principle #5

Conclusion

Bring Away Points

CONCLUSION

Bring Away Points

• SOLID is the pattern built for a “good quality” development
• All the concepts are interconnected
• Use one means use all (or less)

​

• There is nothing between practice and theory, only you !
• Be Responsible

Q&A

Questions ?

UPCOMING MEETUP

Check out our event page

Stay tuned for what’s coming next!

​