Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Документ'
Gil’s Jewellery – не просто ще один магазин, в якому продаються ювелірні прикраси. Прагнучи перейняти багатовікову культуру кращих ювелірних салонів ...полностью>>
'Документ'
В соответствии с постановлением Правительства Российской Федерации от 22.06.2004 № 303 ДСП «О порядке эвакуации населения, материальных и культурных ...полностью>>
'Документ'
Текущая деятельность Морского совета при Правительстве Санкт-Петербурга (далее Морской совет) осуществляется секциями и постоянными комиссиями Морског...полностью>>
'Публичный отчет'
Цель издания – информировать коллектив ГПНТБ СО РАН и библиотечную общественность о важнейших событиях и результатах работы по основным направлениям ...полностью>>

Как правильно писать тесты 46 Цикл разработки 46 Структура проекта с тестами 51 Утверждения (Asserts) 52 Утверждения в форме ограничений 54 Категории 56

Главная > Тесты
Сохрани ссылку в одной из сетей:

329

Содержание

Содержание 1

Процесс разработки программного обеспечения 3

Основные принципы объектно-ориентированного программирования (начало) 13

История 15

Основные принципы объектно-ориентированного программирования (продолжение) 17

Главные понятия 17

Основные принципы 17

Абстракция данных 17

Инкапсуляция 18

Наследование 19

Основные принципы объектно-ориентированного программирования (окончание) 21

Полиморфизм 21

Отношения 22

Основы .NET Framework 26

Введение 26

Обзор выполнения кода в среде CLR 30

Компиляция исходного кода в управляемые модули 31

Части управляемого модуля 32

Объединение управляемых модулей в сборку 33

Загрузка CLR при выполнении программы 36

Исполнение кода сборки 37

IL и верификация 41

Небезопасный код 42

IL и защита интеллектуальной собственности 42

NGen.exe — генератор объектного кода 43

Библиотека классов .NET Framework 44

Общая система типов (Common Type System, CTS) 46

Общеязыковая спецификация 48

Модульное тестирование (unit testing) 50

Предпосылки 50

Преимущества 50

Поощрение изменений 51

Упрощение интеграции 51

Документирование кода 51

Отделение интерфейса от реализации 52

Ограничения 52

Как правильно писать тесты 52

Цикл разработки 52

Структура проекта с тестами 58

Утверждения (Asserts) 59

Утверждения в форме ограничений 60

Категории 62

Настройка среды выполнения тестов 64

Дополнительные утверждения 65

Тесты и исключения 67

Правила тестирования 68

Юнит-тестирование 77

Пример 77

Два вида констант 105

Операторы is, as и приведение типов 108

Метод ToString() 117

Типы-значения и ссылочные типы 124

Неизменяемые (Immutable) атомарные типы-значения 130

0 в типах-значениях 140

Методы ReferenceEquals(), Equals(), статический метод Equals() и operator== 142

Циклы foreach 148

Управление ресурсами в .NET 152

Инициализаторы переменных 158

Инициализация статических полей классов с помощью статических конструкторов 164

Цепочки конструкторов 166

Применение операторов using и try/finally для освобождения ресурсов 169

О минимизации мусора 176

Упаковка и распаковка 178

Наследование классов и реализация интерфейсов 180

Отличие реализации методов интерфейса от переопределения виртуальных методов 187

Введение в паттерны проектирования 193

Что такое паттерн проектирования 195

Паттерны проектирования в схеме MVC 198

Описание паттернов проектирования 201

Каталог паттернов проектирования 203

Как решать задачи проектирования с помощью паттернов 206

Механизмы повторного использования 218

Сравнение структур времени выполнения и времени компиляции 225

Проектирование с учетом будущих изменений 227

Как выбирать паттерн проектирования 236

Как пользоваться паттерном проектирования 238

Делегаты и события 243

Делегаты 243

События 248

Параметры событий 250

Атрибуты 254

Синтаксис 254

Создание атрибута 257

Составляющие класса атрибута 259

Получение значений атрибута 261

Задание 1 263

Задание 2 264

Обобщения 269

Проблемы создания объектных образов и восстановления значений 270

Типовая безопасность и строго типизованные коллекции 271

Проблемы создания объектных образов и строго типизованные коллекции 276

Пространство имен System.Collections.Generic 277

Тип List<T> 279

Создание обобщенных методов 281

Пропуск параметров типа 283

Создание обобщенных структур (и классов) 286

Ключевое слово default в обобщенном программном коде 288

Создание пользовательских обобщенных коллекций 290

Установка ограничений для параметров типа с помощью where 292

Отсутствие поддержки ограничений при использовании операций 298

Создание обобщенных базовых классов 299

Создание обобщенных интерфейсов 301

Создание обобщенных делегатов 303

Несколько слов о вложенных делегатах 305

Задачи 306

Примеры реализации по шаблонам Мост+Фабрика 309

Пример 1 309

Пример 2 312

Пример 3. Контроллер в виде интерфейса, а не класса. 314

Различное поведение фабрик 318

Фабрики для создания плагинов 319

Фабрики для создания объектов по некоторому алгоритму 320

Фабрики для клонирования объектов 320

Некоторые замечания об использовании свойств и наследования 322

Замечания об использовании свойств 322

Замечания об использовании наследования. Проблема «хрупкого» базового класса. 324

Процесс разработки программного обеспечения1 2

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

Заказчика, как правило, интересует две вещи: сколько стоит проект и сколько времени займет написание программы.

Т.о. разработка ПО постоянно происходит при этих ограничениях.

Возможны два пути выполнения проекта.

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

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

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

Пользователь должен иметь возможность поиска турпохода.

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

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

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

Пользователь должен ввести уровень сложности и получить список маршрутов с заданной сложностью.

Второе утверждение заказчика:

Пользователь должен иметь возможность заказать снаряжение.

Ваши варианты:

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

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

Какие варианты ближе всего к ожиданиям заказчика?

Скорее всего, ответ нельзя дать однозначно. Поэтому если вы не уверены в том, что хочет заказчик, всегда вернитесь к нему и спросите еще раз.

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

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

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

Итак, мы приходим к понятию итерации разработки.

Современное ПО разрабатывается итеративно. Мы уже говорили о том, что произойдет, если игнорировать существование заказчика. Итерация позволяет ответить разработчику на вопрос: что нужно делать именно сейчас?

Без итераций процесс можно изобразить так:

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

Если же воспользоваться итерациями:

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

Длина итерации выбирается в процессе разработки, обычно (для средних проектов) она составляет 20 дней.

В итоге итерация дает:

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

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

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

Каждая итерация – это минипроект. У него есть все присущие большому проекту этапы:

  • сбор требований,

  • проектирование,

  • кодирование,

  • тестирование.

Попробуем оценить возможности или функции сайта, которые нам пришлось бы реализовать, если бы мы делали сайт для турпоходов. Мы оцениваем все возможности по длительности и приоритету (10 макс., 50 мин.). Нужно расставить возможности на таймлайне проекта. Нужно учитывать, что заказчик не хочет, чтобы пользователи могли заказывать снаряжение, не залогинившись.

Одно из решений могло быть таким:

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

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

При этом возникают большие проблемы.

Чтобы решить новую задачу, придется:

1) оценить время необходимое на выполнение новых функций

2) заставить заказчика расставить реальные приоритеты для новых возможностей по сравнению с оставшимися

3) переделать план

4) проверить сроки сдачи проекта

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

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

Хорошие программисты пишут программы, отличные программисты сдают их заказчику! :-)

Основные принципы объектно-ориентированного программирования (начало)

Объектно-ориентированное программирование (ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов.

Класс — это тип, описывающий устройство объектов. Понятие «объект» подразумевает нечто, что обладает определённым состоянием и поведением. Кроме того задается признак, по которому объекты одного класса можно отличить от других объектов этого же класса (объекты одного класса могут существовать одновременно).

Говорят, что объект — это экземпляр класса. Класс можно сравнить с чертежом, согласно которому создаются объекты. Объект описывается своим классом или с другой стороны класс описывает все возможные состояния объектов данного класса (то, что объект может знать) и его поведение (то, что он может делать).

Объекты – это живые, динамичные сущности. Мы их создаем во время выполнения программы. Объекты выполняют возложенную на них работу.

Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области.

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

Сообщение состоит из четырех частей:

• идентификатор получателя;

• кода, который должен быть выполнен получателем (метод, функция получателя);

• аргументами для этого метода;

• возвращаемого отправителю значения.

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

По способу взаимодействия с другими объектами различают такие виды объектов:

• клиент – воздействует (отправляет запросы) на другие объекты;

• сервер – обслуживает запросы других объектов;

• агент – играет роль и клиента и сервера.

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


В объектно-ориентированных языках тип – синоним класса, но на этапе проектирования эти понятия различаются.

Объекты одного типа имеют общие свойства и поведение.

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

Основной особенностью интерфейса является то, что он включает в себя только объявление методов класса без реализации.

История

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

Первым языком программирования, в котором были предложены принципы объектной ориентированности, была Симула. В момент своего появления (в 1967 году), этот язык программирования предложил поистине революционные идеи: объекты, классы, виртуальные методы и др., однако это всё не было воспринято современниками как нечто грандиозное. Тем не менее, большинство концепций были развиты Аланом Кэйем и Дэном Ингаллсом в языке Smalltalk. Именно он стал первым широко распространённым объектно-ориентированным языком программирования.

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

Основные принципы объектно-ориентированного программирования (продолжение)3

Главные понятия

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

Наличие инкапсуляции достаточно для объектности языка программирования, но ещё не означает его объектной ориентированности — для этого требуется наличие наследования.

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



Скачать документ

Похожие документы:

  1. Отчет о научно-исследовательской работе по теме: №21 «Разработка рекомендаций по созданию и использованию единой системы объединеных государственных и муниципальных информационных ресурсов» (Заключительный)

    Публичный отчет
    Ключевые слова: ГОСУДАРСТВЕННЫЕ ИНФОРМАЦИОННЫЕ РЕСУРСЫ, АРХИТЕКТУРА ЭЛЕКТРОННОГО ГОСУДАРСТВА, АГЕНТ, МЕТАДАННЫЕ, ПОРТАЛ, РЕПОЗИТОРИЙ, РЕГЛАМЕНТ, СЕРВИС.
  2. Ларри Хьелл, Дэниел Зиглер Теории личности

    Книга
    На Западе настоящее издание является одним из самых читаемых в своей области. Если бы такая книга вышла у нас лет двадцать назад, российская психология как наука избежала бы многих проблем роста.
  3. Предисловие (20)

    Документ
    В 1982 г. Майк Маллер [Mike Muller], автор книги «Здоровье народов» [The health of Nations] - одного из первых крупных исследований международного фармацевтического рынка - заметил, как трудно идти в ногу с быстро меняющейся ситуацией в этой области.
  4. С. Гринберг Управление стрессом

    Документ
    Известно, что борьба со стрессом и его профилактика крайне сложны и нередко оказываются низко­эффективными. В предлагаемой книге рассматриваются физические, психологические, социологические и духовные аспекты стресса.
  5. Риалы VI международной научной конференции (2-3 марта 2006 г.) Белово 2006 ббк ч 214(2Рос-4Ке) 73я431 н 34

    Документ
    Н-34 Наука и образование: Материалы VI Международной научной конференции (2-3 марта 2006 г.): В 4 ч. / Кемеровский государственный университет. Беловский институт (филиал).

Другие похожие документы..