Шатёркинда ладно - sql тоже затронем :)

автор
*** BAD code: ***

SELECT @country_name = country.country_name
FROM country,
city,
address
WHERE country.country_id = city.country_id
AND city.city_id = address.city_id
AND address.address_id = @address_id;

*** GOOD code: ***
SELECT @country_name = country.country_name
FROM country
JOIN city
ON city.country_id = country.country_id
JOIN address
ON address.city_id = city.city_id
AND address.address_id = @address_id;

что-то мне подсказывает, что всё с точностью до наоборот :)Я до недавнего времени тоже не был поклонником метода с ключевым словом JOIN - более того, стоял на "старом" синтаксисе насмерть, как 26 бакинских комиссаров. А всё из-за многолоетней привычки. Но на новой работе меня заставили перейти на новый синтакс, и поработав с ним я стал его поклонником (думаю, отзывы в этой ветке тоже кое-что да изменят в моих взглядах). Если вкратце, то при WHERE-методе всё свалено в одну кучу; при JOIN-методе мы имеем несколько меньших "кучек", и каждый раз можем комфортно сосредоточиться на том, как одна таблица связана с общей картиной; проанализировав её, переходим к следующей. Как в притче с веником: целый веник сломать трудно, а по прутику - легко!

18-я веснарассмотрим в разрезе рефакторинга:
Допустим поменялся набор параметров для вызова окна (добавлен, удален, переименован параметр)
При технике 1 если не везде в вызывающем коде отразить эти изменения, то ошибки после удаления или переименования всплывут только в рантайм при попытке открыть окно.
При технике 2 ошибки после удаления или переименования возникнут уже при компиляции и их придется исправить.ОК, ошибки всплывут на несколько минут позже, при юнит-тесте. Видишь, что параметр не получен - смотришь почему (в вызывающем скрипте). Из-за этого наводнять аппликацию десятками объектов, да ещё и поддерживать (каждый раз изменять) их?

18-я веснаСамодокументирование.
Техника 1. Перечень и тип возможных параметров можно узнать только проанализировав алгоритм разбора этих параметров в окне.
Техника 2. Параметры отделены от алгоритма и четко видны.При первом методе всё сосредоточено в скрипте, принимающем параметры (Open, pfc_open, uf_get_key() или что бы там ни было) - имею в виду в плане самодокументации, чтоб понять что передаётся. Т.е. всё - в одном месте, а не разбросано по разным частям аппликации как в методе 2. О чём ещё мечтать бедному программисту? Кроме того, не все параметры всегда передаются (имеются объекты параметров, используемые в разных обстоятельствах - иначе пришлось бы иметь не сотни, а тысячи подобных "красавцев"). И вот я смотрю на поля объекта параметров, которые, как ты пишешь, "четко видны", и вижу, что имеются незаполненные. Что это? Баг или нет? Как определить? Всё равно придётся лезть в открывающий скрипт и смотреть логику, алгоритм, а при неполучении ожидаемого результата - дебагировать.

Конечно, в твоих контраргументах есть много рационального, хоть я на них и ответил своими. Но тут мы имеем то, что всегда имеем - палку о двух концах, а именно: какой метод ни возьми, он имеет достоинства и недостатки. Единственный выход - ждать пенсии.

Anatoly MoskovskyА мой вопрос был: как конкретно реализована передача разных наборов аргументов в разные окна используя наследование Message?Я так предполагаю, имеется некий класс (унаследованный от Message) с полями для передачи самых часто встречающихся в приложении сущностей (а в каждой аппликации их как правило хоть несколько штук да имеется) плюс, быть может, поинтеры для транспортировки datawindows, datastores и NVOs и прочих непримитивных типов, а от него унаследованы другие, в которых объявлены дополнительные, уже специфические для тех частей аппликации где объекты будут использованы. Причём базовый класс может быть инстантиирован для использования as is если имеющихся в нём полей достаточно. Или не угадал?

Дык давай версии - может, что-нибуть гениальное придумаем.

urvasПрограммист!
Пиши так, чтобы конечному пользователю было комфортно, удобно и приятно.Это уже абсолютно другая тема, хоть и важная. А сейчас обсуждается тема - чтоб было комфортно, удобно и приятно программисту. Мы ж тоже люди!

Статья о стиле программирования переработана и дополнена, если кому интересно.