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

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

В качестве примера возьмем десятизначный номер телефона в США. Вам трудно вспомнить десятизначное число в вашей голове, поэтому мы делаем то, что психологи называют «чанкингом». Это означает, что мы мысленно разбиваем числа на куски, которые мы можем лучше запомнить.

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

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

Answer 2

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

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

Таким образом, поскольку некоторая информация доступна через эти интерфейсы, некоторая информация должна быть скрыта и недоступна внутри объекта. Свойство, которое демонстрирует такая информация, называется скрытием информации, которое Парнас определил, утверждая, что модули должны быть спроектированы так, чтобы скрывать как сложные решения, так и решения, которые могут измениться.

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

Рассмотрим класс с двумя методами: метод a (), который является информацией, скрытой внутри класса, и метод b (), который является открытым и, таким образом, доступным напрямую другим классам.

Существует определенная вероятность того, что в будущем изменение метода a () потребует изменений методов в других классах. Также существует определенная вероятность того, что в будущем изменение метода b () потребует изменений методов в других классах. Однако вероятность того, что такие колебания будут происходить для метода a (), обычно будет ниже, чем для метода b (), просто потому, что от метода b () может зависеть больше классов.

Эта уменьшенная вероятность пульсации является ключевым преимуществом инкапсуляции.

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

Кроме того, рассмотрим язык, в котором есть только методы и нет классов, и, следовательно, нет средств скрытия информации друг от друга. Допустим, наша программа имеет 1000 методов. Что такое MPE этой программы?

Теория инкапсуляции говорит нам, что, учитывая систему из n открытых узлов, MPE этой системы равен n (n-1). Таким образом, MPE наших 1000 открытых методов составляет 999 000.

Теперь давайте разберем эту систему на два класса, каждый из которых имеет 500 методов. Поскольку у нас теперь есть классы, мы можем выбрать, чтобы некоторые методы были открытыми, а некоторые - частными. Это будет иметь место, если каждый метод фактически не зависит от любого другого метода (что маловероятно). Допустим, что 50 методов в каждом классе являются публичными. Каким будет ПДВ системы?

Теория инкапсуляции говорит нам, что это: n ((n / r) -1 + (r-1) p) где r - количество классов, а p - количество открытых методов на класс. Это дало бы нашей двухклассовой системе MPE 499 000. Таким образом, максимальная потенциальная стоимость изменения в этой двухклассовой системе уже значительно ниже, чем у неинкапсулированной системы.

Допустим, вы разбили свою систему на 3 класса, каждый из которых имеет 333 класса (ну, один будет иметь 334), и снова каждый с 50 открытыми методами. Что такое MPE? Используя приведенное выше уравнение снова, MPE будет примерно 482 000.

Если система будет разбита на 4 класса по 250 методов каждый, MPE будет составлять 449 000.

Если может показаться, что увеличение количества классов в нашей системе всегда будет уменьшать его MPE, но это не так. Теория инкапсуляции показывает, что число классов, на которые система должна быть разложена для минимизации MPE, равно: r = sqrt (n / p), которое для нашей системы на самом деле равно 4. Например, система с 6 классами будет иметь MPE 465 666

Answer 3

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

Answer 4

Я ни в коем случае не фанатик какой-либо парадигмы программирования, но какое-то время я работал в режиме OO.

Лично у меня было много "а-ха"! моменты, когда занятия напрямую помогли мне лучше понять сферу, в которой я работаю.

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

Короче говоря, инкапсуляция действительно делает меня счастливее. ;)

Надеюсь, это поможет.

Answer 5

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

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

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

Answer 6

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

Answer 7

Я предпочитаю классы, чтобы я мог разделить большую проблему на управляемые части, которые можно тестировать как отдельные единицы. ИМХО, повторное использование кода переоценено - я почти не видел, чтобы это происходило там, где я работаю. Для меня то, что я получаю больше всего от хорошего ОО, это хорошая тестируемость.

Другая крайность - использовать кучу глобальных переменных и заклинить всю логику в public static void main (или Page_Load в ASP.NET) и вызывать статические методы, которые вызывают другие статические методы и т. Д. (I закружилась голова в конце последнего предложения.)

Единственное, что сломало бы мое ОО-мышление, - это если бы я работал с чисто функциональным языком, о котором я, к сожалению, не думал со времен колледжа.

Answer 8

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

Я программировал в Visual Basic 3 в течение долгого времени, поэтому у меня был большой опыт функционального программирования, затем я пришел к VB5 и обнаружил, что объекты - это огромное облегчение, потому что я мог связать сущности реального мира с моим кодом, и это очень помогло.

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

Answer 9

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

Что касается удобства сопровождения, на мой взгляд, гораздо проще взглянуть на диаграмму классов UML и выяснить, как все устроено, чем смотреть на список функций.

Answer 10

Объективно, откуда вы знаете, что использование классов не является причиной приложение для начала большое?

Возьмите любую большую программу / приложение, которое не было написано на языке OO (например, C, COBOL, даже обычный SQL), и вы должны быть в состоянии убедиться, что размер кода напрямую не связан с языковой парадигмой. Для каждого числа хорошо спроектированных, высокоразвитых, многократно используемых, многократно используемых компонентов C # или Java также имеется равное количество хорошо спроектированных, высокоразвитых, многократно используемых DLL-библиотек C. И наоборот, одинаковое количество ужасного раздутого кода.

Дело в том, что хорошие программисты могут усовершенствовать свои системные решения независимо от языка / платформы.

Что касается ООП, то, по крайней мере, для меня, это сводит к столу «потенциал» - взгляд на мир программирования и ближе к нашему реальному миру. Мы все знаем, что наш мир и эта вселенная материи полны объектов, состоящих из меньших объектов . Продолжая увеличивать масштаб от галактических звездных систем вплоть до молекулы, атома и субатомных частиц, поистине удивительно, насколько сильно разная материя состоит из одних и тех же крошечных частиц, объединенных в различные структуры. Даже если взглянуть на нашу собственную биологию, иногда кажется ошеломляющим, что 60% наших тел на самом деле просто вода, если разбить ее до самого лучшего. Но взгляните на все различные системы и органы, сгорающие от химии, чтобы поддерживать нас в рабочем состоянии.

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

(Правильное) использование классов - это разбиение системы на ее лучшие. По возможности. Чтобы вы могли взглянуть на что-то в определенный момент времени и на определенный уровень абстракции и не быть перегружены целями и логикой, которые не имеют отношения к вашей нынешней проблемной области. Всякий раз, когда вы разрабатываете систему, думайте о своей собственной анатомии; подумайте, как вы бы создали человеческое тело. Всякий раз, когда вы разрабатываете систему, подумайте о создании новой компании ; Каковы основные подразделения, отделы, необходимые вам для управления бизнесом. Кто тип сотрудников, необходимых для управления этими отделами. Различное оборудование, которое им нужно использовать и взаимодействовать для выполнения своей работы. Как вы разбиваете бизнес-операции на самые лучшие, чтобы позволить себе лучше понять это?

Когда вы поймете основной принцип, согласно которому какой-то объект просто состоит из более мелких объектов, вы будете на пути к созданию многократно используемых клеток или молекул.