Я могу найти определение объекта в ООП. но не могу найти определение сервиса. Современная разработка, например, на симфони, предпологает широкое использование сервисов. но что такое сервис я не могу понять. Например, объект (как я это понимаю) - это доменная сущность, др. словами доменный предмет, который можно представить будто оно живое, одушивить его (антропоморфизм), который имеет сосотояние и поведение. и вы со мной можете не согласиться, но в ооп объект именно это. а не экземпляр класса (хотя это тоже называется объектом, но все таки это наверное эксемпляр класса). Но вот что такое сервис - не понятно. Например я могу создать объект состояние, которого может храниться в другом объект, или в бд, или в файле, или во всех 3-х местах. но все таки это будет объект доменной модели.
Чем сервис отличается от объекта у которого состояние может храниться не в самом экземпляре класса, а в других местах (например в стейт машине)? Вот я создаю такую модель доменного объекта в виде одного класса, состояние переношу скажем в стейт-машину, и что это получается у меня сервис получился?
P.S. если требуются ссылки на статьи я могу их привести. все понятия и измышления я взял не с потолка.
Чисто из общих соображений сервис - это чёрный ящик с выставленным наружу хорошо описанным интерфейсом. По этому интерфейсу ему в описанном формате передаются входные данные, по переданным параметрам сервис выполняет некие описанные действия, а обратно он возвращает результат обработки исходных данных и/или выполненных действий.
Вот я создаю такую модель доменного объекта в виде одного класса, состояние переношу скажем в стейт-машину, и что это получается у меня сервис получился?
Если интерфейс стейт-машины описан как принимающий объект и сохраняющий его, с возвращением статуса (сохранён, невалидные данные и пр.) и, возможно, уникального идентификатора объекта во внутреннем хранилище, а также как возвращающий объект по его внутреннему идентификатору или переданному полному либо частичному набору характеристик требуемого объекта - то почему бы ему и не быть сервисом?
Отличный ответ, я тоже так думаю, не могли бы вы подкрепить это умозаключение ссылками на статьи подтверждающие это, чем больше тем лучше, заранее вас благодарю
Сервис - это часть одного из паттернов проектирования ООП. Обычно это такой класс, который реализует львиную долю логики программы. К которому обращаются все остальные классы.
Объект - экземпляр класса.
Это если речь про ООП.
Также, сервис в разработке - это отдельная часть некого большого проекта, которая работает независимо и представляет собой отдельную программу или скрипт. Общение с которым реализуется через отдельное подключение, например http, ws или даже pipes
Объект - экземпляр класса. в общем смысле это не тот объект о котором говоорится в словосочетании объектно-ориентированный. т.е. само определение объектно(1)-ориентированные не об экземплярах класса.
хотя экземпляр класса тоже называется объектом (2), но это не синоним.
Следовательно Если сервис явлется экземпляром класса, и называется объектом(2) то не будет являться объектом (2) - следовательно это не ООП. Благодарю за ответ, был бы рад если вы придете ссылки опровергающие мое утверждение (если я не прав)
В центре ООП находится понятие объекта. Объект — это сущность, которой можно посылать сообщения и которая может на них реагировать, используя свои данные. Объект — это экземпляр класса. Данные объекта скрыты от остальной программы.
Hemul GM, отлично, не хотел бы сейчас разбираться написал я бред или нет (я считаю что нет). в общем понравилось вот это:
В центре ООП находится понятие объекта. Объект — это сущность, которой можно посылать сообщения и которая может на них реагировать, используя свои данные.
я так понимаю реакция это есть некоторое поведение ведь так?
НО насколько я понимаю сервисы не имеют состояния, главная плюшка сервисов в том, что они в себе хранят только логику но не состояние. состояние как раз хранит объект. Могу ли я сказать что Сервисы выходят за рамки ООП? Мне кажется они больше подходят к СОП (сервис-ориентированное программирование)
vitaly_74, сервис в ООП, как я уже сказал - это часть паттерна(шаблона). Как фабрика.
Но всё это всё ещё и есть ООП!
Реакция может быть разной, не обязательно меняющей состояние.
А сервис может делать что хочет. Хранить состояние или не хранить. Быть единственным в архитектуре, или быть один из десятков. Синглтоном или фабричным произведением.
vitaly_74, при этом сервис тоже является объектом. Хоть и может по сути представлять только простой интерфейс. Но для его работы ты все равно должен создать этот класс с реализацией методов и потом инициализировать экземпляр класса сервиса, если, например, методы не являются классовыми
Hemul GM, а чем это отличается от СОП (выше давал расшифровку). и Чем тогда Доменный объект отличается от сервиса?
п.с. вики.
Это объекты в объектно-ориентированных компьютерных программах, выражающие сущности из модели предметной области, относящейся к программе, и реализующие бизнес-логику программы.
vitaly_74, во-первых, нет такого понятия как "СОП", есть СОА. Сервис-ориентированная архитектура. И это не об ООП, как сказали тебе в первом ответе. И это именно то, о чем я сказал во втором абзаце своего ответа.
Во-вторых, объект в ООП - это всегда объект и не важно что он из себя представляет или какая роль ему отведена. Сервис это или фабрика или синглтон - это всё равно просто объект (класс).
vitaly_74, "Доменный объект" - это сущность предметной области в которой он применяется. Это может быть вообще не класс (не объект, экземпляр класса), а просто структура.
Доменный объект не является понятием из ООП, это просто понятие для архитектуры бизнес логики
vitaly_74, Если и сейчас ты не поймешь:
ООП - это парадигма, где архитектура построена на объектах и связях между ними. Точка. Больше там нет других вещей.
"Сервис" в ООП - это абстрактное понятие для конкретного класса (это значит, что он может быть и объектом или просто классом с методами). Равно как "Фабрика".
"Доменный объект" - это абстрактное понятие для описания объекта, который представляет сущность, например "Пользователь" или "Товар".
И то и другое архитектурные концепции, и их значение может от контекста зависеть.
Например в ddd главное отличие - сущность имеет идентификатор. То есть работая с доменным объектом Order, вы работаете с конкретным заказом, а не со всеми заказами сразу.
Если вы инстанцируете класс order, и можете работать из него с любым заказом - это скорее сервис.
По крайне мере в ddd сущность описывается именно через identity. Можете почитать книгу Эрика Эванса или Вона Вернона (главы где рассказывается, что такое entity).
