Определение ООП для нового программиста

Ответ 1

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

Самый простой набор словарей для ООП - это класс, метод и параметр.

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

Метод просто ссылается на функцию, заключенную в класс.

Параметр - это переменная, которая передается в функцию, которая указывает ему, как действовать или передает информацию для обработки.

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

DRY означает "Не повторяй себя", и это означает именно это. Если вы напишете какой-то код, вам больше не придется повторять этот конкретный код. В практическом плане это означает более абстрактное мышление и планирование с самого начала. Я приведу пример в ближайшее время.

KISS означает Keep It Simple, Stupid и означает, что вы должны попытаться написать код, который выполнит свою задачу самым простым способом. Упрощение означает меньше возможностей для ошибок и упрощения обслуживания. В контексте ООП это обычно означает, что каждый метод или функция имеет только одну задачу. Если вы обнаружите, что метод выполняет несколько операций, это обычно означает, что его можно реорганизовать на несколько более мелких методов, каждый из которых посвящен конкретной задаче.

Теперь для простого примера (кто-то может придумать лучший, но пойдите со мной на нем сейчас):

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

Для автомобилей нам нужно будет записать следующую информацию:

• Цвет
• Размер двигателя
• Тип передачи
• Количество дверей

Для грузовиков нам нужно:

• Цвет
• Размер двигателя
• Тип передачи
• Размер кабины
• Грузоподъемность

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

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

• Цвет
• Объем двигателя
• Тип передачи

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

Затем мы создадим еще два класса: грузовик и автомобиль, оба из которых унаследуют все методы класса транспортного средства и расширят его с помощью уникальных для них методов.

Класс автомобиля будет иметь метод под названием numberOfDoors, а класс грузовика будет иметь методы cabSize и towingCapacity.

Хорошо, давайте предположим, что у нас есть рабочий пример как для процедурного, так и для программирования OO. Теперь давайте рассмотрим несколько сценариев.

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

• Цвет
• Размер двигателя
• Тип передачи
• Количество пассажиров

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

ООП: Мы просто расширяем класс автомобиля классом шины и добавляем метод numberOfPassengers.

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

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

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

Сценарий 3. Мы хотим перейти от универсального автомобиля к конкретным маркам, например: Nissan и Mazda.

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

OOP: Мы расширяем класс автомобиля классом nissan и классом mazda и добавляем методы для каждого набора уникальной информации для этого автомобиля.

Сценарий 4. Мы обнаружили ошибку в области типа передачи нашей формы и должны ее исправить.

Процедурный: мы открываем и обновляем каждую форму.

OOP: Мы фиксируем метод передачи в классе транспортного средства, и изменение сохраняется в каждом классе, который наследуется от него.

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

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

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

Ответ 2

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

Вы можете запрограммировать его двумя способами:

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

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

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

Ответ 3

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

Ответ 4

Не тратьте время на "определение" ООП.

Просто используйте язык ООП для всех ваших примеров.

Объекты тривиально очевидны. Реальный мир полон объектами.

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

Люди, не имеющие программирования, не имеют глупых ожиданий, основанных на процедурном программировании.

Люди, которые изучили COBOL или Basic, будут иметь проблемы.

Части этого зависят от языка. Некоторые языки сильно затрудняют ООП.

Например, в С++ "класс" является просто определяющим. Он не существует как дискретный объект во время выполнения.

В Java и С++ некоторые вещи являются объектами, но несколько "примитивных" типов не являются объектами.

Некоторые языки упрощают ООП.

Python и Smalltalk - все это объект. Нет никаких примитивных типов для мутной воды. Когда вы изучаете OO на языке, таком как Python, объективность ясна и очевидна, потому что она пронизывает все. Точно так же, как в реальном мире, где объекты повсюду.

Ответ 5

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

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

Изменить: подумав об этом, пример животных намного лучше. См. Объяснение ООП без упоминания классов и этот поток SO о том же предмете.

Ответ 6

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

Каждая позиция подобна классу в OO; он определяет набор обязанностей. Члены команды являются экземплярами этих классов.

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

Ответ 7

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

Например, вы хотите описать Транспортные средства, которые семья имеет в гараже. Для вас есть атрибуты каждого интересующего вас автомобиля:

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

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

Vehicle A Model is a Toyota.
Vehicle A Year is 2001.
Vehicle A has four Wheels
Vehicle A is driven by Mom, Dad, and Junior

Vehicle B is a Moto Guzzi
Vehicle B was made in 2004
Vehicle B has two wheels
Vehicle B is driven by Dad

На разных языках вы можете грубо ссылаться на два примера следующим образом:

A = new Vehicle();
A.model = "Toyota";
A.year = 2002;
A.wheelCount = 4;
A.drivers = [ "Mom", "Dad", "Junior" ];

B = new Vehicle();
B.model = "Moto Guzzi";
B.year = 2004;
B.wheelCount = 2;
B.drivers = [ "Dad" ];

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

Кроме того, вы можете "подкласс", что является способом повторного использования объекта в разных контекстах. Например, вы можете использовать более конкретные типы объектов транспортного средства, такие как Car and Motorcycle, которые наследуют их функции от описания Vehicle:

A = new Car();
B = new Motorcycle();

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

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

Ответ 8

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

Ответ 9

Объектно-ориентированное программирование в разговорной речи:

• Все в вашей программе - вещь (объект). У этой вещи есть свойства, которые объясняют это (размер, форма, цвет и т.д.).
• Программист задает вопрос о том, что делать с вопросами/ответами: Сделайте свой размер большим (setSize) или Что ваш размер (getSize)

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

Это не позволяет программисту сообщать вещь . Если вы прямо скажете вещь, чтобы ее размер был красным, он должен отказаться (красный не является допустимым размером). Кроме того, он позволяет вещам управлять побочными эффектами изменения его свойств.

Предположим, что вещь originalSize большая. Если я просто изменил размер на маленький, я должен запомнить вещь, что она больше не является ее originalSize. Если я попрошу вещь изменить размер на маленький, он изменит свой размер на маленький и изменит значение originalSize на false. Теперь, когда я задаю вопрос, является ли это его originalSize, он ответит нет.

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

Ответ 10

Здесь простое определение.

Gun gun = new Gun(new Bullet);
gun.Aim = Appendage.Foot;
gun.PullTrigger();

;)

Ответ 11

Любое объяснение ООП сильно зависит от объясняющей интерпретации понятия. Моя интерпретация концепции выглядит примерно так.

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

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

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

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

Ответ 12

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

Ответ 13

его так же легко, как пирог, записанный назад. 3 основных принципа оо:

инкапсуляция наследование Полиморфизм

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

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

Ответ 14

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

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

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

Ответ 15

Это странно. Вы спрашиваете об обучении ООП людям, которые ничего не знают о ПРОГРАММИРОВАНИИ, и все отвечают "Как научить ООП?"

Ответ: нет. Как вы преподаете функциональное программирование тем, кто никогда не программировал? Вы этого не сделаете. У вас есть функции, код переполнен ими, они используются повторно и т.д. На Java весь ваш код должен быть в классе. Что такое класс? Это, прежде всего, место для размещения вашего кода. Программы начинаются с метода Main. Позже вы можете создать экземпляр, и каждый класс имеет свои собственные методы и свойства. И тогда вы говорите о статических методах и переменных. И потом, когда-нибудь позже вы расскажете о полиморфизме и наследовании. И когда-то там они начинают разрабатывать свои собственные API-интерфейсы и использовать сервлеты и постоянные классы или что-то новое, что нужно реализовать (snervlets? IHibernate?)

Но если вы никогда не видели программирования раньше, нет необходимости садиться и иметь большой чат OOP. Это необходимо, только если вы сохраняете кого-то из не-ООП-программирования. Просто преподавайте программирование. ООП? Есть ли другой вид? Да, но мы не учим этому сегодня, поэтому не беспокойтесь об этом.

[По аналогии: когда вы идете в класс боевых искусств, они обычно не тратят много времени на объяснение. Сначала вы растягиваетесь, они заставляют вас работать, а затем они учат вас некоторым методам. Если вы заинтересованы в том, чтобы понять, какое боевое искусство вы изучаете, вы направляетесь в библиотеку.]