Author: Dhanik Lal Sahni

Dhanik Lal Sahni is a Salesforce Independent Consultant and Architect with extensive experience in Salesforce implementation, integration, and custom development. He helps businesses design scalable, AI-driven CRM solutions using Sales Cloud, Service Cloud, Experience Cloud, and Salesforce Data Cloud. As the founder of SalesforceCodex.com, Dhanik shares practical insights, tutorials, and architectural best practices to help professionals grow in the Salesforce ecosystem. Explore his consulting and freelance services at dhaniksahni.com , where he offers end-to-end Salesforce solutions for startups and enterprises worldwide.

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. According to this principle, component should be Open to ExtensionNew behavior can be added in the future. Closed to Modification Changes to source code is not required. Based on above statement, software entities should change behavior without changing code. For this, we have to use abstraction to implement behavior. In .NET we can use Interface and Abstract class to implement abstraction. Let us see an example of e-commerce application to calculate cart’s total amount. public class OrderItem { public string StockKeepingUnit { get; set; }…

Read More

According to Wikipedia the Dependency Inversion Principle (popularized by Robert Martin) states that: High Level Modules should not be depend upon low level modules. Both should depend upon abstractions. Abstraction should not depend upon details. Details should depend upon abstraction. In application architecture, UI is always on top level. All request goes from UI to business layer and then database layer. Database layer connects with database and fetch required data.   When we define Dependency Inversion Principle in above architectute, The presentation layer defines the abstractions it needs to interact with an business layer and the business layer defines the…

Read More

SRP states, “An object should have only one reason to change”. If an object has more than one reason to change then it has more than one responsibility and is in violation of SRP. An object should have one and only one reason to change. Let us take example of below code, where XML file with product information is parsed and displayed on screen. FileDialogReader.Filter = “XML Document (*.xml)|*.xml|All Files (*.*)|*.*”; var result = FileDialogReader.ShowDialog(); if (result == DialogResult.OK) { txtFileName.Text = FileDialogReader.FileName; lstProduct.Items.Clear(); var fileName = txtFileName.Text; using (var fs = new FileStream(fileName, FileMode.Open)) { var reader = XmlReader.Create(fs);…

Read More

SOLID Design Principle is a collection of best-practice,object-oriented design principles which can be applied to your application design. This allow us to accomplish various desirable goals such as loose-coupling, higher maintainability. SOLID is an acronym where: (S)RP: Single Responsibility Principle There should never be more than one reason to change any class. (O)CP: Open Closed Principle Software Entities (Classes, Modules, Functions, etc. ) should be open for extension but closed for any modification. (L)SP: Liskov Substitution Principle Function that use objects of base clasesses must be able to use objects of other dervied class wihout knowing it. (I)SP: Interface Segregation…

Read More

Singleton Design Pattern is used when we want to ensure that only one object of a particular class need to be created. All other objects will refer that object to get values. This pattern create object so it falls under Creation Pattern of Gang Of Four design patterns. Condition for Singleton Design Pattern: Singleton Design Pattern need to be implemented where below three requirements are satisfied Controls concurrent access to a shared resource Access to the shared resource will be requested from multiple, disparate parts of the system There can only be one object of class Some Example where we can use Singleton Design Pattern:…

Read More