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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Две вещи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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