Можете ли вы рассказать про зацепление и связность?

Слушай, а давай разберём эту парочку — Зацепление и Связность. Это как два чувака в коде: один отвечает за порядок у себя дома, другой — за то, чтобы не лазить к соседу через забор без спросу.

1. Связность (Cohesion) — это про то, насколько твой класс не раздолбанный, а собранный в кучу.

• Высокая связность — это охуенно. Это когда твой класс, как нормальный мужик, делает одно дело, но делает его хорошо. Все его методы — как одна банда, работают на одну цель.
• Вот пример класса, у которого связность — хуйня полная, пиздец. Он как мартышлюшка, которая и на дереве качается, и банан чистит, и в жопу себе тычет пальцем одновременно:

  class UserReport {
      public void generatePdf() { /* ... */ }
      public void calculateTax() { /* ... */ } // Нахуя тут налоги? Это же отчёт!
      public void sendEmail() { /* ... */ } // А это вообще откуда, блядь?
  }

  Чувак, это же пиздопроебибна! Один класс и отчёты генерит, и налоги считает, и письма шлёт. Доверия ебать ноль к такому уродцу.

• А вот как надо, чтобы было красиво и с высокой связностью:

  class UserReport { // Этот чувак знает только отчёты. И точка.
      public void generatePdf() { /* ... */ }
      public void generateCsv() { /* ... */ }
  }
  class TaxCalculator { // А этот — только налоги. Свой паёк знает.
      public void calculateTax() { /* ... */ }
  }

  Видишь разницу? Каждый занят своим делом. Никакой ерундой не страдает. Волнение ебать — на нуле, потому что всё предсказуемо.

2. Зацепление (Coupling) — это про то, насколько твой класс прилип к другим, как говно к ботинку.

• Слабое зацепление — это мечта. Это когда ты можешь поменять что-то у себя, и у соседа ничего не развалится. Живёшь сам и даёшь жить другим.
• Пример сильного, удушающего зацепления, от которого хочется впендюрить монитор:

  class OrderProcessor {
      private MySQLDatabase db = new MySQLDatabase(); // Жёстко вманджен конкретный MySQL! Хуй с горы!
      public void saveOrder(Order order) {
          db.query("INSERT INTO orders ..."); // И тут ещё SQL-запросы на прямую! Ёпта!
      }
  }

  Представь: завтра начальник скажет: «Давайте на PostgreSQL переедем». И ты, чувак, будешь ебать колотить этот класс, потому что он намертво прикручен к MySQL. Терпения ноль ебать с таким подходом.

• А вот слабое зацепление, когда ты умный и делаешь через интерфейсы и внедрение зависимостей:

  interface OrderRepository { // Абстракция, детка! Не важно, что под капотом.
      void save(Order order);
  }
  class OrderProcessor {
      private OrderRepository repository; // Держимся за интерфейс, а не за конкретную реализацию
      public OrderProcessor(OrderRepository repo) { // Говорим: «Дайте мне что-то, что умеет сохранять». И нам дают.
          this.repository = repo;
      }
      public void process(Order order) {
          repository.save(order); // А мы даже не в курсе, это SQL, файл или голубиная почта. **Да похуй!**
      }
  }

  Вот это красота! Хочешь — подсовывай реализацию для MySQL, хочешь — для MongoDB. Класс OrderProcessor даже не бзднет. Он просто работает.

Идеал, к которому надо стремиться, — это, блядь, высокая связность и слабое зацепление. Получается код, который легко понять (потому что классы не занимаются ерундой), легко тестировать (потому что зависимости можно подменить) и легко менять (потому что всё не сцеплено намертво). А иначе будет хиросима и нигерсраки при первой же попытке что-то обновить.