борется с объектно-ориентированным дизайном класса

Question

Я из научного прошлого, и мне трудно думать, что объектно-ориентированный.Я всегда думаю о функциях, а не об объектах.

Например, у меня есть набор данных, содержащий несколько 2D-массивов, и мне нравится извлекать области интереса из этих массивов.Так что мой первый дизайн был чем-то вроде класса RoIFinder, которому я передаю ссылку на объект Dataset.Объект RoIFinder сделал свое волшебство и возвратил RoI.

Но это вызывает у меня плохое предчувствие, поскольку он больше похож на функцию, чем на объект. Это больше похоже на Blackbox.Но я понятия не имею, как это делается правильно.

Как бы вы сделали что-то подобное?

Answer 1

ОО это не серебряная пуля.Выполняйте свою работу так, как это кажется правильным с разных точек зрения: декомпозиция проблемы, эффективность, простота кода, тестирование и т. Д.

Не заставляйте код выглядеть OO, если вы этого не делаетенужно.Целью ОО является упрощение жизни, когда проблема слишком сложна, а не решение сложных проблем сложным способом.

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

Answer 2

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

Вкратце, ОО - это объединение

• состояние
• поведение
• (личность).

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

Если у вас есть несколько различных критериев для выбора областей интересов из набора данных, вы можете реализовать их как отдельные *Finderклассы, реализующие общий базовый интерфейс.Там у вас есть иерархия классов ОО!С этого момента Искатели могут даже использоваться в вашем коде как взаимозаменяемые Стратегии .

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

Мы не знаем, что вы должны делать с данными в массивах - может быть некоторая возможность найти большетам есть абстракции и на них тоже строятся некоторые типы ОО и объекты.

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

Answer 3

Ваш 2D массив может быть реализован как матричный класс.Один объект Область интереса - это другой класс.

Получение области интереса из матрицы - это метод.

"Итераторы" в ваших матрицах - это классы.

Answer 4

То, что вы сделали, вероятно, лучше, чем очевидный ОО-подход - добавление find_roi() к самому классу набора данных.Зачем?Потому что, похоже, вы создали функциональность RoIFinder только на основе открытого API набора данных.Хранить набор данных проще и хорошо.В STL (в наши дни это просто часть стандартной библиотеки) есть примеры того, как алгоритмы, такие как sort, применимы к нескольким контейнерам, а не в каждом контейнере есть функция-член sort (хотя в случае с возможностями оптимизации списка приводятэто для реализации своей собственной версии).STL также зЬй :: строка, которая controvertially встраивает много функциональных возможности, которые могли бы быть вынесено - на моем взгляде, это хорошо разработан, prioritorising удобного и элегантное использование которых имеет важное значение в таком повсеместном классе, который так часто и сильно управляетсяна.Итак, выберите то, что подходит к ситуации.В любом случае, нет смысла помещать RoIFinder в класс, если он в равной степени может быть просто функцией, но если вы нашли какое-то состояние (например, элементы данных), которое удобно сохранить, или это помогает удобству использования другим способом, тоэто достаточно веская причина придерживаться своего объекта.