Продолжаем про ООП.
Налицо поверхностное понимание. Я попробую сжато ответить на вопрос «зачем» (осознавая грандиозность замысла).
Давайте так. Задумайтесь над вопросом «зачем ООП», ответ дайте в нескольких словах. Выразите максимально емко все пользы ООП.
Не нажимайте «читать дальше» пока не ответили для себя.
Разумеется правильного ответа никто не знает. Но два самые главные пользы следующие:
1. УПРОЩЕНИЕ ПОНИМАНИЯ ЧЕЛОВЕКОМ
2. ЛОКАЛИЗАЦИЯ ВЛИЯНИЯ КОДА
1. Упрощение понимания — человеком. Ведь наш, человеческий, язык так и устроен. Помните шутку про «утку»?
Что такое «стул»? «Вот это стул, на нем сидят». Это одновременно и поведение, и предмет.
Человек привык обозначать _класс предметов схожего поведения_ одним словом, которое определяет его поведение.
Что же удивительного в том, что эта практика перекочевала в программирование?
Ведь гораздо проще рассуждать о стеке, чем об «этом наборе данных и кода, который отдает первым последний занесенный объект».
2. Локализация влияния.
Давайте представим себе неправильную разработку приложения. Например, есть структура с данными пользователя и есть структура записи журнала. При сохранении на диск с ними нужно работать одинаково — рассматривать их как непрерывный блок данных. Однако, эта работа не была проделана. Не было ВЫЯВЛЕНО ПОВЕДЕНИЕ. Значит в любом месте у нас дублируется код записи в файл, системные вызовы и т.д.
Начинаем расширять — хотим транзакционную запись. Как быть? Ее нужно прикрутить ее _ко всем местам_, где есть запись на диск.
И т.д. Через какое-то время расширение приложения становится СЛИШКОМ дорогостоящим. Получаем то, что называют «монолитное приложение». Это плохо, вроде бы все это понимают.
Внимание — вопрос. А что является «антимонолитным» приложением? Остановитесь, подумайте. Какая она — идеальная архитектура?
Все просто — она легко РАСШИРЯЕТСЯ в рамках поставленных задач.
Как этого достичь?
Правильный ответ такой — нужно выделить одинаковое поведение и запрограммировать его в одном месте.
Следующий вопрос — одинаковое поведение «чего»? Компонента, класса, объекта? А это важно?
Неважно как назвать. Что такое БД? Объект, класс, модуль, компонент? ЭТО НЕВАЖНО.
Важно то, что мы разрешили иметь собственное СОСТОЯНИЕ для реализации ПОВЕДЕНИЯ по управлению внешним хранением данных.
И «освободили» свой код от этого поведения.
Вы уже наверное догадались к чему я клоню.
К тому, что принципы, которые я называю «принципы ООП» (разделение поведения и разрешение иметь свое состояние) естественным образом возникают при решении _любой_ мало-мальски сложной задачи. Это важно и я повторю:
Только разделение (специализация) поведения позволяет создавать архитектуру, которая легко расширяется. Разделение поведения означает появление собственного (локального) состояния и, следовательно, возникают какие-то сущности, хранящие состояние. «Локальность» состояния означает, что влияние кода ограничено рамками сущности.
Назовем сущности объектами (в смысле экземпляры классов), а поведение — классом.
Это и есть ООП.
Механизмы реализации остаются на совести (или бессовестности) создателей языков и компиляторов.
Где-то есть автоматический деструктор, где-то — нет. Где-то есть приватные данные класса, где-то нет. Где-то есть наследование, а где-то его надо сооружать. Где-то есть явные классы, а где-то объект может быть каким угодно. Где-то есть интерфейсы, где-то нет.
Это не ООП. Это _механизмы реализации_.
ООП — это АРХИТЕКТУРА ПРИЛОЖЕНИЯ
Главный принцип ООП — РАСШИРЯЕМСЯ КЛАССАМИ.
ВЫЯВИ (ЛОКАЛИЗУЙ) ПОВЕДЕНИЕ И СОЗДАЙ ДЛЯ ЭТОГО КЛАСС.
И еще. Это НЕ ДЛЯ НОВИЧКОВ.
_Использование объектов_ не является ООП. Если программист может вызвать Math.random(), он не становится ООП-программистом.
Но разработка в стиле ООП — это не азы. Не начала программирования.
Чтобы выявить поведение — нужно иметь опыт. Нужно понимать что такое «специализация поведения».
Как быть новичку? Изучать хорошо спроектированные приложения. В той области, которая интересна.
Налицо поверхностное понимание. Я попробую сжато ответить на вопрос «зачем» (осознавая грандиозность замысла).
Давайте так. Задумайтесь над вопросом «зачем ООП», ответ дайте в нескольких словах. Выразите максимально емко все пользы ООП.
Не нажимайте «читать дальше» пока не ответили для себя.
Разумеется правильного ответа никто не знает. Но два самые главные пользы следующие:
1. УПРОЩЕНИЕ ПОНИМАНИЯ ЧЕЛОВЕКОМ
2. ЛОКАЛИЗАЦИЯ ВЛИЯНИЯ КОДА
1. Упрощение понимания — человеком. Ведь наш, человеческий, язык так и устроен. Помните шутку про «утку»?
Что такое «стул»? «Вот это стул, на нем сидят». Это одновременно и поведение, и предмет.
Человек привык обозначать _класс предметов схожего поведения_ одним словом, которое определяет его поведение.
Что же удивительного в том, что эта практика перекочевала в программирование?
Ведь гораздо проще рассуждать о стеке, чем об «этом наборе данных и кода, который отдает первым последний занесенный объект».
2. Локализация влияния.
Давайте представим себе неправильную разработку приложения. Например, есть структура с данными пользователя и есть структура записи журнала. При сохранении на диск с ними нужно работать одинаково — рассматривать их как непрерывный блок данных. Однако, эта работа не была проделана. Не было ВЫЯВЛЕНО ПОВЕДЕНИЕ. Значит в любом месте у нас дублируется код записи в файл, системные вызовы и т.д.
Начинаем расширять — хотим транзакционную запись. Как быть? Ее нужно прикрутить ее _ко всем местам_, где есть запись на диск.
И т.д. Через какое-то время расширение приложения становится СЛИШКОМ дорогостоящим. Получаем то, что называют «монолитное приложение». Это плохо, вроде бы все это понимают.
Внимание — вопрос. А что является «антимонолитным» приложением? Остановитесь, подумайте. Какая она — идеальная архитектура?
Все просто — она легко РАСШИРЯЕТСЯ в рамках поставленных задач.
Как этого достичь?
Правильный ответ такой — нужно выделить одинаковое поведение и запрограммировать его в одном месте.
Следующий вопрос — одинаковое поведение «чего»? Компонента, класса, объекта? А это важно?
Неважно как назвать. Что такое БД? Объект, класс, модуль, компонент? ЭТО НЕВАЖНО.
Важно то, что мы разрешили иметь собственное СОСТОЯНИЕ для реализации ПОВЕДЕНИЯ по управлению внешним хранением данных.
И «освободили» свой код от этого поведения.
Вы уже наверное догадались к чему я клоню.
К тому, что принципы, которые я называю «принципы ООП» (разделение поведения и разрешение иметь свое состояние) естественным образом возникают при решении _любой_ мало-мальски сложной задачи. Это важно и я повторю:
Только разделение (специализация) поведения позволяет создавать архитектуру, которая легко расширяется. Разделение поведения означает появление собственного (локального) состояния и, следовательно, возникают какие-то сущности, хранящие состояние. «Локальность» состояния означает, что влияние кода ограничено рамками сущности.
Назовем сущности объектами (в смысле экземпляры классов), а поведение — классом.
Это и есть ООП.
Механизмы реализации остаются на совести (или бессовестности) создателей языков и компиляторов.
Где-то есть автоматический деструктор, где-то — нет. Где-то есть приватные данные класса, где-то нет. Где-то есть наследование, а где-то его надо сооружать. Где-то есть явные классы, а где-то объект может быть каким угодно. Где-то есть интерфейсы, где-то нет.
Это не ООП. Это _механизмы реализации_.
ООП — это АРХИТЕКТУРА ПРИЛОЖЕНИЯ
Главный принцип ООП — РАСШИРЯЕМСЯ КЛАССАМИ.
ВЫЯВИ (ЛОКАЛИЗУЙ) ПОВЕДЕНИЕ И СОЗДАЙ ДЛЯ ЭТОГО КЛАСС.
И еще. Это НЕ ДЛЯ НОВИЧКОВ.
_Использование объектов_ не является ООП. Если программист может вызвать Math.random(), он не становится ООП-программистом.
Но разработка в стиле ООП — это не азы. Не начала программирования.
Чтобы выявить поведение — нужно иметь опыт. Нужно понимать что такое «специализация поведения».
Как быть новичку? Изучать хорошо спроектированные приложения. В той области, которая интересна.