Shareware. Delphi - Shareware и бизнес

Здравствуйте, rean, Вы писали:

R>Это само собой. Но я имею ввиду 1 форма = 1 исходник — это означает необходимость для всей формы целиком в рамках одного файла писать обработчики для всех контролов. В случае рефакторинга самой формы это выливается в кучу работы, посколько надо выдирать код и переносить по каждому обработчику. Еще есть неприятная особенность сортировки функций по алфавиту, что мешает группировать функции. Если бы можно было делать обработчик на логическую часть формы в своем классе, проблем бы не было.

А кто тебе мешает разделить gui и бизнес-логику?

Здравствуйте, wamaco, Вы писали:

W>Приветствую!
W>Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi
W>Поделитесь успешными историями, доходами, "подводными камнями", какого рода программы, используемые технологии VCL,FMX...
W>Нужно для мотивации!

Ну что я вам скажу про Сахалин, ой Object Pascal.
Это прекраснейший чётко типизированный язык программирования.
Да там нет как-бы таких штук как шаблоны(в чистом виде языка каким я его запомнил),метапрограммирования,всяческого.
Да выражать на нём многие мысли не так удобно как на C++(возможно просто к C++ я привык 20 лет почти как никак кодю ,
а от Делфи отвык на нём отсилы годика два кодил.) VCL присутствует не только в Delphy но и в C++ Borland Builder.
По сути, конечно удобней было в те стародавние времена MSVC + QT, ибо фич больше , код приятней,и много других няшек.
Отладочные символы не отваливаются во время отладки(а это то чем запомнилась отладка и в Delphi и в Builder).
Успешные проекты?Мне похвастаться на делфе совершенно нечем. Хотя попадались в руки поделки в начале 2000-ых,
типа Essential Net Tools, Но интерфейс там был настолько ущербным, что выкинуть их хотелось обычно сразу.
Delphi это язык зоданный для того, что-бы за него можно было посадить кого угодно, но квалифицированные люди рано
или поздно уходили на тот-же С++ Игшдвук к примеру(хотя особой разницы то и нет,кроме одной наличие всех вкусняшек C++).

R>Это само собой. Но я имею ввиду 1 форма = 1 исходник — это означает необходимость для всей формы целиком в рамках одного файла писать обработчики для всех контролов. В случае рефакторинга самой формы это выливается в кучу работы, посколько надо выдирать код и переносить по каждому обработчику.

Чего? Это если писать код прямо в обработчике события (да, да, я тоже этим грешил в былые времена).
По уму в обработчике только вызов функции/метода из модуля с логикой.

Ну вот мой проект тут описывают
http://www.manhunter.ru/underground/568_programmi_dlya_zamorozki_vremeni_i_obhoda_trialnih_zaschit.html
Единственное что сделал на Delphi это форму с ListBox-ом , Combobox-ом, драйвера, сервис и библиотеку заморозки естественно
делал на C++. Поскольку это была курсовая когда-то, на интерфейс просто не хотелось тратить время.
Собсно вот интерфейсная часть моего тайм-фрозера HallOfTheMontainKing который.

Проект покачто закрыт. Некогда заниматься такой ерундой. Проблем слишком много.

Здравствуйте, extazy42, Вы писали:

E>Здравствуйте, alfa78x, Вы писали:

A>>Ну кто разбирается, тот поймет, что софт не из валирийской стали.

E>Да, лучше бы подошел пример с твердостью и прочностью металла

Вам твёрдость по Роквеллу или по Бринеллю?

Здравствуйте, TMU_1, Вы писали:

TMU>Чего? Это если писать код прямо в обработчике события (да, да, я тоже этим грешил в былые времена).
TMU>По уму в обработчике только вызов функции/метода из модуля с логикой.

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

Здравствуйте, wamaco, Вы писали:

W>Кто нибудь есть, кто делает и успешно продает shareware используя для разработки Delphi

Делаем и успешно продаём. Начиная с 2003 года. За это время Delphi успели несколько раз похоронить, но это не смущает, если честно, потому как лучшего средства для разработки софта, работающего с СУБД, в мире просто ещё не придумали.
Можно, конечно, и на Java и на .NET рисовать формы к БД, но трудозатраты просто не сравнимы, особенно на Java.
Также успешно пишутся всякие DLL для запуска в качестве веб-сервиса через тот же IIS. Все стабильно работает и не требует 20 человек для кодинга.
Как-то так

И ещё небольшое уточнение.
Недавно Эмба выпустила компилятор для Линукса. Народ на скуле активно плюётся, типа фигня какая-то, asm не красивый генерится. Это же так важно, у нас все заказчики и покупатели софта первым делом проверяют оптимальность сгенерированного компилятором кода, а не функции софта.

Но вот на буржуйских форумах ситуация иная. Внезапно всплыл Крюков (автор FMX) со своим shareware проектом http://www.fmxlinux.com/
Выглядит интересно. Так что Delphi живет и, думаю, будет жить ещё очень долго.
Во всяком случае мы никуда мигрировать не планируем. Всё работает.

Здравствуйте, rkcsoft, Вы писали:
R>Но вот на буржуйских форумах ситуация иная. Внезапно всплыл Крюков (автор FMX) со своим shareware проектом http://www.fmxlinux.com/
R>Выглядит интересно. Так что Delphi живет и, думаю, будет жить ещё очень долго.
R>Во всяком случае мы никуда мигрировать не планируем. Всё работает.

Ну дык правильно, FMX он же продал несколько лет назад, вот новый проект — EMB потом купит! :D

Ну а по теме, у нас на сайте все на Delphi и Lazarus, драйвера на Си. Менять на что-то другое смысла нет.

Здравствуйте, rean, Вы писали:

R>Это вам не формы 70-х годов на мейнфреймах, когда ввел кучу данных, даже не общаясь с самим ЭВМ, и лишь после нажатия на финальную кнопку понеслось взаимодействие с хостом. Сейчас формы таковы, что любое нажатие на кнопку или перемещение мыши что-то меняет на форме.

И что это меняет? Говнокод можно на любом языке создавать.
Если ты не представляешь как отделить GUI от логики, то видимо квалификация хромает.

Здравствуйте, rean, Вы писали:

R>Перечитайте еще раз, о чем идет речь. А речь идет не о разделении бизнес логики от представления, а о том, что большая часть кода пишется в одном юните. И если представление активно взаимодействует с контролами, то получаем гиганский по размеру исходник.

в одном юните только методы для изменения и отображения состояния бизнес логики
десятки и сотни контролов на одной форме — плохо спроектированный интерфейс

R>А теперь представьте, что на форме десятки контролов, изменение которых в реальном времени должно что-то поменять в бизнес-логике и одновременно еще что-то рисуется и все контролы должны обновить свое актуальное значение.

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

Здравствуйте, rean, Вы писали:

R>Пример обработки одного контрола:

R>

R>procedure TMainForm.SomePosEditChange(Sender: TObject);
R>begin
R>  if ImmediateChanging then
R>  begin
R>    ImmediateChanging := False;
R>    SomeControllerValue := SomePosUpDown.Position;
R>    CallBusinessLogicToApplyChangeImmediately;
R>    CallBusinessLogicToSyncChangeToFormControls;
R>    ImmediateChanging := True;
R>  end;
R>end;
R>

Если коротко, то: "Не делайте так" (C)
Тут чисто ошибка проектирования, ни Object Pascal ни VCL никого не принуждают делать именно так.

Здравствуйте, rean, Вы писали:

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

ну почему же, наследование форм хорошо работает, фреймы есть
да и никто не заставляет ограничиваться визуальным программированием, можно динамически GUI генерировать и на Delphi

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

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

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

Здравствуйте, rean, Вы писали:

R>Потому что событие изменения значения контрола одновременно возникает и на присваивание и на изменение юзером;

отключай обработчик при присваивании

R>а изменение бизнес логики длится не мгновенно, и надо еще опитимизировать код так, чтобы не все менять.

используй callback в бизнес логике

похоже ты просто зациклился на визуальности и не видишь картины в целом

От:	K13	http://akvis.com
Дата:	13.04.17 18:36
Оценка:

	От:	icezone
	Дата:	14.04.17 07:30
	Оценка:

	От:	icezone
	Дата:	14.04.17 07:39
	Оценка:	+1

	От:	Burbulis1978
	Дата:	14.04.17 08:18
	Оценка:

	От:	TMU_1
	Дата:	14.04.17 08:18
	Оценка:	+2

От:	Черный Властелин	https://www.softperfect.com
Дата:	14.04.17 12:13
Оценка: