|
Переменные PUBLIC - что плохого?
|
||
|---|---|---|
Участник
Откуда: Из Курска понаехал
Сообщения: 10 249 |
||
| 26.11.2007, 09:35 |
|
|
|
|
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
Всем привет! Поискал по форуму - информации много, но кусочно-разрозненная. Можно ли по пунктам - что плохого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2007, 17:32 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
StandDВсем привет! Поискал по форуму - информации много, но кусочно-разрозненная. Можно ли по пунктам - что плохого? Да, в общем, ничего. Если бы они были принципиально плохими, от них бы избавились как в свое время от оператора перехода go to. Просто нужно понимать, что эти переменные существуют до конца работы программы и, соответственно, все это время занимают память. Но если Вы не создаете безумных размеров массивы, трудно представить, что Вы сможете забить всю память переменными. Но даже, если Вы создаете такие массивы , существует команда RELEASE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2007, 18:11 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
StandDВсем привет! Поискал по форуму - информации много, но кусочно-разрозненная. Можно ли по пунктам - что плохого? Плохо тем, что что тяжело ошибки связанные с глобальными переменными в коде искать. Если есть возможность, то лучше их заменять на свойства объектов или как параметр передавать. А ты с какой целью интересуешься? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2007, 19:05 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
Еще тяжело в чужом коде разбираться - откуда что в глобальной переменной взялось, да и в своем коде (давно забытом) - не проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2007, 19:15 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
StandDВсем привет! Поискал по форуму - информации много, но кусочно-разрозненная. Можно ли по пунктам - что плохого? На работе уже 6 месяцов(думаю что и дальше буду на сколько сили хватит) борюся чтоб не использовали PUBLIC переменные. В ответ слышу "а почему бы и нет ведь ето просто". Я еже устал бороться с етим. Не, я понмаю что их мона использовать но когда речь заходит о нескольких программистах работаюший в одной группе, сразу на глобальные переменные ставим большой крест. Выше написанно что потом отлаживать, анализировать код просто не вожможно и так оно и есть... мы используем простой подход Код: plaintext в form1.init() пишем Код: plaintext 1. 2. Все же очень проста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2007, 22:40 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
4kinНа работе уже 6 месяцов(думаю что и дальше буду на сколько сили хватит) борюся чтоб не использовали PUBLIC переменные. В ответ слышу "а почему бы и нет ведь ето просто". Я еже устал бороться с етим. Не, я понмаю что их мона использовать но когда речь заходит о нескольких программистах работаюший в одной группе, сразу на глобальные переменные ставим большой крест. Это не проблема переменных PUBLIC и даже не проблема программистов. Это проблема менеджера проектов. Должен существовать документ, определяющий не только правила создания переменных PUBLIC, LOCAL или PRIVETE, но и правила создание интерфейсов пользователя: шрифты, расстояние между контролами на форме и т.д. Например, все переменные имеют префикс. Первый символ префикса определяет область видимости переменной: глобальные “g”, локальные “l”, приватные “p”. Второй символ префикса определяет тип значения переменной: символьные “c”,числовые “n”, логические “l”, объекты “o”. Эта азбука, по-моему, даже где-то в хелпе предлагается. Имя массива содержит третий символ префикса “a”. Имена переменных должны отражать их содержимое. Например, PUBLIC gcStartPath. Переменные должны объявляться и описываться в начале блока, в котором они используются. Если проект состоит из нескольких модулей, часть из которых может отсутствовать у некоторых пользователей, то глобальные переменные, используемые во всех модулях, объявляются в стартовой процедуре стартового модуля. Глобальные переменные, используемые в подгружаемых модулях, создаются в стартовой процедуре подгружаемого модуля, и к их префиксу добавляется имя создающего из модуля. В этом случае префикс завершается символом “_” (подчеркивание). Префиксы глобальных переменных, созданных формой, включают в себя имя формы, и удаляются при закрытии формы. И т.д. и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 10:02 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
Всем спасибо за информацию. 2DimaT: интересуюсь просто потому, что в последнее время ими чересчур увлекся и решил проверить, чем грозит. 2Fox_vik: переменных порядка сотни. Массивов - 5-6. Это ведь немного по памяти? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 11:09 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
StandDВсем спасибо за информацию. 2DimaT: интересуюсь просто потому, что в последнее время ими чересчур увлекся и решил проверить, чем грозит. 2Fox_vik: переменных порядка сотни. Массивов - 5-6. Это ведь немного по памяти? Памяти хватит, но все-же многовато. У меня 5-7 с общими настройками. Я на 9-ке вместо глобальных переменных свойства к _screen добавляю. чтобы потом не вспоминать как точно назвал, "_screen." пишешь, а там подсказка вылазит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 11:27 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Код: plaintext в form1.init() пишем Код: plaintext 1. 2. Все же очень проста.[/quot] А мне еще нужно знать из какого Grid (у меня основных 3 - сама запись, куда входит, из чего состоит) этой формы был вызов (да еще какое свойство было текущей записи - непример деталь, сборка, покупное). Пока использую глобальные переменные. Что посоветуете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 11:29 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
StandD2Fox_vik: переменных порядка сотни. Массивов - 5-6. Это ведь немного по памяти? Посмотрите в Help Вашей версии FoxPro раздел Visual FoxPro system capacities. Для 9-й версии: Default # of variables. 16,384 Maximum # of variables. 65,000 Maximum # of arrays. 65,000 Maximum # of elements per array. - Normal: 2 gigabytes - Member array: 2 gigabytes - Array of member objects: 65,000 Это общее к-во, включая локальные, существующие на каждый момент времени. Соглашение по именам переменных в разделе Naming Conventions ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 12:03 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
olegv12Здравствуйте. Код: plaintext в form1.init() пишем Код: plaintext 1. 2. Все же очень проста. А мне еще нужно знать из какого Grid (у меня основных 3 - сама запись, куда входит, из чего состоит) этой формы был вызов (да еще какое свойство было текущей записи - непример деталь, сборка, покупное). Пока использую глобальные переменные. Что посоветуете?[/quot] Так же как в качестве параметров передаете форму, передайте и все остальные параметры (грид, деталь, сборка, покупное) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 12:19 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
fox_vikТак же как в качестве параметров передаете форму, передайте и все остальные параметры (грид, деталь, сборка, покупное)Да да. Параметрами передаваемые через форму. StandD поверьте нет таких ситуаций (я их не встречал) в которых необходимость PUBLIC переменных так уж необходима. Придерживайтесь принцыпов об`ектности, хотя в FoxPro трудно их придерживаться, что мня очень удручает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 17:31 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
4kin StandD поверьте нет таких ситуаций (я их не встречал) в которых необходимость PUBLIC переменных так уж необходима. Вообще-то, такие ситуации есть. Как правило, это некая глобальная настроечная информация, которая может быть использована во всех частях приложения. Например, пути доступа к разным директориям. В частности к той, где находится база данных. Сообщения о причине отказа тригера. Набор общих процедур, оформленных как методы некоего глобального класса и т.д и т.п. Другой вопрос, как оформить подобные настройки. Более того, любое приложение имеет глобальные переменные. Просто называются они по другому. Ну, например, в FoxPro Вы всегда можете обратится к свойствам таких объектов как _SCREEN или _VFP. Разве это не глобальные переменные? То, что они являются объектами не отменяет их "глобальности". А вот локальная информация, которая требуется для взаимодействия нескольких локальных объектов, например двух форм, действительно не должна выносится в глобальные переменные. Зачем же из программы помойку делать? Вообще, программирование на FoxPro требует повышенной самодисциплины от программиста. Слишком уж снисходительно относится FoxPro к ошибкам программистов. В отношении глобальных переменных это проявляется особенно заметно. 4kinПридерживайтесь принцыпов об`ектности, хотя в FoxPro трудно их придерживаться, что мня очень удручает... Покажите пример этих трудностей. Может быть, проблема вовсе не в FoxPro, а в Ваших привычках? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2007, 20:41 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
http://www.sql.ru/forum/actualthread.aspx?tid=474634&hl=public авторинтересуюсь просто потому, что в последнее время ими чересчур увлекся и решил проверить, чем грозит если попадете в команду, в которой исп-ся принципы ООП - получите по рукам и всего делов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2007, 09:35 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
Одно из неявных неудобств Public-переменных - загромождение окна дебагера. Представьте себе сотню строк в окне Locals, среди которых нужно отыскать свою. Избежать этого можно, создав один глобальный объект и сделав переменные свойствами этого объекта. Тогда, по мере необходимости, можно открывать нужную ветвь и смотреть значение этих переменных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2007, 11:06 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
ВладимирМ 4kin StandD поверьте нет таких ситуаций (я их не встречал) в которых необходимость PUBLIC переменных так уж необходима. Вообще-то, такие ситуации есть. Как правило, это некая глобальная настроечная информация, которая может быть использована во всех частях приложения. Например, пути доступа к разным директориям. В частности к той, где находится база данных. Сообщения о причине отказа тригера. Набор общих процедур, оформленных как методы некоего глобального класса и т.д и т.п. Другой вопрос, как оформить подобные настройки. Более того, любое приложение имеет глобальные переменные. Просто называются они по другому. Ну, например, в FoxPro Вы всегда можете обратится к свойствам таких объектов как _SCREEN или _VFP. Разве это не глобальные переменные? То, что они являются объектами не отменяет их "глобальности". А вот локальная информация, которая требуется для взаимодействия нескольких локальных объектов, например двух форм, действительно не должна выносится в глобальные переменные. Зачем же из программы помойку делать? Вообще, программирование на FoxPro требует повышенной самодисциплины от программиста. Слишком уж снисходительно относится FoxPro к ошибкам программистов. В отношении глобальных переменных это проявляется особенно заметно. Согласен. ИМХО использование PUBLUC переменых исключительная ситуация ВладимирМ 4kinПридерживайтесь принцыпов об`ектности, хотя в FoxPro трудно их придерживаться, что мня очень удручает... Покажите пример этих трудностей. Может быть, проблема вовсе не в FoxPro, а в Ваших привычках? Есть домумет, я их так любля просто назавть, а посути об`ект, базируется на Контейнере. По логики в етом документе должна быть "красота"(чтоб пользователь мог работать), и какие-то данные (в частоности датаЕнваермент с КурсорАдаптерами). И как реализовать ету весчь? Чтоб в одном контейнере сделать пользовательский интерфейс (кcтати "красоты" там достичь не возможно тк по определению ForPro убог на "красоту"), и датаЕнваермент??? Никак. Все попытки типа Код: plaintext Код: plaintext И хде ООП? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 19:13 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
кcтати "красоты" там достичь не возможно тк по определению ForPro убог на "красоту" Спорное утверждение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 19:43 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
4kin ВладимирМ 4kinПридерживайтесь принцыпов об`ектности, хотя в FoxPro трудно их придерживаться, что мня очень удручает... Покажите пример этих трудностей. Может быть, проблема вовсе не в FoxPro, а в Ваших привычках? Есть домумет, я их так любля просто назавть, а посути об`ект, базируется на Контейнере. По логики в етом документе должна быть "красота"(чтоб пользователь мог работать), и какие-то данные (в частоности датаЕнваермент с КурсорАдаптерами). И как реализовать ету весчь? Чтоб в одном контейнере сделать пользовательский интерфейс (кcтати "красоты" там достичь не возможно тк по определению ForPro убог на "красоту"), и датаЕнваермент??? Никак. Все попытки типа Код: plaintext Код: plaintext И хде ООП? А без выпендрежа и по русски можете объяснить проблему? Я ничего не понял. Вы хотите создать некий класс-контейнер (но не форму) и прикрутить к этому классу источник данных? И в чем проблема? Кстати, "красоту" тоже каждый понимает по своему... Как правило, "красота" в приложении работающем с базой данных только мешает. Вы не забыли, что FoxPro - это СУБД? Т.е. изначально ориентирован на задачи обработки баз данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 20:14 |
|
||
|
Переменные PUBLIC - что плохого?
|
|||
|---|---|---|---|
|
#18+
4kin...Чтоб в одном контейнере сделать пользовательский интерфейс (кcтати "красоты" там достичь не возможно тк по определению ForPro убог на "красоту"), и датаЕнваермент??? Никак. ... Контейнер с пользовательским интерфейсом и ДЕ - это форма. Если уж речь зашла об определениях, то наверно надо дать определение "красоты" для начала. Программа не картина, ей не любуются. Это инструмент. Как думашь строитель задумывается насколько красив его молоток? Понятны и измеримы (хотя бы субъективно) такие вещи как удобство и дружелюбность пользовательского интерфейса, когда пользователь минимальным количеством операций получает нужный результат и не ломает голову "а куда же ткнуть чтобы то-то получилось?" Если речь о "красоте" кода, то не надо утверждать что все плохо, только потому что не получается сделать хорошо. Классическое ООП "красиво" только в теории. ООП делалось под С++ и там реализовано в полном объеме, но я бы не сказал что писать на С++ удобно. PS Вкус и цвет - повод для драки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 08:20 |
|
||
|
|
start [/forum/topic.php?desktop=1&fid=41&tid=1588479]: |
0ms |
get settings: |
12ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
47ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 243ms |
| total: | 360ms |
| 0 / 0 |
