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

Ответ 1

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

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

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

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

Рассмотрим класс с двумя методами: метод 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? Используя приведенное выше уравнение, MPE будет составлять примерно 482 000.

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

Я отнюдь не фанатик по отношению к какой-либо программной парадигме, но я некоторое время работал в стиле OO.

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

Две вещи.

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

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

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

Ответ 9

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

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

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

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

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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