Book Image

Mastering C# and .NET Framework

Book Image

Mastering C# and .NET Framework

Overview of this book

Mastering C# and .NET Framework will take you in to the depths of C# 6.0/7.0 and .NET 4.6, so you can understand how the platform works when it runs your code, and how you can use this knowledge to write efficient applications. Take full advantage of the new revolution in .NET development, including open source status and cross-platform capability, and get to grips with the architectural changes of CoreCLR. Start with how the CLR executes code, and discover the niche and advanced aspects of C# programming – from delegates and generics, through to asynchronous programming. Run through new forms of type declarations and assignments, source code callers, static using syntax, auto-property initializers, dictionary initializers, null conditional operators, and many others. Then unlock the true potential of the .NET platform. Learn how to write OWASP-compliant applications, how to properly implement design patterns in C#, and how to follow the general SOLID principles and its implementations in C# code. We finish by focusing on tips and tricks that you'll need to get the most from C# and .NET. This book also covers .NET Core 1.1 concepts as per the latest RTM release in the last chapter.
Table of Contents (21 chapters)
Mastering C# and .NET Framework
Credits
About the Author
Acknowledgements
About the Reviewer
www.PacktPub.com
Preface
Index

Dependency Inversion principle


The last of the SOLID principles is based on two statements, that Wikipedia states in this form:

  • High-level modules should not depend on low-level modules. Both should depend on abstractions.

  • Abstractions should not depend upon details. Details should depend upon abstractions.

As for the first statement, we should clarify what we understand by high-level and low-level modules. The terminology is related to the importance of the actions performed by the module.

Let's put it simply: if a module holds the business logic of a Customers class, and another includes the format that a list of the Customers class uses in a report, the first one would be high-class and the second would be low-class.

The second statement speaks by itself. If an abstraction depends on details, the usage as a definition contract is compromised.

In the case of our sample, we still have some code that will not grow appropriately: the SportsCar creation method depends much on what the user writes...