10/12/2025
.NET Framework relation with Windows Version
.NET Framework
The .NET Framework is a software development platform developed by Microsoft.
Types of .NET Platforms : While ".NET Framework" refers specifically to the original Windows-only version, there are other types in the broader ".NET" ecosystem:
It provides a controlled environment for developing and running applications, primarily on Windows.
It includes a large class library called the Framework Class Library (FCL) and provides language interoperability across several programming languages, most notably C#, VB.NET, and F#.
Types of .NET Platforms : While ".NET Framework" refers specifically to the original Windows-only version, there are other types in the broader ".NET" ecosystem:
1. .NET Framework
Platform: Windows-only
Use Case: Legacy enterprise applications, desktop apps
Latest Version: .NET Framework 4.8.1 (as of 2023)
2. .NET Core
Platform: Cross-platform (Windows, macOS, Linux)
Use Case: Modern web apps, microservices
Status: Superseded by .NET 5+
3. .NET (formerly .NET 5 and later)
Platform: Unified and cross-platform
Use Case: Web, desktop, mobile, cloud, gaming, IoT
Latest Version: .NET 8 (as of 2024)
4. Mono/Xamarin
Platform: Mobile and embedded systems
Use Case: iOS and Android apps using C#
Status: Integrated into .NET MAUI
5. .NET MAUI (Multi-platform App UI)
Platform: Cross-platform UI framework
Use Case: Build native apps for Android, iOS, macOS, and Windows with a single codebase
Dependency Inversion Principle vs Dependency Injection
Dependency Injection:
A design pattern or technique used to implement DIP by injecting dependencies (like services or repositories) into a class, rather than the class creating them itself.
It is done using Constructor injection, property injection, DI containers(Autofac, Unity, Windsor Castle)
Dependency Inversion Principle
Instead of a class depending directly on another concrete class, it should depend on an interface or abstract class.This makes your code flexible, testable, and maintainable.
Easy to switch implementations (e.g., Service1, Service2). Easy to test using mocks. Follows DIP and promotes clean architecture
interface IService
{
public void ResetDevice();
}
public class Service1 : IService
{
public void ResetDevice() {// Sercice1 logic}
}
public class Service2 : IService
{
public void ResetDevice() {// Service2 logic}
}
public class Program
{
public static void Main()
{
IService service;
if(_soapVersion <= 1)
service = new Service1();
else
service = new Service2(); //easily replaceable, swithable
}
}
Without LSP:
Why the name inversion - The word "inversion" in Dependency Inversion Principle (DIP) refers to a reversal of the conventional direction of dependency in software design.
Without DIP: High-level modules (like business logic) depend on low-level modules (like database or email services).
This means the flow of control and design is top-down, and high-level logic is tightly coupled to implementation details.
With DIP: Both high-level and low-level modules depend on abstractions (interfaces or abstract classes).
The control is inverted: instead of high-level modules controlling low-level ones directly, they rely on abstractions that are implemented by low-level modules. - loosly coupled
Instead of a class depending directly on another concrete class, it should depend on an interface or abstract class.This makes your code flexible, testable, and maintainable.
Easy to switch implementations (e.g., Service1, Service2). Easy to test using mocks. Follows DIP and promotes clean architecture
interface IService
{
public void ResetDevice();
}
public class Service1 : IService
{
public void ResetDevice() {// Sercice1 logic}
}
public class Service2 : IService
{
public void ResetDevice() {// Service2 logic}
}
public class Program
{
public static void Main()
{
IService service;
if(_soapVersion <= 1)
service = new Service1();
else
service = new Service2(); //easily replaceable, swithable
}
}
Without LSP:Without DIP: High-level modules (like business logic) depend on low-level modules (like database or email services). This means the flow of control and design is top-down, and high-level logic is tightly coupled to implementation details.
With DIP: Both high-level and low-level modules depend on abstractions (interfaces or abstract classes). The control is inverted: instead of high-level modules controlling low-level ones directly, they rely on abstractions that are implemented by low-level modules. - loosly coupled
3/16/2025
IoC vs DI vs DIP
1.Inversion of Control (IoC)
A fundamental principle that inverts traditional control flow
Enables decoupling of components from their dependencies
Provides flexibility in how objects are created and managed
Enables decoupling of components from their dependencies
Provides flexibility in how objects are created and managed
2.Dependency Inversion Principle (DIP)
A design guideline that specifies how modules should relate
Ensures high-level modules don't depend directly on low-level ones
Promotes abstraction-based relationships
3.Dependency Injection (DI)
A concrete technique for implementing IoC
Provides a specific mechanism for delivering dependencies
Helps achieve the goals outlined by DIP
IoC is the broad principle that enables various patterns, DIP guides how modules relate to each other, and DI provides a specific technique for implementing both concepts. Together, they form a powerful foundation for building maintainable software systems.
3/15/2025
Liskov Substitution Principle
Without LSP:Example, we are creating different robots, Kawasaki, Yaskawa, and ABBRobots all inheriting IRobots and have methods like Connect(), Operate() , Move(). Later say some new functionality in ABBRobots like ReportFaultData() is introduced, so we need to added ReportFaultData() in interface and other robots should do " throw NotSupportedException("Reporting fault data is not supported");" , this leads to compile time error or we need to do nothing, and so we need to change other classes.
With LPS:Instead we will create new interface ISupportsFaultDataReporting and add the new ReportFaultData() and inherit only for ABBRobots
public class ABBRobots : IRobots, ISupportsFaultDataReporting
{
}
public class Program
{
public static void Main()
{
List robots = new List{new Kawasaki(),new Yaskawa(),new ABBRobots()};
foreach (var robot in robots)
{
robot.Move();
if (robot is ISupportsFaultDataReporting faultDataReportingRobot)
{
faultDataReportingRobot.Report();
}
}
}
}
Without LSP:
Why the name substitution - The idea is that you should be able to substitute the base class with the derived class without breaking the functionality.
// Substituting base class with dereived class
Shape shape = new Rectangle(5, 10);
Without LSP:
Example, we are creating different robots, Kawasaki, Yaskawa, and ABBRobots all inheriting IRobots and have methods like Connect(), Operate() , Move(). Later say some new functionality in ABBRobots like ReportFaultData() is introduced, so we need to added ReportFaultData() in interface and other robots should do " throw NotSupportedException("Reporting fault data is not supported");" , this leads to compile time error or we need to do nothing, and so we need to change other classes.
With LPS:
Instead we will create new interface ISupportsFaultDataReporting and add the new ReportFaultData() and inherit only for ABBRobots
public class ABBRobots : IRobots, ISupportsFaultDataReporting
{
}
public class Program
{
public static void Main()
{
List robots = new List{new Kawasaki(),new Yaskawa(),new ABBRobots()};
foreach (var robot in robots)
{
robot.Move();
if (robot is ISupportsFaultDataReporting faultDataReportingRobot)
{
faultDataReportingRobot.Report();
}
}
}
}
Without LSP:
Why the name substitution - The idea is that you should be able to substitute the base class with the derived class without breaking the functionality.
// Substituting base class with dereived class
Shape shape = new Rectangle(5, 10);
Subscribe to:
Posts (Atom)