История изменений

Это встроенный API.

Он в Java далёк от идеала, тут соглашусь. Особенно то, что проектировали давным давно, в самых первых версиях.

Но вообще для тебя, видимо, и сишный struct это ООП. Тут ты не прав.

Если говорить более предметно, то ООП это:

Объединение данных и методов. Это плохо, этим пользоваться не надо, данные и алгоритмы должны быть разделены. Естественно это не значит, что нельзя использовать поля, это философский пункт. Сделать сеттер с валидацией значения это нормально, сделать класс-сервис, у которого поля сервисы, инициализируемые по принципу IoC, это нормально. Сделать класс, который в себе хранит данные и сам же умеет их сохранять в БД, это уже ненормально.
Защита данных, разделение реализации и представления. Это нормально.
Использование интерфейсов и классов-реализаций. Это бывает полезно, много паттернов на этом строятся. Это нормально.
Наследование интерфейсов. Это тоже нормально.
Наследование классов. А вот тут начинается настоящее ООП, вкупе с первым пунктом, и вот именно этот пункт привносит все проблемы. Поэтому тут строго нет.

Это не значит, что в программе нельзя использовать extends. Как минимум, мы пользуемся фреймворками, которые написали пусть и не совсем умные, но всё же старательные люди, и пользоваться ими надо так, как задумано. Если во фреймворке задумано наследование для реализации какого-то функционала, придётся это сделать. Но по-хорошему это делать не надо было бы.

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

Это встроенный API.

Он в Java далёк от идеала, тут соглашусь. Особенно то, что проектировали давным давно, в самых первых версиях.

Но вообще для тебя, видимо, и сишный struct это ООП. Тут ты не прав.

Если говорить более предметно, то ООП это:

Объединение данных и методов. Это плохо, этим пользоваться не надо, данные и алгоритмы должны быть разделены. Естественно это не значит, что нельзя использовать поля, это философский пункт. Сделать сеттер с валидацией значения это нормально, сделать класс-сервис, у которого поля сервисы, инициализируемые по принципу IoC, это нормально. Сделать класс, который в себе хранит данные и сам же умеет их сохранять в БД, это уже ненормально.
Защита данных, разделение реализации и представления. Это нормально.
Использование интерфейсов и классов-реализаций. Это бывает полезно, много паттернов на этом строятся. Это нормально.
Наследование интерфейсов. Это тоже нормально.
Наследование классов. А вот тут начинается настоящее ООП, вкупе с первым пунктом, и вот именно этот пункт привносит все проблемы. Поэтому тут строго нет.

Это не значит, что в программе нельзя использовать extends. Как минимум, мы пользуемся фреймворками, которые написали пусть и не совсем умные, но всё же старательные люди, и пользоваться ими надо так, как задумано. Если во фреймворке задумано наследование для реализации какого-то интерфейса, придётся это сделать. Но по-хорошему это делать не надо было бы.

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

Это встроенный API.

Он в Java далёк от идеала, тут соглашусь.

Но вообще для тебя, видимо, и сишный struct это ООП. Тут ты не прав.

Если говорить более предметно, то ООП это:

Объединение данных и методов. Это плохо, этим пользоваться не надо, данные и алгоритмы должны быть разделены. Естественно это не значит, что нельзя использовать поля, это философский пункт. Сделать сеттер с валидацией значения это нормально, сделать класс-сервис, у которого поля сервисы, инициализируемые по принципу IoC, это нормально. Сделать класс, который в себе хранит данные и сам же умеет их сохранять в БД, это уже ненормально.
Защита данных, разделение реализации и представления. Это нормально.
Использование интерфейсов и классов-реализаций. Это бывает полезно, много паттернов на этом строятся. Это нормально.
Наследование интерфейсов. Это тоже нормально.
Наследование классов. А вот тут начинается настоящее ООП, вкупе с первым пунктом, и вот именно этот пункт привносит все проблемы. Поэтому тут строго нет.

Это не значит, что в программе нельзя использовать extends. Как минимум, мы пользуемся фреймворками, которые написали пусть и не совсем умные, но всё же старательные люди, и пользоваться ими надо так, как задумано. Если во фреймворке задумано наследование для реализации какого-то интерфейса, придётся это сделать. Но по-хорошему это делать не надо было бы.

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

Это встроенный API.

Он в Java далёк от идеала, тут соглашусь.

Но вообще для тебя, видимо, и сишный struct это ООП. Тут ты не прав.

Если говорить более предметно, то ООП это:

Объединение данных и методов. Это плохо, этим пользоваться не надо, данные и алгоритмы должны быть разделены. Естественно это не значит, что нельзя использовать поля, это философский пункт. Сделать сеттер с валидацией значения это нормально, сделать класс-сервис, у которого поля сервисы, инициализируемые по принципу IoC, это нормально. Сделать класс, который в себе хранит данные и сам же умеет их сохранять в БД, это уже ненормально.
Защита данных, разделение реализации и представления. Это нормально.
Использование интерфейсов и классов-реализаций. Это бывает полезно, много паттернов на этом строятся. Это нормально.
Наследование интерфейсов. Это тоже нормально.
Наследование классов. А вот тут начинается настоящее ООП, вкупе с первым пунктом, и вот именно этот пункт привносит все проблемы. Поэтому тут строго нет. Опять же я не спорю, что возможно в мире существуют ситуации, когда наследование классов уместно. Но я таких ситуаций не встречал пока. Везде, где использовалось наследование классов, оно было не уместно и могло бы быть заменено на более подходящую композицию и/или использование интерфейсов, от чего архитектура решения бы только выиграла.

Опять же это не значит, что в программе нельзя использовать extends. Как минимум, мы пользуемся фреймворками, которые написали пусть и не совсем умные, но всё же старательные люди, и пользоваться ими надо так, как задумано. Если во фреймворке задумано наследование для реализации какого-то интерфейса, придётся это сделать. Но по-хорошему это делать не надо было бы.

Это встроенный API.

Он в Java далёк от идеала, тут соглашусь.

Но вообще для тебя, видимо, и сишный struct это ООП. Тут ты не прав.

Если говорить более предметно, то ООП это:

Объединение данных и методов. Это плохо, этим пользоваться не надо, данные и алгоритмы должны быть разделены. Естественно это не значит, что нельзя использовать поля, это философский пункт. Сделать сеттер с валидацией значения это нормально, сделать класс-сервис, у которого поля сервисы, инициализируемые по принципу IoC, это нормально. Сделать класс, который в себе хранит данные и сам же умеет их сохранять в БД, это уже ненормально.
Защита данных, разделение реализации и представления. Это нормально.
Использование интерфейсов и классов-реализаций. Это бывает полезно, много паттернов на этом строятся. Это нормально.
Наследование интерфейсов. Это тоже нормально.
Наследование классов. А вот тут начинается настоящее ООП, вкупе с первым пунктом, и вот именно этот пункт привносит все проблемы. Поэтому тут строго нет.

Опять же это не значит, что в программе нельзя использовать extends. Как минимум, мы пользуемся фреймворками, которые написали пусть и не совсем умные, но всё же старательные люди, и пользоваться ими надо так, как задумано. Если во фреймворке задумано наследование для реализации какого-то интерфейса, придётся это сделать. Но по-хорошему это делать не надо было бы.

Это встроенный API.

Он в Java далёк от идеала, тут соглашусь.

Но вообще для тебя, видимо, и сишный struct это ООП. Тут ты не прав.