Куда их совать-то?

Та же проблема, что и в анекдоте про свечки, существует в программировании и особенно в ООП языках. Допустим есть у нас набор объектов, скажем драйверы разных графических адаптеров. И другой набор объектов, скажем графические примитивы: линии, окружности, многоугольники. И решили мы нарисовать одно на другом. И написали для этого код. Всё уже почти работает, но перед нами встала архитектурная проблема: куда засунуть метод? В C#, например, функция должна быть в классе. Можно определить, конечно, класс с одним (или несколькими) статическим методами, но заклюют за недостаток архитектурности. Можно засунуть в графический примитив. Сделать у каждого метод Draw. А можно наоборот, в драйвере сделать виртуальные DrawLine и DrawCircle. Оба решения имеют недостатки. Например, примитивы могут быть вообще не классами, а структурами и методы рисования на конкретного вида устройствах там создают ненужные зависимости. А драйверы потому и драйверы, что не содержат всякой высокоуровневой логики. Надо сделать визитора, скажут прочитавшие Design Patterns или wrappers для примитивов, или ещё один уровень поверх драйверов, и понеслось. Что интересно, раздумья эти с точки зрения выполнения кода не очень интересны, код всё равно будет один и тот же. Это скорее предмет для бурного обсуждения на API review meeting. Что наводит на мысль, что это вообще ненужное размышление. Это плата за ООП и его упрощённую модель, когда метод принадлежит только одному классу. Логически у нас есть операция нарисовать одно на другом и некоторая матрица кодов, которые выбираются исходя из некоторых условий. Старый С-программист сделал бы функцию a la printf с форматной строкой и большим switch внутри и не был бы сильно неправ. Компьютер бы полюбил такой код за компактность, но архитект бы поморщился от такой примитивности и неархитектурности. Независимый С++-программист просто написал бы набор функций. Я не буду сейчас пока описывать как я представляю хорошее решение данного примера на разных языках. Моя мысль дня была в том, что ненужные с точки зрения кода рассуждения вероятно не нужны вообще и их наличие - недостаток архитектуры. А навеян пост продолжением чтения книжки про Руби и обнаружением в классе numeric метода, повторяющего блок N раз. Блин, оператор цикла - метод в классе целого числа. Зачем он вообще метод? "А потому!" - скажет автор, и будет по-своему, по-авторски, прав. Хочу тоже быть автором.