Программирование на языке C++

Размещено на http://www.allbest.ru/

Оглавление

программирование framework маршрутизация интерфейс

Введение

1. Индивидуальное задание кафедры

2. Разработка приложения на языке C++

3. Платформа .NET Framework

4. Паттерн репозиторий

5. Принципы SOLID

6. Применение полученных знаний на практике. Создание приложения

Заключение

Список использованной литературы



Введение

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

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

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



1. Индивидуальное задание кафедры

· Ознакомление с деятельностью предприятия и протекающими в нем бизнес-процессами

· Адаптироваться к рынку труда и возможной будущей трудовой деятельности, связанной с проектированием, внедрением и сопровождением

· Изучить информационную систему предприятия

· Приобретение практических навыков по выполнению должностных обязанностей

· Закрепление на практике теоретических знаний при изучении общепрофессиональных и специальных дисциплин на 1-3 курсах

ТОО «Dynamics Technologies» - один из крупнейших казахстанских поставщиков в области разработки программного обеспечения и решений. Компания была образована в 2007 году. Компания имеет статусы Microsoft Gold Partner и SAP Service Partner. Компания является разработчиком системы электронного документооборота «Эвридок». «Dynamics Technologies» разрабатывает программное обеспечение для мобильных устройств на различных платформах: iOS, Android и Windows Phone.

Компания специализируется на следующих продуктах:

· Microsoft SharePoint

· Microsoft Exchange

· Microsoft Linq

· Microsoft Search

· Microsoft BizTalk

· Microsoft SQL Server

· Microsoft Forefront

· Microsoft System Center

· SAP ERP

· SAP NetWeaver

· SAP SRM

· SAP Business Objects

· SAP xApps

· SAP Mobility

И оказывает услуги в направлениях:

· Office Collaboration -- Совместная офисная работа

· DMS/DocFlow -- Системы электронного документооборота (СЭД)

· Unified Communication -- Объединенные коммуникации (видео-конференции, IP-телефония, обмен сообщениями и др.)

· Data Warehousing/BI -- Корпоративные хранилища данных и бизнес аналитика

· Enterprise Information Portals -- Корпоративные информационные порталы

· Enterprise Resource Planning -- Системы планирования и управления ресурсами предприятий

· Suppliers Relation Management -- Системы взаимоотношений с поставщиками

· Maintenance, repair, and operations (ТОРО/ТОиР) -- Системы технического обслуживания и ремонта оборудования

· Business Process Management -- Системы управления бизнес-процессами, корпоративные шины данных

· Customer Relation Management -- Системы управления отношениями с клиентами

· Mobility -- Доступ к корпоративным информационным системам посредствам мобильных устройств (iPad / iPhone, Android, и др.)

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

Алгоритмизация - разработка алгоритма решения задачи.

Аппаратный интерфейс - устройство, обеспечивающее согласование между отдельными блоками вычислительной системы.

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

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

Базовое программное обеспечение - совокупность программ, обеспечивающих взаимодействие компьютера с базовыми аппаратными средствами.

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

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

Класс -- абстрактный тип данных.

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

Метод -- функция или процедура, принадлежащая какому-то классу или объекту.

Аргумент -- параметр в программировании. Параметр переданный какой-либо функции

Информация -- Сообщения, осведомляющие о положении дел, о состоянии чего-н.

Данные - зарегистрированные сигналы.

Контроллер -- устройство, управляющее работой внешних узлов ЭВИ

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

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

Защита данных - комплекс мер, направленных на предотвращение утраты, воспроизведения и модификации данных.

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

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

Линейный алгоритм - алгоритм с однозначным последовательным выполнением команд.

Локальная сеть - компьютеры, расположенные в пределах одного или нескольких рядом стоящих зданий и объединенные с помощью кабелей и разъёмов.

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

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

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

Компилятор -- программа выполняющая компиляцию.

Сбор данных - накопление информации с целью обеспечения достаточной полноты для принятия решений.

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

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

2. Разработка приложения на языке C++

C++ - объектно-ориентированный язык программирования. Разработан в 1998--2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework и впоследствии был стандартизирован как ECMA-334 и ISO/IEC 23270.

C++ относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов (в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщённые типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.

Переняв многое от своих предшественников -- языков C++, Pascal, Модула, Smalltalk и, в особенности, Java -- С++, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем, например, C++ в отличие от C++ не поддерживает множественное наследование классов (между тем допускается множественное наследование интерфейсов).

Особенности языка

C++ разрабатывался как язык программирования прикладного уровня для CLR и, как таковой, зависит, прежде всего, от возможностей самой CLR. Это касается, прежде всего, системы типов C++, которая отражает BCL. Присутствие или отсутствие тех или иных выразительных особенностей языка диктуется тем, может ли конкретная языковая особенность быть транслирована в соответствующие конструкции CLR. Так, с развитием CLR от версии 1.1 к 2.0 значительно обогатился и сам C++; подобного взаимодействия следует ожидать и в дальнейшем (однако, эта закономерность была нарушена с выходом C++ 3.0, представляющего собой расширения языка, не опирающиеся на расширения платформы .NET). CLR предоставляет C++, как и всем другим .NET-ориентированным языкам, многие возможности, которых лишены «классические» языки программирования. Например, Сборка мусора не реализована в самом C++, а производится CLR для программ, написанных на C++ точно так же, как это делается для программ на VB.NET, J++ и др.

Последняя версия C++ 4.0

Превью C++ 4.0 было представлено в конце 2008 года, вместе с CTP-версией Visual Studio 2010.

Visual Basic 10.0 и C++ 4.0 были выпущены в апреле 2010 года, одновременно с выпуском Visual Studio 2010.

Новые возможности в версии 4.0

· Возможность использования позднего связывания, для использования:

· с языками с динамической типизацией (Python, Ruby)

· с COM-объектами

· отражения (reflection)

· объектов с изменяемой структурой (DOM). Появляется ключевое слово dynamic.

· Именованные и опциональные параметры

· Новые возможности COM interop

· Ковариантность и контравариантность

· Контракты в коде (Code Contracts)

3. Платформа .NET Framework

.NET Framework - программная платформа, выпущенная компанией Microsoft в 2002 году. Основой платформы является общеязыковая среда исполнения Common Language Runtime (CLR), которая подходит для разных языков программирования. Функциональные возможности CLR доступны в любых языках программирования, использующих эту среду.

Считается, что платформа .NET Framework явилась ответом компании Microsoft на набравшую к тому времени большую популярность платформу Java компании Sun Microsystems (ныне принадлежит Oracle).

Хотя .NET является патентованной технологией корпорации Microsoft и официально рассчитана на работу под операционными системами семейства Microsoft Windows, существуют независимые проекты (прежде всего это Mono иPortable.NET), позволяющие запускать программы .NET на некоторых других операционных системах.

Архитектура .NET

Программа для .NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для .NET промежуточный байт-код Common Intermediate Language (CIL) (ранее назывался Microsoft Intermediate Language, MSIL). В терминах .NET получается сборка, англ.assembly. Затем код либо исполняется виртуальной машиной Common Language Runtime (CLR), либо транслируется утилитой NGen.exe в исполняемый код для конкретного целевого процессора. Использование виртуальной машины предпочтительно, так как избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR встроенный в неё JIT-компилятор «на лету» (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Виртуальная машина CLR также сама заботится о базовой безопасности, управлении памятью и системе исключений, избавляя разработчика от части работы.

Архитектура .NET Framework описана и опубликована в спецификации Common Language Infrastructure (CLI), разработанной Microsoft и утверждённой ISO и ECMA. В CLI описаны типы данных .NET, формат метаданных о структуре программы, система исполнения байт-кода и многое другое.

Объектные классы .NET, доступные для всех поддерживаемых языков программирования, содержатся в библиотеке Framework Class Library (FCL). В FCL входят классы Windows Forms, ADO.NET, ASP.NET, Language Integrated Query, Windows Presentation Foundation, Windows Communication Foundation и другие. Ядро FCL называется Base Class Library (BCL).

Языки программирования в .NET

Одной из основных идей Microsoft .NET является совместимость программных частей, написанных на разных языках. Например, служба, написанная на C++ для Microsoft .NET, может обратиться к методу класса из библиотеки, написанной на Delphi; на C++ можно написать класс, наследованный от класса, написанного на Visual Basic .NET, а исключение, созданное методом, написанным на C++, может быть перехвачено и обработано в Delphi. Каждая библиотека (сборка) в .NET имеет сведения о своей версии, что позволяет устранить возможные конфликты между разными версиями сборок.

Языки, поставляемые вместе с Microsoft Visual Studio:

· C++

· Visual Basic .NET

· JScript .NET

· C++/CLI -- новая версия Managed C++

· F++ -- член семейства языков программирования ML, включён в VS2010/VS2012/VS2015

· J++ -- последний раз был включён в VS2005

.NET Core

.NET Core является кроссплатформенным (Windows, Mac, Linux) аналогом .NET Framework, с открытым исходным кодом. Он содержит среду CoreCLR -- кросс-платформенную реализацию CLR, в которую входит JIT-компилятор -- RyuJIT. Также .NET Core включает в себя CoreFX -- набор библиотек, функциональность которых частично совпадает с BCL: API .NET Core предоставляет подмножество API .NET Framework, но также и предоставляет ряд собственных API.

.NET Core версии 1.0 выпущен 27 июня 2016 года, вместе с Microsoft Visual Studio 2015 Update 3, в которой поддерживается разработка под .NET Core.

ASP.NET

Active Server Pages для .NET - технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформыMicrosoft .NET и развитием более старой технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.NET 5.

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

Принципы ASP.NET

Хотя ASP.NET берёт своё название от старой технологии Microsoft ASP, она значительно от неё отличается. Microsoft полностью перестроила ASP.NET, основываясь на Common Language Runtime (CLR), которая является основой всех приложений Microsoft .NET. Разработчики могут писать код для ASP.NET, используя практически любые языки программирования, входящие в комплект .NET Framework (C++, Visual Basic.NET и JScript .NET). ASP.NET имеет преимущество в скорости по сравнению со скриптовыми технологиями, так как при первом обращении код компилируется и помещается в специальный кэш, и впоследствии только исполняется, не требуя затрат времени на парсинг, оптимизацию, и т. д.

Преимущества ASP.NET перед ASP

· Компилируемый код выполняется быстрее, большинство ошибок отлавливается ещё на стадии разработки

· Значительно улучшенная обработка ошибок во время выполнения запущенной готовой программы, с использованием блоков try..catch

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

· Использование метафор, уже применяющихся в Windows-приложениях, например, таких как элементы управления и события

· Расширяемый набор элементов управления и библиотек классов позволяет быстрее разрабатывать приложения

· ASP.NET опирается на многоязыковые возможности .NET, что позволяет писать код страниц на VB.NET, Delphi.NET, Visual C++, J++ и т. д.

· Возможность кэширования всей страницы или её части для увеличения производительности

· Возможность кэширования данных, используемых на странице

ASP.NET MVC Framework

ASP.NET MVC - фреймворк для создания веб-приложений, который реализует шаблон Model-view-controller.

В апреле 2009 года исходный код ASP.NET MVC был опубликован под лицензией Microsoft Public License (MS-PL). 27 марта 2012 года лицензия была изменена на Apache License 2.0

В настоящее время разрабатывается ASP.NET MVC 6, как часть ASP.NET Core; 27 июня 2016 года состоялся выход версии 1.0.0.

Основные компоненты ASP.NET MVC

Платформа ASP.NET MVC базируется на взаимодействии трех компонентов: контроллера, модели и представления. Контроллер принимает запросы, обрабатывает пользовательский ввод, взаимодействует с моделью и представлением и возвращает пользователю результат обработки запроса.

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

Движок представлений

Для управления разметкой и вставками кода в представлении используется движок представлений. До версии MVC 5 использовались два движка:

Web Forms и Razor. Начиная с MVC 5 единственным движком, встроенным по умолчанию, является Razor. Движок WebForms использует файлы .aspx, а Razor -- файлы .cshtml и .vbhtml для хранения кода представлений. Основой синтаксиса Razor является знак @, после которого осуществляется переход к коду на языках C++/VB.NET. Также возможно и использование сторонних движков. Файлы представлений не являются стандартными статическими страницами с кодом html, а в процессе генерации контроллером ответа с использованием представлений компилируются в классы, из которых затем генерируется страница html.

Маршрутизация

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

Паттерны программирования

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

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

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

На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы.

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

Плюсы

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

Минусы

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

Многие шаблоны проектирования в объектно-ориентированном проектировании можно рассматривать как идиоматическое воспроизведение элементов функциональных языков. Питер Норвиг утверждает, что 16 из 23 шаблонов, описанных в книге «Банды Четверых», в Lisp или Dylan реализуются существенно проще, чем в С++, либо оказываются незаметны. Пол Грэхэм считает саму идею шаблонов проектирования -- антипаттерном, сигналом о том, что система не обладает достаточным уровнем абстракции, и необходима её тщательная переработка. Нетрудно видеть, что само определение шаблона как «готового решения, но не прямого обращения к библиотеке» по сути означает отказ от повторного использования в пользу дублирования. Это, очевидно, может быть неизбежным для сложных систем при использовании языков, не поддерживающих комбинаторы и полиморфизм типов, и это в принципе может быть исключено в языках, обладающих свойством гомознаковости (хотя и не обязательно эффективно), так как любой шаблон может быть реализован в виде исполнимого кода.



4. Паттерн репозиторий

Паттерн Repository Посредничает между уровнями области определения и распределения данных (domain and data mapping layers), используя интерфейс, схожий с коллекциями для доступа к объектам области определения.

Система со сложной моделью области определения может быть упрощена при помощи дополнительного уровня, например Data Mapper, который бы изолировал объекты от кода доступа к БД. В таких системах может быть полезным добавление ещё одного слоя абстракции поверх слоя распределения данных (Data Mapper), в котором бы был собран код создания запросов. Это становится ещё более важным, когда в области определения множество классов или при сложных, тяжелых запросах. В таких случаях добавление этого уровня особенно помогает сократить дублирование кода запросов.

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

Паттерн Unit Of Work (Единица работы)

Описание Unit of Work

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

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

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

Реализация паттерна Unit of Work следит за всеми действиями приложения, которые могут изменить БД в рамках одного бизнес-действия. Когда бизнес-действие завершается, Unit of Work выявляет все изменения и вносит их в БД.

5. Принципы SOLID

SOLID - мнемонический акроним, введённый Майклом Фэзерсом (Michael Feathers) для первых пяти принципов, названных Робертом Мартином в начале 2000-х, которые означали пять основных принципов объектно-ориентированного программирования и проектирования. Эти принципы, когда применяются вместе, предназначены для повышения вероятности того, что программист создаст систему, которую будет легко поддерживать и расширять в течение долгого времени. Принципы SOLID -- это руководства, которые могут применяться во время работы над программным обеспечением для удаления «кода с запашком» предписывая программисту выполнять рефакторинг исходного кода, пока тот не станет разборчиво написанным и расширяемым. Это часть общей стратегии гибкой и адаптивной разработки.

Описание

S (single responsibility principle, принцип единственной обязанности) обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.

Термин был введён Робертом С. Мартином в одноименной статье как часть его Принципов объектно-ориентированного проектирования, ставших популярными благодаря его книге Быстрая разработка программ. Принципы, примеры, практика. Мартин описал её как основанную на принципе связности, сформулированномТомом ДеМарко в его книге Structured Analysis and Systems Specification.

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

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

Принцип единственной обязанности используется в методологиях проектирования «от обязанности», таких как RDD и URDAD

O (open/closed principle, принцип открытости закрытости) принцип объектно-ориентированного программирования, устанавливающий следующее положение: «программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения»; это означает, что такие сущности могут позволять менять своё поведение без изменения их исходного кода. Это особенно значимо в производственной среде, когда изменения в исходном коде потребуют проведение пересмотра кода, модульного тестирования и других подобных процедур, чтобы получить право на использования его в программном продукте. Код, подчиняющийся данному принципу, не изменяется при расширении и поэтому не требует таких трудозатрат.

Термин «принцип открытости/закрытости» имеет два значения. Оба значения используют наследование для решения дилеммы, но цели, способы и результаты -- различны.

Бертран Мейер в основном известен как основоположник термина Принцип открытости/закрытости, который появился в 1988 году в его книге Object-Oriented Software Construction. Идея была в том, что однажды разработанная реализация класса в дальнейшем требует только исправления ошибок, а новые или изменённые функции требуют создания нового класса. Этот новый класс может переиспользовать код исходного класса через механизм наследования. Производный подкласс может реализовывать или не реализовывать интерфейс исходного класса.

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

L (Liskov substitution principle, принцип подстановки Барбары Лисков) принцип в объектно-ориентированном программировании является специфичным определением подтипа, предложенным Барбарой Лисков в 1987 году на конференции в основном докладе под названием Абстракция данных и иерархия.

Роберт С. Мартин определил этот принцип так:

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

Таким образом, идея Лисков о «подтипе» даёт определение понятия замещения -- если S является подтипом T, тогда объекты типа T в программе могут быть замещены объектами типа S без каких-либо изменений желательных свойств этой программы (например, корректность).

Этот принцип является важнейшим критерием для оценки качества принимаемых решений при построении иерархий наследования. Сформулировать его можно в виде простого правила: тип S будет подтипом Т тогда и только тогда, когда каждому объекту oS типа S соответствует некий объект oT типа T таким образом, что для всех программ P, реализованных в терминах T, поведение P не будет меняться, если oT заменить на oS.

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

Саттер и Александреску в своём руководстве по использованию C++ для выражения этого принципа также используют фразу «подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый класс». По мнению данных авторов, публичное наследование в C++ можно употреблять только тогда, когда оно удовлетворяет принципу Лисков. Приватное наследование, по их же мнению, дозволено использовать для доступа к protected части базы и перекрытия виртуальных методов. В любом же ином случае, то есть для всего лишь повторного использования кода из базы, наследование применять нельзя.

Основания: использование публичного наследования для повторного использования кода приводит к тому, что внешний мир начинает считать класс Derived разновидностью класса Base, и возможно появление кода, явно использующего этот факт. Это сильно сужает простор для манёвра архитектора в дальнейшем поддержании и рефакторинге класса Derived.

I (Interface segregation principle, принцип разделения интерфейса) один из пяти принципов проектирования классов в объектно-ориентированном программировании. Следование этому принципу помогает системе оставаться гибкой при внесении изменений в логику работы и пригодной для рефакторинга.

Роберт С. Мартин определил этот принцип так:

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

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

D (dependency inversion principle, принцип инверсии зависимостей) важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

Формулировка:

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

· Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Рефакторинг

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

· если функция не используется - удалите функцию;

· если название функции не отражает намерения программиста - переименуйте функцию.

Процессы написания нового кода и рефакторинга должны быть разделены - эту мысль замечательно выразил Кент Бек:

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

Рефакторинг должен проводиться постоянно, даже во время изучения кода. Однако он выделяется в качестве отдельного этапа TDD (Test Driven Development, разработки через тестирование).

Даже у опытных программистов нередко бывает предчувствие, что в программе что-то не так, но не удается определить что именно. Фаулер замечательным образом систематизировал методы рефакторинга, а также отметил признаки плохого кода - так называемые “запахи”, однако более фундаментальными для объектно-ориентированного подхода являются принципы SOLID.

6. Применение полученных знаний на практике. Создание приложения

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

Придерживаясь принципа инверсии зависимости я использовал IOC Container, Ninject.

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

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

Структура приложения

Приложение реализует шаблон Model/View/Controller.В папке Models находится класс модели предметной области. В папке Controllers наши контроллеры - обработчики событий. В Views наши представления. Как вы видите каждому контроллеру соответствует представление.



В папке Shared находятся два файла. Layout используется как макет, а Error.cshtml возвращается при обнаружении ошибки в методе контроллера

Контроллеры

AccountController.cs класс используемый для авторизации.BaseController.cs используется шаблоном Unit Of Work. Каждый контроллер-класс наследуется от BaseController.cs класса. CategoryController используется для представления категорий вещей.SignupController.cs класс исползуемый при регистрации пользователей. При открытии приложения запускается класс HomeController.cs

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



Так же приложение предусматривает поиск интересующих дел

Возможность отсортировать по названию



Заключение

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

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

Размещено на Allbest.ru