зависимости в конструкторе не видны, нельзя интерфейсы использовать, зависимость классов от локатора, тесная связь с локатором

день сурка прямо

всмысле, я уже спрашивал что ли?))

ну в смысле ты был в обсуждении тут про IoC

да пздц, теория без практики это бред полный. Толку вот что я все это читаю с вами обсуждаю, а в ежедневной практике не использую((

ну и забываю всё соответственно

почему не используешь? у меня все классы на DI уже и DIC используется вовсю, single responsibility и лискова не забываю

или тебе на работе тупо ООП не дают писать

почему не используешь? у меня все классы на DI уже и DIC используется вовсю, single responsibility и лискова не забываю

лискову. это она

лисков она

лисков она

Просто подстановка?

блин вот щас вспомнил что статью же советовали уже

https://martinfowler.com/articles/injection.html

>With the service locator you have to search the source code for calls to the locator.

вот это самое тупое в локаторе

часто его не только в конструктор напихают же, а еще по всему коду

я использую DIC как SL в легаси коде

у меня гигантский проект, там все плохо с зависимостями

все в императивном стиле

я выделяю куски логики в самостоятельные объекты, которые создаются в DIC

а легаси юзает этот DI как сервислокатор

бля а чем тогда сервис локатор от реестра отличается?

или это его частный случай

и мне кажется это удобно

реестр по имени класса ищет, еще тупее, с локатором хоть можно какой-то интерфейс на сам локатор запилить и ставить его на классы, с именами вообще ничего

опечатался где-то в запросе к реестру, и поехали ошибки

алсо в реестре же один объект на строку, это уже зависимость всех классов от одного объекта

да спасибо

вот ещё нашел хорошее объяснение

http://stackoverflow.com/questions/27854298/registry-pattern-vs-service-locator-pattern-vs-dependency-injection-container

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

Лол

Ненужно обсуждают в чате про ненужно

Всем привет. Подскажите пожалуйста новичку. Есть задание: необходимо разработать класс Element, реализующий элемент блок-схемы. Есть четыре стиля его отображения, которые надо комбинировать: по-умолчанию, инвертированный (inverted), зачеркнутый (striked), выделенный (highlighted). Кроме того, необходимо в дальнейшем легко добавлять новые стили и их комбинации. Способ реализации: на русских словах опиши какие классы, названия, методы и свойства и краткий пример использования. Язык JavaScript.

Дополнение . При создании экземпляра класса , Настройки делать через свойства . К примеру : экземпляр = новый Элемент ({ стиль: [{инверторный: true }] })

Как лучше это сделать

? Странно, вопрос по ООП. Ну ок, спасибо

привет. вообще, то, что ты хочешь в языке c# очень здорово подходит под перечисление. т.е. у класса Element должно быть поле типа "перечисление". ну, а создать конструктор для класса Element вообще не вижу сложностей.. как бы все понятно, вроде

а вообще что-то похоже я нашел здесь: http://stackoverflow.com/questions/287903/enums-in-javascript

а вообще что-то похоже я нашел здесь: http://stackoverflow.com/questions/287903/enums-in-javascript

Спасибо !

день сурка прямо

Это главный спор ООП

всмысле, я уже спрашивал что ли?))

Ну так может это была другая твоя личность? Осталось дождаться ту личность, что увидит твой вопрос и ответит.

надо еще ioc упоминуть)

скучно уже за ооп сраться

ооп vs фп

типо почему люди в ооп не разделяют состояние и поведение)

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

это шутка))) но поспорить можно)

как не разделяют? вполне разделяют. анемичные модели из всех дыр лезут

так получается это не кошерный ооп

и вся логика в сервисах, которые не имеют своего состояния и являются только модулями с набором процедурок

и модели и тд это просто структура данных (массив)

просто хранилище

а сервисы это набор функций так как они состояние не хранят)

и сервисы могут быть заменены функциями

и далее то что функция должна быть чистой и тд

потом осознание того что можно использовать map, reduce

понятие функтора для данных

потом filter и прочие мелочи)

и вся логика в сервисах, которые не имеют своего состояния и являются только модулями с набором процедурок

это получается не правильный ооп же )

а в чем "правильность" ооп?

фишка ооп в объединение состояния и поведения)

идея того что все есть объект

а объект это набор состояний и поведений

и что там есть полиморфизм, наследоване, инкапсуляция

и как раз выдернуть из объекта состояние и передать его куда то это нарушение инкапсуляции

ERROR: S client not available

ну это так умные дядьки думают у нас в проектах все по другому)

ну и еще хороший аргументом ооп это возможность проецировать систему сверху вниз (от общего к частному)

это получается не правильный ооп же )

заменить анемичную модель и получается вполне ок

и вся логика в сервисах, которые не имеют своего состояния и являются только модулями с набором процедурок

это получается не ооп а процедурное программирование вроде

с точки зрения теории)

ты не можешь в своих сервисах хранить состояние, иначе у тебя проблемы будут

я знаю о чем ты )

поэтому все твое состояние в доменных модельках, в структурках типа VO/DTO

и мне тоже кажется этот подход удобным)

и гуляет это все по твоим связанным процедуркам под именем сервисы

кстати вопрос

получается процедурное программирование )

а не ооп )

:D

где начинается ДДД? и возможно ли оно без агрегатов?

это получается не ооп а процедурное программирование вроде

потому что ооп это процедурщина на стероидах, иначе в реальном мире оно не виживет

мне кажется что выделение доменной области с сервисами уже ДДД

не?

ой ддд отдельная пенся, я ее так и не осилил)

потому что ооп это процедурщина на стероидах, иначе в реальном мире оно не виживет

ну тут не о выживаемости)))

мне кажется что выделение доменной области с сервисами уже ДДД

домены, апликейшен сервисы, инфраструктурные сервисы...

а о том что когда мы говорим что у нас ооп код, а по факту там намазано всего по чуть чуть

ну ок, из ООП в этих сервисах только типы и абстракции используются. если все делать по SOLID то у тебя как раз таки и выходят процедурки, которые делают только 1 функцию, подменяются наследниками, расширяются за счет сервисов и им подкладывают зависимости сверху

хочешь еще и состояние хранить? получать миллион проблем с синхронизациями

ну иногда ооп удобно ))

не всегда все так плохо )

но проблема в том что применение ооп далеко не всегда удобно

просто получается если идти от solid дальше

то можно придти в ооп

раскладывая все в ddd, придерживаясь solid

и тд