main в ООП == god object?

Если я сделаю функцию main, которая создает экземпляр одного класса, сует в него данные, получает результат вычисления, засовывает в экземпляр другого класса, и тот принтит результат как надо, разве эта функция main - не god object

Нет, всем занимаются сторонние классы. На мой взгляд, суть main в утилите - обработать аргументы командной строки (без лишних велосипедов), затем отправить данные в другие процедуры и классы.

Все дело в обязанностях. Идеал: один объект, одна обязанность ...

Очень сложно. Я не понимаю, как это сделать красиво и не понимаю, как заворачивать задачи для потоков в классы, чтобы сделать заебись.

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

Если я сделаю функцию main, которая создает экземпляр одного класса, сует в него данные, получает результат вычисления, засовывает в экземпляр другого класса, и тот принтит результат как надо

Шозабред. Классы нужны, когда есть состояние. Какое состояние у алгоритма поиска пути? Или у принтера?

Алгоритм с потоками и очередью творит всякие непотребства.

Нет такого, что «блабла» это просто плохо (или просто хорошо). Всегда есть причины, по которым это плохо. И, раз кто-то это вообще придумал и использовал, есть причины, по которым это хорошо. Вот и взвешивай эти плюсы и минусы конкретно в твоём случае, а не следуй догмам. Программирование это не христианство с семью заповедями. Это инженерная дисциплина.

У тебя между двумя вызовами поиска пути сохраняется какое-то состояние? O_O

У принципов программирования сотня разных трактований, прямо как у библии.

Используй stl и исключения, stl - дар божий. Почему их использовать? Потому что так сказал Страуструп, он боженька. А почему он боженька? Так в стандарте написано.

Один вызов ищет его в несколько потоков, одновременно добавляя новую информацию.

У тебя между двумя вызовами поиска пути сохраняется какое-то состояние? O_O

Один вызов ищет его в несколько потоков, одновременно добавляя новую информацию.

Добавляя новую информацию в алгоритм?

В данные, на которых он работает.

То есть у алгоритма состояния нет, но ты хочешь сделать его объектом. Ну окей, наслаждайся своим ООП головного мозга и его последствиями.

как это сделать красиво

unix-way

Пожалуй мой тред - тупняк. Пора закрывать.

На Прологе пишется в несколько строчек.

нарисуй UML-ные диаграммы use case (прецеденты с человечками), деятельностей, взаимодействия, коллаборации, последовательностей.

потом нарисуй CRC таблички (Class Responsibility Collaboration): R что класс делает сам, C — с кем общается.

R должно быть только 1 у каждого класса, если получается 2 — раздели этот класс на 2.

функции в диаграмме последовательностей, протоколе вызова представляй как методы, получится декомпозиция на классы. или объектный протокол. или метаобъектный, если ассоциации со стереотипами и метаклассы остались.

общий принцип: по 1 ответственности у класса, чтобы не получился антипаттерн «блоб».

божественный объект это сингтон. или метакласс-синглтон и метабоъектный протокол через функторы в С++.

здесь нужно понять где у тебя типы, а где классы. и не выдумывать классы там, где достаточно типов-синглтонов.

эти данные и есть состояние, снимок объекта. но да, объект тебе тут не нужен — нужны типы а не классы. ооп это вообще разновидность структурного, и ADT это разновидность объектов. вот в сторону старого доброго ADT и думай.

блиян! А я думал анонiмус разбанился опять :-/

Это все вообще категории быдлопрогерства, и к ООП не имеет отношения. Любой объект, это поведение, которое в свою очередь является совокупностью поведения других объектов. Поэтому можно комбинировать поведения как угодно, можно поручить одному объекту вообще все, это не создаст проблем в декомпозиции, и разделении обязанностей, при грамотном проектировании. нет никакого объекта, который берет на себя слишком много, есть дыра в головах разработчиков, которая его порождает.

а за что его зобанили-то? нечто эпическое, с пруфлинками?

не, сам выложил пароль, хз, наверное обиделся на всех, недостойны мы его :(