This is the 12th day of my participation in the August More Text Challenge. For details, see: August More Text Challenge

Demeter’s (least knowledge) law: if two classes do not have to communicate directly with each other, then the two classes should not interact directly. If one class needs to call a method of the other class, the call can be forwarded through a third party.

The basic idea is that loose coupling between classes is emphasized. The weaker the coupling between classes, the more reuse is facilitated. A weakly coupled class can be modified without affecting the related classes.

This principle reflects a “high cohesion, low coupling” design philosophy.

For example, when I just came to work in the company, my computer broke down and I need someone from the technical department to fix it. I don’t need to know who the person is, I just need to know the director of the technical department. It’s his business to know who he wants to fix my computer. My goal is to get the computer fixed as soon as possible. Let’s use code to implement this small example.

Maintenance: repair.cs

namespace Dimiter
{
    /// <summary>
    ///Maintenance abstract class
    /// </summary>
    public abstract class repair
    {
        public abstract bool RepairComputer(); }}Copy the code

Maintenance technology Xiaowang.cs

namespace Dimiter
{
    /// <summary>
    ///Maintenance technology xiao Wang class
    /// </summary>
    public class xiaowang:repair
    {
        public override bool RepairComputer()
        {
            return false; }}}Copy the code

Maintenance technology Xiaoli class xiaoli.CS

namespace Dimiter
{
    /// <summary>
    ///Maintenance technology xiao Li class
    /// </summary>
    public class xiaoli:repair
    {
        public override bool RepairComputer()
        {
            return true; }}}Copy the code

Technical department Director. Cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dimiter
{
    /// <summary>
    ///In charge of class
    /// </summary>
    public class director
    {
        public bool res;
  
        public void CallRepair()
        {
            repair xiaowang = new xiaowang();
            res = xiaowang.RepairComputer();
            if (res)
            {
                Console.WriteLine("Xiao Wang went to fix your computer.");
                return;
            }
            
            repair xiaoli = new xiaoli();
            res = xiaoli.RepairComputer();
            if (res)
            {
                Console.WriteLine("Xiao Li went to fix your computer.");
                return;
            }
  
            Console.WriteLine("I'm coming."); }}}Copy the code

Client call: program.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace Dimiter
{
    /// <summary>
    ///The client
    /// </summary>
    class Program
    {
        static void Main(string[] args)
        {
            // I only need to contact the director of the technical department to find out who he will arrange to repair my computer.
            // It's nothing to do with me. My purpose is to fix the computer, right
            director dir = newdirector(); dir.CallRepair(); Console.ReadLine(); }}}Copy the code

The output is shown in the figure below:

To sum up: the pros and cons of Demeter’s law

Advantages:

:1: The practice concept of Demeter’s law is the decoupling between classes, weak coupling, only after the weak coupling, the class reuse rate can be improved.

Disadvantages:

1: The communication efficiency between different modules of the system is reduced, so that the different modules of the system are not easy to coordinate and other shortcomings. :2: Because Demeter’s law requires that classes do not communicate directly with each other as far as possible, if the communication between classes needs to be forwarded by a third party, which directly leads to the existence of a large number of mediation classes in the system, greatly increasing the complexity of the system. 3: the way of solving this problem is: use dependency inversion principle (popular speaking is to be aimed at interface programming, not for specific programming), and this can be between the caller and the called party with an abstraction layer, called party on the premise of following the abstraction layer is free of change, the abstraction layer became caller’s friends.

For good suggestions, please enter your comments below. Welcome to guanchao.site

Welcome to applet: