Искусство программирования для Unix
Шрифт:
Искусство программирования для Unix
Вдохновившим меня Кену Томпсону и Деннису Ритчи
Предисловие
Для кого предназначена эта книга
Как использовать эту книгу
Дополнительные источники информации
Соглашения, используемые в данной книге
Учебные примеры
Авторские благодарности
Часть I Контекст
1 Философские вопросы
1.1. Культура? Какая культура?
1.2. Долговечность Unix
1.3. Доводы против изучения культуры Unix
1.4.
1.5. Что в Unix делается верно
1.5.1. Программное обеспечение с открытым исходным кодом
1.5.2. Кроссплатформенная переносимость и открытые стандарты
1.5.3. Internet и World Wide Web
1.5.4. Сообщество открытого исходного кода
1.5.5. Гибкость на всех уровнях
1.5.6. Особый интерес исследования Unix
1.5.7. Уроки Unix применимы в других операционных системах
1.6. Основы философии Unix
1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами
1.6.2. Правило ясности: ясность лучше, чем мастерство
1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами
1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей
1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо
1.6.6. Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается
1.6.7. Правило прозрачности: для того чтобы упростить проверку и отладку программы, ее конструкция должна быть обозримой
1.6.8. Правило устойчивости: устойчивость-следствие прозрачности и простоты
1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой
1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы
1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить"
1.6.12. Правило исправности: когда программа завершается аварийно, это должно происходить явно и по возможности быстро
1.6.13. Правило экономии: время программиста стоит дорого; поэтому экономия его времени более приоритетна по сравнению с экономией машинного времени
1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ
1.6.15. Правило оптимизации: создайте опытные образцы, заставьте их работать, прежде чем перейти к оптимизации
1.6.16. Правило разнообразия:
1.6.17. Правило расширяемости: проектируйте с учетом изменений в будущем, поскольку будущее придет скорее, чем кажется
1.7. Философия Unix в одном уроке
1.8. Применение философии Unix
1.9. Подход также имеет значение
2 История: слияние двух культур
2.1. Истоки и история Unix, 1969—1995 гг.
2.1.1. Начало: 1969-1971 гг.
2.1.2. Исход: 1971-1980 гг.
2.1.3. TCP/IP и Unix-войны: 1980-1990 гг.
2.1.4. Бои против империи: 1991—1995 гг.
2.2. Истоки и история хакерской культуры, 1961-1995 гг.
2.2.1. Академические игры: 1961 — 1980 гг.
2.2.2. Internet и движение свободного программного обеспечения: 1981—1991 гг.
2.2.3. Linux и реакция прагматиков: 1991—1998 гг.
2.3. Движение открытого исходного кода: с 1998 года до настоящего времени
2.4. Уроки истории Unix
3 Контраст: сравнение философии Unix и других операционных систем
3.1. Составляющие стиля операционной системы
3.1.1. Унифицирующая идея операционной системы
3.1.2. Поддержка многозадачности
3.1.3. Взаимодействующие процессы
3.1.4. Внутренние границы
3.1.5. Атрибуты файлов и структуры записи
3.1.6. Двоичные форматы файлов
3.1.7. Предпочтительный стиль пользовательского интерфейса
3.1.8. Предполагаемый потребитель
3.1.9. Входные барьеры для разработчика
3.2. Сравнение операционных систем
3.2.1. VMS
3.2.2. MacOS
3.2.3. OS/2
3.2.4. Windows NT
3.2.5. BeOS
3.2.6. MVS
3.2.7. VM/CMS
3.2.8. Linux
3.3. Все повторяется
Часть II Проектирование
4 Модульность: четкость и простота
4.1. Инкапсуляция и оптимальный размер модуля
4.2. Компактность и ортогональность
4.2.1. Компактность
4.2.2. Ортогональность
4.2.3. Правило SPOT
4.2.4. Компактность и единый жесткий центр
4.2.5. Значение освобождения
4.3. Иерархичность программного обеспечения
4.3.1. Сравнение нисходящего и восходящего программирования
4.3.2. Связующие уровни
4.3.3. Учебный пример: язык С считается тонким связующим уровнем
4.4. Библиотеки
4.4.1. Учебный пример: подключаемые подпрограммы GIMP
4.5. Unix и объектно-ориентированные языки
4.6. Создание модульного кода
5 Текстовое представление данных: ясные протоколы лежат в основе хорошей практики
5.1. Важность текстовой формы представления