Идея сама по себе отличная. Но просто советы в стиле fortune особенной пользы не приносят. Хороший поиск «сделает» половину проекта. Другую половину сделает сообщество :) То есть, два-три хороших грамотных программиста для ревью советов нужны как воздух.
Мой список желаний:
Тематический каталог.
Тэги — их не должно быть слишком много, по возможности.
Несколько авторитетных (хотя бы для Вас) C++ программистов.
Ничего не помешает. Только я глазами читаю гораздо быстрее звучания различимой на слух речи. Плюс, могу пропустить ненужные детали, не вникая. Что называется, «по диагонали». Со звуком это не покатит, увы.
Кроме того, следует понимать, что естественный язык несет в себе отпечаток истории, культуры, менталитета и выражает совсем не то, что нужно выразить при написании программы. Естественность языка программирования такая же утопия, как CASE-средства. Помните прогнозы, что программистов заменят компьютеры, ведомые вооруженными мышками домохозяйками?
Кесарю — кесарево, слесарю — слесарево. Не смешивайте врожденную иррациональность и неоднозначность человеческих языков с математической беспощадностью машин :)
Какова цель таких способов/языков программирования? Вы знаете, я, наверное, процентов 60 своего времени (а то и больше) провожу за чтением, переосмыслением и правкой того, что написал. И это нормальный рабочий цикл. А как быть с речью? Как ее править? Вы много людей знаете способных нормально с первого раза выразить свои мысли? Я уже не говорю про нормально с первого раза написать программу :)
Нет-нет, не надо 10 киловольт и обугленных пальцев за любую копипасту. Я о другом.
Строго говоря, copy/paste вообще вне добра и зла. Это просто инструмент, который требует осторожности. То есть, прежде чем воткнуть скопированное, надо остановиться и немножко подумать. И почему-то мне кажется, что легкий неприятный разряд тока заставит многих помедлить, прежде чем воткнуть голые данные/кусок кода/копию настроек. А там, глядишь, мелькнет мысль «а может, сделать константу/функцию/секцию general в конфиге».
Элегантный, хотя и лисповатый способ, спасибо. Хотя мне все чаще мечтается о клавиатурах с обратной связью, бьющие током за нажатие комбинаций <Ctr-C> + <Ctrl-V>.
Ну и, господа, пять страниц комментариев на тему «как правильно ставить скобочки»! Блестяще! :)
Если исходить из Ваших мыслей, то у программирования очень много общего с боевыми искусствами: споры о методологиях аналогичны утверждениям «мое кунг-фу лучше твоего», в реальной схватке все решит опыт и немножко удачи, ну и все дерутся не постановочно, а так, как могут, иначе есть риск получить в глаз :) И только истинные мастера, достигшие вершин, разят врагов в соответствии с идеями своей школы. Но в принципе, это выглядит немного странно и мало кому нужно, а большинству достаточно простой рукопашки.
В данный момент как раз занимаюсь подобной переработкой существующего ПО. В качестве контейнеров с данными используются наследники TDataSet. К каждому набору данных пишется фасад — объект с методами, изменяющими содержимое контейнера. Фасады я использую в коде для реализации бизнес-логики, к ним же пишу биндинги для вызова из скриптов.
Медиаторы в моем случае выполняют роль посредников между TDataSet и визуальным компонентом (в данный момент используется библиотека DevExpress). Кроме того, медиаторы устанавливают, что будет происходить при изменении данных, используя события объектов TField из набора данных. Ну и главное — медиаторы определяют внешний вид и поведение данных на основе ролей пользователей.
Я не имею права привести здесь реальный код, но если Вам интересно, то могу переработать его для примера. И еще деталь, я пишу на C++ и почти не знаю Object Pascal :)
Delphi не любят в основном из-за отсутствия такого подхода, какой описан в Вашем цикле статей. Бизнес, гуи и SQL-запросы в одном обработчике нажатия кнопки на форме не редкость, увы.
Слоты и сигналы на коленке? :) Скажите, не рассматривали возможность создания Mediator'а для привязки экземпляра TUser к экземпляру формы? Тогда события форма не будет влиять непосредственно на юзера, плюс «отвязку» можно безопасно выполнить при наступлении OnDestroy любого из них. Кроме того, время жизни привязки будет зависеть от времени жизни медиатора, что иногда очень-очень удобно.
Я понял, да. Сам проголосовал за вариант с бизнес-логикой (в моей практике такого гораздо больше), а потом подумал и решил, что результаты опроса будут бесполезны без контекста. Ну быть может, косвенно определят соотношение системщиков и прикладников :)
Простите, не понимаю смысла вопроса. Исходя из бизнес-логики чаще всего состояния сохраняются в гуевых дестопных приложениях. С другой стороны, вполне нормален вариант сериализации объекта в файл, скажем, между двумя запусками какой-нибудь консольной утилиты/демона, и это, скорее всего, не обусловлено бизнес-логикой. Таким образом, ответ на ваш вопрос в немалой степени будет зависеть от типа приложений, которые пишет программист.
Сама суть stackoverflow в обстоятельных ответах. Отвечай хорошо или умри — примерно поэтому там сложилось такое сообщество. Что касается эпиграфа, мне кажется, что это способ донести мысль о взаимном уважении, всеобщей любви и «обнимашках с троллями» до широких масс, только и всего.
Вам нужен кто-то, кто снимет свои сандалии и ударит вас ими по лицу. Есть такая добрая дзенская традиция. Наступит просветление и станет понятно, что склеп и тюрьма — просто линия, нарисованная мелом, а на любой вопрос о причинах можно однозначно ответить что их нет. Ну, или снять сандалии и…
> Каждая модель представлена CRUD-реурсом (в каждом по 3-4 расширяющих метода).
Можно чуть поподробнее, что за расширяющие методы? Имеются в виду какие-то дополнительные операции, помимо CRUD? А то гугление по extention method выбрасывает ссылки на C#-контент, что немного смутило.
Был анекдот такой: англичанин, немец и русский в течение года должны были написать исследование, каждый своё, по одной тетради в месяц. Пришло время сдавать. Англичанин с немцем выдают профессору по 12 тетрадей, всё как положено. А русский ничего не принес и на вопрос «где?» ответил: — Вы знаете, профессор, у меня вчера так голова болела…
Часто бывает, что «мысль прет», а тебе приходится решать рутинные проблемы (и внезапно, как правило). Традиционное раззвездяйство и совковый пофигизм создают вечный дедлайн, в котором никогда не будет работать ни одна система.
Благодарю. Что-то подобное я подозревал (и даже немножко нагуглил), просто не был уверен насчет верного названия сего безобразия. Действительно, все начинает сходиться на названиях методов/функций.
А чем плох равиоли-код? Насколько я понимаю, это в принципе то, к чему мы стремимся при ОО-разработке: маленькие идеально инкапсулированные кусочки кода. Гугль говорит, что это антоним спегетти-кода, а Вики несколько туманно намекает на то же самое.
Что же за конфликт терминологий такой?
Мой список желаний:
Кроме того, следует понимать, что естественный язык несет в себе отпечаток истории, культуры, менталитета и выражает совсем не то, что нужно выразить при написании программы. Естественность языка программирования такая же утопия, как CASE-средства. Помните прогнозы, что программистов заменят компьютеры, ведомые вооруженными мышками домохозяйками?
Кесарю — кесарево, слесарю — слесарево. Не смешивайте врожденную иррациональность и неоднозначность человеческих языков с математической беспощадностью машин :)
И чисто технический момент: как предполагается рефакторинг проводить? Ведь чтобы жить, программе нужно развиваться.
Строго говоря, copy/paste вообще вне добра и зла. Это просто инструмент, который требует осторожности. То есть, прежде чем воткнуть скопированное, надо остановиться и немножко подумать. И почему-то мне кажется, что легкий неприятный разряд тока заставит многих помедлить, прежде чем воткнуть голые данные/кусок кода/копию настроек. А там, глядишь, мелькнет мысль «а может, сделать константу/функцию/секцию general в конфиге».
Ну и, господа, пять страниц комментариев на тему «как правильно ставить скобочки»! Блестяще! :)
Медиаторы в моем случае выполняют роль посредников между TDataSet и визуальным компонентом (в данный момент используется библиотека DevExpress). Кроме того, медиаторы устанавливают, что будет происходить при изменении данных, используя события объектов TField из набора данных. Ну и главное — медиаторы определяют внешний вид и поведение данных на основе ролей пользователей.
Я не имею права привести здесь реальный код, но если Вам интересно, то могу переработать его для примера. И еще деталь, я пишу на C++ и почти не знаю Object Pascal :)
Можно чуть поподробнее, что за расширяющие методы? Имеются в виду какие-то дополнительные операции, помимо CRUD? А то гугление по extention method выбрасывает ссылки на C#-контент, что немного смутило.
Часто бывает, что «мысль прет», а тебе приходится решать рутинные проблемы (и внезапно, как правило). Традиционное раззвездяйство и совковый пофигизм создают вечный дедлайн, в котором никогда не будет работать ни одна система.
Что же за конфликт терминологий такой?