Грубо говоря, у ФП и ООП схожие возможности в выражении сложных конструкций и инкапсуляции программ на мелкие куски, которые можно комбинировать между собой.
Самая большая разница между двумя этими «философиями» состоит в том, как данные соотносятся с операциями над данными.
Основной доктриной ООП является то, что данные и операции над ними сильно связаны: объект содержит данные и реализацию операций над данными. Он скрывает всё это от других объектов через интерфейс – набор методов или сообщений, на которые он реагирует. Таким образом, центральной моделью абстракции являются сами данные, спрятанные за небольшим API в виде интерфейса.
При ООП подходе программист составляет новые объекты и расширяет существующие путём добавления к ним методов.
Основной доктриной ФП является то, что данные слабо связаны с функциями. Над одним и тем же набором данных можно совершать разные действия, а центральной моделью абстракции является функция, а не структура данных. Функции прячут их реализацию, а абстракции языка общаются с функциями.
При ФП подходе программист пишет новые функции.
В поединке между медведем и крокодилом решающим фактором выступает местность.
Так когда же одно предпочтительнее другого? Поскольку блог посвящён практическим реализациям, я отметаю теоретические построения вроде возможности механически рассуждать о коде и думать про всякие прагматичные вещи, писать бизнес-код в такой ситуации, когда нужно сделать слишком много всего при недостатке ресурсов и времени.
Может ли одна из двух моделей победить в бизнес окружении? Подумайте хорошенько, пока я заварю себе чашечку эспрессо…
Конечно, в бизнес-программировании доминирует функциональная модель. Сюрприз? Сюрприз, если вы рассматриваете только такие языки, как Java, C++, C# и Ruby.
Если подумать, то всё это ООП – тонкая прослойка для доступа к базам данных и SQL, что на самом деле – функциональный язык. Хотя и возможно управлять базой данных через встроенные процедуры PL/SQL, это создаёт узкое место, и обычно не стоит того.
Главное преимущество реляционных баз данных – возможность работы с требованиями, которые возникнут в будущем. Когда вам нужны новые отчёты, вы просто их пишете. Разные приложения могут одинаково обращаться к базе. Ограничения можно накладывать программно, чтобы они работали во всех приложениях.
Отойдя назад, вы увидите, что база данных – это большая структура данных, а приложения – наборы операций с ними. В сердце любого бизнес-приложения лежит большая функциональная база данных.
И тем не менее, мы хватаемся за объекты в приложениях. Простое следование моде? Или есть некая фундаментальная разница между тем, что нам нужно сделать в приложениях, и тем, что нам нужно сделать при работе с базой данных?
Ответ в том, что просто сделать через ООП, а что просто сделать в базах данных.
Хорошая ООП-архитектура позволяет легко менять то, как вещи связаны друг с другом. Инкапсуляция позволяет легко менять взаимодействие частей. Правда, в ООП не очень легко добавлять новые действия.
Но если у вас есть бизнес-процесс размещения заказа, который рефакторят на предмет поддержки новых бизнес-правил – тут ООП встаёт во всей красе. Те части кода, которым не нужно знать о происходящих изменениях, изолированы от тех, кому знать о них надо.
С другой стороны, хорошо разработанная база данных делает простым добавление новых запросов и операций. Возможно смотреть на данные с другой точки зрения или добавлять новые обновления данных. Клиентские приложения изолированы от таких вещей, как индексация и быстродействие.
Менять связи сложно. Если вы меняете структуру управления, и переходите от одного менеджера на отчёт к системе «многие ко многим», это сломает много приложений.
Поэтому, если мы запишем всё, что должно быть в бизнес-приложении, на карточках, те, что представляют длительные и редко изменяющиеся отношения, идут в базу данных, а те, что представляют эволюционирующие и изменяющиеся операции, идут в приложение.
Набор «карточек» (элементов приложения) обычно раза в четыре выше набора элементов базы данных. Всё меняется, бизнес должен учиться, расти и развиваться.
Так что насчёт ФП – код, написанный в функциональном стиле? Что насчёт простой организации ООП-программ в виде набора операций, действующих над относительно неизменными наборами данных?
Допустимо и то, и другое, однако всегда нужно задумываться над приоритетами – над продолжительностью связей. Если что-то вряд ли поменяется, при этом над этим будут работать разные меняющиеся вещи – его лучше оформлять в ФП-стиле. Если что-то меняется часто, это лучше оформить в виде ООП.
Если у каждого менеджера может быть несколько отчётов, а у каждого отчёта – только один менеджер, такие операции вряд ли стоит прятать за API, где объекты manager скрытым образом делегируют операции. Такую вещь проще создать в виде данных, над которыми производятся операции. Но правило насчёт стоимости доставки скорее всего поменяется, и его надо инкапсулировать посильнее, чтобы изолировать от него остальную часть программы.
Хорошие программы пишутся с помощью обоих стилей, потому что хорошие программы должны выполнять несколько разных задач.
Самая большая разница между двумя этими «философиями» состоит в том, как данные соотносятся с операциями над данными.
Основной доктриной ООП является то, что данные и операции над ними сильно связаны: объект содержит данные и реализацию операций над данными. Он скрывает всё это от других объектов через интерфейс – набор методов или сообщений, на которые он реагирует. Таким образом, центральной моделью абстракции являются сами данные, спрятанные за небольшим API в виде интерфейса.
При ООП подходе программист составляет новые объекты и расширяет существующие путём добавления к ним методов.
Основной доктриной ФП является то, что данные слабо связаны с функциями. Над одним и тем же набором данных можно совершать разные действия, а центральной моделью абстракции является функция, а не структура данных. Функции прячут их реализацию, а абстракции языка общаются с функциями.
При ФП подходе программист пишет новые функции.
В поединке между медведем и крокодилом решающим фактором выступает местность.
Так когда же одно предпочтительнее другого? Поскольку блог посвящён практическим реализациям, я отметаю теоретические построения вроде возможности механически рассуждать о коде и думать про всякие прагматичные вещи, писать бизнес-код в такой ситуации, когда нужно сделать слишком много всего при недостатке ресурсов и времени.
Может ли одна из двух моделей победить в бизнес окружении? Подумайте хорошенько, пока я заварю себе чашечку эспрессо…
Конечно, в бизнес-программировании доминирует функциональная модель. Сюрприз? Сюрприз, если вы рассматриваете только такие языки, как Java, C++, C# и Ruby.
Если подумать, то всё это ООП – тонкая прослойка для доступа к базам данных и SQL, что на самом деле – функциональный язык. Хотя и возможно управлять базой данных через встроенные процедуры PL/SQL, это создаёт узкое место, и обычно не стоит того.
Главное преимущество реляционных баз данных – возможность работы с требованиями, которые возникнут в будущем. Когда вам нужны новые отчёты, вы просто их пишете. Разные приложения могут одинаково обращаться к базе. Ограничения можно накладывать программно, чтобы они работали во всех приложениях.
Отойдя назад, вы увидите, что база данных – это большая структура данных, а приложения – наборы операций с ними. В сердце любого бизнес-приложения лежит большая функциональная база данных.
И тем не менее, мы хватаемся за объекты в приложениях. Простое следование моде? Или есть некая фундаментальная разница между тем, что нам нужно сделать в приложениях, и тем, что нам нужно сделать при работе с базой данных?
Ответ в том, что просто сделать через ООП, а что просто сделать в базах данных.
Хорошая ООП-архитектура позволяет легко менять то, как вещи связаны друг с другом. Инкапсуляция позволяет легко менять взаимодействие частей. Правда, в ООП не очень легко добавлять новые действия.
Но если у вас есть бизнес-процесс размещения заказа, который рефакторят на предмет поддержки новых бизнес-правил – тут ООП встаёт во всей красе. Те части кода, которым не нужно знать о происходящих изменениях, изолированы от тех, кому знать о них надо.
С другой стороны, хорошо разработанная база данных делает простым добавление новых запросов и операций. Возможно смотреть на данные с другой точки зрения или добавлять новые обновления данных. Клиентские приложения изолированы от таких вещей, как индексация и быстродействие.
Менять связи сложно. Если вы меняете структуру управления, и переходите от одного менеджера на отчёт к системе «многие ко многим», это сломает много приложений.
Поэтому, если мы запишем всё, что должно быть в бизнес-приложении, на карточках, те, что представляют длительные и редко изменяющиеся отношения, идут в базу данных, а те, что представляют эволюционирующие и изменяющиеся операции, идут в приложение.
Набор «карточек» (элементов приложения) обычно раза в четыре выше набора элементов базы данных. Всё меняется, бизнес должен учиться, расти и развиваться.
Так что насчёт ФП – код, написанный в функциональном стиле? Что насчёт простой организации ООП-программ в виде набора операций, действующих над относительно неизменными наборами данных?
Допустимо и то, и другое, однако всегда нужно задумываться над приоритетами – над продолжительностью связей. Если что-то вряд ли поменяется, при этом над этим будут работать разные меняющиеся вещи – его лучше оформлять в ФП-стиле. Если что-то меняется часто, это лучше оформить в виде ООП.
Если у каждого менеджера может быть несколько отчётов, а у каждого отчёта – только один менеджер, такие операции вряд ли стоит прятать за API, где объекты manager скрытым образом делегируют операции. Такую вещь проще создать в виде данных, над которыми производятся операции. Но правило насчёт стоимости доставки скорее всего поменяется, и его надо инкапсулировать посильнее, чтобы изолировать от него остальную часть программы.
Хорошие программы пишутся с помощью обоих стилей, потому что хорошие программы должны выполнять несколько разных задач.
