Как проектировать в стиле е.о, с чего начинается разработка с определения сущностей, сценарии использования? Где почитать можно
Читать полностью…Композиция, когда тебе внутри объекта нужен другой объект для его работы. Например у тебя будет File
и у него метод для чтения по байтам и FileContent
который будет иметь метод, который просто возвращает содержимое файла в виде строки, и вот он будет содержать File
передаваемый ему через конструктор. А декоратор это когда тебе нужно как-то поменять поведение объекта: например будет еще ReversedFileContent
который будет декарировать FileContent
и возвращать перевернутую строку. И делать это нужно через интерфейс если язык с типами. Например интерфейс Text
у которого будет asString
и FileContent
, и ReversedFileContent
будут реализовывать этот интерфейс (но тогда лучше переименовать ReversedFileContent
в ReversedText
)
Это когда объекты и имеют одинаковый интерфейс. Т.е разделить один и тот же объект например File на FileEtc с одинаковыми методами?
Читать полностью…Всем привет!
Вопрос по elegant objects.
В каких случаях применяется декоратор, и в каких композиция?
Ну тогда надо решать, что тебе важнее. Красивые ЕО и на каждый реквест ты явно через new создаёшь объект сервиса, или важнее парадигма спринга и экономия времени/памяти и тогда можно параметризовать метод process(data, step)
Читать полностью…А если это не синглтон? ТО создаю новый слой получается? И туда руками кидаю Formatter и step?
Читать полностью…Сколько раз ты хочешь создать FooService? Если это синглтон и бин спринга то вот такой вариант через конфигурации, без Autowired в конструкторах:
@ConfigurationЧитать полностью…
public class FooConfig {
@Bean
FooFormatter fooFormatter() {
return new FooFormatter();
}
@Bean
FooService fooService(FooFormatter fooFormatter) {
return new FooService(fooFormatter, step);
}
}
Потому-что это важная его часть, без которой объект может остаться в промежуточном состоянии, вроде-бы создан, а вроде и не полностью
Читать полностью…я понял, что я немного спутал) наверное всё такие перегрузка методов должна обыгрываться объектами через композицию. Т.к. перегрузка это по факту нарушение интерфейса. Если метод ждёт один параметр то это контракт.
Читать полностью…Про спринг вопрос открыт, Я отказываюсь принимать что все тут за ООП задвигают и вместо конструкторов спокойно через методы прокидывают пропертя...
Читать полностью…Насколько декомпозировать обьект File, разделить по методам? Т.е File с методом чтения по байтам, File возвращающий содержимое в виде строки, File с методом etc... ?
Читать полностью…Просто отказаться от DI спринга сложно. Выходит для этого надо сделать подслои для сервисов/репозиториев и тд
Читать полностью…Если не синглтон, то надо смотреть. Либо да, новый слой, какая нибудь фабрика (куда же джава без фабрик)), либо можно scope в конфигурации бина проставлять. Тогда ничего не меняется, бин создаётся спрингом в конфигах
Читать полностью…public class FooService {
private FooFormatter fooFormatter;
@Autowired
public FooService(FooFormatter fooFormatter) {
this.fooFormatter = fooFormatter;
}
}
Как добавить в конструктор этого класса еще какой то параметр, например "int step"?
Одно дело передать свойство объекта, другое дело передать кусок данных, которые этот объект может "переварить" или "обработать", при этом не меняя своего внутреннего состояния
Читать полностью…А тут ты что делаешь? Ты сам посоветовал передвать данные в process, всмысле мало кто делает?
Читать полностью…> через методы прокидывают пропертя
Думаю мало кто тут так делает
> Я отказываюсь принимать
Понял
Может я не правильно понял, но полагаю имелось ввиду конкретно в интерфейсах перегрузки не указывать.
Читать полностью…