Design Principles for Low Level Design

Code like order.GetCustomer().getAddress().getZipCode() violates the Law of Demeter. This code is coupled to the internal structure of three different objects. Instead, have Order.getCustomerZipCode() that handles the navigation internally.

Method chaining itself is not the problem. Fluent interfaces like builder.setName("John").setAge(30).build() are fine because they return the same object type, e.g., PersonBuilder.

Your UI layer shouldn’t contain business logic. Your business logic shouldn’t know how data is stored. Your data access layer shouldn’t format strings for display.

Compare:

public class TicTacToe
{
  private readonly char[,] _board = new char[3, 3];

  public void Play()
  {
    while (true)
    {
      // Display logic...
      for (var r = 0; r < 3; r++)
        Console.WriteLine($"{_board[r, 0]}{_board[r, 1]}{_board[r, 2]}");

      // Input handling...
      var row = int.Parse(Console.ReadLine() ?? "0");
      var col = int.Parse(Console.ReadLine() ?? "0");
      _board[row, col] = 'X';

      // Game rules...
      if (_board[0, 0] == _board[1, 1] && _board[1, 1] == _board[2, 2])
      {
        Console.WriteLine("Winner!");
        break;
      }
    }
  }
}

… to:

public class TicTacToe
{
  private readonly Board _board = new();
  private readonly Display _display = new();
  private readonly InputHandler _inputHandler = new();

  public void Play()
  {
    while (!_board.HasWinner())
    {
      display.Render(_board);
      var move = _inputHandler.GetNextMove();
      _board.MakeMove(move);
    }

    _display.ShowWinner(_board.GetWinner());
  }
}

… where the game rules, display, and input handling are separate, e.g., switching from a console input to a GUI only touches InputHandler.

YAGNI doesn’t mean “never think ahead”; it means “don’t build ahead”. Design with extension in mind, but only implement what’s needed now. If designing a parking lot system, don’t add support for valet parking and electric vehicle charging stations unless the requirements specifically mention them.

Used without continuous refactoring, YAGNI could lead to lots of disorganized code and massive rework. YAGNI is dependent on supporting practices such as continuous refactoring, continuous automated tests, and continous integration.

If three classes all validate email addresses in the same way, create a shared validation method. That way, if email validation rules change, you update the one method.

Sometimes the simplest solution is to duplicate code in two places rather than build an abstraction. The key is whether the logic is conceptually the same, not just textually similar.

Frequently, devs over-engineer to flex design pattern knowledge or anticipate extensions that never come. Distinguish between problems that need sophisticated solutions and problems that need simple ones.

If a single class handles the job without getting messy, don’t split it up. If it grows to 500 lines with 10 different responsibilities, then refactor.

If you can solve the problem with a simple conditional, use that. If adding a new payment method means modifying code in five places, then introduce a Strategy pattern. But start simple.