Не знаю почему, но на эту важнейшую технологию обращают так мало внимания. Я хочу несколько исправить положение, поэтому это — первая статья в цикле «Кодогенерация». При рассмотрении данной темы будет использован язык PHP и БД MySQL, но кодогенерация сама по себе возможна на любом языке и с использованием любой БД, просто на PHP мне будет проще объяснять некоторые важные моменты. Так же я буду обращать внимание на состояние дел в других системах и языках.
Данная статья посвящена одному вопросу: какие проблемы присутствуют в современном программировании.
Для того, чтобы строить сложные системы с повторным использованием кода был придуман ООП (объектно ориентированный подход). Этот подход используется долгое время и приносит хорошие результаты.
Что присуще ООП? Обратимся к Википедии.
Но оправдывают ли себя такие подходы в настоящее время?
Что мы сейчас видим:
1. Многоуровневое наследование.
В современных сложных системах (особенно .NET, Java) многие классы имеют много уровней наследования и свойства вместе с методами суммируются в конечных классах. С одной стороны это хорошо: постепенный рост сложности от примитивных классов к специфическим компонентам. Но с другой стороны программист, который пользуется конечным классом, использует не более 10-20% его возможностей в каждом конкретном случае (например, в ASP.NET GridView имеет сотни свойств, многие из которых вообще в проекте не понадобятся). А ведь такое большое число методов и свойств несет в себе сложность. Во-первых, для программиста. Когда он набирает имя объекта и нажимает точку, то открываются огромные списки, среди которых сложно найти то, что надо. Во-вторых это все занимает память и процессорное время.
2. Многоуровневые абстракции.
При проектировании современных систем используются многоуровневые абстракции. На верхнем уровне — сущности реального мира. И чем ближе к низу, тем дальше от сущностей реального мира к сущностям исполняющей среды. Этот подход хороший, но опять же несет в себе сложность. Получается очень много классов. Программист, который работает с такими системами, должен держать в голове много информации при построении и сопровождении данной системы. Более того, для согласования абстракций часто приходится использовать неоптимальные методы.
3. Рутинная работа.
Какая бы ни была система, часто бывает рутинная монотонная работа, которую должен выполнять программист. Например, создание однообразных страниц, где каждая следующая страница отличается от предыдущей лишь источником или представлением данных. В таких ситуациях часто используется «копи-паст». Но если определенное изменение надо внести в массу этих же однообразных страниц, то опять появляется рутинная работа. Но строить абстрактные модели по таким мелким поводам никто не будет, ведь классы нуждаются в проектировании.
4. Библиотеки.
Сложно представить проект, который не использовал бы какой-либо библиотеки классов/функций. Программист не просто вынужден изучать эти библиотеки, но и должен следовать их правилам и абстракциям, что опять же добавляет сложность проекту и вынуждает программиста держать в голове большой объем информации.
Современные подходы порождают излишнюю сложность и рутину. А сложность — враг любого проекта. Чем проще проект, тем он качественнее.
В следуюших статьях мы рассмотрим то, как кодогенерация может решать такие проблемы.
Данная статья посвящена одному вопросу: какие проблемы присутствуют в современном программировании.
Какие сейчас есть проблемы
Для того, чтобы строить сложные системы с повторным использованием кода был придуман ООП (объектно ориентированный подход). Этот подход используется долгое время и приносит хорошие результаты.
Что присуще ООП? Обратимся к Википедии.
Абстракция данных
Объекты представляют собою упрощенное, идеализированное описание реальных сущностей предметной области. Если соответствующие модели адекватны решаемой задаче, то работать с ними оказывается намного удобнее, чем с низкоуровневым описанием всех возможных свойств и реакций объекта.
Инкапсуляция
Инкапсуляция — это принцип, согласно которому любой класс должен рассматриваться как чёрный ящик — пользователь класса должен видеть и использовать только интерфейсную часть класса (т. е. список декларируемых свойств и методов класса) и не вникать в его внутреннюю реализацию. Поэтому данные принято инкапсулировать в классе таким образом, чтобы доступ к ним по чтению или записи осуществлялся не напрямую, а с помощью методов. Принцип инкапсуляции (теоретически) позволяет минимизировать число связей между классами и, соответственно, упростить независимую реализацию и модификацию классов.
Наследование
Наследованием называется возможность порождать один класс от другого с сохранением всех свойств и методов класса-предка (прародителя, иногда его называют суперклассом) и добавляя, при необходимости, новые свойства и методы. Набор классов, связанных отношением наследования, называют иерархией. Наследование призвано отобразить такое свойство реального мира, как иерархичность.
Полиморфизм
Полиморфизмом называют явление, при котором один и тот же программный код (полиморфный код) выполняется по-разному в зависимости от того, объект какого класса используется при вызове данного кода. Полиморфизм обеспечивается тем, что в классе-потомке изменяют реализацию метода класса-предка с обязательным сохранением сигнатуры метода. Это обеспечивает сохранение неизменным интерфейса класса-предка и позволяет осуществить связывание имени метода в коде с разными классами — из объекта какого класса осуществляется вызов, из того класса и берётся метод с данным именем. Такой механизм называется динамическим (или поздним) связыванием — в отличие от статического (раннего) связывания, осуществляемого на этапе компиляции программы.
Но оправдывают ли себя такие подходы в настоящее время?
Что мы сейчас видим:
1. Многоуровневое наследование.
В современных сложных системах (особенно .NET, Java) многие классы имеют много уровней наследования и свойства вместе с методами суммируются в конечных классах. С одной стороны это хорошо: постепенный рост сложности от примитивных классов к специфическим компонентам. Но с другой стороны программист, который пользуется конечным классом, использует не более 10-20% его возможностей в каждом конкретном случае (например, в ASP.NET GridView имеет сотни свойств, многие из которых вообще в проекте не понадобятся). А ведь такое большое число методов и свойств несет в себе сложность. Во-первых, для программиста. Когда он набирает имя объекта и нажимает точку, то открываются огромные списки, среди которых сложно найти то, что надо. Во-вторых это все занимает память и процессорное время.
2. Многоуровневые абстракции.
При проектировании современных систем используются многоуровневые абстракции. На верхнем уровне — сущности реального мира. И чем ближе к низу, тем дальше от сущностей реального мира к сущностям исполняющей среды. Этот подход хороший, но опять же несет в себе сложность. Получается очень много классов. Программист, который работает с такими системами, должен держать в голове много информации при построении и сопровождении данной системы. Более того, для согласования абстракций часто приходится использовать неоптимальные методы.
3. Рутинная работа.
Какая бы ни была система, часто бывает рутинная монотонная работа, которую должен выполнять программист. Например, создание однообразных страниц, где каждая следующая страница отличается от предыдущей лишь источником или представлением данных. В таких ситуациях часто используется «копи-паст». Но если определенное изменение надо внести в массу этих же однообразных страниц, то опять появляется рутинная работа. Но строить абстрактные модели по таким мелким поводам никто не будет, ведь классы нуждаются в проектировании.
4. Библиотеки.
Сложно представить проект, который не использовал бы какой-либо библиотеки классов/функций. Программист не просто вынужден изучать эти библиотеки, но и должен следовать их правилам и абстракциям, что опять же добавляет сложность проекту и вынуждает программиста держать в голове большой объем информации.
Итог
Современные подходы порождают излишнюю сложность и рутину. А сложность — враг любого проекта. Чем проще проект, тем он качественнее.
В следуюших статьях мы рассмотрим то, как кодогенерация может решать такие проблемы.
