Хочу излить душу и поставить очередной памятник в честь KISS принципа проектирования.
Не заморачивайтесь вы по поводу этих всяких принципов проктирования, не усложняйте себе и другим жизнь.
Пишите код как можно проще. Все равно все эти принципы не спасут вас от костылей.
Да все на словах звучит красиво, определения из мира ООП ласкают слух. Но, мля, как только дело доходит до реализации - это пи...ц. На простейшие веши, подчеркиваю ПРОСТЕЙШИЕ, уходят тонны apex классов, apex методов и просто сугробы всяких абстракций. Получается что вместо того чтобы знать apex и программировать, я должен изучать "язык программирования" того человека который начал реализовывать решение. КАЖДАЯ сточка - сплошные вызовы каких-то сервисов, с передачей всяких DTO которые еще надо знать как правильно инициализировать. ЗАЧЕМ ВСЕ ЭТО? Все равно когда встает вопрос о повторном использовании этого кода приходится лезть в эти сервисы и писать костыли под новые требования.
В итоге простейшая реализация функционала на полчаса превращается в день разбора того что хотел сделать первый программист и что "накостыляли" другие программисты после него. Причем спорить о правильности или неправильности выбранного подхода НЕЛЬЗЯ потому что у каждого свое видение паттернов и все превращается в холивар.
ЛЮДИ, KISS.
На счет DRY - don’t repeat yourself. Тут именно ключевое слово yourself - себя. тут ничего не сказано про не повторяй другого человека. А почему? потому что это нереально. Если команда состоит более чем из одного человека - как можно не повторять другого? Вы умеете читать мысли других людей? Поэтому нафиг все эти DRY в больших проектах - есть кусок функционала - делаем его независимым, одиноким во вселенной. Твой функционал не должен знать что где-то в другом участке кода есть что-то аналогичное, потому что оно там может поменяться и тогда твоему коду придет пи...ц.
Знаешь, мне кажется, использование различных подходов к программированию похоже на воспитание, если тебя с детства приучили что-то делать, то ты так и будешь продолжать это делать, а если уж не научили, то только в редких случаях ты будешь делать это сам.
Хорошая архитектура спасает тебя при поддержке большого приложения - факт!
К тому же я в очередной раз столкнулся с ситуацией, когда у двух человек абсолютно разное видение шаблонов проектирования (ну опыт у них разный) и разработка просто превращается в "кто перетянет одеяло".
ЛЮДИ, KISS 
излил душу! Прямо полегчало
Я пишу код в Eclipse и тесты там прогоняю (ну, если один класс и надо протестить новый функционал). Так вот, если что-то где-то посмотреть, откуда вытягиваются данные, то ООП с его наследованиями и инкапсуляциями идет тут лесом.
Я один функционал как-то реализовал через ООП, а птм вылавливал "фичи". Это ж не Visual Studio для C# или Java проект в Eclipse. Так что ООП для Apex - это кошмар.
Повторяющийся код в одно место - да. Но я лучше почти продублирую два класса, кот будут отличаться 2-3 полями, но без Generics. Да, там подход одного инерфейса был. Был кошмар.
К паттернам нельзя приучить, их нельзя зазубрить, их нужно прочувствовать. И пока этого не произойдёт, организм будет отвергать их как вирус.
Кстати говоря, советую обратить внимание на это https://github.com/financialforcedev/fflib-apex-common + https://github.com/financialforcedev/fflib-apex-mocks (сори если повторяюсь, но вроде я на форуме не видел чтобы кто-то про это писал). В репах реализации UOW, обёртки над триггерами (triger handler) и казалось бы невозможные в Apex моки. Если следовать принципам, которые предлагают авторы совместно со статьями сала, то можно получить довольно независимую и прозрачную архитектуру Service, Domain, Selector. Есть примеры. Можем по обсуждать если заинтересовало. Особенно порадовал примитивный IOC контейнер :). С этим инструментом можно писать независимый код, который в паре с моками можно легко тестировать. DRY всем!
видео с DF: https://www.youtube.com/watch?v=qlq46AEAlLI
слайды к видео: https://docs.google.com/file/d/0B6brfGow3cD8RVVYc1dCX2s0S1E/edit
пример: https://github.com/financialforcedev/fflib-apex-common-samplecode
P.S. Эти реализации по тем статьям, что Дима писал у себя в блоге.
Зато потом эти 4 класса и 6 страниц переносятся в другой проект не меняя ни строчки и не добавляя тестов
Это и есть DRY
Все просто. Будет дальнейше расширенеи функционала - городи огород, нет - нет.
Тоже не хочется городить огород, если смысла в этом нет. "А вот, а вдруг надо будет". Надо будет, перепишем на огород. Когда понадобится.
А не надо на прежних. Новый огород, в который переносишь логику из "развалин" и все работает дальше.
За 4 года я такое делал всего два раза. Из-за одного случая в два года каждый раз городить огород - ну это же перебор. Вместо задачи на 4 часа, она выходит на 8-10, только из-за красивого огорода на будущее. А птм, через год вспоминай, зачем каждая грядка в этом огороде. Еще плюс 4 часа.
У каждого свои задачи.
Кстати, да.
Я вот как единственный, кто занимается СФ частью, знаю, где мне надо сделать компактно и быстро, а где с возможностью роста. Я знаю приложения, кот используют мой код и знаю, где потенциально пользователи могут попросить расширение. Я сам думаю о том, огород мне нужен или один горшочек.
Если есть отдельный Архитектор, то он общается с товарищами, которые задают тон приложению и они знают, где будет расширение в будущем.
Дима, зря ты эту тему поднял. =)
Я же говорю вирус)
В моем конкретном случае я делаю либо новый функционал, который связан с существующим, но никак не пересекается в плане кода; либо добавить поля, что как бы тоже не супер расширение функционала, трубующее огородов.
Кстати. Надо посмотреть те ссылки :-) А то вдруг там совсем не огороды, а я тут рассказываю :-)
Ну я исходники особо не смотрел UOW только немного смотрел, так как важен был порядок DML по логике, в итоге от него пришлось отказаться, хотя ничего не мешало дописать возможность конфигурирования кастомного порядка DML, на будущее пригодилось бы, да просто времени не было.
А что там криво сделано, не оптимально что-то?
Я как-то собеседовался в компанию, которая пилила свое продукт в AppExchange - мне предложили на $400 меньше, чем я просил - видимо, я не пригоден к тру энтэрпрайз. И от Теленора я ушел, ибо их махины меня не впечатлили с кучей прослоек и корпоративной культурой.
Неет, не пишите такой код никогда, поберегите коллег.
Каким образом я тут могу if..else обойти?
Не нужно решать такую проблему просто "разрезанием" метода на куски, нужно стараться находить те части, которые относятся к одной логической операции и которые могут в дальнейшем применяться в других местах, не зависимо от контекста. Меньше зависимостей - меньше проблем.
ну тут логично разделить на поиск и формирование + методы доступа к xml вынести, что бы можно потом использовать, в других местах. Вдруг завтра придут к тебе и скажут, "не, получать будем в JSON". И ты давай всё переписывать, а будь у тебя логическое разделение, ты бы подставил другую реализацию поиска, а код формирования прежний, оттестированный. Профит)
P.S. Ничего личного.
тема - огонь!)
развели тут земельное хозяйство
Как я вижу идеальную структуру:
например логика связанная с Payment:
- N страниц с контроллерами
- 1 PaymentService c кучей статических методов и набором DTO (классы обертки) там же.
- 1 тест класс
ВСЁ! Зачем больше.
Не знаю что это за подход, возможно он больше подходит под определение функцонального программирования.
Зато все в одном месте, программист варится с свой маленькой песочницы, ни от кого не зависит. И не надо держать 100500 вкладок в IDE и вспоминать где что и за что отвечает.
Если честно. За годы работы в ВРП, все проекты, что я видел были именно такими.
Был один новый проект, на котором один сеньер-помидор-девелопер ввел паттерны. Но помоему после полугода использования этих паттернов, он же и переписал все в человеческий вид, ибо даже он сам не смог их поддержать, поэтому что все его трудозатраты были безсмысленными. Он действительно нагородил кучу всего, и вроде бы да, можно сказать - еб@ть как у вас тут все красиво, с паттернами, а зачем это надо, если можно было запилить один класс, который бы делал все тоже самое, это заняло бы меньше времени, маштабировалось бы, тоже быстро? Ответ: ну потому, что это высший класс, это же паттерны...
Опять же, я не говорю, что не надо использовать паттерны и прочие ООП штуки, я говорю, что их надо использовать там, где это действительно нужно, а не потому что это круто.
И запомните самое главное - вы пишете код для людей!
Честно говоря у меня просто пригорело от темы, я даже пароль забыл.
Метод в 2к строчек (в 1к строчек) это ВСЕГДА ненормально.
Если кто-то считает, что я не прав желаю ему попасть на чей-то легаси код в таком стиле.
И, например, неделю на добавление какой-то серьезной фичи в "это".
'Manual Test' Driven Development (ссори, если накосячил с английским, гг)
Что еще за тесты ручками? Как там с регрессией?
А если полностью структуру запроса надо поменять?
Или, например, сделать всё не в один веб-запрос, а в 101? (частями ответы шлёт сервер, например).
Ну вообще добавление поля, которое ни на что не влияет это еще полдела, а если из-за этого поля появляется логика влияющия, внезапно, на всю остальную логику (в 2к строчках)?
Добавил флаг?
Я так и вспоминаю проект
if (cloneMode) { ... }
else if (copyMode) { ... }
else if (createMode) { ... }
и тд
и в каждом блоке 100500 строк
Народ вы не уловили всю соль моего послания.
можно и нужно использовать паттерны проектирования - это конечно полезно и делает код красиво.
Но используйте его тогда в своем проекте в сферическом вакууме.
Вынос паттернов проектирования на уровень продукта с которым работают несколько программистов и есть текучка кадров - это большая ответственность:
- уделите тогда время выработке нормальной документации,
- выделите время на обучение новых сотрудников вашим стандартам и проведение периодического обучения старых.
- найдите человека(ов), который будет следить за соблюдением стандартов.
Ваши заказчики готовы платить за это деньги? тогда да, почему бы и нет.
Возьмем к примеру наш любимый Salesforce:
если фирма берет на работу Salesforce разработчика, то фирма будет уверена, что он знает Salesforce - есть догма - документация, которой ты просто обязан следовать если ты salesforce разработчик.
Salesforce разработчик не обязан знать паттерны проектирования - этого нет в документации Salesforce. А если должен, то что должен знать? Я так понимаю вот это догма?
есть доки по Salesforce - следуйте этим докам и пишите код проще.Типичный пример из жизни
Кто за селекторы взамен чистых SOQL в Salesforce?
Есть селектор, который конструирует запрос и выбирает нужные данные из базы.
Супер! Все используют.
Беру и я использовать - мне не подходит дефолтная сортировка. Что я делаю? лезу в этот селектов и добавляю метод, которые мне возвращает то что мне нужно. И так делает каждый. Что в итоге получаем? Селектор с 100 методами. Причем что делает новый программист? Он не будет разбираться со всех этих 100 методах и набором необходимых параметров и искать то что ему подходит - он обязательно добавит свой (или сломает чужой если мозгов хватит). Что надо делать чтобы такого не произошло? Тратить КУЧУ времени на обучение, проверку кода и длинную железную линейку для пальцев.
И это всего лишь малый пример.
Поэтому все начинается красиво, а заканчивается плохо!!!!!!!!!!!!!!!
Тоже пример из жизни.
На проекте есть куча красивых абстракций, красивые DTO все разрабатывалось в рамках одной страницы, выносилось, раскладывалось по слоям. Я пишу уже логику на remoteAction и должен воссоздать тоже самое используя существующую мега оптимизированную логику в бэкенде. Что получается в итоге? Вся логика заточена под VF страницы и не работает под JSON сериализацию. Кастыли? Они родные, куда без них в ООП, ведь уже не DRY.
И что не говорите, на чистый apex (нормально оптимизированный) никто так не жаловался как на результаты внедрения принципов ООП.
Ты не про это случаем?
https://developer.salesforce.com/page/Apex_Design_Patterns
Saleforce-разработчик это прежде всего разработчик, а уже потом "salesforce-".
Я сам раньше не понимал плюсы паттернов (Gres подтвердит), но после 2х более-менее крупных проектов с такой лапшой я просто в отчаяние впадаю, когда вижу код, который вы описываете.
Часто замечаю, что такой код пишут люди "не в команде".
Знаешь, проблема правильного кода, как ты верно подметил, не в кода а в командах.
Знаешь, я сейчас попал в команду, проект, в котором все мега круто и очень по ООП, но мы тратим 30% времени только на то чтобы поддерживать это все в рабочем состоянии и не сломать. Это круто. Есть чему поучиться.
Но я хочу заметить из минусов:
- скорость разработки катастрофически низкая. Необходимо следить за тем что делает КАЖДЫЙ разработчик, чтобы быть в курсе последних изменений и знать как их использовать. Приходится ждать пока один выкатит кусок кода чтобы все потом начали его использовать и это тоже не 5-10 минут.
- все равно костыли про которые я упоминал выше, каждому надо своя вариация общего функционала.
- кода реально ДОХРЕНА. На простейший проект уже потрачено половина лимита в 3 000 000 символов.
Тут только команда в максимум 5-7 человек сможет нормально работать. Что собственно и происходит.
Я работал на других проектах, где людей есть или побывала куча и нет четкого центра, контроля. Это реально жесть. Если еще страницу + контроллер ( + возможно отдельно логика ) еще можно как-то разобрать и починить, допилить, то уже с пародиями на ООП просто ничего не реально сделать - проще заново написать.
Прелесть ООП в одном - можно посадить заказчика на "иглу" и разводить его на деньги.
В идеальном мире может все это ООП и работает, но в реально увы 
Просто я за простоту. Я за максимальное использование стандартных возможностей Apex.Ладно народ!!!! Неплохо пообщались!!! Каждый высказал свою точку зрения исходя из опыта.
Понятное дело что я тоже использую паттерны проектирования (просто может не всегда об этом догадываюсь 
)
Наверное выскажу общее мнение всех здесь отписавшихся:
писать код надо проще, и с паттернами или без паттернов это не имеет значение.
Кстати, на счет https://developer.salesforce.com/page/Apex_Design_Patterns#Facade - мой случай про класс на 2к строчек, над которым я сейчас работаю.
А вот https://developer.salesforce.com/page/Apex_Design_Patterns#Strategy - это ужас, если использовать его в Eclipse. Я столько намучался птм с моим кодом, который был сделан по канонам этого паттерна. Вот разберусь с MavensMate, тогда попробую еще раз.
Максимум, что я из ООП сейчас использую, это наследование :-) Делаю базовый DTO с минимальным набором полей и полный - с полным набором полей. Сервис возвращает базовый когда в запросе приходит определенный флаг, и полный, когда его нет.
for(PricingRequest__c pricingRequest : pricingRequests) {
for (PricingEquipmentModel model : Pricing.getEquipment(pricingRequest))
{
prvoList.add(Pricing.createPricingRequestOption(pricingRequest,model));
}
}
Ой какая жесть! Java попахивает.
Это Apex ошибку догодался какую получил?
Точно SOQL ! Я к тому это говорю что не правильное использование шаблонов хуже чем просто класс с набором методов.Кто это переписывать будет я не знаю там кода под 4K
Так может паттерны не ради паттернов делаются?
А ради удобства поддержки, расширяемости + если останется кому-то легаси
То что в примере просто криворукость какая-то, которая не учитывает особенности SF.
Полностью согласен с этим. Вот простой пример я для своего проекта написал триггер паттерн клас в котором 3 иннер класса для сбора статистики и обработки исключений. На работе мой начальник разбил этот класс аж на 4 класса. И что вы думаете это улучшило хоть что-то ?
