Comments 16
Я сторонник второго варианта, ибо при возможность сделать что угодно — это непременно будет сделано, и потом к кому посыпятся просьбы/вопросы/негодования?
Я бы придерживался принципа «Less is more», то есть второго варианта. Для иллюстрации первого варианта мы уже имеем массу примеров opensource cms пользоваться которыми с относительным комфортом могут лишь айтишники.
речь в вопросе конечно идет про разработчиков (собственно, айтишников), для которых и создается инструментарий (CMF) а не про конечных пользователей.
Вопрос в том, стоит ли в этом инструментарии запрещать стороннему разработчику «выстрелить себе в голову»
Вопрос в том, стоит ли в этом инструментарии запрещать стороннему разработчику «выстрелить себе в голову»
конечно стоит. необходимость оставлять лазейки для ускоренной подгонке инструмента под вдруг возникнувшие задачи говорит лишь о плохом уровне проработки/проектирования инструментария.
спускаясь до должного уровня атомизации компонентов системы, правильно используя ООП и другие техники гибкого, например, программирования, можно создать систему-конструктор, конечный продукт в которой будет собираться как из кирпичиков.
используя такой подход, нужно сильно постараться, чтобы сделать компонент системы, в котором оставляются лазейки для чего-либо, а значит и работа его будет всегда идти по ожидаемому алгоритму, что только улучшает стабильность системы.
имха, вообще, не стоит писать своей CMF. используйте готовые зарекомендовавшие себя решения, ведь их делают много фанатичных голов, а это всегда хорошо.
спускаясь до должного уровня атомизации компонентов системы, правильно используя ООП и другие техники гибкого, например, программирования, можно создать систему-конструктор, конечный продукт в которой будет собираться как из кирпичиков.
используя такой подход, нужно сильно постараться, чтобы сделать компонент системы, в котором оставляются лазейки для чего-либо, а значит и работа его будет всегда идти по ожидаемому алгоритму, что только улучшает стабильность системы.
имха, вообще, не стоит писать своей CMF. используйте готовые зарекомендовавшие себя решения, ведь их делают много фанатичных голов, а это всегда хорошо.
про грамотное проектирование — это все правильные слова, часто имеющие мало общего с реальностью, в условиях ограниченности ресурсов. К сожалению, мы живем в реальном мире.
Вопрос скорее сводится к тому, кто какой идеологии придерживается:
— разрешено все, что не запрещено, или
— запрещено все, что не разрешено…
конкретный пример, просто из жизни, демонстрирующий применение этого принципа (может, немного упрощенно).
Есть компонент, конкретно — элемент формы (поле ввода с доп. примочками). Как параметры ему передаются данные, которые могут трактоваться как аттрибуты html-тега. Эти аттрибуты задает только разработчик-пользователь CMF. По какому пути пойти?
А насчет не стоит писать — я бы не был настолько категоричен. Если следовать вашей логике — зачем писать разный софт, выполняющий одни задачи — хватит одной ОС, одного редактора, одного плейера, одной игры.
Вопрос скорее сводится к тому, кто какой идеологии придерживается:
— разрешено все, что не запрещено, или
— запрещено все, что не разрешено…
конкретный пример, просто из жизни, демонстрирующий применение этого принципа (может, немного упрощенно).
Есть компонент, конкретно — элемент формы (поле ввода с доп. примочками). Как параметры ему передаются данные, которые могут трактоваться как аттрибуты html-тега. Эти аттрибуты задает только разработчик-пользователь CMF. По какому пути пойти?
- 1 — разрешить в значениях и именах этих параметров только символы, которые гарантировано не нарушат спецификацию XHTML, будут валидны в качестве JS-селекторов и прочее и прочее. Если разработчик-пользователь CMF что-то не то указал — жутко ругаться и прекращать работу, или
- 2 — оставить имена и значения параметров на усмотрение разработчика-пользователя CMF. Если надо использовать «невалидные аттрибуты» — это его дело, он сам за это отвечает.
А насчет не стоит писать — я бы не был настолько категоричен. Если следовать вашей логике — зачем писать разный софт, выполняющий одни задачи — хватит одной ОС, одного редактора, одного плейера, одной игры.
ООП это ведь и есть проекция реальной жизни на программирование. В этом его сакральный смысл. Так им и нужно пользоваться.
Разделение системы на обособленные прототипы (программные интерфейсы, абстрактные классы и т.п.) и создание на этих прототипах конкретных реализаций (непосредственно классы, реализующие конечную четкую задачу). Тогда проектирование системы сводится к продумыванию взаимодействия её частей между собой — в связях и прослойке, так сказать. Это взаимодействие реализуется конечными точками — теми самыми абстрактными классами -, а не их конкретными реализациями.
В итоге получаем систему, где в случае необходимости, мы просто создаём новый класс реализацию, которая мгновенно вписывается во всю систему. Так было бы и с вашим примером — поэтому вариант 2. =)
Конечно, это всё таки утопия, но на довольно большом проценте задач данный подход полностью работает, поэтому я его и придерживаюсь.
А по поводу написания или нет своего CMF, то тут, конечно же, всё зависит от поставленной задачи.
Разделение системы на обособленные прототипы (программные интерфейсы, абстрактные классы и т.п.) и создание на этих прототипах конкретных реализаций (непосредственно классы, реализующие конечную четкую задачу). Тогда проектирование системы сводится к продумыванию взаимодействия её частей между собой — в связях и прослойке, так сказать. Это взаимодействие реализуется конечными точками — теми самыми абстрактными классами -, а не их конкретными реализациями.
В итоге получаем систему, где в случае необходимости, мы просто создаём новый класс реализацию, которая мгновенно вписывается во всю систему. Так было бы и с вашим примером — поэтому вариант 2. =)
Конечно, это всё таки утопия, но на довольно большом проценте задач данный подход полностью работает, поэтому я его и придерживаюсь.
А по поводу написания или нет своего CMF, то тут, конечно же, всё зависит от поставленной задачи.
В голову не нужно, а вот в ногу пусть стреляют :)
Лучше придерживаться золотой середины. Например, вместо того что бы не давать что-либо делать — можно уведомить пользователя о том что лучше так не делать и почему.
Выбор очень сильно зависит от целевой аудитории инструментария. Если продукт рассчитан на совсем-совсем арийский тип (блондинок с голубыми глазами) — ограничить действия пользователя неким подмножеством функционала жизненно необходимо.
согласен с ответом и комментами IntenT'а, хоть я сам и быдлокодер аццкий, но вся ответственность за мои проекты лежит на мне, а не на тех чьи фреймворки я использую… так я смогу учиться на собственных ошибках и понимать почему так нельзя делать, а не просто думать что так не получится…
про сторонние CMF: я их использую только для изучения или создания на скорую руку… для себя я пишу все сам… так и интереснее, и развитие, и быстрее работает, и похвастаться есть чем и вообще куча плюсов… ну… при условии что делать нормально…
а если использовать сторонние CMF, то это + в скорости, но никакого развития… с ними можно даже не понимать что и как делается, но делать довольно много… скучно…
да и я заметил что чаще всего любые OpenSource CMF, CMS со временем достигают пика и их переписывают с ноля…
про сторонние CMF: я их использую только для изучения или создания на скорую руку… для себя я пишу все сам… так и интереснее, и развитие, и быстрее работает, и похвастаться есть чем и вообще куча плюсов… ну… при условии что делать нормально…
а если использовать сторонние CMF, то это + в скорости, но никакого развития… с ними можно даже не понимать что и как делается, но делать довольно много… скучно…
да и я заметил что чаще всего любые OpenSource CMF, CMS со временем достигают пика и их переписывают с ноля…
Sign up to leave a comment.
Перфекционизм в разработке инструментария