override or overload ?

← →
Сергей М. © (2008-05-13 12:40) [40]

> что же догда понимать под справочником программы ?

Это тебя надо спросить, что ты под этим понимаешь)

> как реализовать "гибкий справочник"

Какой такой "гибкий" ?)

← →
Skyle © (2008-05-13 12:41) [41]

> User1 (13.05.08 12:30) [39]

Определение "гибкого справочника для работы с некоторыми таблицами в БД" в студию.

← →
Игорь Шевченко © (2008-05-13 12:50) [42]

Любой "гибкий справочник" подлежит безусловному сожжению в топке

← →
Сергей М. © (2008-05-13 12:58) [43]

Мож и не любой, но "справочник программы" типа Гандбук гореть будет хорошо)

← →
User1 (2008-05-13 13:04) [44]

> Игорь Шевченко © (13.05.08 12:50) [42]

Почему ?

← →
Игорь Шевченко © (2008-05-13 13:08) [45]

User1 (13.05.08 13:04) [44]

Потому что нет ничего более уродливого и не сопровождабельного, чем "гибкое".

← →
Сергей М. © (2008-05-13 13:14) [46]

> User1 (13.05.08 13:04) [44]

ИШ хотел сказать, что колоть орехи можно и микроскопом, со всеми вытекающими последствиями.

← →
Anatoly Podgoretsky © (2008-05-13 13:26) [47]

> User1 (13.05.2008 13:04:44) [44]

Гнется куда не надо.

← →
User1 (2008-05-13 13:49) [48]

> Игорь Шевченко © (13.05.08 13:08) [45]

Может быть, но тогда посоветуйте из своего опыта:
Как тогда лучше реализовать справочник n таблиц ?
Помещать на форму DataSource, DataSet, Grid- ы для каждой таблицы ?

Это конечно вариант, но тогда увеличатся размеры программы, а хочется как-то менее масштабной сделать.

← →
Игорь Шевченко © (2008-05-13 14:04) [49]

User1 (13.05.08 13:49) [48]

> Как тогда лучше реализовать справочник n таблиц ?

Наверное как лучше реализовать интерфейс к n справочникам, находящимся в n таблицах ?

Воспользоваться механизмом наследования, например, сделав базовую функциональность в форме-предке, а работу с конкретными справочниками вынести в наследников этой формы, если есть различия. Ну и разумеется на каждый справочник свой DataSet, в датамодуле или в одном кучу или в нескольких, по вкусу. Соответственно, Grid и DataSource будут находиться в предке. Один раз.

Но это чаще всего идиотский интерфейс, сделанный, потому что "по другому не умеем". Делать работу со справочниками в программе вместо того, чтобы заполнять их один раз, стоит только в единственном случае - когда данные в справочниках меняются примерно с той же интенсивностью, что и данные, в которых эти справочники используются.

Размер программы - это последнее, на что стоит обращать внимание при ее разработке.

← →
User1 (2008-05-13 14:37) [50]

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

Очень верно заметили, спасибо что обозначили направление в котором необходимо двигаться. Теперь немного понял суть "общего" дела.

Хотелось бы последний вопрос запостить в этой ветке, а именно:

> Воспользоваться механизмом наследования, например, сделав
> базовую функциональность в форме-предке, а работу с конкретными
> справочниками вынести в наследников этой формы, если есть
> различия.

Вот этого примеры есть ?

← →
oxffff © (2008-05-13 14:38) [51]

> Игорь Шевченко © (13.05.08 13:08) [45]
> User1 (13.05.08 13:04) [44]
>
> Потому что нет ничего более уродливого и не сопровождабельного,
> чем "гибкое".

Честно говоря слух режет.
У вас был печальный опыт?
Может вы хотели сказать о недокументированном коде?

Гибкостью имеет смысл жертвовать в угоду скорости, но в угоду выразительности не стоит. IMHO.

← →
User1 (2008-05-13 14:39) [52]

К
> User1 (13.05.08 14:37) [50]

Наверное как лучше реализовать интерфейс к n справочникам, находящимся в n таблицах ?

← →
Kolan © (2008-05-13 14:39) [53]

> Потому что нет ничего более уродливого и не сопровождабельного,
> чем «гибкое».

Соглдасен.

> Как тогда лучше реализовать справочник n таблиц ?

Просто. Надо сделать n форм для каждого справочника. Причем уи должен учитывать особенноти конкретного справочника.

← →
Игорь Шевченко © (2008-05-13 14:50) [54]

oxffff © (13.05.08 14:38) [51]

> У вас был печальный опыт?
> Может вы хотели сказать о недокументированном коде?

Честно говоря, не совсем понял направление мысли.

Код должен быть простым и ясным, человек должен быть непьющим, вся гибкость в прикладных задачах обычно идет лесом, потому что прикладные задачи обычно живут дольше, чем предполагается при их разработке и разгребать гибкость, пусть даже комментированную, не самое приятное занятие.

> Гибкостью имеет смысл жертвовать в угоду скорости, но в
> угоду выразительности не стоит. IMHO.

Выразительность кода - это самое главное качество в прикладных программах, по причине, приведенной чуть выше, если только по постановке не оговорено обратное. Например, если особо оговорено быстродействие, то имеет смысл критические части кода написать на ассемблере (если все остальное уже испробовано и не привело к успеху), хотя выразительность ассемблерного кода мягко говоря, невысока.

User1 (13.05.08 14:37) [50]

> Вот этого примеры есть ?

А я не знаю твоих задач, как я могу привести примеры ?

← →
oxffff © (2008-05-13 14:52) [55]

> Игорь Шевченко © (13.05.08 14:04) [49]
> User1 (13.05.08 13:49) [48]
>
>
> > Как тогда лучше реализовать справочник n таблиц ?
>
>
> Наверное как лучше реализовать интерфейс к n справочникам,
> находящимся в n таблицах ?
>
> Воспользоваться механизмом наследования, например, сделав
> базовую функциональность в форме-предке, а работу с конкретными
> справочниками вынести в наследников этой формы, если есть
> различия. Ну и разумеется на каждый справочник свой DataSet,
> в датамодуле или в одном кучу или в нескольких, по вкусу.
> Соответственно, Grid и DataSource будут находиться в предке.
> Один раз.

Довольно странное предложение о формах предках.
А что нельзя передавать Caption и Dataset в конструкторе.
Ведь судя по коду ведь ничего не требуется.

>User1 (13.05.08 14:37) [50]

Твоя задача в достижении гибкости заключается в отвязывании от конкретных справочников.

Такой код следует избегать.

> constructor TfHandBook.Create(AOwner: TComponent; ARec:
> THandBook);
> begin
> inherited Create(AOwner);
> FRec := ARec;
> case FRec.ShowType of
> shbUnknown:
> begin
> Close;
> end;
> shbRequisite:
> begin
> Caption := SRequisite;
> ds.DataSet := dm.qRequisite;
> end;
> else
> begin
> //Íåèçâåñòíûé âèä âûçûâàåìîãî ñïðàâî÷íèêè.
> end;
> end;
> end;

А заменить на

constructor TfHandBook.Create(AOwner:Component;ShowType:Integer);
var Rec:THandBook;
begin
rec:=AvailableDicts[ShowType];
rec.BeforeActivate;
if rec.AllowToShow then
begin
Caption := rec.caption;
ds.DataSet := rec.qRequisite;
end
else
Close;
rec.AfterActivate;
end;

RegisterDict( TUniDict.create(caption,Dataset,OnBeforeActivate,OnAfterActivate));

← →
Юрий Зотов © (2008-05-13 14:54) [56]

> Игорь Шевченко © (13.05.08 14:04) [49]

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

Есть справочник. Пополняется по одной записи в месяц. Пополнять его должен обыкновенный юзер. Как быть?

← →
Сергей М. © (2008-05-13 15:04) [57]

> User1 (13.05.08 13:49) [48]
>
>

Какая уж тут "гибкость", если ты жестко прописал информацию о таблицах, с которыми будет вестись работа, прямо в коде будущего приложения ?

← →
Anatoly Podgoretsky © (2008-05-13 15:04) [58]

> Юрий Зотов (13.05.2008 14:54:56) [56]

Пополнять может только то кто имеет права на это.

← →
Игорь Шевченко © (2008-05-13 15:10) [59]

oxffff © (13.05.08 14:52) [55]

> RegisterDict( TUniDict.create(caption,Dataset,OnBeforeActivate,
> OnAfterActivate));

Через какое время ты забудешь о том, что делает этот код ?

Юрий Зотов © (13.05.08 14:54) [56]

> Есть справочник. Пополняется по одной записи в месяц. Пополнять
> его должен обыкновенный юзер. Как быть?
> <Цитата>
> » удаление...

В разных случаях по-разному, очевидно. Какой юзер, какие данные, и т.д.
Можно раз в месяц выполнить SQL-запрос на вставку записи, например. Можно написать "интерфейс" по образу и подобию, как у автора темы, чтобы раз в месяц юзер с чувством глубокого удовлетворения вводил туда очередную запись.
Можно еще что-нибудь.

← →
Юрий Зотов © (2008-05-13 15:12) [60]

> Можно раз в месяц выполнить SQL-запрос на вставку записи

Довольно сомнительно, чтобы обыкновенный юзер вообще знал слово SQL.

← →
oxffff © (2008-05-13 15:16) [61]

> Игорь Шевченко © (13.05.08 15:10) [59]
> oxffff © (13.05.08 14:52) [55]
>
>
> > RegisterDict( TUniDict.create(caption,Dataset,OnBeforeActivate,
>
> > OnAfterActivate));
>
>
> Через какое время ты забудешь о том, что делает этот код
> ?

Я не забуду. Для более сложных случаев я делаю пометки в виде словестного описания.

← →
Игорь Шевченко © (2008-05-13 15:20) [62]

Юрий Зотов © (13.05.08 15:12) [60]

> Довольно сомнительно, чтобы обыкновенный юзер вообще знал
> слово SQL.

Обыкновенный юзер не знает слова Windows - этому слову его учат.
А для слова SQL применительно к обновлению справочника можно вполне составить пошаговую инструкцию с картинками.

oxffff © (13.05.08 15:16) [61]

> Я не забуду. Для более сложных случаев я делаю пометки в
> виде словестного описания

Если ты занимаешься этим один, то никаких вопросов с моей стороны нет и быть не может, все, в чем человек варится самостоятельно, может быть организовано как угодно.
Я обычно имею в виду работу в команде, когда код передается от программиста программисту.

← →
User1 (2008-05-13 15:25) [63]

> Юрий Зотов © (13.05.08 14:54) [56]

К сказанному, имеются таблицы: tPoint (Населенные пункты), tStreet (Улицы), tHome (Дома), обновляется таблица tHome примерно 1-9 раз в месяц. И не именно из-за того что эта таблица должна нести "свежие данные", тогда бы это был не справочник, а из-за выявления ошибок, или добавления "вновь поступивших" домов. Таблица содержит примерно 55000 записей причем 55000 индивидуальны (одна запись, один дом и информация о нем).
Таблицы tPoint и tStreet обновлялись один раз, и особой потребности в их обновлении не наблюдается, но их тоже необходимо отображать Оператору в виде справочной информации.

Всего справочников насчитывается около 9 таблиц, и для этих 9 таблиц необходимо реализовать "достойный пользовательский интерфейс", "достойный" как в смысле размеров приложения, гибкости справочника (в принципе оператор этого не замечает), так и в смысле навигации и поиска.

Для решения поставленной самому себе задачи, я пока судя из ветки вижу два способа, это: constructor, переписка метода Create и interface.

Как реализовать справочник при помощи "constructor" я уяснил, как реализовать справочник при помощи interface, пока мне непонятно.

Т.к. "constructor" судя по ветке был "закритекован" чем же тогда лучше "interface метод" ?
И как решаете и решали эти задачи вы ? А задача это реализовать справочник в программе...

Спасибо.

← →
Игорь Шевченко © (2008-05-13 15:28) [64]

> К сказанному, имеются таблицы: tPoint (Населенные пункты),
> tStreet (Улицы), tHome (Дома),

Если не секрет, зачем ?
Как они используются ?

← →
User1 (2008-05-13 15:32) [65]

> Сергей М. © (13.05.08 15:04) [57]
>
> > User1 (13.05.08 13:49) [48]
> >
> >
>
>
> Какая уж тут "гибкость", если ты жестко прописал информацию
> о таблицах, с которыми будет вестись работа, прямо в коде
> будущего приложения ?

Гибкость в пределах конкретного приложения.

Если бый хотел реализовать гибкость в пределах приложений, тогда бы пришлось помещать форму справочника в dll, и жестко не прописывать используемые таблицы в юните, а передавать в качестве параметра одной из функций (процедуре) указатель на DataSet, а с этим возникает множество проблем...

← →
Юрий Зотов © (2008-05-13 15:34) [66]

> Игорь Шевченко © (13.05.08 15:20) [62]

> Обыкновенный юзер не знает слова Windows - этому слову его учат.
> А для слова SQL применительно к обновлению справочника можно вполне
> составить пошаговую инструкцию с картинками.

Ты предлагаешь заодно обучить его SQL? И поставить ему дополнительную программу, которая этот SQL выполнять будет? И научить его с этой программой работать?

По инструкции с картинками.

Что ж, это можно. Можно придумать и еще целую кучу ректальных решений вместо одного простого, всем понятного и вполне естественного - сделать форму редактирования справочника.

И не морочить юзеру голову SQL и прочими вещами, которые к его работе не имеют никакого отношения.

← →
Сергей М. © (2008-05-13 15:36) [67]

> User1 (13.05.08 15:25) [63]

А ты не задумывался над распределенным Web-приложением ?

На стороне Web-клиента все готово - любой Web-браузер вполне успешно выполнит роль "универсального гибкого справочника".

На стороне Web-сервера ты волен строить любые польз.интерфейсы любого уровня сложности и "достойности" для доступа к любому набору данных.

← →
User1 (2008-05-13 15:48) [68]

> Игорь Шевченко © (13.05.08 15:28) [64]

tPoint -> tStreet -> tHome- это только часть связки структуры БД.

Затем чтобы можно было производить выборку без GROUP.
Затем чтоб сократить размер базы. (Тут конечно проигрыш в производительности, но с сегодняшним оборудованием я не вижу особых ограничений.)
Они используются в отчетах, где в таблицах tPoint, tStreet имеются поля классифицирующие каждую запись по своему и в соответствии с этим получаем несколько отсчетов разной формы.

Юрий Зотов © (13.05.08 15:34) [66]

Вот поэтому линукса никогда не будет на декстопе. Потому что забота о том, чтобы пользователь кроме мышки ничего в руку не брал и каждый раз продирался сквозь лабиринт окошек. Зато чудно, все при деле - юзер кнопки на мышке ломает, программистам на хлебушек, чтобы на каждый чих пользователя очередной набор окошек писать.

> Ты предлагаешь заодно обучить его SQL? И поставить ему дополнительную
> программу, которая этот SQL выполнять будет? И научить его
> с этой программой работать?

Вот при установке клиента Oracle, например, с которым наши "юзеры" работают, программка, которая SQL выполняет, ставится, знаешь ли, по умолчанию.

> И не морочить юзеру голову SQL и прочими вещами, которые
> к его работе не имеют никакого отношения.

Юра, если ты написал такую программу, что пользователям кроме нее вообще ничего не нужно (кроме операционной системы), я тебе искренне обзавидовался.

User1 (13.05.08 15:48) [68]

> Затем чтобы можно было производить выборку без GROUP.

Больше вопросов не имею

← →
User1 (2008-05-13 15:51) [71]

> Что ж, это можно. Можно придумать и еще целую кучу ректальных
> решений вместо одного простого, всем понятного и вполне
> естественного - сделать форму редактирования справочника.
>
>
> И не морочить юзеру голову SQL и прочими вещами, которые
> к его работе не имеют никакого отношения.

Good ! :o) Хотя я конечно понимаю, что Игорь Шевченко сказал это не в прямом смысле...

← →
User1 (2008-05-13 15:53) [72]

> Вот поэтому линукса никогда не будет на декстопе. Потому
> что забота о том, чтобы пользователь кроме мышки ничего
> в руку не брал и каждый раз продирался сквозь лабиринт окошек.
> Зато чудно, все при деле - юзер кнопки на мышке ломает,
> программистам на хлебушек, чтобы на каждый чих пользователя
> очередной набор окошек писать.

Тоже верно.

← →
User1 (2008-05-13 16:09) [73]

Вот к слову например:

Реализованный в Enterprise Manager SQL Server 2000, Grid (который появляется при выполнении Open Table -> Return all Rows), я так понимаю при каждом создании таблицы, “ведь не создается форма с Grid- ом…”.

Как например там реализовали “подход справочника” если можно так сказать… ?

> Игорь Шевченко © (13.05.08 15:50) [69]

Игорь, юзер хочет и должен заниматься СВОЕЙ работой, а не освоением команд ОС, языка SQL и клиента Oracle. У него и без этого забот хватает.

Компьютер для него - лишь инструмент, который эту ЕГО работу ускоряет, делает простой и удобной. Именно потому, что есть мышка, окошки и программист, эти окошки написавший.

Я не поверю, что твои юзеры - другие.

у нас например некоторый юзер считает, што его работа - забить данные в эксель, а потом одну кнопку нажать - остальное не его забота, чего происходит по кнопке, потом только пусть отчеты правильные и все
главный инструмент юзера - эксель

> Юрий Зотов (13.05.2008 15:34:06) [66]

Зачем дополнительную, что пункта меню и отдельной формы недостаточно?
Вспомним также историю создания SQL - он как раз для рядовых пользователей и создавался, что бы они могли строить простые запросы без программиста.

Юрий Зотов © (13.05.08 16:15) [74]

Безусловно, пользователь должен заниматься своей работой. В процессе любой работы он пользуется инструментами. Можно сделать один инструмент на все операции пользователя (гибрид пассатижей с молотком), а можно для разных операций использовать разные инструменты. Только и всего.

Ты знаешь, как ни странно, навигацию в интернете пользователи осваивают довольно быстро, несмотря на то, что к работе эта навигация обычно не имеет ни малейшего отношения.

> Я не поверю, что твои юзеры - другие.

Они у меня разные. И выполняют разные задачи. И вообще мы в дальнейшем от ручного ввода отказываемся - невыгодно, слишком много ошибок, слишком много противоречий, обычно нужные нам данные уже в какой-то электронной форме тем или иным образом присутствуют, их надо только преобразовать в нужный для системы вид и загрузить в нее.

> Anatoly Podgoretsky © (13.05.08 16:26) [77]

Толь, честное слово, я не предлагал для редактирования справочников писать отдельную программу, веришь?
:о)

> ^-k2-^ © (13.05.08 16:26) [78]

Действительно - и на фига в Екселе форма справочника? Да вообще формы?
:о)

override or overload ? Найти похожие ветки