"Demeter's Law": This means that "the less your class knows about other classes, the better";

1. Concept:

A software entity should interact with other entities as little as possible. Each software unit has the least knowledge of other units, and is limited to those software units closely related to the unit. The original purpose of Dimiter's Law is to reduce the coupling between classes. As each class minimizes its dependence on other classes, it is easy to make the functional modules of the system function independently, and there is no (or very few) dependency between them. Dimiter's law does not want to establish a direct link between classes. If there is a real need to establish contacts, also hope to be conveyed through its friend class. Therefore, one of the possible consequences of applying Dimiter's rule is that there are a large number of intermediary classes in the system. These classes exist solely for the purpose of transferring the call relationship between classes, which increases the complexity of the system to a certain extent.

2. Simulated scenarios:

Scenario: The company's chief financial officer gives instructions to people in the financial department to count the number of companies that the company has.

A Normal Programming: (Definitely a counterexample to LoD)

UML class diagram:

Code demo:

namespace TestLibrary.ExtensionsClass
{
    using System;
    using System.Collections.Generic;

    /// <summary>
    /// Chief Financial Officer
    /// </summary>
    public class CFO
    {
        /// <summary>
        /// The Chief Financial Officer issued a directive for the financial department to count the number of paid persons.
        /// </summary>
        public void Directive(Finance finance)
        {
            List<Employee> employeeList = new List<Employee>();
            // Initialization of payroll
            for (int i = 0; i < 500; i++)
            {
                employeeList.Add(new Employee());
            }

            // Tell the finance department to start counting the employees of the settled company
            finance.SettlementSalary(employeeList);
        }
    }

    /// <summary>
    //Finance Department
    /// </summary>
    public class Finance
    {
        /// <summary>
        /// Statistics of employees in settled companies
        /// </summary>
        public void SettlementSalary(List<Employee> employeeList) 
        {
            Console.WriteLine(string.Format("Number of settled wages:{0}", employeeList.Count));
        }
    }

    /// <summary>
    /// staff
    /// </summary>
    public class Employee
    {

    }

    /// <summary>
    //Main program
    /// </summary>
    public class Runner
    {
        public static void main(String[] args)
        {
            CFO cfo = new CFO();
            // Financial Controller Issues Directives
            cfo.Directive(new Finance());
        }
    }
}

According to the simulation scenario: the CFO asked the finance department to sum up the number of paid people. The CFO and the employee are strangers (that is, the director does not need to perform any operations on the employee). From the above UML diagrams and code solutions, it is clear that the above practices violate the LoD rule.

Decoupling according to LoD's law: (an example conforming to LoD)

UML class diagram:

Code demo:

namespace TestLibrary.ExtensionsClass
{
    using System;
    using System.Collections.Generic;

    /// <summary>
    /// Chief Financial Officer
    /// </summary>
    public class CFO
    {
        /// <summary>
        /// The Chief Financial Officer issued a directive for the financial department to count the number of paid persons.
        /// </summary>
        public void Directive(Finance finance)
        {
            // Notify the finance department to start counting the employees of the settled company
            finance.SettlementSalary();
        }
    }

    /// <summary>
    //Finance Department
    /// </summary>
    public class Finance
    {
        private List<Employee> employeeList;  

        //A person who passes on the company's wages.
        public Finance(List<Employee> _employeeList)
        {
            this.employeeList = _employeeList;  
    }  

        /// <summary>
        /// Statistics of employees in settled companies
        /// </summary>
        public void SettlementSalary() 
        {
            Console.WriteLine(string.Format("Number of settled wages:{0}", employeeList.Count));
        }
    }

    /// <summary>
    /// staff
    /// </summary>
    public class Employee
    {

    }

    /// <summary>
    //Main program
    /// </summary>
    public class Runner
    {
        public static void main(String[] args)
        {
            List<Employee> employeeList = new List<Employee>();

            // Initialization of payroll
            for (int i = 0; i < 500; i++)
            {
                employeeList.Add(new Employee());
            }

            CFO cfo = new CFO();

            // Financial Controller Issues Directives
            cfo.Directive(new Finance(employeeList));
        }
    }
}

According to the LoD principle, we need to make no connection between the CFO and the employees. That's the way to abide by Dimiter's Law.