Множество ответов здесь - это ответы об обучении ООП программистам Perl, которые его не используют, но ваш вопрос звучит так, как будто вы зашли в тупик из-за того, как преподавать курс по качеству кода, в свете того факта, что ваш Программисты Perl не используют ООП, в особенности то, что вы хотите научить ООП не-ОО программистам и принуждать их к этой парадигме.
Это оставляет нам две другие парадигмы программирования, которые Perl поддерживает достаточно хорошо:
- Старомодный Структурированный Программирование также Модульный Программирование
- Поддержка функционального программирования в Perl (также Perl высшего порядка )
Я использую оба из них - в сочетании с здоровой дозой объектов, а также. Итак, я использую объекты по той же причине, что и хорошую структуру, а также модули и функциональные конвейеры. Использование инструмента, который вносит порядок и здравомыслие в процесс программирования. Например, объектно-ориентированное программирование является основной формой полиморфизма, но ООП - это , а не сам полиморфизм. Таким образом, если вы пишете идиомы, которые помогают в полиморфизме, они помогают в полиморфизме, им не нужно зацикливаться на каком-то специальном библиотечном «классе» и называть его UtilClass->meta_operator( $object ), который имеет маленький сам полиморфизм. ,
Moose - это отличный объектный язык, но вы не вызываете Moose->has( attribute => is => 'rw', isa => 'object' ). Вы звоните оператору has. power из Moose заключается в библиотеке объектов , которые инкапсулируют мета-операции над классами, но также и в простых выразительных операторах, которые допускает довольно открытый синтаксис Perl. Я бы назвал это оценкой решения проблем, которые ООП решает с объектами.
Кроме того, я думаю, у меня есть проблема с вашей проблемой, потому что "не ООП" - это большое поле. Он может варьироваться от кодирования «все в главном» до не строго -OOP (где процесс программирования - это не просто анализ ООП). Поэтому я думаю, что вы должны знать свою аудиторию и знать, что они используют, чтобы сохранить этот код структурированным и разумным. Я не могу представить себе современную аудиторию Perl, которая по крайней мере не является объектом - пользователей .
Оттуда Perl Best Practices (часто сокращенно PBP) может помочь вам. Но так же, узнав, что
- просто потому, что ООП является одной из лучших опор для полиморфизма, но не является полиморфизмом сам по себе
- просто потому, что ООП - одна из лучших опор для инкапсуляции, она сама по себе не является инкапсуляцией.
- Что ООП помогло структурированное и модульное программирование - и это не само по себе. Часть его силы - просто просто этих дисциплин.
Кроме того, как бы я ни был автором и потребителем объекта, ООП - не , как я думаю. Возможность повторного использования - вот способ, которым я думаю: что я сделал раньше, что я не хочу писать снова? Что я написал, что похоже? Как я могу сделать свою текущую задачу просто адаптером из того, что было написано ранее. (И часто: как я могу прокрутить ветку своего поведения установленным модулем в одну строку?)
В результате ряд моих конструкций провалится пешеходная цель ООП.Чтобы вам было удобнее: я делю код на два «домена»: очень абстрактный и полиморфный код Library и Scripting , которые мне нужно сделать, чтобы получить конкретный функция, которая мне нужна в текущем проекте.(это по сути то, что означает «приложение», но я не думаю, что это было бы так ясно).В результате полиморфизм в основном способствует обеспечению адаптивности , но сама адаптация - это то, что занимает меньше всего строк кода.Моя оптимальная система - это библиотека, которая позволяет создавать сценарии / адаптировать в любой момент между поведением библиотеки и набором конфигураций или сценариев, которые решают конкретную проблему.Опять же, если бы у меня были мои детекторы, конфигурация была бы введена из скриптового домена, и ни один библиотечный код сам по себе не сказал бы «Мне нужен файл свойств», если только это не был библиотечный модуль, инкапсулирующий алгоритм конфигурации, созданный в файлах свойств.Он просто знал бы, что ему нужны «политики» (или решения из области приложения), чтобы выполнить свою функцию.
Таким образом, мое идеальное приложение содержит «объекты» специального назначения, которые соответствуют «ролям», но где классы бесполезны, за исключением того, что классы выполняют поведение, допускающее инъекцию данных иповедение.Таким образом, некоторые из моих «объектов» Perl нарушают анализ ООП, потому что они представляют собой просто инкапсуляцию одноразовых решений, наподобие push-pin (expando) объектов JavaScript.
Я часто (позже) пересматриваю объект специального назначения и толкаю его дальше в область библиотеки, когда обнаруживаю, что мне нужно снова написать что-то подобное.Все объекты в домене библиотеки находятся на некотором уровне спектра указанного поведения.Кроме того, я организую «сети передачи данных», где есть класс Sourced, который просто инкапсулирует поведение доступа к данным либо в самом объекте, либо в другом исходном объекте.Это помогает ускорить мои решения безмерно , но я никогда не видел его адресованным ни в одном учебнике по ООП "утка-кошка-собака-машина-грузовик".Также шаблонирование - особенно в сочетании с «сетями передачи данных» - чрезвычайно полезно в решениях по кодированию в полдюжины строк или полдня работы.
Так что я думаю, что 'Говоря, в той степени, в которой вы знаете только ООП для структурирования программирования, вы не сможете оценить, что некоторые старые, здоровые практики или другие парадигмы делают для вас - или как вещи, которые квалифицируются какООП может способствовать посредственной адаптивности.(Кроме того, компоненты намного более актуальны, чем «объекты».) Инкапсуляция решает многие проблемы, но также способствует отсутствию данных там, где они вам нужны.Идея состоит в том, чтобы получить данные там, где они вам нужны, чтобы ваше постоянное поведение могло осознать специфику проблемы и воздействовать на нее.
- Перечитайте кое-что о структурном программировании
- Прочитайте кое-что о функциональном программировании (при условии, что вы еще не знакомы с ним.)
Такжевозможно, что даже устоявшаяся, «продуктивная» команда Perl пишет ... хрень .Если они не ООП-программисты, потому что они просто пишут дерьмовый код, то непременно научите их ООП, и если им не хватает даже структурированного программирования *, то пихают их обоих в горло * (мне трудно подуматьярлык "профессиональный", здесь).