Private, Protected, Public or Internal

[axm2017]

D365

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

Не могли бы помочь сформулировать все «за» и «против» реализации инкапсуляции и особенности D365FO, которые надо учитывать при использовании модификаторов доступа. В идеале с примерами.

В общем хочется BP
ps и понять конечно где правильно писать final

[Pandasama]

Цитата:

этот модификатор

какой этот? Private, Protected, Public или Internal?

Цитата:

где правильно писать final

я бы сказал, что final зло и писать его не надо нигде - но в некоторых случаях D365 вроде бы требует

[axm2017]

Цитата:

Сообщение от Pandasama

я бы сказал, что final зло и писать его не надо нигде ..

Это вы еще с internal плотно не работали. Отрыжка капитализма имхо в чистом виде не дающая использовать объект для своих нужд но при этом видимая.

[DSPIC]

Из наболевшего, скажу про Private:
1. В D365 чей-то недальновидный мозг решил проставлять Private по умолчанию. В результате чего сотни стандартных классов отправляется на помойку: наследовать смысла нет - код закрыт. Пишется такая же сотня-копия классов с парой-другой строками своих методов. Клиенты платят кучу денег, партнеры занимаются копипастом и наклеиванием соплей в код. Ну и обновления, выпускаемые MS, сооветсвенно остаются за бортом, т.к. классы-копии никто не актуализирует в ногу с обновлениями, если это явно не всплывёт

2. Я бы Private вообще исключил из любого языка программирования и уже точно из AX: Ну не возможно заранее предсказать, что твой метод не нужно будет переопределять.

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

[Logger]

Цитата:

Сообщение от DSPIC

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

private по дефолту начался в 2012-й.
Во всех версиях до нее ничего не ставилось, что эквивалентно public.
Вы пришли к тому с чего все началось.

[belugin]

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

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

[Logger]

Цитата:

Сообщение от belugin

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

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

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

[belugin]

Цитата:

Сообщение от Logger

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

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

Цитата:

На них просто забили и поэтому все они дружно совершают смертный грех - "copy paste". Т.е. итог оказался еще хуже.

Есть некоторое концептуальное противоречие между DRY и независимостью и стабильностью расширений.

[mazzy]

Цитата:

Сообщение от belugin

Мы регулярно их делаем.

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

[belugin]

Цитата:

Сообщение от mazzy

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

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

[Logger]

Цитата:

Сообщение от belugin

Они могут себе попросить точку расширения, которой им не хватает.

Не могут. Вернее могут, но это слишком дорого и трудозатратно. Т.е. по факту не могут. И на практике ищут обходные пути. Об этом многократно говорилось.
Пожалуй я соглашусь с Евгением (DSPIC), что если по умолчанию ставить везде protected вместо private, то всем будет намного легче.

[fed]

Цитата:

Сообщение от belugin

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

Могу поделиться опытом: Запросили точку расширения 19 мая. Получили ее в версии 10.0.21, которая в сентябре попала в general availability. Поскольку фича была непринципиальна - мы могли позволить себе подождать.
Но в целом соглашусь с другими ораторами: Запрос точки расширения могут себе позволить только ISV. В проектных условиях - cut and paste - наше все...

[Stitch_MS]

А мне нравится теперешняя поддержка Майкрософт.

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

К сожалению, клиент не хочет ждать полгода-год, и всякий раз приходится изобретать. Например, использовать reflection, если нужно вызвать private метод, а однажды даже написать event handler к навигационному методу на таблице (это которого не видно в aot, но он там всё-таки есть после активации определенного свойства на table relation-е), потому-что по-другому ну никак.

[belugin]

Цитата:

Сообщение от Stitch_MS

Например, использовать reflection, если нужно вызвать private метод

А как в итоге вы это в дальнейшем поддерживаете? Пишите тест что оно не отвалилось? Ведете список таких мест и руками проверяете?

[Stitch_MS]

Цитата:

Сообщение от belugin

А как в итоге вы это в дальнейшем поддерживаете? Пишите тест что оно не отвалилось? Ведете список таких мест и руками проверяете?

По возможности пишу юнит-тесты, или ставлю какой-нибудь if, чтобы костыль перестал работать, если стандартый код отработает как надо.

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

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

[Logger]

Цитата:

Сообщение от Stitch_MS

а однажды даже написать event handler к навигационному методу на таблице (это которого не видно в aot, но он там всё-таки есть после активации определенного свойства на table relation-е), потому-что по-другому ну никак.

Как интересно! А вы не могли бы описать подробнее ?

[Stitch_MS]

Цитата:

Сообщение от Logger

Как интересно! А вы не могли бы описать подробнее ?

Нужно было использовать запись ERFormatMappingTable, но не ту, что ER модуль предлагает. Детали не спрашивайте, у меня у самого вопросы к консультанту, но задачу нужно было решить. Поскольку модуль закрыт, пришлось прицепиться к навигационному методу solution, чтобы подставить нужную запись ERFormatMappingTable, из которой уже в стандартном коде будет найдена соответствующая ERSolutionTable через ERFormatMappingTable.solution().

[ExtensionOf(tableStr(ERFormatMappingTable))]
final class ERFormatMappingTableNNN_Extension
{
    [PreHandlerFor(tableStr(ERFormatMappingTable), tableMethodStr(ERFormatMappingTable, solution))]
    public static void ERFormatMappingTable_Pre_solution(XppPrePostArgs args)
    {
        NNNEuSalesListReportingEngineContext context = NNNEuSalesListReportingEngineContext::current();

        if (context != null && context.generatingReport && context.reportFormatMappingId != 0)
        {
            ERFormatMappingTable erFormatMappingTable = ERFormatMappingTable::find(context.reportFormatMappingId);

            ERFormatMappingTable callerERFormatMappingTable = args.getThis() as ERFormatMappingTable;

            callerERFormatMappingTable.data(erFormatMappingTable);
        }
    }

}

[belugin]

Цитата:

Сообщение от Stitch_MS

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

Мне тогда трудно использовать эту информацию. Хотелось бы знать, зачем, чего не хватило в стандартном функционале.

P.S. Вот тут "as XXX" лучше убрать имхо. Если что-то не так, то лучше получить invalidcastexception и знать в чем именно дело, чем nullreferenceexception и гадать то ли пришел null то ли не тот тип.

            ERFormatMappingTable callerERFormatMappingTable = args.getThis() as ERFormatMappingTable;

            callerERFormatMappingTable.data(erFormatMappingTable);

Да и короче будет

[mazzy]

Цитата:

Сообщение от axm2017

ps и понять конечно где правильно писать final

final изначально пришел из Java.
в Java все методы были виртуальными по умолчанию.
это значит, что их надо вызывать через таблицу виртуальных методов.

в то далекое время руководство Sun Microsystems болело идеей "Джаву в каждый утюг" (примерно как сейчас руководство Майкрософт болеет идееей "Всё в облака"). Поэтому вопрос вызова джава кода из всяких девайсов, С, С++, ASM казался очень-очень актуальным.

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

потом, когда болезнь стала менее актуальной, final стали применять к классам. а потом и к пропертям класса, а потом и к переменным метода. Теперь модификатор final в Джаве трактуется как const.

то, что final запрещает наследовать, на практике стали использовать гораздо позже, когда в джаве появились enum.

=============
классическая аксапта до CIL использует очень древнуюю виртуальную машину Java. Final там никаким боком. Поэтому использовали его достаточно хаотически. Насколько я понимаю, единственное его оправданное применение - это классы, которые реализованы в ядре. Типа TextBuffer. Но и то не уверен.

final в x++ не дает заметных преимуществ в скорости работы.
проверено

=============
лично я оставляю модфикатор final в коде X++ во взаимосвязанных классах.
когда изменение в одном неизбежно должно повлечь изменение в другом.
причем появление final обильно комментирую.

как правило, это код, который работает с внешними dll, .net или com.

final конечно же не помешает моим коллегам поменять класс или отнаследоваться.
он просто повышает вероятность, что натолкнувшись на ошибки компиляции и матюкнувшись на криворукого автора, коллеги таки прочтут комментарий.
на проектах никаких других гарантий final в X++ не дает

=============
также модификаторы final/private часто использую при рефакторинге в своих иерархий классов. типа наваял 3-5-10 дочерних классов, потом подумал (как обычно) и изменил методы внутре. если при этом нужно удалить какой-то базовый метод, то очень даже удобно сначала пометить его как final или private и сделать инкрементную компиляцию - компилятор выдает ошибки в дочерних методах, которые надо изменить.

=============

Цитата:

Сообщение от DSPIC

2. Я бы Private вообще исключил из любого языка программирования и уже точно из AX: Ну не возможно заранее предсказать, что твой метод не нужно будет переопределять.

ну... исключать наверное не стоит.

но то, что вендор оставляет private/final, говорит лишь о том, что вендор ни фига не понимает какой продукт и для кого он делает.

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

https://coub.com/view/itbtz

[Logger]

Цитата:

Сообщение от mazzy

классическая аксапта до CIL использует очень древнуюю виртуальную машину Java

Что, правда ? Мне казалось что Дамгаарды просто посмотрели на Java 1.0 и сделали по мотивам, но все сами. Как же оно было на самом деле?