OO ABAP: когда и почему?

Question

Спустя месяцы после того, как моя компания обновилась с 4.6c до ECC6.0, наша команда программистов все еще занимается кодированием традиционным способом 4.7c. Мне не терпится опробовать новый ООП-подход ABAP, но, к моему большому разочарованию, большинство людей здесь делают упор только на том, чтобы добиться цели в кратчайшие сроки.

Мой вопрос будет:
1) Когда люди в вашей организации начали программировать в OO ABAP?
2) Есть ли существенная причина, по которой люди хотели бы закодировать это ОО-способом? например Метод вызова быстрее, чем оператор PERFORM?

Answer 1

1) Когда люди в вашей организации начали программировать в OO ABAP?

Большинство разработчиков в моей организации изучили классический ABAP до появления ABAP OO. В основном это старшие разработчики, которые воздерживаются от изучения принципов ООП и ООД. Они по-прежнему используют в основном процедурные функции ABAP. Кроме того, мы работаем в устаревшей среде. Основы нашего бэкэнда были построены во времена 4.6C. Трудно внедрить надлежащий OO Design в устаревшие системы.

С другой стороны, процедурные функции все еще работают. Некоторые функции, такие как транзакционные обновления базы данных, в основном используются из процедурной части ABAP. Возможно, вы знаете, обновить функциональные модули или подпрограммы исключительно для транзакций базы данных (те, которые вы можете назвать IN UPDATE TASK). Они являются неотъемлемой частью базовых компонентов ABAP. Нельзя отрицать, что процедурная часть ABAP по-прежнему необходима.

2) Есть ли существенная причина, по которой люди хотели бы закодировать это OO-способом? например Вызов метода быстрее, чем оператор PERFORM?

Как вы сравнили время выполнения CALL METHOD и PERFOM? Вы пробовали программу RSHOWTIM / Или вы провели некоторые тесты производительности из рабочей среды ABAP? Один вызов подпрограммы существенно не отличается от вызова метода. Однако при вызове в массовом тесте вызовы имеют немного лучшую производительность (по величине микросекунд).

В целом, я рекомендую OOD и OOP с теми же аргументами, что и пользователи, которые публиковали ранее. Но вы должны иметь в виду, что старшие разработчики, знакомые со старым миром ABAP, должны понимать принципы ОО, прежде чем они начнут писать ОО ABAP. В противном случае ваша организация не получит прибыль от ABAP OO, а наоборот. Есть много опытных разработчиков ABAP без знания ОО, которые были вынуждены писать классы. На самом деле они имитируют процедурные принципы с классами (например, класс со исключительно статическими методами - в качестве замены функциональных модулей / подпрограмм).

Удачи вашей организации в решении проблем с ABAP OO! Речь идет не о языке, а о том, как принципы OO должны быть в уме ваших сотрудников.

Answer 2

ОО или нет ОО это не вопрос !!

Вопрос в том, где ОО, а где НЕ ОО.

Все преимущества подхода OO (OOD и OOP) могут быть полностью использованы, пока вы находитесь в пространстве имен клиента. Однако каждый доступ к стандартной функциональности SAP создает огромные проблемы. Целостность транзакций, согласованность и синхронизация объектов, фиксации БД, экраны (пулы модулей и экраны выбора), проверки полномочий, пакетный ввод. Это лишь некоторые из объектов, которые сложно (или даже невозможно) интегрировать в ОО-подход. Интеграция стандартных модулей SAP перемещает это на еще более высокий уровень сложности.

Пользовательские выходы, События: Большая часть данных представлена ​​в интерфейсе. Доступ к специфическим для клиента данным или настройке может быть размещен в объектах.

Отчеты: большая часть данных будет прочитана стандартным FM. Специальная обработка данных может быть размещена в объектах. Может быть легко использован в других отчетах. Элементы управления SAPjoy могут быть обернуты объектной оболочкой для простого использования и повторного использования. Экраны не могут быть следами в объектах. : - (((

Базовая обработка: SAP не поддерживает замену обслуживания бизнес-объекта SAP или процессов SAP. Но если это случай пациента и готов к огромным усилиям. Давайте посмотрим ближе. Существует много технических проблем: синглтон-паттерн, оптимизация доступа к БД, блокировка, синхронизация и т. Д. Следует учитывать разделение технических и бизнес-функций. Объекты не очень подходят для массовой обработки (высокая нагрузка на БД), поэтому следует учитывать массовую обработку.

Answer 3

Некоторые веские причины для перехода на ABAP OO:

• ABAP OO более понятный и простой в использовании
• ABAP OO имеет более строгую проверку синтаксиса, которая устраняет много неоднозначности в языке ABAP
• Большая часть новых функций Netweaver доступна только при использовании OO

Добавьте это к преимуществам, перечисленным Taurean :

• Лучшая инкапсуляция данных
• Множественная инстанция
• Лучшая сборка мусора
• Повторное использование кода по наследству
• Управление бизнес-объектами через стандартные интерфейсы
• Событийно-управляемое программирование

Начало использования ABAP OO:

• Начните с вызова некоторых стандартных функций OO SAP в своем коде: используйте классы ALV, а не функциональные модули - классы предоставляют гораздо больше функций. Попробуйте вызвать некоторые стандартные методы в CL_ABAP* или CL_GUI_FRONTEND* классах
• Написать отчет в виде Singleton с использованием локальных классов
• Попробуйте создать простой класс в SE24 для чего-то знакомого вам (например, обработчик файлов)

Ресурсы:

1. Разработка шаблонов в объектно-ориентированном ABAP от Игоря Барбарика
2. Еще не используете объекты ABAP? Восемь причин, почему каждый разработчик ABAP должен взглянуть на это со второго раза Хорст Келлер и Герд Клюгер

Answer 4

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

Для этого есть множество причин:

• Требуется около года погружения в настоящую ОО-среду (smalltalk, не Java или C ++), чтобы получить что-то хорошее в разработке ОО.
• Они не могут начинаться с нуля, много унаследованного кода и нехватка времени.
• Весь их устаревший код не является ОО. Требуется значительное усилие для реструктуризации.
• Устаревший код плохо структурирован, содержит много дубликатов и не содержит модульных тестов. Изменение занимает слишком много времени, поэтому у них нет времени, чтобы все исправить. (Удивительно, что вы можете извлечь из проекта, ничего не зная об этом. :)).

Как следствие, их новый код, скорее всего, будет процедурным, но в классах и методах. Они не будут впечатлены преимуществами ОО.

Answer 5

Я не знаю об ABAP, но я видел то же самое, когда разработчики VB переходили на платформу .Net.

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

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

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

Answer 6

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

С точки зрения дизайна, нет никаких сомнений (как много людей говорили на этом форуме), что он лучший и используется с незапамятных времен. SAP сильно отстает с точки зрения технологий. Их дизайн ECC DB все еще в 2-NF. стандартная 3-NF - это то, что они называют «трехмерной» базой данных. Не слишком сильно отклоняясь от основной темы, я считаю, что теперь у вас слишком много хороших ответов для принятия решения.

Answer 7

Ниже приведены некоторые преимущества ООП, о которых вы должны знать:

• Инкапсуляция данных
• Инстанцирование
• Повторное использование кода
• Интерфейсы

Воспользовавшись этим, есть много важных причин для использования OO ABAP «по возможности». Даже если вы не хотите использовать ОО-программирование, использование объектов ABAP все еще является хорошей идеей, поскольку оно предоставляет некоторые функции, которых нет в процедурном программировании.

Итак, вот что ABAP Objects предлагает вам по процедурному ABAP:

• Лучшая инкапсуляция
• Поддержка нескольких экземпляров
• Лучшие методы для повторного использования кода
• Лучшие интерфейсы
• Явная концепция события

Существует только две цели, для которых процедурный ABAP признан необходимым:

• Инкапсуляция классических экранов в функциональные модули.
• Когда вы хотите сделать функции доступны для других систем, но не в состоянии сделать методы класса доступно извне с использованием XI-сервера прокси. В этом случае вы должны используйте функциональные модули.

Изучите их подробнее здесь и вы увидите, что вам не нужны какие-либо существенные операционные / демонстрационные причины, чтобы убедить себя перейти на OO ABAP, поскольку все эти причины уже очень важны.