Нахождение неявного общения в классах

Question

В настоящее время я занимаюсь рефакторингом очень полезного, но плохо спроектированного класса в C ++, и у меня возникает проблема с дизайном: вместо передачи данных с использованием аргументов к методам, данные передаются путем установки частных переменных состояния вучебный класс.Это делает мне очень трудным наметить, как данные перемещаются через функции.Моя задача на выходных состоит в том, чтобы как можно больше убрать этот стиль передачи данных, поскольку это делает программу совершенно невозможной для понимания только из сигнатур методов, поскольку сигнатуры рассказывают только часть истории.Я решил

Мой текущий подход к проверке того, взаимодействует ли метод с использованием частных переменных уровня класса:

1. Отредактируйте метод и сделайте его функцией, а не методом, который удаляет его доступ к переменным состояния в классе.
2. Отредактируйте все вызовы метода так, чтобы они вызывали функцию, а не метод.
3. Компиляция, посмотрите, не ломается ли что-нибудь,Составьте список методов доступа, которые нужно добавить в исходный класс.
4. Запустите модульные тесты, чтобы проверить, не нарушил ли я что-либо очень тонким способом.

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

Единственное упоминание об этой проблеме, которое я нашел до сих пор, это цитата из Coders at Work через Объектно-ориентированное программирование, запись в Википедии :

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

Редактировать в ответ на хороший вопрос от Оли Чарльзуорт :

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

Answer 1

С учетом разъяснения в вопросе мой комментарий: «Вы уверены, что не просто вам не нравится стиль другого программиста?То есть с 78 членами данных и множеством битов, которые связаны, но не принадлежат к своему классу, я бы начал с группировки связанных данных и извлечения функциональности, которая на них работает.ИМХО, нет необходимости проходить этап, когда вы явно передаете данные в функции в существующем классе.Просто выберите группу связанных элементов данных, найдите подходящее имя, извлеките их и определите, где они использовались и как вам нужно перенести функциональность в новый класс.

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

Answer 2

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

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