Модуль против объектно-ориентированного программирования в VBA

Question

Моим первым «серьезным» языком была Java, поэтому я понял объектно-ориентированное программирование в том смысле, что элементарный кирпич программы - это класс.Сейчас я пишу на VBA и Python.Есть языки модулей, и я испытываю постоянный дискомфорт: я не знаю, как мне разложить программу на модули / классы.

Я понимаю, что один модуль соответствует одной области знаний, один модуль должен иметь возможностьпроверить отдельно ... Должен ли я воспринимать модуль только как пространство имен (c ++)?

Answer 1

Это вопрос вкуса. Если вы используете модули, ваша «программа» будет более процедурной. Если вы выберете классы, он будет более или менее ориентирован на объект. Я работаю с Excel в течение нескольких месяцев, и лично я выбираю классы, когда могу, потому что мне удобнее. Если вы перестанете думать о objects и будете думать о них как Components, вы можете использовать их с элегантностью. Основная причина, по которой я предпочитаю занятия, состоит в том, что у вас может быть больше, чем один. Вы не можете иметь два экземпляра модуля. Это позволяет мне использовать инкапсуляцию и лучшее повторное использование кода.

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

Answer 2

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

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

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

Answer 3

VBA также позволяет использовать классы. К сожалению, эти классы не поддерживают все возможности полнофункционального объектно-ориентированного языка. Особенно наследование не поддерживается.

Но вы можете работать с интерфейсами, по крайней мере, до определенной степени.

Я использовал только такие модули, как «один модуль = один синглтон». Мои модули содержат «статические» или даже методы без сохранения состояния. Поэтому, на мой взгляд, модуль VBa не является пространством имен. Чаще всего группа классов и модулей образует «пространство имен». Я часто создаю новый проект (DLL, DVB или что-то подобное) для такого «пространства имен».

Answer 4

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

1. "C" - это все о процедурном разложении.
2. Основная идиома в Java о декомпозиции класса или объекта.Функции не отсутствуют, но они становятся частью показанного поведения этих классов.
3. «Python» обеспечивает поддержку как декомпозиции проблем на основе классов, так и процедурной.

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

Если вы знакомы с ОО, вы должны очень хорошо использовать его в Python.