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

Чтобы роботы не сканировали отдельные страницы, иногда используют метатег robots. Не все поисковые системы придают значение таким метатегам.

Альтернативный текст alt в теге img индексируется многими поисковыми системами.

Графические изображения в верхней части страницы более значимы, нежели изображения в нижней части страницы.

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

Плотность ключевых слов (keyword density) – мера определения количества ключевых слов на единицу текста: плотность ключей = количество ключей на странице / общее количество слов на странице.

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

Некоторые поисковые системы не учитывают плотность ключевых слов на странице.

Подсвечивание ключевых слов в результатах поиска – highlighting.

Многие поисковики считают текст гиперссылки (anchor text) релевантным, им нравится возможность записать текст и внутри, и вокруг ссылок.

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

Активный текст – clickable.

Пользователей чаще привлекают шрифты, которых нет в установках по умолчанию.

Поисковики обычно не переходят по сенсорным изображениям (image map).

Главное преимущество выпадающих меню (drop-down menu) – экономия пространства на странице. Специалисты по юзабилити не рекомендуют использовать выпадающее меню.

Перекрестная ссылка (cross-linking) действует внутри сайта, связывая его страницу с другой его же страницей.

Продвижение ссылок (link development) связывает один сайт с совершенно другим сайтом.

Должны быть ясные ориентационные подсказки типа you are there («вы сейчас здесь») с ключами.

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

? – знак динамического URL. В динамическом URL желательно минимизировать число параметров.

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

Поисковые роботы автоматически конвертируют относительные ссылки в абсолютные.

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

Проблемные символы URL?, &, $,=, +, % можно заменить»,» и '/».

Дорвеи (doorway) – одна из форм спама. А информационные страницы приемлемы для поисковиков и интернет-каталогов. Тексты дорвеев предназначены для достижения лидирующих позиций и генерируются компьютерами. Информационные страницы, напротив, целенаправленно стремятся удовлетворить посетителей сайта, поскольку содержат полезную и интересную информацию. Дорвеи применяют redirect, поэтому нуждаются в клоакинге (cloaking).

searchenginewatch.com.

Поисковики не включают страницы с идентификатором сеанса в URL в индексы.

robots. txt – протокол запрета сканирования (robots exclusion protocol). Протокол запрета сканирования нужно размещать на сервере до размещения запрещенного им контента, чтобы избежать появления ненужной информации в результатах поиска.

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

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

«Фермы ссылок» – free-for-all link farms.

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

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

Нельзя дублировать тег title.

Страницы с фреймами снабжайте тегом noframes.

Поисковики снижают релевантность текста внутри noscript и noframes.

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

С отказом от фреймов поток посетителей, приходящих из поисковых систем, обычно возрастает.

Коэффициент рентабельности – return on investment, ROI.

Для подозрительных ссылок задавайте атрибут nofollow.

Формат GIF поддерживается практически всеми броузерами.

Около 15—20% всех запросов в поисковых системах имеют отношение к графическим изображениям.

Для графики важно название файла.

Полезные высказывания из книги «Совершенный код» Макконнелла

В разделе приведены цитаты из [12].

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

Для широкого распространения исследовательских разработок требуется от 5 до 15 и более лет.

Ежегодно программистами становятся около 50000 человек.

Число дипломов, вручаемых в отрасли, около 35000.

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

Сайт книги cc2e.com/1234.

Конструирование ПО = кодирование.

На конструирование приходится 65% в больших проектах.

Во время конструирования допускается от 50 до 75% ошибок в больших проектах.

Ошибки конструирования дешевле исправлять.

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

При написании программы только этапа конструирования нельзя избежать.

Почта и сайт автора: stevencc@construx.com, stevemcconnell.com.

Книги никогда не создаются в одиночку.

Составляющие разработки ПО за последние 25 лет:

– определение проблемы;

– выработка требований;

– создание плана конструирования;

– разработка архитектуры ПО, или высокоуровневое проектирование;

– детальное проектирование;

– кодирование и отладка;

– блочное тестирование;

– интеграционное тестирование;

– интеграция;

– тестирование системы;

– корректирующее сопровождение.

Проекты бывают формальные, неформальные.

Конструирование не включает определение проблемы.

Конструирование = программирование.

В центре конструирования – кодирование и отладка.

Конкретные задачи, связанные с конструированием:

1. Проверка выполнения условий, необходимых для успешного конструирования.

2. Определение способов последующего тестирования кода.

3. Проектирование и написание классов и методов.

4. Создание и присвоение имен переменным и именованным константам.

5. Выбор управляющих структур и организация блоков команд.

6. Блочное тестирование, интеграционное тестирование и отладка собственного кода.

7. Взаимный обзор кода и низкоуровневых программных структур членами группы.

8. «Шлифовка» кода путем его тщательного форматирования и комментирования.

9. Интеграция программных компонентов, созданных по отдельности.

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

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

На конструирование обычно уходит 30—80% времени работы.

Требования к приложению и архитектура разрабатываются, чтобы гарантировать эффективность этапа конструирования.

Тестирование системы выполняется после конструирования, чтобы проверить его правильность.

Производительность труда отдельных программистов во время конструирования изменяется в 10—20 раз.

Исходный код – самая свежая документация на ПО.

Тестирование системы должно контролироваться статистически.

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

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

Метафоры позволяют лучше понять разработку ПО.

Использование метафор (аналогий) – моделирование.

Эффективность моделей объясняется их яркостью и концептуальной целостностью.

При чрезмерном обобщении модели вводят в заблуждение.

Хорошие метафоры простые, согласуются с другими метафорами и объясняют многие данные и явления.

Описываемое метафорами поведение предсказуемо и понятно всем людям.

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

90% общего объема работы над программной системой выполняется после выпуска первой версии.

Популярные метафоры о разработке ПО:

1. Написание письма.

2. Выращивание сельскохозяйственных культур.

3. Процесс формирования жемчужины.

4. Построение дома (невыгодно писать компоненты, которые можно купить готовыми).

Программная система из 1 млн строк требует 69 видов документации, спецификация требований занимает 4000—5000 страниц.

В неудачных проектах конструирование приходится выполнять несколько раз.

Вайнберг «The psychology of computer programming».

Хороших программистов всегда не хватает.

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

– требования довольно стабильны;

– проект приложения прост и относительно понятен;

– группа разработчиков знакома с прикладной областью;

– проект не связан с особым риском;

– важна долговременная предсказуемость проекта;

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

Итеративный подход (вопросы решаются по мере работы) применяется, когда:

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

– проект приложения сложен, не совсем ясен или и то и другое;

– группа разработчиков незнакома с прикладной областью;

– проект сопряжен с высоким риском;

– долговременная предсказуемость проекта не играет особой роли;

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

Итеративные подходы эффективны чаще.

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

Процесс программирования:

1) определение проблемы;

2) выработка требований;

3) вроектирование архитектуры;

4) конструирование;

5) тестирование системы;

6) будущие улучшения.

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

Требования подробно описывают, что должна делать программная система.

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

Процесс разработки помогает разработчикам и клиентам лучше понять свои потребности.

В среднем проекте требования во время разработки изменяются на 25%, на что приходится 80% повторной работы над проектом.

Изменение требований влечет пересмотр графика и сметы.

evolutionary prototyping – поставка системы клиенту по частям.

Определить моменты прекращения работы над проектом.

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

Интерфейс проектируется на этапе выработки требований либо в архитектуре.

Архитектура должна быть модульной.

Архитектура определяет подходы к безопасности.

В требованиях определяются показатели производительности.

Масштабируемость – возможность системы адаптироваться к росту требований.

Интернационализация – реализация в программе поддержки региональных стандартов.

Локализация – перевод интерфейса программы и реализация в ней поддержки конкретного языка.

Архитектура выражает отношение к избыточной функциональности.

Архитектура четко описывает стратегию изменений.

В архитектуре должны быть обоснованы важнейшие принятые решения.

Цели должны быть четко сформулированы.

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

В проекте без проблем работа над требованиями, архитектурой и предварительным планированием поглощает 20—30% времени.

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

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

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

Ada, Cobol используются в Минобороны США.

SQL – декларативный язык.

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

Важный аспект работы проектировщика – анализ конкурирующих характеристик проекта и достижение баланса между ними.

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

Существенные свойства – которыми объект должен обладать, чтобы быть именно этим объектом.

Несущественные (акцидентные) свойства – которые не влияют на суть объекта.

Управление сложностью – самый важный аспект разработки ПО.

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

Цель всех методик проектирования ПО – разбиение сложной проблемы на простые фрагменты.

Краткость методов помогает снизить нагрузку на интеллект.

Этому же способствует написание программы в терминах проблемной области, а также работа на самом высоком уровне абстракции.

Как бороться со сложностью? Чаще всего причинами неэффективности являются:

– сложное решение простой проблемы;

– простое, но неверное решение сложной проблемы;

– неадекватное сложное решение сложной проблемы.

Дейкстра: «Сложность современного ПО обусловлена самой его природой».

Двойственный подход к управлению сложностью:

– старайтесь свести к минимуму объем существенной сложности, с которым придется работать в каждый конкретный момент времени;

– сдерживайте необязательный рост несущественной сложности.

Внутренние характеристики проекта:

– минимальная сложность;

– простота сопровождения;

– слабое сопряжение;

– расширяемость;

– возможность повторного использования;

– система предусматривает интенсивное использование вспомогательных низкоуровневых классов;

– класс использует минимальное число других классов;

– портируемость;

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

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

– соответствие стандартным популярным подходам.

Уровни детальности проектирования программной системы:

– вся система;

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

Отношения между системами должны быть простыми.

В порядке уменьшения простоты:

1) одна подсистема вызывает методы другой;

2) одна подсистема содержит классы другой;

3) наследование классов одной подсистемы от классов другой.

Программа не должна содержать циклических отношений.

Часто используемые подсистемы:

– бизнес-правил;

– пользовательского интерфейса;

– доступа к БД;

– изоляции зависимостей от ОС.

Разделение подсистем на классы обычно требуется во всех проектах.

Объект – динамическая сущность, класс – статическая.

БД: различие между классом и объектом аналогично различию между «схемой» и «экземпляром».

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

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

При проектировании с использованием искусственных объектов и объектов реального мира определите:

– объекты и их атрибуты (методы и данные);

– действия, которые могут быть выполнены над каждый объектом;

– действия, которые каждый объект может выполнять над другими объектами (включение и наследование);

– части каждого объекта, видимые другим объектам, то есть открытые и закрытые части;

– открытый интерфейс каждого объекта (на уровне языка программирования).

Открытый интерфейс – данные и методы, которые объект предоставляет в распоряжение остальным объектам.

Защищенный интерфейс – части объекта, доступные производным от него объектам.

2 вида итерации:

– высокоуровневая, направленная на улучшение организации классов;

– на уровне определенных классов, направленная на детализацию проекта каждого класса.

Дом – абстракция его составляющих.

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

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

Создавать абстракции на уровне интерфейсов методов, интерфейсов классов и интерфейсов пакетов.

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

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

Поддержка языком операций вроде Open () или Close () при отсутствии информации о конкретном типе двери вплоть до периода выполнения называется полиморфизмом.

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

Разработка интерфейса класса – итеративный процесс (пытаться создать или использовать другой подход).

Сокрытие аспектов проектирования позволяет значительно уменьшить объем кода, затрагиваемого изменениями (например, применение именованных констант вместо литералов; сокрытие информации: «id=new Id ();" вместо «id=++g_maxId;»).

Категории секретов:

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

– секреты, которые скрывают источники изменений с целью локализации результатов возможных изменений.

Барьеры, препятствующие сокрытию информации:

– избыточное распространение информации (например, использование литералов вместо констант, распространение кода взаимодействия с пользователем по системе – GUI концентрировать в одном классе (пакете, подсистеме));

– круговая зависимость (B зависит от А, который зависит от B; не позволяет протестировать один класс, пока не будет готова часть другого);

– ошибочное представление о данных класса как о глобальных данных;

– кажущееся снижение производительности.

Крупные программы, использующие сокрытие информации, в 4 раза легче модифицировать, чем программы, его не использующие.

Размышлять о том, что скрыть.

Подготовка к изменениям:

1. Определите элементы, изменение которых кажется вероятным.

2. Изолируйте элементы, изменение которых кажется вероятным.

Интерфейс класса должен скрывать изменения в классе.

Области, изменяющиеся чаще всего:

– бизнес-правила;

– зависимости от оборудования;

– ввод-вывод;

– нестандартные возможности языка;

– сложные аспекты проектирования и конструирования;

– переменные статуса.

В качестве переменных статуса применять не булевые переменные, а перечисления.

Вместо непосредственной проверки переменной использовать методы доступа.

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

Если изменение маловероятно, но его легко предугадать, рассмотрите его внимательнее, чем более вероятное изменение, которое трудно спланировать.

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

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

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

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

Слабое сопряжение (loose coupling) – классы и методы имеют немногочисленные, непосредственные, явные и гибкие отношения с другими классами.

Эффективный механизм соединения максимально прост.

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

Критерии оценки сопряжения:

– объем связи (число соединений между модулями – число параметров метода, число открытых методов);

– видимость (заметность связи между двумя модулями);

– гибкость (легкость изменения связи между модулями).

Самые распространенные виды сопряжения:

– простое сопряжение посредством данных-параметров (передача элементарных типов данных через списки параметров);

– простое сопряжение посредством объекта (модуль создает экземпляр объекта, с которым сопряжен);

– сопряжение посредством объекта-параметра (объект 1 требует, чтобы объект 2 передал ему объект);

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

Классы и методы должны упрощать работу.

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

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

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

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

Шаблоны проектирования – эффективный инструмент управления сложностью.

Шаблон – это эвристический принцип.

Связность (cohesion) должна быть максимальна.

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

Формируйте иерархии.

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

Люди в целом находят иерархии естественным способом организации сложной информации.

Рисуя сложный объект, люди рисуют его иерархически.

Формализовать контракты классов (обещания клиентов – предусловия, обязательства класса – постусловия).

Грамотно назначать сферы ответственности.

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

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

Тщательно выбирать время присвоения переменной конкретного значения (binding time).

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

Рисовать диаграммы – они представляют проблему на более высоком уровне абстракции.

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

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

Проектирование – итеративный процесс. После его завершения нужно возвращаться к началу.

Лучше обнаруживать варианты, которые не работают, чем ничего не делать.

Нисходящее (top-down) проектирование начинается на высоком уровне абстракции.

Восходящее (bottom-up) начинается со специфики и постепенно переходит ко все большей общности.

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

Нисходящая стратегия – декомпозиция.

Восходящая – композиция.

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

Прототипирование работает плохо, если задача недостаточно конкретна.

Имена прототипных классов и пакетов должны иметь префикс prototype.

Механические действия вытесняют творчество.

Регистрировать протоколы обсуждения проекта и принятые решения при помощи Wiki.

Отправлять резюме дискуссий всем членам группы по электронной почте.

Фотографировать схемы на доске.

Хранить плакаты со схемами проекта.

Использовать UML.

Класс – это набор данных и методов, имеющих общую, целостную, хорошо определенную сферу ответственности.

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

Абстрактный тип данных – это набор, включающий данные и выполняемые над ними операции (служащие одной цели).

Преимущества использования АТД:

– возможность сокрытия деталей реализации;

– ограничение области изменений;

– более высокая информативность интерфейса;

– легкость оптимизации кода;

– легкость проверки кода;

– удобочитаемость и понятность кода;

– ограничение области использования данных;

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

Принципы использования АТД:

– представлять в форме АТД распространенные низкоуровневые типы данных;

– представлять в форме АТД часто используемые объекты, такие как файлы;

– представлять в форме АТД даже простые элементы;

– обращайтесь к АТД так, чтобы это не зависело от среды, используемой для его хранения.

В ООП каждый АТД можно реализовать как класс (класс дополнительно поддерживает наследование и полиморфизм).

Интерфейс класса – это абстракция реализации класса, скрытой за интерфейсом.

Принципы проектирования интерфейсов:

– выражать в интерфейсе класса согласованный уровень абстракции (смешанные уровни абстракции делают программу все менее и менее понятной);

– убедиться в понимании того, реализацией какой абстракции является класс;

– представляйте методы вместе с противоположными им методами (создавать противоположные методы, не имея на то причин, не следует);

– убирать постороннюю информацию в другие классы;

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

– элементы интерфейса должны находиться на одном уровне абстракции;

– не включать в класс открытые члены, плохо согласующиеся с абстракцией интерфейса;

– рассматривать абстракцию и связность вместе.

Хорошая инкапсуляция:

– минимизировать доступность классов и их членов;

– не делать данные-члены открытыми;

– не включать в интерфейс класса закрытые детали реализации;

– класс не должен делать предположений о том, как этот интерфейс будет или не будет использоваться;

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

– не делать метод открытым лишь потому, что он использует только открытые методы;

– ценить легкость чтения кода выше, чем удобство его написания;

– избегать зависимости клиентского кода от закрытой реализации класса, а не от его открытого интерфейса (должен быть интерфейс, позволяющий разобраться, не глядя на реализацию);

– остерегаться жесткого сопряжения – сильной связи между двумя классами.

Включение (containment) – один класс содержит примитивный элемент данных или другой класс.

Включение проще наследования и меньше подвержено ошибкам.

Включение можно реализовать отношением «содержит» (в крайнем случае – закрытое наследование).

Класс должен содержать 9 примитивных типов или 5 сложных объектов.

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

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

Наследование повышает сложность программы.

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

Убедиться, что наследуется только то, что нужно.

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

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

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

С подозрением относитесь к базовым классам, имеющим только один производный класс.

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

Избегайте многоуровневых иерархий наследования, ограничивая иерахии наследования максимум 6 уровнями.

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

Делайте все данные закрытыми, а не защищенными.

Миксин – простой класс, позволяющий добавлять ряд свойств в другой класс.

Ромбовидная схема наследования – классическая проблема.

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

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