O шаблонах в программировании - from different perspective
Вот тут avva написал одну интересную статью, и помог мне сформулировать то, что давно крутилось в голове.
Сначала - disclaimer - в примере приведенном Аввой - все правильно. И способ решения - в меру оригинальный, и вполне подходит для задачи.
И я с ним согласен, снимаю шляпу и т.д.
Но ....
Но, применительно к моей области деятельности (которая бесконечно далека от javascripts, игр и цветных квадратиков), у подобных красивых и элегантных решений, использующих особенности исходной задачи, есть некий "встроенный" недостаток.
Даже несколько.
1. Они слишком "заточены" под текущее понимание проблемы. Вполне вероятно что то, как сформулировано задание сегодня - это отражение результата кучи разнообразных процессов (спецификации исходной задачи, наличия бюджета, наличия времени, обстоятельств большого мира и т.д.) на СЕГОДНЯ. Что будет завтра - можно прогнозировать, но почти наверняка - что-то изменится.
2. Они требуют мысленных затрат :) То есть - их надо придумать. При учете пункта 1, из которого следует что вовсе не факт что решение вообще нужно, получается что умный (глупый и не придумает) будет тратить время на изобретение, объяснение (глупым, интеграторам, конфигураторам, тестерам, тех. писателям) того, что можно сделать просто и не задумываясь. В данном случае "не задумываясь" - не означает плохо. Это означает "так, как принято в проекте". Если 20 модулей написано "слева направо", если общая архитектура подстроена под "слева направо", если в общем случае "слева направо" достаточно хорошо и работает - то не надо придумывать как написать модуль номер 21. Вот если оказывается что в данном случае "слева направо" никак не подходит, очень сложно, дорого и т.д. - можно начать думать (то есть задача возвращается к архитектору / дизайнеру). А если нет - слушайте "Валенки" :)
3. Чем оригинальнее / элегантнее решение, тем больше у него шансов оказаться "неподходящим" завтра / через 3 года, или непонятым следующим поколением программистов (в нашей области код живет 10 лет как минимум, чаще - 15 / 20).
Применительно к примеру Аввы:
При чтении (еще до того как я дошел до "punch line"), на фразе "описание карты каждого уровня, начальной позиции." у меня возник когнитивный диссонанс.
Карта - это мир. В нем есть элементы, со своими "поведениями" (клетки). Поведения имеют свойство усложнятся. В данном случае речь идет о спецификации (конфигурации) мира и его элементов. 99.9999% (опять же, в моей области) что конфигурация чего-то существенного будет сложнее чем один байт (буква).
А pattern как читать composite configuration, как поддерживают возможное расширение типов элементов, расширение их поведений, возможных параметров и т.д. - это стандартный object oriented. То есть по принципу "лучше потратить день на обучение летать, а потом за час долететь" из незабвенного мультика - мне бы и в голову не пришло в проекте базировать что нибудь существенное на предположении что конфигурация - это всегда один байт. Да, быстрый и эффективный программист напишет десериализацию такой карты за треть/четверть времени потребного для написания generic enough solution. Но потом с бОльшой долей вероятности эту работу надо будет переделать. Не потому что он в момент написания не учел какие-либо требования, а потому что это требования были осознаны / родились позже.
При этом конфигурация карты будет сложнее, ее будет неудобно писать "в тексте", буквочками и палочками.
Ну и что ? Либо это будет малочитаемый XML, либо будет написан отдельный редактор карт, с подгружаемыми редакторами для разных типов объектов, с возможностью разместить там бонусные / штрафные клетки, клетки само-рассоединяющиеся после Х ходов, клетки само-соединяющиеся после выполнения каких-то условий и т.д.
Существенным является generic enough solution. Иначе весь проект станет кладбищем белых слонов.
Скажем, если речь идет о местоположении объекта, можно (и красиво наверно) предположить что можно разбить весь Израиль на клеточки, пронумеровать их, и работать в такой, внутренней картезианской системе.
Очень удобно - все расстояния считаются по теореме Пифагора, при движении на юг / север или восток/запад одна из координат постоянная и т.д.
Более того, я даже видел системы так написанные.
И видел, фигурально выражаясь - facepalm - разработчиков (естественно не тех, кто принял изначальное решение работать в такой системе координат) при сообщение что система продана, скажем, в Бразилию.
Можно поступить чуть умнее, и предположить что координат будет три (если система картезианская) или две (если геоцентрическая).
Правильнее работать с GeoPosition, из которой есть стандартные методы конвертации в картезианские, геоцентрическая и т.д. системы координат, так что весь код, принимающий, хранящий, вычисляющий расстояния, углы, включения / исключения и т.д. работает с GeoPosition.
Почему - потому что с большой степенью вероятности географические системы координат будут разные (UTM/GEO/ECEF со всеми возможными вариациями) для разных типов данных, для разных клиентов и разных мест установки.
С другой стороны, можно предположить что все операции с GeoPosition инвариантны по отношению ко времени, что центр Земли неподвижен, магнитный полюс стоит на месте (есть всякие космические проекты где такие предположения не сработают, но пока мы привязаны к земле - сойдет).
Да, если проект захотят поставить на Enterprise через 500 лет - James T Kirk подождет пока система пройдет адаптацию :)
П.С.
У меня в отделе в армии был программист после армейского курса. Умный и т.д. парень, способный с бешеной скоростью выдавать прилично работающий код (в основном на Дельфи, но на С++ тоже мог). До тех пор, пока никто не менял требования - все было пучком. Программы в общем-то работали, баги в них он чинил быстро и их было немного.
Но вот если просили "вот эту штучку перевернуть и сюда прикрутить" - все.
Апофигеем была некая хреновина, где он половину логики завязал на то, что цвет отрисовки каждого объекта содержал в себе индекс (id) собственно объекта (через палетки в Windows), причем объектов мало (< 256), и hit detection можно было делать по цвету пикселя под курсором.
Детали я уже не помню, но помню что когда надо было чего-то поменять (увеличить количество объектов в 5 раз), его "дома" не оказалось. Первый программист вернулся с изумленным лицом (он в жизни не слышал про палетки Windows и не понимал как они работают и зачем), второй вернулся с еще более изумленным лицом когда оказалось что система не работает если драйвер дисплея поддерживает True Color, третьим оказался я, и восхитившись собственному любопытству, заставившему меня в свое время изучить Petzolda, включая главу по палетки в Windows 3.1, переделал все нафиг.
Сначала - disclaimer - в примере приведенном Аввой - все правильно. И способ решения - в меру оригинальный, и вполне подходит для задачи.
И я с ним согласен, снимаю шляпу и т.д.
Но ....
Но, применительно к моей области деятельности (которая бесконечно далека от javascripts, игр и цветных квадратиков), у подобных красивых и элегантных решений, использующих особенности исходной задачи, есть некий "встроенный" недостаток.
Даже несколько.
1. Они слишком "заточены" под текущее понимание проблемы. Вполне вероятно что то, как сформулировано задание сегодня - это отражение результата кучи разнообразных процессов (спецификации исходной задачи, наличия бюджета, наличия времени, обстоятельств большого мира и т.д.) на СЕГОДНЯ. Что будет завтра - можно прогнозировать, но почти наверняка - что-то изменится.
2. Они требуют мысленных затрат :) То есть - их надо придумать. При учете пункта 1, из которого следует что вовсе не факт что решение вообще нужно, получается что умный (глупый и не придумает) будет тратить время на изобретение, объяснение (глупым, интеграторам, конфигураторам, тестерам, тех. писателям) того, что можно сделать просто и не задумываясь. В данном случае "не задумываясь" - не означает плохо. Это означает "так, как принято в проекте". Если 20 модулей написано "слева направо", если общая архитектура подстроена под "слева направо", если в общем случае "слева направо" достаточно хорошо и работает - то не надо придумывать как написать модуль номер 21. Вот если оказывается что в данном случае "слева направо" никак не подходит, очень сложно, дорого и т.д. - можно начать думать (то есть задача возвращается к архитектору / дизайнеру). А если нет - слушайте "Валенки" :)
3. Чем оригинальнее / элегантнее решение, тем больше у него шансов оказаться "неподходящим" завтра / через 3 года, или непонятым следующим поколением программистов (в нашей области код живет 10 лет как минимум, чаще - 15 / 20).
Применительно к примеру Аввы:
При чтении (еще до того как я дошел до "punch line"), на фразе "описание карты каждого уровня, начальной позиции." у меня возник когнитивный диссонанс.
Карта - это мир. В нем есть элементы, со своими "поведениями" (клетки). Поведения имеют свойство усложнятся. В данном случае речь идет о спецификации (конфигурации) мира и его элементов. 99.9999% (опять же, в моей области) что конфигурация чего-то существенного будет сложнее чем один байт (буква).
А pattern как читать composite configuration, как поддерживают возможное расширение типов элементов, расширение их поведений, возможных параметров и т.д. - это стандартный object oriented. То есть по принципу "лучше потратить день на обучение летать, а потом за час долететь" из незабвенного мультика - мне бы и в голову не пришло в проекте базировать что нибудь существенное на предположении что конфигурация - это всегда один байт. Да, быстрый и эффективный программист напишет десериализацию такой карты за треть/четверть времени потребного для написания generic enough solution. Но потом с бОльшой долей вероятности эту работу надо будет переделать. Не потому что он в момент написания не учел какие-либо требования, а потому что это требования были осознаны / родились позже.
При этом конфигурация карты будет сложнее, ее будет неудобно писать "в тексте", буквочками и палочками.
Ну и что ? Либо это будет малочитаемый XML, либо будет написан отдельный редактор карт, с подгружаемыми редакторами для разных типов объектов, с возможностью разместить там бонусные / штрафные клетки, клетки само-рассоединяющиеся после Х ходов, клетки само-соединяющиеся после выполнения каких-то условий и т.д.
Существенным является generic enough solution. Иначе весь проект станет кладбищем белых слонов.
Скажем, если речь идет о местоположении объекта, можно (и красиво наверно) предположить что можно разбить весь Израиль на клеточки, пронумеровать их, и работать в такой, внутренней картезианской системе.
Очень удобно - все расстояния считаются по теореме Пифагора, при движении на юг / север или восток/запад одна из координат постоянная и т.д.
Более того, я даже видел системы так написанные.
И видел, фигурально выражаясь - facepalm - разработчиков (естественно не тех, кто принял изначальное решение работать в такой системе координат) при сообщение что система продана, скажем, в Бразилию.
Можно поступить чуть умнее, и предположить что координат будет три (если система картезианская) или две (если геоцентрическая).
Правильнее работать с GeoPosition, из которой есть стандартные методы конвертации в картезианские, геоцентрическая и т.д. системы координат, так что весь код, принимающий, хранящий, вычисляющий расстояния, углы, включения / исключения и т.д. работает с GeoPosition.
Почему - потому что с большой степенью вероятности географические системы координат будут разные (UTM/GEO/ECEF со всеми возможными вариациями) для разных типов данных, для разных клиентов и разных мест установки.
С другой стороны, можно предположить что все операции с GeoPosition инвариантны по отношению ко времени, что центр Земли неподвижен, магнитный полюс стоит на месте (есть всякие космические проекты где такие предположения не сработают, но пока мы привязаны к земле - сойдет).
Да, если проект захотят поставить на Enterprise через 500 лет - James T Kirk подождет пока система пройдет адаптацию :)
П.С.
У меня в отделе в армии был программист после армейского курса. Умный и т.д. парень, способный с бешеной скоростью выдавать прилично работающий код (в основном на Дельфи, но на С++ тоже мог). До тех пор, пока никто не менял требования - все было пучком. Программы в общем-то работали, баги в них он чинил быстро и их было немного.
Но вот если просили "вот эту штучку перевернуть и сюда прикрутить" - все.
Апофигеем была некая хреновина, где он половину логики завязал на то, что цвет отрисовки каждого объекта содержал в себе индекс (id) собственно объекта (через палетки в Windows), причем объектов мало (< 256), и hit detection можно было делать по цвету пикселя под курсором.
Детали я уже не помню, но помню что когда надо было чего-то поменять (увеличить количество объектов в 5 раз), его "дома" не оказалось. Первый программист вернулся с изумленным лицом (он в жизни не слышал про палетки Windows и не понимал как они работают и зачем), второй вернулся с еще более изумленным лицом когда оказалось что система не работает если драйвер дисплея поддерживает True Color, третьим оказался я, и восхитившись собственному любопытству, заставившему меня в свое время изучить Petzolda, включая главу по палетки в Windows 3.1, переделал все нафиг.