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.

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