Телеграмм чат группы Delphi

Что-то я не понимаю... зачем скидка на Free edition?

10:46пожаловаться #1

SB

Kit Bayun

Что-то я не понимаю... зачем скидка на Free edition?

В два раза бесплатнее?

10:47пожаловаться #2

SB

Contribute to PyatyginSY/NoLoad development by creating an account on GitHub.

Сергей Пятыгин

Поделитесь опытом по отделению представления от модели.

Вот конкретный пример:
Есть два юнита=модели (классы с наследниками).
1. u_systemmagnetic

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_systemmagnetic.pas#L1

2. u_noload

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_noload.pas#L1

Есть юнит представление u_main

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L1

Есть контроллер, в виде класса-потока TMainThread в u_main.

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L42

Не могу понять, является это полным разделением модель-представление-контроллер или нет.
С одной стороны, u_systemmagnetic и u_noload полностью независимы, не содержат в implementation uses с u_main и могут быть подвергнуты ЮнитТестированию.
С другой стороны, контроллер находиться в одном юните с представлением и представление содержит в interface uses ссылки на u_systemmagnetic и u_noload.
А если контроллера вынести в отдельный юнит (u_main в uses будет содержать некий u_thread, а u_thread в uses будет содержать u_systemmagnetic и u_noload), то как ему передать данные из представления, ведь в новом юните ему будут не видны классы представления (и опять возникнет вопрос который возник ранее-где освободить классы данных переданные в контролер из представления)?

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L139

GitHub

PyatyginSY/NoLoad

В u_main.pas зачем-то сделан TMainThread = class(TThread), который читает данные из формы. Не надо так делать. Основной поток - это и есть сами формы.

10:49пожаловаться #3

KB

А вообще, кто-то пользовался этим волшебником "Delphi Code Analysis Wizard"? Ну прогнал он проект, показал количество строк кода, количество еще чего-то там, а толку с него?

10:49пожаловаться #4

KB

посмотрел цену enterprise версии - $1500 , чем он такой волшебный, что он так дорого стоит?

10:51пожаловаться #5

SB

Contribute to PyatyginSY/NoLoad development by creating an account on GitHub.

Сергей Пятыгин

Поделитесь опытом по отделению представления от модели.

Вот конкретный пример:
Есть два юнита=модели (классы с наследниками).
1. u_systemmagnetic

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_systemmagnetic.pas#L1

2. u_noload

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_noload.pas#L1

Есть юнит представление u_main

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L1

Есть контроллер, в виде класса-потока TMainThread в u_main.

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L42

Не могу понять, является это полным разделением модель-представление-контроллер или нет.
С одной стороны, u_systemmagnetic и u_noload полностью независимы, не содержат в implementation uses с u_main и могут быть подвергнуты ЮнитТестированию.
С другой стороны, контроллер находиться в одном юните с представлением и представление содержит в interface uses ссылки на u_systemmagnetic и u_noload.
А если контроллера вынести в отдельный юнит (u_main в uses будет содержать некий u_thread, а u_thread в uses будет содержать u_systemmagnetic и u_noload), то как ему передать данные из представления, ведь в новом юните ему будут не видны классы представления (и опять возникнет вопрос который возник ранее-где освободить классы данных переданные в контролер из представления)?

https://github.com/PyatyginSY/NoLoad/blob/01ff3ac55371bb9906ff7979ff4f1c12013fee14/u_main.pas#L139

GitHub

PyatyginSY/NoLoad

Еще после каждого IniFile.WriteString выполняется Application.ProcessMessages; От этого тормозов только прибавится. Лучше в TIniFile включить кеширование или сразу использовать TMemIniFile. Тогда запись нескольких тысяч параметров займет доли секунды.

10:52пожаловаться #6

AS

Alexey Shumkin in Delphi & Lazarus

C ассертами все просто и понятно, они ловят аномалии и некорректные параметры. Могут через месяц успешной работы поймать какую-нибудь аномалию железа или ОС. А тесты так могут?

дык, ты ставишь другую цель перед таким тестированием
из того, что ты говоришь, следуует, что ты тестируешь "ОС или железо ))

а я говорю про тестирование поведения программы

10:53пожаловаться #7

SB

Kit Bayun

посмотрел цену enterprise версии - $1500 , чем он такой волшебный, что он так дорого стоит?

Видимо, для галер, код гребцов-джуниоров проверять.

10:53пожаловаться #8

СП

Сергей Пятыгин... in Delphi & Lazarus

В u_main.pas зачем-то сделан TMainThread = class(TThread), который читает данные из формы. Не надо так делать. Основной поток - это и есть сами формы.

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

Как оптимально передавать класс данных в поток?

10:54пожаловаться #9

AS

Alexey Shumkin in Delphi & Lazarus

Видимо, для галер, код гребцов-джуниоров проверять.

где они , галеры на делфи? ))))

10:54пожаловаться #10

SB

Alexey Shumkin

дык, ты ставишь другую цель перед таким тестированием
из того, что ты говоришь, следуует, что ты тестируешь "ОС или железо ))

а я говорю про тестирование поведения программы

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

10:54пожаловаться #11

СП

Сергей Пятыгин... in Delphi & Lazarus

Еще после каждого IniFile.WriteString выполняется Application.ProcessMessages; От этого тормозов только прибавится. Лучше в TIniFile включить кеширование или сразу использовать TMemIniFile. Тогда запись нескольких тысяч параметров займет доли секунды.

Это микроприложение из разряда "иди на кошках тренируйся". В основной версии именно TMemIniFile. Но это наверное не окончательный вариант.

Вообще если есть возможность и желание, то мне хотелось бы получить побольше замечаний по "запаху" в коде.

10:56пожаловаться #12

AS

Alexey Shumkin in Delphi & Lazarus

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

ну это почти вверху пирамиды тестирования (UI тестирование ))

10:56пожаловаться #13

SB

Сергей Пятыгин

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

Как оптимально передавать класс данных в поток?

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

10:59пожаловаться #14

СП

Сергей Пятыгин... in Delphi & Lazarus

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

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

11:02пожаловаться #15

KB

Видимо, для галер, код гребцов-джуниоров проверять.

как правило, Дельфи использую внутри корпораций фирм, где работают 1-3 программиста над собственными внутренними продуктами. Т.е. одной копии вполне достаточно. Не видел я (почти не видел) фирм, где массово используют Дельфи для написания софта на продажу. Вот в Харькове есть Глобаллоджик, довольно огромная фирма и все, больше не видел.

11:02пожаловаться #16

SB

Alexey Shumkin

ну это почти вверху пирамиды тестирования (UI тестирование ))

Мне от предшественника досталась куча юнит-тестов, там кода было больше, чем в основном проекте. И хотя тесты проходили успешно, система дико тормозила и глючила. То есть, с точки зрения программиста все хорошо, а с точки зрения пользователя прога виснет или падает каждые полчаса работы. Чье мнение важнее начальству? =)

11:05пожаловаться #17

I

Igor in Delphi & Lazarus

вывод: тесты тестировали не то, что нужно

11:07пожаловаться #18

SB

Сергей Пятыгин

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

Предлагаю сделать в классе метод Assign(), который копирует все свойства экземпляра класса в другой экземпляр того же класса. В идеале внутри Assign используется CriticalSection. При создании потока, внутри Execute создавать отдельный экземпляр класса, и снаружи потока (из кнопки формы, нпример) делать Assign данных из класса данных формы в класс данных потока. Или наоборот, Assign данных из потока в форму.

11:11пожаловаться #19

SB

Igor

вывод: тесты тестировали не то, что нужно

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