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

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Если syst & # 233; m разбит на 4 класса по 250 методов каждый, MPE будет 449 000.

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

Две вещи.

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

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

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

Answer 9

  

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

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

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

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

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

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

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

Answer 10

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

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

Answer 11

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

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

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