1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой
1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой
Даже простейшую процедурную логику трудно проверить, однако весьма сложные структуры данных являются довольно простыми для моделирования и анализа. Для того чтобы убедиться в этом, достаточно сравнить выразительную и дидактическую силу диаграммы, например, дерева указателей, имеющего 50 узлов с блок-схемой программы, состоящей из 50 строк кода. Или сравнить инициализатор массива, выражающий таблицу преобразования, с эквивалентным оператором выбора. Различие в прозрачности и ясности поразительно. См. правило 5 Роба Пайка.
Данные более "податливы", чем программная логика. Это означает, что если можно выбирать между сложностью структуры данных и сложностью кода, следует выбирать первое. Более того, развивая проект, следует активно искать пути перераспределения сложности из кода в данные.
Первые оценки этого факта не связаны с Unix-сообществом, но множество примеров Unix-кода отражают его влияние. В частности, средство языка С, манипулирующее указателями, способствовало использованию динамически модифицируемых ссылочных структур на всех уровнях кода, начиная с ядра. Простое отслеживание указателей в таких структурах часто выполняет такие задачи, которые в других языках потребовали бы внедрения более сложных процедур.
Данные методики также описываются в главе 9.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
37. Открытое наследование означает заменимость. Наследовать надо не для повторного использования, а чтобы быть повторно использованным
37. Открытое наследование означает заменимость. Наследовать надо не для повторного использования, а чтобы быть повторно использованным РезюмеОткрытое наследование позволяет указателю или ссылке на базовый класс в действительности обращаться к объекту некоторого
1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами
1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск
1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами
1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix
1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей
1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на
1.6.7. Правило прозрачности: для того чтобы упростить проверку и отладку программы, ее конструкция должна быть обозримой
1.6.7. Правило прозрачности: для того чтобы упростить проверку и отладку программы, ее конструкция должна быть обозримой Поскольку отладка часто занимает три четверти или более времени разработки, раннее окончание работы в целях облегчения отладки может быть очень
1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить"
1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить" Одно из старейших и наиболее постоянных правил проектирования в Unix гласит: если программа не может "сказать" что-либо интересное или необычное, то ей следует
1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"
1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути" Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных
Правило 29: Стремитесь, чтобы программа была безопасна относительно исключений
Правило 29: Стремитесь, чтобы программа была безопасна относительно исключений Безопасность исключений в чем-то подобна беременности… но пока отложим эту мысль в сторонку. Нельзя всерьез говорить о репродуктивной функции, пока не завершился этап ухаживания.Предположим,
Правило 45: Разрабатывайте шаблоны функций-членов так, чтобы они принимали «все совместимые типы»
Правило 45: Разрабатывайте шаблоны функций-членов так, чтобы они принимали «все совместимые типы» Интеллектуальные указатели – это объекты, которые ведут себя во многом подобно обычным указателям, но добавляют функциональность, которую последние не предоставляют.
1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами
1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск
1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами
1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix
1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей
1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на
1.6.7. Правило прозрачности: для того чтобы упростить проверку и отладку программы, ее конструкция должна быть обозримой
1.6.7. Правило прозрачности: для того чтобы упростить проверку и отладку программы, ее конструкция должна быть обозримой Поскольку отладка часто занимает три четверти или более времени разработки, раннее окончание работы в целях облегчения отладки может быть очень
1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой
1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой Даже простейшую процедурную логику трудно проверить, однако весьма сложные структуры данных являются довольно простыми для моделирования и
1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"
1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути" Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных