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

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

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

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

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

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

Ответ 1

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

Начните пытаться сделать (классы, которые станут) реальными объектами, которые представляют реальные вещи в вашем решении. (Здесь есть причудливое имя, но оно также очень простое.) Это НЕ делает классы утилит удобных, тематически связанных функций. Постарайтесь упорядочить так, чтобы данные, сохраненные в ваших объектах, сохраняли ваши параметры при вызове методов на этом объекте. Подумайте об объектах, которые будут существовать как реальные индивидуальные вещи в сообществе. Перенесите их. Расположите вещи так, чтобы вы не беспокоились о том, что происходит в классах, пока вы используете их функциональность.

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

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

Изменить в ответ на комментарий от опроса: Я думаю, что следующий шаг может состоять в том, чтобы сосредоточиться на отношениях между вашими классами. Например, если вы используете объект Customer в своей логике, вам придется потратить No Effort на соответствующий объект Order. Создайте свойство oCustomer.Orders, которое возвращает List<Order>. (Это пример С#). В этом свойстве получите все эти заказы клиентов, поместите их в объект списка, сохраните его в частной переменной, если свойство снова вызвано, и верните этот объект списка. Если вы уже это сделали, ищите следующую самую трудную новую вещь, чтобы попробовать. Возможно, вам нужно часто находить дату, когда клиент сначала сделал заказ. Затем создайте класс Orders, который наследует от Collection<order>, чтобы заменить ваш основной List<Order> и добавить свойство FirstOrder. Затем вы можете сделать var FirstOrderDate = oCustomer.Orders.FirstOrder.OrderDate.

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

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

В конце концов изучите patterns. Насколько я советую вам не превозносить их, они являются отличным источником идей и, самое главное, , чтобы попробовать. (Знание имен общих "шаблонов" также полезно для коммуникационных целей.) Например, когда вы видите модель концепция интерфейсов действительно будет иметь смысл.

Ответ 2

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

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

Короче говоря, для опыта не существует.

Для реального кода я бы начал смотреть на некоторые проекты, которые вас интересуют где-то вроде codeplex.

Здесь классический список шаблонов проектирования GOF.

Вот несколько примеров общих паттернов:

Ответ 3

Во-первых, я просто хотел бы рекомендовать использовать OOP вместо OOPS. ООП - это парадигма программирования, поэтому часть "Система" на самом деле не нужна (но, конечно, это только мнение). Кроме того, большинство людей легче распознают ООП, поэтому это сделает ваш вопрос более понятным. Наконец, поскольку OOPS делает объектно-ориентированное программирование похожим на ошибку (hehehe... извините, плохая шутка). Конечно, это только мое мнение, и я, конечно, ошибаюсь.

В любом случае, по делу. Я думаю, что у вас проблемы, потому что вы передумали в начале фазы планирования. Перестаньте думать о методах и атрибутах каждого объекта. Не думайте о том, как это может быть полезно или как вы собираетесь его использовать. Забудьте о компьютере и о том, как вы собираетесь его реализовать. Просто перечислите, какие объекты приходят на ум. Вы упомянули о создании приложения для базы данных. Вы можете начать с того, какие данные вы хотите сохранить. Например, если вы собираетесь создать базу данных студентов, вы, вероятно, захотите создать объект Student. Вам также понадобится способ подключения к базе данных, поэтому вы, вероятно, захотите, чтобы объект служил соединением с базой данных. Конечно, эти два объекта - только предложения; это зависит от вас, хотите ли вы их использовать.

После создания длинного списка объектов начните просмотр объектов, которые вы создали, и перечислите, что они делают. Просто потому, что объект ничего не делает, не означает, что вы должны удалить его из списка. Например, возьмите объект "Студент". Этот объект может состоять из геттеров и сеттеров, но он является моделью студента и поэтому чрезвычайно полезен в системе баз данных. Если вы знаете язык программирования C, вы можете думать о объекте "Студент" как о структуре. Как только вы закончите этот список, попробуйте объединить объекты, которые кажутся похожими. Отбрасывайте объекты, которые не имеют ничего общего, пассивно (например, хранение данных) или активно (например, подключение к базе данных или получение пользовательского ввода). У вас должны быть ваши объекты и большинство их атрибутов и методов. Все, что осталось сделать, это реализовать эти объекты и добавить дополнительные функции.

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

Ответ 4

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

Многие разработчики при поиске проблемы попытаются поместить его в стандартный шаблон проектирования, который при правильной настройке скорости разработки!

Я бы предложил прочитать на объектно-ориентированных шаблонах проектирования и как их можно применять. Хорошим примером этого является использование абстрактных классов или интерфейсов в шаблоне метода Factory.

Википедия (http://en.wikipedia.org/wiki/Factory_method_pattern)

Ответ 5

Сначала я бы рекомендовал эту классическую книгу по шаблонам дизайна. http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8& S = книги & QID = 1261679601 & ср = 8-1

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

Ответ 6

В тот момент, когда меня щелкали вещи, я читал "Квест Бек" "Испытательное развитие, пример". Вся первая часть книги - это шаг Бек, который шаг за шагом разрабатывает функциональность. Я нашел это очень полезным, потому что вы видите, что процесс происходит органично - начиная с очень немногих классов, которые меняются со временем. Я думаю, что начать с шаблонов не обязательно хорошая идея. Дизайн шаблонов велик, но я считаю, что их полезность становится очевидной только после того, как она сделала это неправильно в реальном проекте в первую очередь, и получила представление о том, что работает, а что нет в OO.