Код Perl главным образом написан в объектно-ориентированном проектировании?

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

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

Рассмотрим эту структуру:

my $foo = {
    meezle => [qw( a d g e l z )],
    twill  => {
        prat => 'qua',
        nolk => 'roo',
    },
    chaw => 7,
    mubb => [ 123, 423,756, 432 ],
    ertet => 'geflet',
};

Когда я получаю такую ​​структуру (вложенную и неоднородную), я начинаю думать об «объекте». Я уверен, когда обнаруживаю, что пишу много кода для доступа, изменения и проверки данных в структуре.

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

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

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

OO-Design не «серебряная пуля». Нет никакого вреда в написании кода, который не является объектно-ориентированным. Это просто «популярный» выбор. Как кто-то однажды сказал (и я перефразирую):

OO-design simply had a better marketing group

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

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

Есть много вещей, которые не очень хорошо поддаются объектам.

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

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

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

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

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

Лучшим пособием для изучения OO Perl, которое я нашел, является : Object Oriented Perl: A Comprehensive Guide to Concepts and Programming Techniques by Damian Conway. Когда я начал изучать OO Perl, я столкнулся с тем, что существует так много различных способов сделать это. В конце концов я остановился на одном и придерживался его на протяжении многих лет.

Большинство кода на Perl, который я пишу, это небольшие скрипты, и я никогда не использую ООП для них, даже если они используют модули CPAN, которые разработаны на основе ООП. Для более крупных проектов я склоняюсь к ООП примерно в 70% случаев, но это зависит от того: будет ли код использоваться в течение длительного времени? Если есть вероятность, что он будет использоваться долго, и многие пользователи будут макать в него свои ложки, то ООП, вероятно, лучший дизайн.