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

Question

Поскольку почти для всех существует модуль, и неоднократно говорят, что мы не должны изобретать велосипед, и, поскольку я не пишу модули для CPAN, мне не нужно использовать OO. Но мой вопрос в том, написан ли профессиональный код на Perl в основном в стиле OO?

Answer 1

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

Answer 2

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

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

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

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 месяцев, недавно пробудившись от глубокого 4 утра, спите, когда начальник босса вашего босса кричит на вас, чтобы исправить чертову программное обеспечение до того, как компания обанкротится.)

Answer 3

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

Answer 4

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

OO-design simply had a better marketing group

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

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

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

Answer 5

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

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

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

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

Лучшая справка для изучения OO Perl, которую я нашел, это: Объектно-ориентированный Perl: всеобъемлющее руководство по концепциям и методам программирования от Damian Conway. Когда я начал заниматься OO Perl, я столкнулся с тем, что существует множество разных способов сделать это. В конце концов я просто остановился на одном и придерживался его на протяжении многих лет.