ОО Дизайн Вопрос

Question

Что вы делаете, когда замечаете, что в приложении много классов, но классы на самом деле не являются объектами, которые можно реализовать, а представляют собой группу общих функций?

Пример:

Class Point 
{ 
 calculatePoints(something) {} 
 calculatePointsAnotherWay(something) {} 
}

Answer 1

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

• принимает в качестве аргумента объект пользовательского типа,
• извлекает данные из этого объекта, а
• выдает результат, основанный на вычислениях этих извлеченных данных,

тогда эта функция является кандидатом на то, чтобы стать методом класса своего аргумента. Этот вид кодирования иногда является подсказкой, что программист, создавший исходный тип, или программист, написавший «внешнюю» функцию (или обе), все еще могут думать в императивном / процедурном стиле, а не в ОО-стиле.

Answer 2

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

Поместите их в отдельное пространство имен, если вы хотите сгруппировать их.

В C # или Java это, конечно, невозможно, поэтому я бы, вероятно, поместил их в отдельный статический класс.

Answer 3

Сделайте методы статическими и и класс тоже (если можете), переименуйте классы, если неправильно назвали (например, Point - очень плохое имя для этого класса), а затем переместите или перегруппируйте методы, если это уместно.

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

Answer 4

Звучит так, будто вы можете назвать класс PointUtilities и сделать функции статичными.

Answer 5

Поскольку вы назвали вопрос как ОО. Я думаю, вы хотите знать, как структурировать это как OO-код.

В настоящее время, как вы описываете, автор написал процедурный код, но просто использовал объектно-ориентированный язык.

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

Это больше, чем я мог бы вписать в ответ здесь. Я думаю, что книга или 10 для небольшого чтения должны привести вас на правильный путь.

Это может быть хорошим началом: http://www.amazon.com/Object-Oriented-Modeling-Design-James-Rumbaugh/dp/0136298419

Answer 6

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

Answer 7

Что ж, похоже, что обычным способом в фреймворках (например, java.lang.Math в Java API, System.Math в .NET Framework Class Library) является группировка этих методов в статический / финальный / запечатанный класс и создание методы statis / final / загерметизированные.

И да - это процедурный подход.

С другой стороны, если вы читаете тонны книг (шутка), возможно, вы могли бы сделать это более объектно-ориентированным ...

По моему мнению, я ничего не имею против этого мнения, где это уместно - может быть, легче наконец признать, что мир не является чисто объектно-ориентированным. :)

Answer 8

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

Затем я поищу методы, которые имеют более 5 параметров, и попытаюсь создать классы на основе параметров. Затем я сделал бы то, что я называю переходом из C в C ++: собрал воедино эти «параметрические» классы с методами, которые над ними работают, так что OO-стиль начал бы появляться.

Answer 9

Из того, что я прочитал, группировка связанных функций, по-видимому, является допустимым использованием класса в мире ООП.