Когда я должен использовать OO Perl?

Question

Я только учу Perl.

Когда рекомендуется использовать OO Perl вместо не OO Perl?

Моя тенденция состояла в том, чтобы всегда отдавать предпочтение ОО, если проект не является просто фрагментом кода из <10 строк. </p>

ТИА

Answer 1

От Дамиана Конвея :

10 критериев знания того, когда использовать объектно-ориентированный дизайн

---

1. Дизайн большой или может стать большим

2. Когда данные объединяются в очевидные структуры, особенно если в каждом агрегате много данных

   Например, IP-адрес не является подходящим кандидатом: существует только 4 байта информации, связанной с IP-адресом. Иммигрант, проходящий таможню, имеет много связанных с ним данных, таких как имя, страна происхождения, провоз багажа, пункт назначения и т. Д.

3. Когда типы данных образуют естественную иерархию, которая позволяет нам использовать наследование.

   Наследование является одной из самых мощных функций ОО, и возможность использовать его - флаг.

4. Когда операции с данными зависят от типа данных

   Обрезка GIF и JPG может выполняться по-разному, даже если они обе графики.

5. Когда, скорее всего, вам придется добавлять типы данных позже

   ОО дает вам возможность расширяться в будущем.

6. Когда взаимодействия между данными лучше всего показывают операторы

   Некоторые отношения лучше всего показывать с помощью операторов, которые могут быть перегружены.

7. Когда реализация компонентов может измениться, особенно в той же программе

8. Когда проект системы уже объектно-ориентирован

9. Когда огромное количество клиентов используют ваш код

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

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

    Например, графические изображения могут быть размытыми, обрезанными, повернутыми и отрегулированными.

11. Когда виды операций имеют стандартные имена (проверка, обработка и т. Д.)

    Объекты позволяют иметь DB::check, ISBN::check, Shape::check и т. Д. Без конфликтов между типами проверки.

Answer 2

Есть хорошая дискуссия на ту же тему @ PerlMonks .

Наличие Moose , безусловно, облегчает всегда использовать OO с самого начала. Единственное реальное исключение - если запуск компиляции является проблемой (у Moose в настоящее время есть накладные расходы времени компиляции).

Answer 3

Я не думаю, что вы должны измерять это строками кода.

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

Во всех случаях, когда вы используете OO Perl Rememebr для , используйте Moose (или Mouse)

Answer 4

Этот вопрос не имеет ничего общего с Perl. Вопрос в том, «когда, при наличии выбора, я должен использовать ОО?» Этот бит «предоставлен выбор» объясняется тем, что в некоторых языках (например, Java) у вас действительно нет выбора.

Ответ - «когда это имеет смысл». Подумайте о проблеме, которую вы пытаетесь решить. Вписывается ли проблема в ОО-концепции классов и объектов? Если это так, отлично, используйте OO. В противном случае используйте другую парадигму.

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

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

Answer 5

Дамиан Конвей содержит отрывок из Perl Best Practices об этом. Вы не должны следовать этому правилу, но, вероятно, это лучший совет, который я могу дать, не зная, что вы делаете.

Вот страница издателя , если это лучшее место для ссылки на книгу.