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

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

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

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

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

Надежда, которая помогает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Две вещи.

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

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

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

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

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

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

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

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

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

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

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

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

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