ОО АБАП: когда и почему?



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



Мой вопрос будет:

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

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

462   7  

7 ответов:

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

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

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

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

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

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

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

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

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

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

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

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

Тому есть множество причин:

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

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

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

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

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

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

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

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

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

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

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

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

Существуют только две цели, для которых процедурный АБАП является существенным:

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

Изучите их подробно здесь и вы увидите, что вам не нужны никакие значительные операционные/демонстративные причины, чтобы убедить себя переехать в ОО АБАП, потому что все эти причины уже очень значительны.

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

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

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

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

Начинаем использовать ABAP OO:

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

Ресурсы:

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

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

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

Comments

    Ничего не найдено.