lipa44, по описанию - вы мечетесь с несколькими довольно разными вопросами.
Насчет архитектуры - правильное использование ООП именно в том, чтобы давать классам ровно столько данных, сколько им реально нужно для работы, и не давать им никакой информации о том, как реализованы внутри другие классы.
У вас, как я понимаю, главная проблема в том, что все эти решатели и поворачиватели все равно работают со всеми данными состояния, влезая в них по локоть. Не получается инкапсуляция, не работает логика ООП. Так может, вам и не нужно делить эту общую работу с едиными данными на разные классы?
lipa44, вам не нужны геттеры и сеттеры.
Например, для поворота грани вам не нужны цвета всех сторон кубика. Нужна только таблица цветов 5x5 с пустыми углами. В результате получится другая таблица, которую можно вернуть классу состояния кубика. А еще получится, что логика настолько элементарна, что создавать под нее целый класс плюс геттер с сеттером бессмысленно, достаточно создать метод поворота грани. А классу решения уже не потребуются сеттеры для того, чтобы повернуть грань, не так ли?
Валентин, например, потому, что с тех пор, как написан этот скрипт, у Убунты сменилась старшая LTS-версия. А он по-прежнему делает нужную настройку системы под работу в офисе.
И нет, если бы я делал это действительно часто, это доросло бы до Анзибла. А раз в полгода - достаточно простого скриптика.
Валентин, вы это рассказываете человеку, у которого скрипт начальной настройки нового компьютера для офиса включает прописывание MIME-типов для двух типов файлов. Именно по расширению, потому что по содержимому один из этих форматов система считает бинарным файлом, а второй - распространенным графическим, но при этом слегка ошибается.
kpb, результаты всяких поделок на коленке непредсказуемы. Есть Illustrator или свободный Inkscape - они должны создавать PDF в соответствии со стандартом.
Uneasy Hearts Weigh the Most, шаблон страницы для печати может серьезно отличаться от веб-представления.
Особенно если хочется сделать круто, в фирменном стиле, чтобы выдавать клиенту эту распечатку с пафосом.
Будет проще разделить, чем пытаться скрещивать.
pfemidi, терминологический спор, имхо.
Если файлу именно на основании того, что у него в имени после точки, можно назначить иконку в ФМ и программу, которая открывает его по умолчанию, почему бы не называть это именно расширением? Никакой другой магии в этот термин никто вроде бы и не вкладывал.
pfemidi, понятие "тип файла" есть, только оно не привязано жестко к расширению, как в винде - но MIME-типы позволяют только определить, какой программой этот файл нужно открывать. К исполняемости они никакого отношения не имеют.
Могут быть две вполне объективные причины писать свой крон:
1. Хочется запускать задачи по расписанию, в котором квант времени меньше минуты.
2. Хочется скрыть всю эту деятельность от администратора системы.
Просто давайте не путать самописную CRM под одну конкретную фирму, где просто автоматизируются ее процессы, и самописную CRM под какой-то спектр бизнеса, где прорва абстракций, настроек, возможностей кастомизации - да еще и документации по этому всему.
Разница в сложности - как между лендингом и магазином.
Поэтому в лоб сравнивать местечковые костыли и популярные платформы по трудозатратам на них совершенно нелепо.
Насчет архитектуры - правильное использование ООП именно в том, чтобы давать классам ровно столько данных, сколько им реально нужно для работы, и не давать им никакой информации о том, как реализованы внутри другие классы.
У вас, как я понимаю, главная проблема в том, что все эти решатели и поворачиватели все равно работают со всеми данными состояния, влезая в них по локоть. Не получается инкапсуляция, не работает логика ООП. Так может, вам и не нужно делить эту общую работу с едиными данными на разные классы?