Сообщение Re[4]: Shareware. Delphi от 13.04.2017 18:08
Изменено 13.04.2017 18:08 CRT
Re[4]: Shareware. Delphi
Здравствуйте, rean, Вы писали:
R>>>2. Стиль 1 форма = 1 исходник = 1 модуль бизнес логики не совместим с продуманным ООП, но совместим с Тяп-Ляп-Ориентированным программированием. В шареваре это особенно актуально, поскольку программа пишется не на один раз. Это придется годами поддерживать и со всеми таким мелочами придется бодаться.
I>>Такой подход скорее не инструментарием определяется, а самим разработчиком.
I>>Если сразу сделать правильную базовую библиотеку классов для будущей системы, то все будет ок.
R>Это само собой. Но я имею ввиду 1 форма = 1 исходник — это означает необходимость для всей формы целиком в рамках одного файла писать обработчики для всех контролов. В случае рефакторинга самой формы это выливается в кучу работы, посколько надо выдирать код и переносить по каждому обработчику. Еще есть неприятная особенность сортировки функций по алфавиту, что мешает группировать функции. Если бы можно было делать обработчик на логическую часть формы в своем классе, проблем бы не было.
R>>>Это какой садист придумал переменные отделять от кода?
I>>Не вижу в этом проблем, это скорее дело привычки.
R>Когда программируешь десятки лет на принципиально разных языках, эта особенность раздражает. Напоминает фортран на перфокартах.
Просто не надо делать код методов и процедур слишком большим. Это полезно, как одна из мер уменьшения вероятности ошибок. А если он небольшой, то переменные получаются близко к коду. Можно также применять вложенные процедуры — вот вам и аналог блоков кода со своими объявлениями переменных. Заодно разобьешь процедуру на подзадачи.
R>>>2. Стиль 1 форма = 1 исходник = 1 модуль бизнес логики не совместим с продуманным ООП, но совместим с Тяп-Ляп-Ориентированным программированием. В шареваре это особенно актуально, поскольку программа пишется не на один раз. Это придется годами поддерживать и со всеми таким мелочами придется бодаться.
I>>Такой подход скорее не инструментарием определяется, а самим разработчиком.
I>>Если сразу сделать правильную базовую библиотеку классов для будущей системы, то все будет ок.
R>Это само собой. Но я имею ввиду 1 форма = 1 исходник — это означает необходимость для всей формы целиком в рамках одного файла писать обработчики для всех контролов. В случае рефакторинга самой формы это выливается в кучу работы, посколько надо выдирать код и переносить по каждому обработчику. Еще есть неприятная особенность сортировки функций по алфавиту, что мешает группировать функции. Если бы можно было делать обработчик на логическую часть формы в своем классе, проблем бы не было.
R>>>Это какой садист придумал переменные отделять от кода?
I>>Не вижу в этом проблем, это скорее дело привычки.
R>Когда программируешь десятки лет на принципиально разных языках, эта особенность раздражает. Напоминает фортран на перфокартах.
Просто не надо делать код методов и процедур слишком большим. Это полезно, как одна из мер уменьшения вероятности ошибок. А если он небольшой, то переменные получаются близко к коду. Можно также применять вложенные процедуры — вот вам и аналог блоков кода со своими объявлениями переменных. Заодно разобьешь процедуру на подзадачи.
Re[4]: Shareware. Delphi
Здравствуйте, rean, Вы писали:
R>>>Это какой садист придумал переменные отделять от кода?
I>>Не вижу в этом проблем, это скорее дело привычки.
R>Когда программируешь десятки лет на принципиально разных языках, эта особенность раздражает. Напоминает фортран на перфокартах.
Просто не надо делать код методов и процедур слишком большим. Это полезно, как одна из мер уменьшения вероятности ошибок. А если он небольшой, то переменные получаются близко к коду. Можно также применять вложенные процедуры — вот вам и аналог блоков кода со своими объявлениями переменных. Заодно разобьешь процедуру на подзадачи.
R>>>Это какой садист придумал переменные отделять от кода?
I>>Не вижу в этом проблем, это скорее дело привычки.
R>Когда программируешь десятки лет на принципиально разных языках, эта особенность раздражает. Напоминает фортран на перфокартах.
Просто не надо делать код методов и процедур слишком большим. Это полезно, как одна из мер уменьшения вероятности ошибок. А если он небольшой, то переменные получаются близко к коду. Можно также применять вложенные процедуры — вот вам и аналог блоков кода со своими объявлениями переменных. Заодно разобьешь процедуру на подзадачи.