Цитата:
Сообщение от
cerbo
Главное в ООП это инкапсуляция
А как же полиморфизм с наследованием - они второстепенны?
Цитата:
Сообщение от
cerbo
которая нужна прежде всего человеку, а не компилятору. А такое поведение (паблик поумолчанию) подстрекает к ее нарушению.
Еще можно утверждать, что наличие класса Object подстрекает к нарушению строгой типизации при использовании ссылочных типов. Просто надо думать, что делаешь, никто же не мешает указывать модификаторы protected/private для методов классов и private - для тех же методов форм и таблиц.
Цитата:
Сообщение от
cerbo
это как раз таки баг из-за непонимания разработчиков что они делают
Баг - это в моем понимании поведение объекта/системы, отличное от декларируемого при соблюдении "правил пользования" объектом/системой (т.е. своего рода "нарушение контракта"). В данном случае если и можно вести речь о багах, то лишь по вине разработчиков приложения Аксапты, не учитываютщих особенности языка, заложенных разработчиками ядра Аксапты.
Цитата:
Сообщение от
cerbo
Ты хоть сам понимаешь какую ахинею несешь!!!
Полегче на поворотах
Цитата:
Сообщение от
cerbo
То что "есть один АОТ" (иными словами одна большая помойка), как раз и есть главная болезнь ахапты.
Одна база с несколькими тысячами таблиц, одно приложение и, соотв., один AOT в случае Аксапты - это то, что отличает ERP-системы от набора разрозненных систем, используемых для автоматизации отдельных участков учета. У такого подхода, конечно, есть и свои минусы, но, как говорится, за все надо платить.
Цитата:
Сообщение от
cerbo
Вести поддержку в таких условиях очень сложно, потому как нет уверености что мои правки не поламали что-нибудь о чем я понятия не имею. Приходится очень долго и нудно проверять, а потом еще и долго боятся "а не забыл ли чего".
Если предполагается изменение в тех местах системы, которые очень широко используются, то, разумеется, приходится долго и нудно проверять, что при этом может "сломаться"; очень сильно такие проверки облегчаются за счет перекрестных ссылок. Но, опять же, возможность изменением одного места в системе повлиять на работу кучи других участков системы дает просто огромные преимущества, и если они не компенсируют указанные "трудности поддержки", то не рискуйте - пишите свои доработки "сбоку". И в любом случае, написание нормального кода, без "зашитых" ограничений и необоснованных предположений, с соблюдением Best Practices, во многом обеспечивает уверенность в том, что ваш код не "сломается" из-за чиьх-то правок в совершенно неожиданных местах системы.
Цитата:
Сообщение от
cerbo
Всего лишь один прайвед в нужном месте может уберечь время и нервы разработчика.
Ну если дело лишь в модификаторах доступа, то все в ваших руках: указывая те или иные модификаторы доступа к тем же методам класса, вы задаете для пользователей (т.е. тех, кто будет использовать класс) протокол взаимодействия с вашим классом. Если вы считаете, что в рамках этого протокола пользователи могут в произвольный момент времени вызывать тот или иной метод, оставляйте его общедоступным (public), в противном случае - это ваша, а не компилятора или разработчиков языка, прямая обязанность ограничить доступ к тому или иному методу класса за счет модификаторов protected/private. Аналогично, в Х++ в любом классе-наследнике может быть перекрыт любой не статический protected/public-метод родительского класса, если в родительском классе это явно не запрещено, т.е. фактически все методы являются виртуальными, в то время как в других языках (тех же C++/C#) нужно явно объявлять методы как виртуальные, иначе в производных классах их перекрыть нельзя. Ну и что теперь? Это тоже "баг" в Х++?..