OSDev

Поясню на примере.
Вот у нас есть объект класса "Строка". Она внутри может быть представлена в разных кодировках. Также, несколько объектов могут иметь одинаковое содержимое, в таком случае им не надо заводить раздельные буфера для хранения содержимого, вполне достаточно разделять общий буфер. Программист может заменить отдельный символ в строке, в таком случае внутреннее устройство строки перед заменой выделит данной строке отдельный буфер, если он ранее разделялся разными экземплярами строк, а также этот символ будет автоматически приведён к нужной кодировке. Это - типичный пример абстрагирования от внутреннего устройства объекта.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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


Про маштабируемость фрагмент из книги Криса К http://www.insidepro.com/kk/012/012r.shtml



-----лучше не объяснить.

[code][/code]

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

Думаю, тут дело в том, что создание хорошего интерфейса -- задача не столько технически сложная (и интересная), сколько геморройная...

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

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

Если делать программу по уму. То это выливается вот во что. Надо сделать основу. Нужно подготовить входные данные, ресурсы. Эту основу надо оттестировать сделав безопасной. А после приделать интерфейс. И сделать документацию на программу и на интерфейс.
Проблема в том что разработка этих 5-6 пунктов по трудоёмкости сопоставимы.
Но самое обидное то что это 5 кратное повторение одного и того же разными словами, способами.

При занятости 1 час в сутки. И размере среднего проекта 100 функций. Имеем 3-6 месяца на написание кода и 1-2 лет на приведения его в порядок.

Во времена создания GNU это был крупный проект тогда все программы не превосходили 10-30 функций. Да и описание имелось. Поэтому время на переписывание UNIX ушло немного.
А вот с виндоусом всё хуже. Он гораздо крупнее. А энтузиастов мало.

Как результат все открытые проекты экономят - убирая лишне пункты. Отчего и появился BusFactor.
Другой вариант привлечение спонсоров. Разработчикам Blender неплохо это удаётся.

Самое удивительное это интерфейс blender'а. Как и любая CAD или любой 3D редактор он очень сложен в освоение. Хотя по сравнению с другими системами в нём многое продуманно лучше и осваивается он быстрее.

Если это "форма оплаты", то не понятно кто при этом получает выгоду.
Это конечно шутка, но в каждой шутке - доля шутки...