---
title: "Замена двунаправленной связи однонаправленной"
type: "refactoring-technique"
slug: "change-bidirectional-association-to-unidirectional"
url: "http://localhost:3000/ru/change-bidirectional-association-to-unidirectional.md"
category: "Организация данных"
description: "Проблема: У вас есть двухсторонняя связь между классами, но один из классов больше не использует фичи другого. Решение: Уберите неиспользуемую связь."
---
# Замена двунаправленной связи однонаправленной

> Проблема: У вас есть двухсторонняя связь между классами, но один из классов больше не использует фичи другого. Решение: Уберите неиспользуемую связь.

## Problem

У вас есть двухсторонняя связь между классами, но один из классов больше не использует фичи другого.

## Solution

Уберите неиспользуемую связь.

## Why Refactor

Двустороннюю связь, как правило, сложнее поддерживать, чем одностороннюю. Такая связь требует наличия дополнительного кода, который бы отслеживал корректное создание и удаление связанных объектов, что приводит к усложнению программы.

Кроме того, неправильно реализованная двусторонняя связь может приводить к проблемам с «очисткой мусора», т.е. освобождения памяти, занятой неиспользуемыми объектами.

Приведём пример: «сборщик мусора» удаляет из памяти объекты, на которые уже не осталось ссылок из других объектов программы. Допустим, была создана, использована, после чего заброшена пара объектов `Пользователь`\-`Заказ`. Однако эти объекты не будут очищены из памяти, так как они все ещё содержат ссылки друг на друга. Стоит, однако, заметить, что эта проблема теряет актуальность с течением времени. С ней уже научились бороться многие современные версии языков программирования, которые автоматически обнаруживают неиспользуемые связки объектов и успешно очищают их из памяти.

Кроме того, существует проблема тесной зависимости между классами. Двусторонняя связь предполагает, что два класса должны знать друг о друге, а значит, такие классы невозможно использовать отдельно друг от друга. Наличие множества таких двусторонних связей приводит к тому, что части программы становятся слишком тесно связанными, и любое изменение в одном из компонентов приводит к необходимости менять другие компоненты программы.

## Benefits

* Упрощает код класса, которому не нужна связь. Меньше кода — проще поддержка.
* Уменьшает зависимость между классами. Независимые классы проще поддерживать, так как изменения в них затрагивают только эти классы.

## How to Refactor

1. Убедитесь, что один из следующих пунктов справедлив в отношении ваших классов:

  * связь не используется вообще;
  * есть другой способ получить связанный объект, например, используя запрос к базе данных;
  * связанный объект может быть передан как аргумент в методы, которые используют его.
2. Избавьтесь от использование поля, содержащего связь с другим объектом. Проще всего заменить такую связь передачей нужного объекта в параметрах метода.
3. Удалите код присваивания связанного объекта полю.
4. Удалите неиспользуемое теперь поле.
## Relations

**Opposite refactorings**

- [Замена однонаправленной связи двунаправленной](/ru/change-unidirectional-association-to-bidirectional.md)

**Eliminates smells**

- [Неуместная близость](/ru/smells/inappropriate-intimacy.md)