Загрузка...
Учебная работа. Реферат: Объектно-ориентированное программирование 2
Введение 3
Главные принципы:
1. Инкапсуляция 4
2. Наследование 9
3. Полиморфизм 16
Совмещенные код и данные 25
Объектно-ориентированная методология(ООМ) 26
программка «Решение квадратного уравнения» 28
Заключение 31
Перечень литературы 32
Вопросец оценки свойства программки (и квалификации написавшего ее разраба) является очень принципиальным и затрагивается во всех методических исследовательских работах на тему программирования. Относительно формулировки Э.Йодана —
— в целом особенных расхождений во воззрениях нет. Он же приводит традиционный пример дискуссии о плюсах программки:
Чудилось бы, данное определение является очень естественным, чтоб его приводить. Но в жизни приходится весьма нередко сталкиваться с ситуацией, когда пробуют ассоциировать несравненные вещи. к примеру, когда противопоставляют то, что «можно создать», с тем, что «уже издавна изготовлено».
Работоспособность программки нуждается в уточнении — она обязана отвечать начальному техническому заданию (Т3), начальным спецификациям. И здесь необходимо подразумевать, что ТЗ может изменяться в процессе разработки программки. Данная неувязка в особенности животрепещуща для Рф и тем наиболее — для внутрифирменных разработок.
Сошлюсь на Мировоззрение 1-го программера, который занимался «внутрифирменными» разработками поначалу в одном большом русском банке, а крайние три года в американской компании (в США
Богатство бумаг просто поражает и выводит из себя новичков из Рф. Но конкретно эта рутинная работа обеспечивает независимость процесса реализации проекта от поведения отдельных его исполнителей. Принятие решения о начале какого-нибудь проекта занимает в США
одна из русских заморочек — очень случайное изменение начального технического задания. По воззрению почти всех профессионалов, наиболее высочайший процент удачных проектов с внедрением «аутсорсинга» определяется сначала неотклонимым наличием проработанного задания и совершенно формализацией отношений меж заказчиком и исполнителем. В почти всех вариантах внутрикорпоративных работ этапы технического задания и технического проекта носят декларативный нрав.
Последующим главным качеством «неплохой» программки является ее выполнение в данные сроки. Этот вопросец был важен постоянно, но на данный момент, в критериях оживленного развития нашей жизни и бизнеса, роль выполнения временных графиков резко растет.
Одним из основной вопросцев, который уже наиболее 30 лет дискуссируется исследователями организации работы программистов, состоит в том, как оценить настоящую трудозатратность проекта (соответственно найти сроки его выполнения и нужные ресурсы) и обеспечить маневренность процесса его реализации.
Если проанализировать процесс развития средств разработки за все эти годы, то можно создать категорический вывод, что первоочередной задачей являлось увеличение производительности труда программера, в том числе за счет понижения эффективности создаваемого кода (понижение эффективности кода за крайние десятилетия — при схожей производительности микропроцессоров и на задачках одной группы трудности — представляется мне практически естественным фактом).
Наиболее того, Модернизация инвентаря сначала преследовала цель увеличения производительности не столько отдельного человека, сколько всего коллектива разрабов. В доказательство этому можно привести много примеров, когда новенькая версия инструмента (к примеру, за счет использования унифицированных компонент, исключения «хитрых» трюков и пр.) даже понижает эффективность работы индивида, но при всем этом увеличивает устойчивость процесса разработки. Конкретно таковым образом «наука-Искусство» программирования преобразовывалось в технологию. К примеру, чтоб компанию из 3-х (плохо управляемых) суперпрограммистов можно было поменять командой из 10 средних, но взаимозаменяемых и управляемых разрабов.
«Если проект начат, то он должен быть закончен».
Не будем останавливаться на случае, когда проект просто досрочно запирается (отсутствие средств повлекло за собой осознание того, что проект не нужен и пр.) — «незавершёнка» является приобретенной заболеванием нашей экономики. Остановимся только на вопросце коренного конфигурации структуры проекта, во вред срокам его реализации.
Разглядим, к примеру, такую ситуацию. Вы начали проект со сроком реализации в один год. Через полгода нашли, что применив, к примеру, совершенно остальные методы (либо средства разработки), можно выполнить проект за 9 месяцев и повысить эффективность результата на 30%. Стоит прекращать выполнение старенького варианта и начинать новейший? естественно, в
таковой ситуации нужно учесть почти все остальные «граничные условия», но в данной постановке задачки практически разумеется, что Издержки на реализацию второго варианта (с учетом уже потраченных усилий) будут на 25% выше. К тому же не следует забывать о вероятных потерях от упущенной выгоды за три месяца задержки.
Не считая того, следует подразумевать иной нюанс: на этом шаге работы возможность удачного окончания в срок первого варианта оценивается в 80%, а второго — в два раза меньше. Потому в общем случае хорошим решением является окончание начатого варианта, а уже позже исследования вопросца о необходимости его модернизации.
Мне хотелось бы направить внимание, что хотя я повсевременно говорю «проект», по сути все выше произнесенное конкретно относится и к разработке даже относительно маленьких программ. И напротив, почти все из того, что говорится применительно к программированию, касается и реализации больших проектов. Одним из вариантов разрешения противоречия ограниченности сроков и необходимости получения завершенного проекта является пошаговое его выполнение с получением 
определенного практического результата на любом шаге, другими словами реализация проекта в виде поэтапного наращивания числа реализуемых функций.
Хоть какое ранжирование носит личный нрав, и самое основное тут то, что выбор ценностей определяется исходя из убеждений данной мотивированной функции. Я поставила свойство простоты программки на третью позицию, имея в виду такую вводную: есть определенная неувязка — ее необходимо решить.
Но если подступать со стратегической точки зрения и разглядывать решение 
определенной препядствия только как некий актуальный шаг, то на 1-ое пространство я бы поставила конкретно данную характеристику программки.
Это даже важнее соответствия спецификациям, так как спецификации могут изменяться (при этом еще в процессе данного шага работы). Это важнее сроков, поэтому что актуальный цикл полезной программки еще продолжительнее времени, отведенного на создание одной ее версии.
Если честно, зафиксировав этот тезис, я нахожусь в неком замешательстве. С одной стороны, мне он представляется естественным и не требующим подтверждения, с иной — очень нередко встречаешься с примерами программ, которые достоинством простоты и наглядности никак не владеют. До этого всего, это необходимо для:
· обеспечения действенного поэтапного проектирования и разработки;
· увеличения надежности программки средством использования хороших схем полного сквозного тестирования;
· минимизации издержек на отладку: поиск и исправление ошибок;
· упрощения подготовки документации;
· обеспечения способности увеличения эффективности работы программ;
· многофункционального расширения программки в ближнем и отдаленном будущем.
Обычно в качестве резона в пользу «простоты» говорится о необходимости поддержки коллективной работы — чтоб аккомпанировать и развивать программку могли бы остальные создатели. Но мне представляется, что любой программер должен верно осознать, что это необходимо до этого всего
для
обеспечения своей эффективности (даже если он «программист-одиночка»).
«Кто ясно мыслит, тот ясно излагает».
К огорчению, посреди разрабов постоянно были люди, которые создание запутанных программ (как они сами молвят, «утонченных») ставили для себя в заслугу. Но при ближнем рассмотрении почаще всего оказывалось, что они запутывают не только лишь окружающих, да и себя.
понятие «простоты и наглядности» является, естественно, достаточно расплывчатым, но я уверена, что Искусство и разработка программирования заключаются в значимой степени в достижении конкретно данной цели.
нужно сказать, что в нюансе данной препядствия работа современных программистов по сопоставлению с иногда двадцатилетней давности в чем либо упростилась, а в чем либо усложнилась. к примеру, возможность использования длинноватых имен очень упростила самодокументирование программ. Но событийная модель приложения, с одной стороны, воплотила интуитивно понятную структуру программки, с иной — привела к возникновению большого числа маленьких процедур, ориентироваться в каких не так просто. (Крайнее утежеляется очень слабеньким механизмом навигации по компонентам проекта, к примеру в том же Visual Basic.)
здесь также следует вспомянуть, что ранее программки имели только один уровень компонент — процедуры (подпрограммы, функции). Но еще посреди 80-х (к примеру, в QuickBasic) возник очередной уровень — модули, которые стали состоять из набора процедур и внутренних переменных модуля. (Поточнее, ранее понятие «модуля» было эквивалентно «процедуре» — в одном модуле могла находиться только одна процедура). Это, естественно, увеличивает упругость разработки приложения, но сходу возникает сложная задачка рационального распределения процедур по модулям.
хотелось бы выделить, что понятие «простоты» в крайнее время весьма нередко подменяется «простым» стилем программирования, который, к огорчению, находится и в учебной литературе.
Аспекты эффективности должны быть непременно заданы в начальных спецификациях проекта. Другими словами в общем случае эффективность обязана соответствовать настоящим требованиям, но не обязана быть самоцелью. Обычно получение действенного кода связывают с необходимостью увеличения трудозатрат. И с учетом избранных выше ценностей стратегия разработки заключается в последующем: поначалу создаем работоспособный вариант программки, а позже начинаем работать над увеличением его эффективности.
Приходится достаточно нередко слышать, как программеры разъясняли не весьма высшую эффективность программки (и свойство ее дизайна) твердыми временными сроками. Но вот в чем феномен: почти всегда конкретно действенный код и не плохая наглядность кода обеспечивают минимизацию временных издержек.
Очевидно, для сложных комплексов можно употреблять особые инструменты, но в реальности почти все способы увеличения эффективности кода отлично известны на чисто теоретическом уровне. Просто необходимо их знать и использовать.
Когда компы были большенными, память у их была малеханькой и
быстродействие тоже. И потому гуру от этих ЭВМ ничего, не считая ассемблера (автокода) и не признавали. И на программистов смотрели свысока — писать, дескать, действенные программки не могут, лишь напрасно машинное время расходуют.
И вправду, как было не признать! Пока программка маленькая и в память помещается — хорошо, живите и радуйтесь! Как больше стала? Здесь-то и придется признать свое бессилие.
Навряд ли кто-либо из сегодняшнего поколения слышал про «суицид программ». Нет, это не стирание EXE-файла во время его работы. Это когда программка во время собственной работы употребляет память, занятую своими командами (которые уже отработали и больше не потребуются) под свои данные. Навряд ли кому-нибудь придется сиим на данный момент
заниматься. А вот когда у Вас всего 18 Кбайт, то и таковым не третировали.
Позже компы стали больше. И в размерах и память с быстродействием тоже росли.
к примеру, ЕС-1022. Памяти там было уже 512 Кбайт, 100 из их занимала ОС. Другие 400 делились меж 3-4 сразу работавшими программками различных юзеров. Так что на тех, кто заказывал больше 200 Кбайт, на ВЦ смотрели достаточно косо — за наш счет ведь!
Эффективность тогда была постоянно на первом плане. Не как-нибудь написать, а более действенным методом, не хоть какой метод употреблять, а наилучший для этого варианта. На этом крепко стояли.
В данной курсовой работе я бы желала создать упор конкретно на эффективность программ.
Начнем с того, каким образом это совершенно можно создать. Есть как минимум два варианта решения данной задачки.
Дан треугольник ABC и разыскиваемая точка X. Чтоб найти принадлежит ли точка треугольнику необходимо сделать последующие деяния:
1. Отыскать площадь треугольника ABC.
2. Отыскать площади треугольников ABX, BCX и ACX.
3. Сопоставить. Если площадь треугольника ABC равна сумме площадей ABX, BCX и ACX, означает точка принадлежит треугольнику, по другому — нет.
Ситуация таковая же: ABC — треугольник, X — точка.
1. Находим площадь треугольника ABC.
2. Находим расстояние от точки X до каждой из вершин треугольника.
3. Избираем меньшее из их. (В данном случае BX)
4. Находим площадь треугольника с новейшей точкой заместо наиблежайшей. (тут XC)
5. Сравниваем. Если площадь первого треугольника больше площади второго, означает, точка не принадлежит треугольнику, по другому — принадлежит.
По трудности реализации оба варианта приблизительно схожи, но дело в том, что во 2-м варианте есть маленькой процент некорректности — когда точка лежит весьма близко к грани треугольника, но не принадлежит ему.
Потому тщательно разглядим лишь 1-ый вариант.
Выбор пути решения ясен. В любом случае в обоих вариантах ответ находится через площадь. Как отыскать площадь по координатам точек? Ответ есть. Существует таковая формула Герона.
Где p — полупериметр, x,y и z — длины сторон. Длину сторон же находятся по формуле длины вектора.
1-ые строки кода смотрятся так:
Переменные
промежные. В их будут храниться временные значения координат. Переменные
— координаты вершин треугольника и разыскиваемой точки. Переменные
и
будут служить для хранения площадей треугольников.
Поначалу напишем функцию получения координат с клавиатуры. Она смотрится так:
Координаты точки будут вводиться через пробел, при нажатии на Enter переход к последующей точке. Итак, мы получили координаты точек треугольников.
сейчас получим их площади.
— формула нахождения длины вектора AB.
— та формула Герона. сейчас при вызове данной процедуры мы будем указывать номер подходящего треугольника. 1 — основной треугольник, 2-4 — треугольники образованные точкой.
сейчас нам необходимо отыскать площади треугольников образованных точкой. Для этого будем временно подставлять заместо координат одной из вершин координаты точки D.
Данной для нас процедуре мы передаем номер операции. Я условно приняла, что нахождение площади ABD — 1, BCD — 2 и ACD — 3. В переменные
и
мы вводим временные координаты точки, чтоб позже можно было их вернуть.
Дальше идет фактически сама процедура сопоставления.
— это площадь головного треугольника, а
— сумма площадей промежных треугольников. Но если мы будем ассоциировать по сиим данным, то ответ будет постоянно отрицательным, потому что опосля всех операций кое-где далековато опосля запятой они все-же расползаются.
Так что нам еще пригодится функция округления до сотых.
// Опосля этого в целой части останутся 1-ые 3 числа
числа.
// Получаем целую часть, т.е. отбрасываем все ненадобное.
/ Делим на 100 и получаем 2 знака опосля запятой.
Написание всех нужных процедур и функций закончено, сейчас можно перебегать к исполняемой части программки.
// Получаем значения с клавиатуры.
// Сейчас в per1 находится площадь головного треугольника.
// Заместо точки C подставляем D.
// сейчас в per2 находится площадь треугольника ABD.
// Возвращаем точке C
// ее координаты.
// Пока сумма равна площади ABD.
// Заместо точки A подставляем D.
// сейчас в per3 находится площадь треугольника BCD.
// Сумма равна площадь ABD + площадь BCD.
Возвращаем точке A
ее координаты.
// Заместо точки B подставляем D.
// сейчас в per4 находится площадь треугольника ACD.
// Сейчас p = ABD + BCD + ACD.
// Округляем сумму до сотых.
// Округляем площадь головного треугольника до сотых.
// Сравниваем и выводим итог.
// Ждем нажатия клавиши Enter.
Еще 10-15 лет вспять числилось, что любой технический спец должен уметь худо-бедно созодать программки для ЭВМ для решения каких-либо собственных задач. В таковой постановке вопросца есть собственный резон, ведь программирование — это, до этого всего создание логического метода для заслуги хотимой цели (при помощи компа либо без него). Не считая того, даже если вы будете передавать задачку проф разрабу, то познание основ программирования поможет верно формулировать задание и совершенно осознавать «смежника».
Но итоги всеобщего обучения программированию той поры навряд ли можно именовать успешными. На практике выходило так, что тот, кто желал фактически созодать программки, осваивал эту технологию без помощи других. Абсолютное же большая часть студентов забывали о программировании скоро опосля сдачи зачета. Так было в 80-х годах, так происходит и на данный момент (я имею в виду подготовку некомпьютерных профессионалов).
обстоятельств этому достаточно много. В 80-е годы (и ранее) освоение программирования напоминало исследование теории плавания без практических занятий на воде. К этому необходимо прибавить откровенно слабенькую методику преподавания, которое сводилось не к исследованию программирования на примере некого языка, а к освоению синтаксиса языка без привязки к технологии построения алгоритмов и практической реализации программ.
на данный момент компы стали значительно доступнее, но ситуация с исследованием программирования фактически не стала лучше. одной из обстоятельств этого является принципное колебание в необходимости его освоения. Вправду, для чего обучаться программированию, если можно пользоваться бессчетными готовыми приложениями? Потому
давайте просто учить «компьютерной грамоте».
Да, таковая постановка вопросца имеет рациональное зерно, но все таки представляется достаточно ограниченной.
1. Программирование помогает лучше формулировать логику решения фактически хоть какой задачки (совершенно не непременно чисто вычислительной). Как гласили в старину, «математика мозги в порядок приводит».
2. Расширение функциональности готовых программ с неизбежностью просит их наиболее узкой опции и адаптации к нуждам определенного юзера. Внедрение способов программирования резко расширяет способности решения данной задачки.
3. Вербование для этого проф разрабов нередко просто глупо: создать самому — резвее, чем идти в другое крыло строения для общения с сотрудниками.
За крайние 10 лет инструменты разработки и разработка их освоения перетерпели радикальное изменение. Эти средства стали значительно наиболее понятными на чисто интуитивном уровне. Не считая того, конструктивно поменялась схема практической работы. Упрощенно говоря, ранее необходимо было поначалу изучить теорию программирования, чтоб написать даже простенькую программу, то на данный момент суровое освоение программирования начинается обычно опосля написания полезного приложения.
Современные средства разрешают почувствовать эффект от программирования практически с первых шагов, предоставляя возможность поэтапного наращивания собственных познаний и способностей. Но при всем этом нужно держать в голове одну важную истин: для перехода к суровой проф разработке 1-го опыта недостаточно — в некий момент будет нужно исследование теории.
1. Информатика, Н.В.Макарова, Л.А.Матвеев, В.Л.Бройдо, Москва 2005.
2. Статья «Побеседуем о программировании», А.Колесов.
3. Статья «О эффективности программ», П.Дворкин.
4. веб.
В 50—60-х годах одной из главных черт трудности электрического оборудования могло служить число применяемых в нем ламп, а потом полупроводниковых вентилей (диодов и транзисторов). Минимизация числа активных компонент цифровых устройств, как правило, означала в то время существенное упрощение ЭВМ , увеличение надежности.
Математический аппарат, который дозволял проектировщику «сберегать мышление» и минимизировать количество применяемых в конструируемом приборе вентилей формальными способами, был в этих критериях полезным и обширно употреблялся.
Опосля возникновения па рубеже 70-х годов интегральных схем средней, а потом и большенный (БИС) интеграции древняя черта трудности цифрового устройства по числу применяемых в нем диодов и транзисторов растеряла всякий смысл. С иной стороны, если в 50—60-х годах никому и в голову не могло придти оценивать конструктивную сложность цифрового устройства суммарным числом «ножек» на цоколях всех его ламп либо общим числом выводов на диодиках и транзисторах, то в 70-х годах оказалось, что общее число активных компонент уже не имеет решающего значения, а почти всегда наиболее необходимыми параметрами являются количество выводов и число кристаллов.
В это время уже тяжело было бы найти разраба цифровой аппаратуры, который из любви к традиционным способам ранее освоенного им математического аппарата занимался бы минимизацией числа транзисторов в цифровой аппаратуре 4-ого поколения.
совсем другая ситуация сложилась в технологии программирования. Аспекты эффективности программ, сформировавшиеся в 50-х годах для ламповых ЭВМ , с трудом «вытравлялись» из науки и
практики программирования середины 70-х годов и все еще сохраняют живучесть в 80-х. Э. Йодан, защищая в 1977 г. структурное программирование от критиков, обращавших внимание ни явное понижение эффективности отлично структурированных программ из-за роста числа воззваний к подпрограммам, обязан был ссылаться на энергичное замечание В. Вульфа:
Твердые советы (что и как следует созодать) здесь не подходят, поэтому что у всякого человека своя, персональная система внутренних ценностей и мотиваций. Программирование нереально свести к набору готовых всепригодных приемов и рецептов на все случаи, которые довольно заучить и механически ввести.
Наивысшей эффективности можно достигнуть лишь одним методом: разработка программки обязана стать действием, приближенным к настоящей ситуации и потому очень гибким. Лишне формальные способы и приемы программирования разрешают накопить познания в собственной проф сфере, но они не посодействуют воплотить эти познания в практику и научиться синтезировать верные решения, потому что основаны на шаблонах, изредка приближенных к определенным ситуациям.
Мастерство программирования некорректно сводить к набору готовых рецептов действий во всех мыслимых ситуациях. В учебниках содержатся довольно общие советы и приводятся примеры, пригодные для критерий, которые никогда не совпадут с определенными критериями определенного разраба. Мастерство программирования представляет собой систему умственных и поведенческих способностей, которые, как разъясняет современная психология
По другому познания, почерпнутые из книжек, останутся мертвой информацией. А чтоб этого не случилось, постарайтесь понять самое основное правило программера:
.
]]>