Как Вы обходитесь без Generic Types и Reflection API?

Я использую [url=https://www.salesforce.com/us/developer/docs/apexcode/Content/langCon_apex_SObjects.htm]SObject, Object[/url], [url=https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_type.htm]Type[/url]

[quote="Gres"]Как Вы относитесь к тому, что в 25 версии выпилили поддержку Generic Types, а также нет Reflection API. 
Кно-нибудь пробовал реализовать DI?[/quote]

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

Два аргумента:
1. был у нас на фирме один человек, который попытался ввести какие-то интерфейсы, наследования (и это еще основы) - код стал монструозным и тяжело поддерживаемым. Хорошо это все использовать если ты один программируешь. А если с тобой работает 10 человек, которые это не используют. В общем этого программиста "сожгли на костре" :) .

2. как-то был на собеседовании у java разработчиков - выжали все соки по теории. Я эти вопросы запомнил и спрашивал у java программистов которые реально работают - ответ был "да фиг его знает, все равно это не используем" и это не мешает им получать солидные бабки :) 

ооооо....ты сильно не прав.

1. Я написал для своего проекта класс который используется для реализации trigger dispatcher. Для фирмы в которой я сейчас работаю, расшарил немного другой вариант. Так вот на админимтративном уровне было решено внедрять именно этот паттерн. Так вот парня что сожгли на костре, отшлепайте и верните в строй :) И таких примеров в моей практике очень много.

[quote="Alex Tsitsura"]Я использую SObject, Object, Type[/quote]
Поддержка динамических запросов в SF реализована, не спорю.

[quote="Dmitry Shnyrev"]А зачем себе так усложнять жизнь? [/quote]
Усложнять? 0_o Так-то это как раз и упрошает жизнь разработчика.
[quote="Dmitry Shnyrev"]В реале все задачи решаются очень просто - достал из базы, показал, измени, проверил, сохранил. [/quote]
Ты считаешь, что все ограничивается CRUD операциями?
[quote="Dmitry Shnyrev"]Все это (как Generic Types) надо только для собеседований, поэтому наверное и выпилили.[/quote]
Наверно, ты просто ничего не использовал.
[quote="Dmitry Shnyrev"]1. был у нас на фирме один человек, который попытался ввести какие-то интерфейсы, наследования (и это еще основы) - код стал монструозным и тяжело поддерживаемым. Хорошо это все использовать если ты один программируешь. А если с тобой работает 10 человек, которые это не используют. В общем этого программиста "сожгли на костре" .[/quote]
Как ты живешь без ООП?
На счет поддерживаемости кода и количества разработчиков, ты совершенно не прав.
[quote="Dmitry Shnyrev"]2. как-то был на собеседовании у java разработчиков - выжали все соки по теории. Я эти вопросы запомнил и спрашивал у java программистов которые реально работают - ответ был "да фиг его знает, все равно это не используем" и это не мешает им получать солидные бабки [/quote]
Среди нас очень много быдлокодеров, не спорю.

Если у вас на фирме реально так все круто в плане использования различных паттернов проектирования, то я вам завидую.
Мой опыт работы в большой компании говорит мне одно - если код вылазит за пределы одного контроллера (я про Salesforce) то большая часть программистов просто закопается!!!
В одном солидном продукте, как-то допустили что один программист написал 3 или 4 класса зависимых наследуемых друг друга - это стало основной проблемой. Время на разобраться с этим функционалом и внести изменения увеличилось в разы и показало что большая часть "новых" программистов просто зарывалась. А еще помню один чудесный класс, который использовался в различных местах, так вот как только кто-то начинал его трогать - отваливалась большая часть всего старого.

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

Полностью согласен с тем что это все не просто так придумано, все эти Generic Types и Reflection API. Когда работаешь сам, можно и не такое придумать. Но когда это бизнес - проще сделать одну страницу и один контроллер с простой GRUD логикой и потом спокойно раздавать их "новичкам" не боясь что они что-то сломают в другом месте.

Чистая практика!

[quote="Gres"]Как ты живешь без ООП? [/quote]
Я вырос из, и остаюсь поклонником функционального программирования :) 

[quote="wilder"] написал для своего проекта класс который используется для реализации trigger dispatcher. Для фирмы в которой я сейчас работаю, расшарил немного другой вариант.[/quote]

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

[quote="wilder"]для реализации trigger dispatcher. [/quote]

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

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

как я понял вы сделали что-то вроде этого?

Именно так и сделал. Но ещё и по другой причине. В салесфорс не возможно контролировать порядок запуска триггеров. 

[quote="Dmitry Shnyrev"][quote="Gres"]Как ты живешь без ООП? [/quote]
Я вырос из, и остаюсь поклонником функционального программирования :)[/quote]

Очень не правильная позиция:)

Здесь про диспатчер

https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices

[quote="wilder"]В салесфорс не возможно контролировать порядок запуска триггеров.[/quote]
А вот это уже проблема архитектуры - зачем писать несколько триггеров, которые друг другу мешают - затрагивают одни и те же данные.

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

Или может есть какой жизненный пример, я бы с удовольствием послушал.

[quote="wilder"]Очень не правильная позиция:)[/quote]
может быть :)

[quote="wilder"]Здесь про диспатчер[/quote]

Спасибо,

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

[quote="Dmitry Shnyrev"]
А вот это уже проблема архитектуры - зачем писать несколько триггеров, которые друг другу мешают - затрагивают одни и те же данные.
[/quote]

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

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

О, чувствую к нам присоединился один из гуру Salesforce.
Добро пожаловать cidr8n, будет очень интересно обменяться знаниями.
:) 

[quote="cidr8n"]Всю эту информацию можно найти и на рутрекере, где выложен курс хитростей для разработчиков на апексе[/quote]
Вот это реально интересно, не думал что на рутрекере такой материал водится. Поищу.

[quote="Den Brown"]не подскажите навскидку какие еще СФ фреймворки, паттерны, т.н. бест практики нужно знать (или хотя бы знать о существовании) СФ программисту в первую очередь?[/quote]
Вот, например, https://github.com/financialforcedev/fflib-apex-common
https://github.com/SalesforceFoundation/Cumulus - не патеррны, но тоже стоит взглянуть.
А так, всем советую читать Фаулера!

[quote="cidr8n"]Всю эту информацию можно найти и на рутрекере, где выложен курс хитростей для разработчиков на апексе[/quote]
Можно пруф?

[quote="Gres"][quote="cidr8n"]Всю эту информацию можно найти и на рутрекере, где выложен курс хитростей для разработчиков на апексе[/quote]
Можно пруф?[/quote]

http://rutracker.org/forum/tracker.php?nm=force.com - первые ссылки

[quote="Gres"][quote="Den Brown"]не подскажите навскидку какие еще СФ фреймворки, паттерны, т.н. бест практики нужно знать (или хотя бы знать о существовании) СФ программисту в первую очередь?[/quote]
Вот, например, https://github.com/financialforcedev/fflib-apex-common[/quote]

Есть еще более простая статья с паттернами под форс: https://developer.salesforce.com/page/Apex_Design_Patterns

[quote="cidr8n"]Есть еще более простая статья с паттернами под форс: https://developer.salesforce.com/page/Apex_Design_Patterns[/quote]
Тут просто описание паттернов из ГОФа

[quote="Gres"][quote="cidr8n"]Есть еще более простая статья с паттернами под форс: https://developer.salesforce.com/page/Apex_Design_Patterns[/quote]
Тут просто описание паттернов из ГОФа[/quote]

Верно, отлично поможет в качестве вводной статьи для новичка, дабы он понял как классические паттерны ложатся на реалии Salesforce

[quote="cidr8n"]Верно, отлично поможет в качестве вводной статьи для новичка, дабы он понял как классические паттерны ложатся на реалии Salesforce[/quote]
Согласен.
Но ГОФ тоже must read!

[quote="cidr8n"]Верно, отлично поможет в качестве вводной статьи для новичка, дабы он понял как классические паттерны ложатся на реалии Salesforce[/quote]

Отлично, давно хотел увидеть как классические паттерны ООП выглядят и используются в СФ.


[quote="Gres"]Вот, например, https://github.com/financialforcedev/fflib-apex-common 
https://github.com/SalesforceFoundation/Cumulus - не патеррны, но тоже стоит взглянуть. [/quote]

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

[quote="Den Brown"]Вероятно это то, каким должен быть дизайин большого "здорового" проекта. В небольшим проектах нет глубины для разворачивания этих всех слоев. Но все большое начинается с малого. И иногда я думаю глядя на небольшой проект - если он будет развиваться, обрастать новыми и новыми компонентами - то придется много переписывать и переделывать...[/quote]
Для этого и придумана архитектура.
Нужно изначально писать гибкие приложекния.
Кто не в курсе всем советую прочитать про принцыпы S.O.L.I.D.

[quote="Den Brown"][quote="cidr8n"]Верно, отлично поможет в качестве вводной статьи для новичка, дабы он понял как классические паттерны ложатся на реалии Salesforce[/quote]

Отлично, давно хотел увидеть как классические паттерны ООП выглядят и используются в СФ.


[quote="Gres"]Вот, например, https://github.com/financialforcedev/fflib-apex-common 
https://github.com/SalesforceFoundation/Cumulus - не патеррны, но тоже стоит взглянуть. [/quote]

Вероятно это то, каким должен быть дизайин большого "здорового" проекта. В небольшим проектах нет глубины для разворачивания этих всех слоев. Но все большое начинается с малого. И иногда я думаю глядя на небольшой проект - если он будет развиваться, обрастать новыми и новыми компонентами - то придется много переписывать и переделывать...[/quote]

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

[quote="wilder"]
Не важен размер разработки, если принципы не правильные на каком-то этапе приходит ощущение что проще написать что-то с нуля а не развивать существующее решение.[/quote]

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