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

ООП с примерами (часть 1)

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

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

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

Основные понятия ООП

Класс

Представьте себе, что вы проектируете автомобиль. Вы знаете, что автомобиль должен содержать двигатель, подвеску, две передних фары, 4 колеса, и т.д. Ещё вы знаете, что ваш автомобиль должен иметь возможность набирать и сбавлять скорость, совершать поворот и двигаться задним ходом. И, что самое главное, вы точно знаете, как взаимодействует двигатель и колёса, согласно каким законам движется распредвал и коленвал, а также как устроены дифференциалы. Вы уверены в своих знаниях и начинаете проектирование.

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

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

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

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

В нашем случае, класс будет отображать сущность – автомобиль. Атрибутами класса будут являться двигатель, подвеска, кузов, четыре колеса и т.д. Методами класса будет «открыть дверь», «нажать на педаль газа», а также «закачать порцию бензина из бензобака в двигатель». Первые два метода доступны для выполнения другим классам (в частности, классу «Водитель»). Последний описывает взаимодействия внутри класса и не доступен пользователю.

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

Объект

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

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

Говоря простым языком, объект имеет конкретные значения атрибутов и методы, работающие с этими значениями на основе правил, заданных в классе. В данном примере, если класс – это некоторый абстрактный автомобиль из «мира идей», то объект – это конкретный автомобиль, стоящий у вас под окнами.

Интерфейс

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

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

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

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

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

Источник

Принципы объектно-ориентированного программирования

Привет, Хабр! Меня зовут Владислав Родин. В настоящее время я являюсь руководителем курса «Архитектор высоких нагрузок» в OTUS, а также преподаю на курсах, посвященных архитектуре ПО.

Специально к старту занятий в новом потоке курса «Архитектура и шаблоны проектирования» я подготовил еще один авторский материал.

Введение

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

Вообще устроено все следующим образом: есть само объектно-ориентированное программирование. У него есть принципы. Из принципов объектно-ориентированного программирования следуют разобранные нам шаблоны GRASP (как вариант — SOLID принципы), из которых, в свою очередь, следуют шаблоны GoF. Из них же следует ряд интересных вещей, например, enterprise паттерны.

Объектно-ориентированная парадигма

Определение гласит, что «Объектно-ориентированное программирование – это парадигма программирования, в которой основной концепцией является понятие объекта, который отождествляется с предметной областью.»

Таким образом, система представляется в виде набора объектов предметной области, которые взаимодействуют между собой некоторым образом. Каждый объект обладает тремя cоставляющими: идентичность (identity), состояние (state) и поведение (behaviour).

Состояние объекта — это набор всех его полей и их значений.

Поведение объекта — это набор всех методов класса объекта.

Идентичность объекта — это то, что отличает один объект класса от другого объекта класса. С точки зрения Java, именно по идентичности определяется метод equals.

Принципы объектно-ориентированного программирования

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

1. Абстрация
2. Инкапсуляция
3. Наследование
4. Полиморфизм

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

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

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

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

Таким образом, получается, что если класс A обращается к полям класса B напрямую, это приводит не к тому, что «нарушается информационная безопасность», а к тому, что класс A завязывается на внутренне устройство класса B, и попытка изменить внутреннее устройство класса B приведет к изменению класса А. Более того, класс A не просто так работает с полями класса B, он работает по некоторой бизнес-логике. То есть логика по работе с состоянием класса В лежит в классе А, и когда мы захотим переиспользовать класс В, это не удастся сделать, ведь без кусочка класса А класс В может быть бесполезным, что приведет к тому, что класс В придется отдавать вместе с классом А. Экстраполируя это на всю систему, получается, что переиспользовать можно будет только всю систему целиком.

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

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

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

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

Полиморфизм

Полиморфизм — это возможность использовать классы – потомки в контексте, который был предназначен для класса – предка.

За самым садистским определением кроется возможность языка программирования для декомпозиции задачи и рефакторинга if’ов и switch’ей.

Источник

Объектно-ориентированный дизайн и как его использовать для проектирования систем

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

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

В последние годы эти области начали сближаться. Проектирование соприкасается с дизайном, а дизайн — с версткой. В этом помогают, к примеру, дизайн-системы, storybook’и, созданные по правилам разработки интерфейсов, а также современные инструменты: Figma, Sketch, InVision Studio и другие.

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

Мой подход основан на OOUX Софии В. Пратер (https://alistapart.com/article/object-oriented-ux/), но дополняет и расширяет его, основываясь на моем опыте применения.

Зачем нужен ООД

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

ООД помогает команде решить несколько важных задач.

Определиться, с чего начать

Вопрос «С чего начать?» возникает даже у самых опытных. Допустим, вам нужно разработать мобильное приложение по доставке котиков. Что вы сделаете в первую очередь? Можно начать рисовать экраны или продумывать структуру, а можно проектировать сущности.

Какие сущности есть в таком приложении? Наверняка там будут «пользователь», «заказ» и «котик». У «пользователя» есть имя и фамилия, а заказ можно сделать из двух мест: с экрана товара или с экрана со списком ранее оформленных заказов. Значит позже нужно подумать, как отразить это в интерфейсе.

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

Сэкономить

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

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

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

Создать MVP

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

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

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

Пример очень бюджетного MVP — стартап по продаже обуви Zappos, который невероятно взлетел, привлек много инвестиций и превратился в суперсервис. Но в самом начале у его основателя Ника Свинмерна не было ничего, кроме совсем простого сайта. Он размещал там фотографии обуви из местных магазинов, чтобы понять, есть ли на нее спрос. Когда кто-то делал заказ, Ник покупал эту пару и привозил клиенту. Свинмерн не вкладывался в инфраструктуру и оборудование, но смог создать у клиентов иллюзию полноценного сервиса и с минимальными затратами проверил, востребован ли его продукт.

Исключить хаотичные скачки

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

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

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

С чего начинается ООД. Составляем карту объектов

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

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

1. Выявляем объекты

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

Выявляем все объекты, которые встречаются в системе.

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

Здесь можно выделить объекты «пользователь» (с подтипом «HR-менеджер»), «транзакция» и «вакансия». С «вакансией» и «транзакцией» определиться легко: они точно являются объектами, с которыми проводятся операции в системе.

С «отчетом» сложнее. Это точно объект, но нет уверенности, что он должен быть частью вашей системы. Чтобы это понять, вы должны выяснить, для чего пользователю отчет и как именно он с ним взаимодействует.

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

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

2. Определяем параметры объекта и связи

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

Параметры для объекта «вакансия»

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

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

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

«Тест» — это отдельный объект, который связан с объектом «вакансия».

С объектом «вакансия» связаны «тест» и «новость».

3. Определить варианты и способы взаимодействия

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

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

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

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

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

4. Определяем свойства параметров

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

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

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

Р — параметр, который задается вручную пользователем и/или администратором системы.

С — статический параметр, который вшит в верстку. Им нельзя управлять, а изменить его может только верстальщик либо разработчик.

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

Данные этого исследования заносим в таблицу.

Напротив параметров указаны их свойства

5. Указываем способы взаимодействия для функций

Для них тоже задают условные обозначения. У нас они выглядят так:

0 — способ доступен без ограничений любому пользователю.

1 — способ доступен с ограничениями. На данном этапе неважно, с какими именно, главное, что ограничение есть и о нем нужно детально подумать при проектировании.

Способы взаимодействия обозначаются цифрами.

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

Если у объектов несколько состояний, мы используем пунктирную линию и указываем только отличия

Как это работает в моей компании

Описанную систему я периодически применяю уже несколько лет, а отдельные подходы ООД — более 6 лет. За это время мы увидели, какую пользу это приносит.

Получается точнее оценивать проекты

Раньше мы всегда работали по фиксированной цене и очень страдали, если ошибались с оценкой.

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

Обычно мы оценивали проект страницами, делали карту сайта, максимально детализировали ее, но могли не продумать отдельные части backend. «Кто будет верстать админку?», — спрашивал разработчик в самом конце. «В смысле верстать админку?», — удивлялись остальные.

Применение ООД помогло нам оценивать проекты на 20−25% точнее. А главное, у нас появился мост между оценкой проекта и началом работы. Если клиент возвращается через месяц после оценки, у нас уже есть упрощенная модель системы — базис для начала работы.

Помогаем стартапам экономить

Порой ребята из стартапов знают про разработку цифровых продуктов столько же, сколько я про балет, но при этом они очень хотят поиграть в product-менеджеров. Стартаперы вдохновляются известными проектами, просят нас прикрутить на сайт красивую функцию, которую видели в «Инстаграме» или на Airbnb, а потом узнают, что это стоит 500 000 ₽ и пугаются.

Наша задача — показывать таким заказчикам объективную реальность. Список объектов и параметров здорово в этом помогает. Можно сказать человеку: «Смотри, если добавить параметр X, цена вырастет на 100 000 ₽, а если убрать Y — снизится на 200 000 ₽». Обычно клиент счастлив, потому что минус 200 000 ₽ — всегда классно.

Мозговые штурмы стали эффективней

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

Берем профиль пользователя, кладем карточку на стол и всю встречу говорим только об одном объекте. Например, о том, как Вася взаимодействует с «вакансией». Клиент больше не отвлекается и не уходит в сторону. Раньше мозговые штурмы занимали 2,5−3 часа, а сейчас — 40−60 минут.

Появился обмен знаниями

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

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

Проще делать контент

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

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

Копирайтерам тоже важно подключаться к процессу на этапе проектирования. Раньше до начала разработки сайта они могли лишь продумать стратегию и tone of voice, а теперь берут на себя больше задач: придумывают структуру текстов по каждому объекту (теперь у них на старте есть знания о параметрах объектов и вариантах взаимодействия с ним), создают драфты, выдвигают свои требования и пожелания по формированию состава объектов.

Вместо заключения

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

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

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

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

Что почитать про ООД

Статьи об OOUX от Sophia V Prater

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

«Разработка требований к программному обеспечению» Карла Вигерса

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

«Пользовательские истории» Майка Кона

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

Источник