Private, Protected, Public or Internal

[axm2017]

D365

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

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

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

[Pandasama]

Цитата:

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

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

Цитата:

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

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

[DSPIC]

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

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

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

[axm2017]

Цитата:

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

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

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

[belugin]

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

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

[Logger]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

[Stitch_MS]

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

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

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

[belugin]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

[Stitch_MS]

Цитата:

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

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

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

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

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

[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

[sukhanchik]

Цитата:

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

D365

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

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

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

На самом деле не очень ясно - "а какая разница, если ты не вендор"?
Т.е. все эти красивые слова по сути нужны только Microsoft-у. Либо любой компании, от кода которой наследуются многие другие компании.
internal внутри одной модели использовать бессмысленно по определению
final требуется ставить на Extension-ах, но для своих методов смысла особого нет. Можно особо выпендриться и ставить final на parm-методах (исходя из условия, что они точно не будут наследоваться), но ... нужно ли?
Подход к использованию private / protected / private не меняется по сравнению со старыми версиями АХ, если работать в одной модели

Если работа производится с несколькими моделями - то тут вопрос - насколько нужно именно несколько моделей? И как часто их приходится поддерживать (часто - в плане обращений потребителей)

Если же вопрос ставится от имени Microsoft - то тут отдельный вопрос. Тут перед закрытием кода нужно API готовить и т.д.. В общем - отдельный разговор.

[DSPIC]

Мне кажется - тут дискуссия слегка ушла в сторону. То, для чего нужны нужны final\private всем в той или иной мере понятно, и почитать об этом можно в любом учебнике.

Проблема поднята немного другая:

Цитата:

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

Цитата:

В D365 чей-то недальновидный мозг решил проставлять Private по умолчанию

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

Цитата:

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

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

Закрыли код и понеслась фантазия: COC, ивенты, хукабл\не хукабл, рефлекшн в бизнесс-логике. Превратили систему в неуправляемую помойку... Точки расширения они делают регулярно. Деятели...

[mazzy]

Цитата:

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

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

Свергни тирана - получишь щастье?!

Неее. Это не так работает.
Программисты не заморачиваются там, где их не заморачивают типлиды.
Тимлиды и не думают там, где их не напрягают архитекторы и руководство.

А вот руководство как раз и не понимает кто платит за то, что делают их команды. Как не понимают то, какими свойствами должен обладать их продукт, чтобы за него платили.

Это ж не только private. Продавать только Azure версию, Seal классов, закрытые механизмы развертывания, сильно ограниченный доступ SQL...

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

Цитата:

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

То, для чего нужны нужны final\private всем в той или иной мере понятно, и почитать об этом можно в любом учебнике.

нееее. ни в каком учебние не раскрывается что делать пользователям ЗАКРЫТОГО фреймворка, когда вендор этого фреймворка использует эти модификаторы как полный невменько.

для классических аксапт и вопроса такого не возникало.
хотя и там были закрытые слои.


===============
добавлено:
и да!
полностью согласен, что вместо private почти всегда лучше использовать protected.
и полностью не согласен, что изменение модификатора по умолчанию хоть что-то изменит.
...хотя бы потому, что private-методы внутри Майкрософт не обязательно покрывать тестами.

[axm2017]

Цитата:

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

На самом деле не очень ясно - "а какая разница, если ты не вендор"?
Т.е. все эти красивые слова по сути нужны только Microsoft-у.

"За державу обидно"
А вот ни фига. Так же как ТБ написана кровью так и BPзачастую написаны после потери n часов и дней.

Не вижу принципиальной разницы между ребятами из MS и нами. У них просто как правило более масштабная промышленная разработка и соответственно некоторые мелкие вещи играют на массе бОльшую роль (тот же отказ от тестировщиков к примеру зато переход к авто тестам)

[mazzy]

Цитата:

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

Не вижу принципиальной разницы между ребятами из MS и нами.

у ребят из MS полный доступ к коду.

[sukhanchik]

Цитата:

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

"За державу обидно"
А вот ни фига. Так же как ТБ написана кровью так и BPзачастую написаны после потери n часов и дней.

Не вижу принципиальной разницы между ребятами из MS и нами.

Я конечно погорячился - прошу прощения.
Про BP я не говорил - речь шла именно про расширения. Т.е. в моем понимании правила использования private / public / protected методов с т.з. BP - не поменялись с прошлых версий АХ, если использовать их в одной модели. А слово internal в этом случае вообще не нужно.

А вот разница между ребятами из MS и прочими ребятами как раз-таки и есть в том, что при соблюдении правил BP с прошлых версий АХ - ребята из MS должны больше думать о точках расширений, нежели все остальные. Потому что количество людей, которые использует код ребят из MS, как закрытый к правке - гораздо больше, нежели количество людей, которые используют код других ребят, как закрытый к правке.

Грубо говоря - мне дали задачу, я написал класс, в котором 20 методов private и 10 методов public / protected. Если я обычный программист - я не думаю о последователях - ибо их нет, а расставлять точки расширения наобум - это бестолковая задача. А вот если я программист MS - я обязан дополнительно подумать об (условно) 5 точках расширения, которые я должен заложить в свой код.

Про "красивые слова" я имел в виду - что (если развивать мою мысль далее по поводу отсутствия последователей) раз моим кодом никто не будет пользоваться (именно, как готовым продуктом) - то вся красота будет сильно субъективна. Ну т.е. будут несколько человек - условно Вы, я, еще кто-то - кто будет соблюдать эту красоту просто "из любви к искусству". Но большинство будет подходить по принципу - "закодил, работает и забыл". А за всех не проверишь.

В общем - посмотрим. Наверное Вы правы - постепенно к осознанию необходимости "феншуйности" кода все придут.

[axm2017]

Цитата:

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

...

Грубо говоря - мне дали задачу, я написал класс, в котором 20 методов private и 10 методов public / protected. Если я обычный программист - я не думаю о последователях - ибо их нет, а расставлять точки расширения наобум - это бестолковая задача. А вот если я программист MS - я обязан подумать об (условно) 5 точках расширения, которые я должен заложить в свой код

Увы. Есть такое понятие как карма и поддержка.

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