LINUX.ORG.RU

main в ООП == god object?

 ,


0

2

На заборе В Интернете пишут, что god-object в ООП это плохо. https://ru.wikipedia.org/wiki/Божественный_объект

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

Пожалуй уточню поконкретнее: надо сделать вычисление пути в графе. Соотвественно создаю экземпляр вычислятора, засовываю в него слова по одному, получаю путь, передаю путь в функцию или класс, который/ая умеет красиво выводить этот путь, и всё это в функции main или например в методе класса Program. Это плохо?

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

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

Deleted
()
Ответ на: комментарий от anonymous

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

hlebushek ★★
() автор топика

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

Iron_Bug ★★★★★
()

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

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

tailgunner ★★★★★
()

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

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

hlebushek ★★
() автор топика
Ответ на: комментарий от hlebushek

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от hlebushek

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

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)

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

hlebushek ★★
() автор топика

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

yoghurt ★★★★★
()
Ответ на: комментарий от hlebushek

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

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

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

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

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

anonymous
()
Ответ на: комментарий от hlebushek

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

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

anonymous
()
Ответ на: комментарий от hlebushek

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.