Я думал, что ООП — это просто «IS-A»… Пока одно собеседование не уничтожило мою уверенность

Я до сих пор помню то собеседование, на котором чувствовал себя необычно уверенно

DSA? Готово. SQL? Справлюсь. Базовая Java? Легко

Потом интервьюер улыбнулся и спросил:

«Можете объяснить отношение HAS-A в ООП?»

И мой мозг мгновенно открыл внутри себя 47 вкладок Chrome

Потому что в моём представлении отношения в ООП были примерно такими:

Всё. Я знал наследование. Я знал extends. Я знал «IS-A»

Я думал, что этого достаточно

Потом интервьюер продолжил:

«В чём разница между Aggregation и Composition?»

В этот момент даже потолочный вентилятор начал меня осуждать. 😅

Собеседование дало мне понять, что знание синтаксиса не равно умению проектировать программное обеспечение

Отношения между классами — это ключевая часть ООП, которая часто недооценивается. Многие новички учат классы, объекты и наследование, но упускают из виду фактические связи между объектами, которые требуются для проектирования эффективных систем

Применение CSS в Java-приложениях показывает, как два языка могут взаимодействовать для создания более сложных приложений. CSS и Java: как использовать CSS для стилизации объектов в Java-приложениях

Применение CSS в Java-приложениях показывает, как два языка могут взаимодействовать для создания более сложных приложений. CSS и Java: как использовать CSS для стилизации объектов в Java-приложениях

Почему отношения между классами важны

Представьте, что вы создаёте приложение для доставки еды

Настоящий вопрос — как эти объекты связаны между собой?

Создание программного обеспечения — это не просто работа с классами; это умение проектировать отношения между ними

Наследование — знаменитое отношение «IS-A»

Это обычно первое отношение, которое все изучают

Наследование означает: один класс становится специализированной версией другого класса

Примеры из реальной жизни:

Пример на Java

class Animal { void eat() { System.out.println("Animal eats food"); }
}
class Dog extends Animal { void bark() { System.out.println("Dog barks"); }
}
public class Main { public static void main(String[] args) { Dog d = new Dog(); d.eat(); // унаследовано от Animal d.bark(); // собственный метод Dog }
}

Что здесь происходит

Dog унаследовал метод eat() от Animal с помощью ключевого слова extends. Это означает:

• Dog получает все методы и свойства Animal
• Dog также может иметь собственные методы, например bark()
• Dog становится разновидностью Animal — поэтому везде, где ожидается Animal, можно использовать Dog

Зачем использовать наследование

Без наследования каждый класс животного повторял бы одну и ту же логику eat():

class Dog { void eat() {} }
class Cat { void eat() {} }
class Cow { void eat() {} }
// Много повторяющегося кода!

Наследование решает это через повторное использование кода — напишите один раз, наследуйте везде

⚠️ Продвинутое понимание

Наследование создаёт тесную связанность. Если родительский класс сильно изменится, дочерние классы могут неожиданно сломаться. Именно поэтому в современной разработке часто говорят:

«Предпочитайте Composition вместо Inheritance.»

Мы разберём это позже

Ассоциация — классы, которые просто знают друг друга

Ассоциация гораздо чаще встречается в реальных приложениях

Ассоциация означает, что два объекта взаимосвязаны, но ни один из них не контролирует другой. Они могут существовать независимо

Пример на Java

class Teacher { String name; Teacher(String name) { this.name = name; }
}
class Student { String name; Teacher teacher; // Student "знает" Teacher Student(String name, Teacher teacher) { this.name = name; this.teacher = teacher; } void study() { System.out.println(name + " studies under " + teacher.name); }
}
public class Main { public static void main(String[] args) { Teacher t1 = new Teacher("Sharma Sir"); Student s1 = new Student("Yukti", t1); s1.study(); }
}

Ключевое понимание

Student хранит ссылку на Teacher — он знает учителя. Но:

• Teacher может существовать без какого-либо Student
• Student может существовать без Teacher

Поэтому это слабое, общее отношение

Типы ассоциации

Это становится крайне важным, когда вы позже проектируете базы данных:

• Один-к-одному — один учитель, один студент
• Один-ко-многим — один учитель, много студентов
• Многие-ко-многим — много учителей, много студентов

Агрегация и Композиция — два лица отношения HAS-A

Вот где начинается самое интересное — и именно здесь большинство разработчиков путаются на собеседованиях

Агрегация — слабое HAS-A

Агрегация означает: один объект содержит другой объект, но содержащийся объект может существовать независимо, даже если контейнер уничтожен

Department has Teachers → Если кафедра закрыта, преподаватели всё равно существуют

Team has Players → Если команда расформирована, игроки всё равно существуют

Library has Books → Если библиотека сгорит… ну, будем надеяться, что книги уцелеют 📚

class Teacher { String name; Teacher(String name) { this.name = name; }
}
class Department { String deptName; Teacher teacher; // Department HAS-A Teacher (слабо) Department(String deptName, Teacher teacher) { this.deptName = deptName; this.teacher = teacher; // Teacher передаётся СНАРУЖИ } void display() { System.out.println(teacher.name + " works in " + deptName); }
}
public class Main { public static void main(String[] args) { Teacher t1 = new Teacher("Yukti"); // Создан независимо Department d1 = new Department("Computer Science", t1); d1.display(); // Даже если d1 удалён, t1 (Teacher) всё равно существует }
}

Обратите внимание на ключевую строку:

Teacher t1 = new Teacher("Yukti"); // Создан ВНЕ Department

Объект Teacher был создан отдельно и затем передан в Department. Это означает, что Department использует учителя, но не владеет его жизненным циклом и не контролирует его. Вот в чём суть агрегации — дочерний объект является независимой сущностью

Композиция — сильное HAS-A

Вот где интервьюеры становятся опасными. 😅

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

Human has Heart → Сердце без человека (в данном контексте) не может функционировать самостоятельно

House has Rooms → Снесите дом — комнаты исчезнут

Car has Engine → Сдайте машину в утиль — двигатель уйдёт вместе с ней

class Heart { void beat() { System.out.println("Heart is beating"); }
}
class Human { private Heart heart; // Human HAS-A Heart (сильно) Human() { heart = new Heart(); // Heart создаётся ВНУТРИ Human } void live() { heart.beat(); System.out.println("Human is alive"); }
}
public class Main { public static void main(String[] args) { Human h = new Human(); h.live(); // Когда h уничтожается, Heart внутри него тоже исчезает }
}

Принципиальное отличие от агрегации — внутри Human:

heart = new Heart(); // Создаётся ВНУТРИ родителя

Родитель создаёт дочерний объект. Объект Heart не существует вне Human. Это означает: сильное владение, единый жизненный цикл, дочерний объект не имеет самостоятельного существования

Aggregation в сравнении с Composition — любимый вопрос на собеседованиях

Этот вопрос встречается почти на каждом собеседовании по ООП. Давайте упростим его раз и навсегда

Задайте себе один вопрос: «Может ли дочерний объект существовать без родителя?»

• ДА → Aggregation
• НЕТ → Composition

Один вопрос решает спор каждый раз

Зависимость — временное отношение

Зависимость (Dependency) — самое непринуждённое из всех отношений

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

Customer uses ATM (временно)

Computer uses Printer (когда нужно)

User uses Internet (на основе сессии)

class Printer { void printDocument() { System.out.println("Printing document..."); }
}
class Computer { // Printer НЕ хранится как поле — используется только временно void print(Printer p) { p.printDocument(); // Использует Printer только для этого вызова метода }
}
public class Main { public static void main(String[] args) { Printer p1 = new Printer(); Computer c1 = new Computer(); c1.print(p1); // Временное использование — нет постоянной связи }
}

Computer не хранит Printer как поле класса. Он просто получает его как параметр метода и использует для одного вызова. Как только метод завершён, связь исчезает. Если Printer завтра изменится, Computer может потребовать небольшого обновления — именно это делает это зависимостью: он знает о Printer, но лишь едва

Общая картина: все пять отношений

Отношение	Значение	Сила	Время жизни
Inheritance	IS-A	Сильная	Постоянное
Association	Knows-A	Слабая	Может быть постоянным
Aggregation	HAS-A (слабая)	Умеренная	Независимое
Composition	HAS-A (сильная)	Сильная	Общее
Dependency	USES-A	Слабейшая	Временное

Пример из реальной жизни: приложение для доставки еды 🍕

Давайте свяжем всё воедино на примере реального приложения

Inheritance — IS-A

User
├── Customer
└── DeliveryPartner

Оба являются специализированными типами User

Association — Knows-A

Customer ↔ Restaurant

Покупатель взаимодействует с ресторанами, но оба существуют независимо

Aggregation — Weak HAS-A

Team ◇---- DeliveryPartner

У команды доставки есть партнёры, но если команда распускается, партнёры (сотрудники) всё равно существуют

Composition — Strong HAS-A

Order ◆---- OrderItem

Order владеет своими OrderItems. Удалите заказ — и позиции исчезнут вместе с ним, они не имеют смысла сами по себе

Dependency — USES-A

PaymentService - - -> UPI_API

PaymentService временно вызывает UPI API для обработки платежа. Постоянная связь не хранится

Почему современная разработка выбирает Composition

Современная разработка программного обеспечения активно предпочитает Composition вместо Inheritance

Наследование со временем может стать жёстким и тесно связанным. Composition даёт:

• ✅ Гибкость — легко заменять поведение
• ✅ Модульность — каждая часть независима
• ✅ Более чистую архитектуру — легче рассуждать о коде
• ✅ Более лёгкое тестирование — можно мокировать (mock) отдельные компоненты

Именно поэтому современные фреймворки и паттерны проектирования — такие как Strategy, Decorator, Dependency Injection — повсеместно опираются на композицию

Забавно — то собеседование, где меня уничтожил вопрос про HAS-A, помогло мне больше, чем многие лёгкие собеседования

Потому что оно заставило меня перестать заучивать синтаксис и начать понимать проектирование

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

Если вы изучаете Java или готовитесь к собеседованиям, освоение этих отношений значительно улучшит:

• Ваши инстинкты проектирования кода
• Структуру ваших проектов
• Ваши ответы на собеседованиях
• Ваше понимание реальных систем

И самое главное — вы больше никогда не будете смотреть в потолок после вопроса: «Можете объяснить composition в сравнении с aggregation?» 😭

Ответы на эти вопросы могут быть для вас полезными

В чём принципиальная разница между Aggregation и Composition?

В Aggregation дочерний объект создаётся снаружи и передаётся в родительский — он может существовать независимо. В Composition дочерний объект создаётся внутри родителя и уничтожается вместе с ним. Простой тест: «Может ли дочерний объект жить без родителя?» — если да, это Aggregation; если нет, это Composition

Почему наследование считается опасным в больших системах?

Наследование создаёт тесную связанность между классами. Если родительский класс изменится, все дочерние классы могут сломаться непредсказуемым образом. Именно поэтому в современной разработке предпочитают Composition: каждый компонент независим, его легче заменить и протестировать

Что такое Dependency и чем она отличается от Association?

Dependency — это временная связь: объект использует другой только в рамках одного вызова метода, не сохраняя ссылку. Association — более устойчивая связь, когда один объект хранит ссылку на другой как поле класса. Dependency — самое слабое из всех отношений

Как отношения между классами проявляются на практике — например, в приложении для доставки еды?

Customer и Restaurant связаны через Association — оба существуют независимо. Order и OrderItem — это Composition: позиции заказа не имеют смысла без самого заказа. PaymentService и UPI API — Dependency: сервис вызывает API временно, без постоянной связи

Когда на собеседовании спрашивают про HAS-A, что именно имеют в виду?

HAS-A — это общее название для двух отношений: Aggregation (слабое HAS-A) и Composition (сильное HAS-A). Интервьюер, как правило, хочет услышать именно это различие: понимаете ли вы, что «иметь» объект может означать как слабое использование, так и полное владение его жизненным циклом