Как классы помогают вам управлять большими приложениями?

Question

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

Мне не очевидно, как они это делают.

Мой вопрос к вам, откуда вы знаете? Какие существуют объективные меры, которые показывают, что классы повышают производительность, повторное использование кода и снижают сложность производства программы? Какие аспекты занятий делают их идеальными для совместной работы больших групп?

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

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

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

Что вы думаете?

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

edit2: кажется, есть некоторая путаница в том, что я имею в виду под функциональным программированием. (Я не думаю, что какая-либо версия VB когда-либо была функциональной, конечно, не более старые версии). Пожалуйста, обратитесь к статье в Википедии. http://en.wikipedia.org/wiki/Functional_programming

edit3: и позвольте мне подчеркнуть, что я ищу объективные меры. Не субъективные мнения.

Answer 1

Две вещи.

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

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

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