Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 106
Текст из файла (страница 106)
Указывайте видимость методов. Открытые методы доступны извне класса. Их интерфейсы должны быть опубликованы. Интерфейс открытого метода, который используется другими классами, изменить очень сложно, поэтому нужно стремиться свести количество таких методов к минимуму и тщательно продумывать их в процессе разработки. Скрытые методы находятся внутри класса, нх можно удалять или изменять, и эти действия никак не затронут другие классы. Защищенные методы обладают промежуточной степенью видимости (см. раздел 18.1).
Аккуратное использование видимости (раздел 4.1А) облегчает понимание классов и делает код более эластичным. Закрытые и защишенные методы скрывают ненужные детали от клиентов класса. В отличие от открытого метода, закрытый метод не может быть применен вне своего контекста, поэтому он может учитывать предусловия или информацию о состоянии класса. Скрывайте структуры данных.
Не экспортируйте структуры данных из метода. Внутренние структуры данных зависят от выбранного алгоритма. Если вы экспортируете их, вы не сможете впоследствии поменять алгоритм. Избегайте прослеживания нескольких связей и каскадных вызовов методов. Метод не должен иметь полного знания о модели классов. Он должен прослеживать связи со своими соседями и должен вызывать их метолы, но ему не следует прослеживать связь между его соседом и еще каким-либо классом, потому что эта связь не должна быть непосредственно видимой данному классу.
Вместо этого класс должен вызвать метод соседнего класса, 446 Глава 20 ° Стиль программирования если ему нужно обратиться к данным других классов. Если сеть ассоциаций изменится, изменения в методах будут минимальными. Не допускайте применения одного метода к результатам выполнения другого метода, если класс результата еще не доступен в виде атрибута, аргумента, соседнего класса или класса из библиотеки низкого уровня. Напишите новый метод в исходном целевом классе, чтобы он выполнял составной метод. Описанные принципы были предложены в работе ~1леЬегЬегг-89~.
° Не используйте множественное ветвление на основании типа объекта. Применяйте полиморфизм. Множественное ветвление можно использовать для проверки внутренних атрибутов объекта, но не для выбора поведения в зависимости от типа объекта. Выбор операций в зависимости от типа объекта — это самая суть полиморфизма, о чем забывать не следует. ° Проектируйте в расчете на переносимость. Системно-зависимые операции должны быть сконцентрированы в небольшом числе методов. Это облегчит перенос программного обеспечения на другие платформы. Например, при использовании базы данных можно изолировать доступ к ней. Это облегчит переключение на базу данных другого производителя и даже смену парадигмы (например, переход с реляционной базы данных на объектно-ориентированную).
20.4. Устойчивость Вы должны стремиться к эффективности методов, но не за счет устойчивости. Метод считается устойчивым, если он не вызывает аварийного завершения даже при получении некорректных параметров. Никогда не жертвуйте устойчивостью к ошибкам пользователя. ° Предусматривайте защиту от ошибок. Программа должна защищаться от некорректного ввода и не давать сбить себя с толку.
Методы должны проверять входные данные, которые могут вызвать ошибку. Ошибки бывают двух типов. Анализ позволяет обнаружить ошибки, которые существуют в предметной области. Для таких ошибок можно указать адекватную реакцию системы. Например, банкомат должен обрабатывать ошибки сканирования карт и ошибки сетевого взаимодействия. Существуют также низкоуровневые системные ошибки, связанные с программными аспектами.
К ним относятся ошибки выделения памяти, ошибки ввода-вывода, сбои аппаратного обеспечения. Программа должна контролировать возникновение системных ошибок и быть способной, по крайней мере, корректно завершить работу, если никакие другие действия уже не возможны. Старайтесь предотвращать ошибки программирования и включать в программу диагностическую информацию. В процессе разработки бывает полезно вставлять в программу утверждения, которые помогут отыскивать ошибки. Впоследствии проверочные операции можно будет удалить для повышения эффективности работы.
Языки с жесткой типизацией предоставляют 20. 1. Устойчивость 447 более належную защиту от ошибок, связанных с несоответствием типов, а контрольные утвержления можно использовать в любом языке. В частности, не забывайте о проверке границ массивов. Оптимизируйте программу только после того, как она заработает. Не занимайтесь оптимизацией, пока программа не начнет работать. Часто программисты тратят слишком много времени на оптимизацию кода, который выполняется относительно редко. Измерьтс производительность отдельных частей программы.
Чаще всего большую часть времени программа тратит на выполнение небольшого набора операций, Изучите приложение чтобы понять, какие критерии производительности для вас важны, например производительность в худшем случае или частота вызова методов. Если метол может быть реализован несколькими способами, оцените альтернативы по затратам памяти и времени с учетом простоты реализации. Старайтесь избегать избыточной оптимизации, так как любая оптимизация снижает расширяемость, возможность повторного использования и понятность кода. Если методы инкапсулированы правильно, вы сможете заменить их оптимизированными версиями, не меняя других частей программы.
Создавайте объекты сразу в корректном состоянии [Уегшец!еп-00). В противном случае кто-нибудь может вызвать конструктор, а после него не вызвать нужный инициализирующий метод. Код всегда должен быть логически безупречным, это тоже одно нз правил хорошего стиля в программировании. Проверяйте аргументы. Открытые методы, доступные клиентам класса, должны досконально проверять передаваемые аргументы, потому что клиенты могут нарушать подразумеваемые ограничения.
Эффективность закрытых и защищенных методов можно повысить, если предположить, что их аргументы имеют корректные значения. При реализации закрытых методов можно положиться на то, что все необходимые проверки осуществляются в открытых методах. Не пишите свои и не используйте чужие методы, аргументы которых невозможно проверить.
Например, печально известная функция эсад в ПЫ1Х считывает строку во внутренний буфер, не проверяя размер этого буфера. Этот недостаток используется для написания вирусов, вызывающих переполнение буфера в программном обеспечении, которое не осуществляет самостоятельной проверки аргументов. Исключайте предопределенные ограничения.
Везде, где это возможно, используйте динамическое выделение памяти для создания структур данных без предопределенных ограничений. Предсказать максимальную емкость структур данных в приложении достаточно сложно, поэтому не устанавливайте вообше никаких пределов. Время жестких ограничений на количество записей в таблице символов, на имена пользователей и файлов должно было давно закончиться. Большинство объектно-ориентированных языков предоставляют отличные средства динамического выделения памяти.
Снабжайте программу средствами для отладки и контроля производительности. Подобно тому, как проектировщики интегральных схем снабжают 448 Глава 20 ° Стиль программирования их контрольнгями точками, вы должны встраивать в свой код средства для тестирования, отладки, сбора статистики и контроля производительности. Уровень средств зависит от используемой среды программирования. Вы можете вставить отладочные операторы в методы, запуск которых будет зависеть от установленного уровня отладки. Отладочные операторы могут выводить сообщения при запуске и завершении работы метода, а также печатать выборочные значения переменных.
Для облегчения понимания поведения классов в них можно добавить код, осуществляющий сбор статистических данных. Некоторые операционные системы (в частности, 13Н1Х) предос гавляют средства для профилирования выполнения приложения. Обычно эти средства возвращают информацию о количестве вызовов каждого метода и затратах времени на его выполнение. Если в вашей системе подобные средства отсутствуют, вы можете встроить их в код самостоятельно. 20.5. Программирование крупных систем Программирование крупных систем — это создание крупных программных комплексов командами программистов. В таких проектах первостепенной задачей становится обеспечение взаимодействия сотрудников, для чего используются соответствующие методики конструирования программного обеспечения.
Помимо них вы можете руководствоваться следующими общими правилами хорошего стиля. ° Не начинайте программировать раньше времени. Продумывайте систему как можно дольше н тщательнее н только потом воплощайте ее в код. В конце концов, код все равно придется написать, чтобы создать приложение.
Но писать код тяжело, а вносить в него изменения еше сложнее. Модели гораздо более «податливы», поскольку они разрабатываются на высоком уровне и не содержат лишних деталей. Гораздо лучше проработать свои идеи в моделях, достичь полного понимания системы и только затем переходить к написанию кода. ° Делайте методы удобочитаемыми. Осмысленные имена переменных повышают удобочитаемость метода. Затраты на ввод нескольких лишних символов значительно меньше, чем на устранение последствий неправильного понимания вашего кода другим программистом. Не используйте непонятных сокращений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
