что значит: разные наборы данных? интерфейс документа один, все наследники документа будут являтся им и соблюдать контракт.

например есть личные документы и есть корпоративные документы. Во втором случае кроме имени компании есть еще конкретный исполнитель или ответственный

пример от балды конечно)

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

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

Я решил эту проблему по другому, документ по сути это холдер данных пусть он еще что то считает в себе там сумму чего то, сколько персонала и т.д. информациооный эксперт. Но перед печатью документ еще нужно форматировать

а формат может быть разный и поэтому можно ввести класс Formatter который уже будет отдавать строку, которую будут печатать

Вроде бы геттеры это плохо, но в то же время допустим если мне нужно чтобы документ выдавал каку то инфу, которая должна быть правильной т.е. мне нужно протестировать корректность данных. Поэтому нужны сетттеры, а когда я буду разбирать вывод документа который будет уже напечатан т.у. String то это по моему как то не особо если мягко сказанно. TDD показывает мне здесь что с геттерам всё норм т.к. всё нормально тестируется.

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

документ это результат какого-то процесса, подозреваю

или подтверждение процесса

Ну допустим скорее всего здесь Document не сильно подходящее имя пусть будет Report, есть данные которые приходят в какой то класс который отдает Report

документ это результат какого-то процесса, подозреваю

да

Ну допустим скорее всего здесь Document не сильно подходящее имя пусть будет Report, есть данные которые приходят в какой то класс который отдает Report

который обрабатывает данные и отдает Report

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

В общем пример конечно шляпный

в uml всё красиво, но...

документ это информация информация это данные, для того чтобы с данными что то сделать их нужно куда то передать. т.е get set

А если не передавать то опять будет возвращение к той же проблеме что была до решения разбивать на классы

как единичное решение это может быть и норм когда какой то документ будет печататаься только в одно место, если мест будет два то привет get set

Самое стремное в размазывании документа и принтера на отдельные классы - это когда принтеров или документов становится много и они сильно различны. Тогда это превращается в ад из визиторов или мультиметодов

Самое стремное в размазывании документа и принтера на отдельные классы - это когда принтеров или документов становится много и они сильно различны. Тогда это превращается в ад из визиторов или мультиметодов

А если это бизнесс требования, есть разные документы, есть разные места назначения куда этот документ нужно вывести.

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

зачем сеттеры-то? О.о

документ это информация информация это данные, для того чтобы с данными что то сделать их нужно куда то передать. т.е get set

нет, передавать это не get set

вы можете кидаться какими-то dto между вашими объектами

+1

Конкретный объект с данными определённой структуры

вы можете кидаться какими-то dto между вашими объектами

ну вот чтобы распечатать этот дто опять же нужно взять данные и как то их обработать. Тот же юзер в каком нибудь веб приложении, чтобы отобразить его на морде нужно: getName() getAge() getGender() и т.д.

ну вот чтобы распечатать этот дто опять же нужно взять данные и как то их обработать. Тот же юзер в каком нибудь веб приложении, чтобы отобразить его на морде нужно: getName() getAge() getGender() и т.д.

в дто просто все поля публичные

ну это уже смотря какой язык брать, суть та же, публичные или геттеры

да любой

java не приветствует такое

в любом случае dto это не ваша сущность, которая что-то умеет

хотя если обьекты иммутабельны то можно делать public final и обойтись без сеттеров, это уже спуск вниз от uml к конкретным языкам

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

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

чтобы всё можно было расширять во все стороны и ничего не трогать - так не бывает.

идеальное решение получить просто невозможно

можно получить кучу приемлемых на данный момент

Если поднятся даже над uml и следовать логике: есть какие то данные которые нужно распечатать разными способами, разные способы это разные действия которые нужно выполнить чтобы добиться результата, поэтому придется что то разделять на какие то части. и т.д.

Есть ещё вариант сделать документу принт-интерфейсы которые знают как отображать его данные в конкретной реализации)

Есть ещё вариант сделать документу принт-интерфейсы которые знают как отображать его данные в конкретной реализации)

Так вроде бы это было на диаграмме выше что я кидал, или ты имеешь в виду что то другое, лучше рисовать. т.к. на словах не всегда понятно конкретно о чем речь.

Оу, диаграму про**ал) Ну да, именно это)

Вообще нужно Егора Бугаенко слушать, он бы пояснил здесь за ООП, только на каждоый конференции после десяти минут его доклада остальные 50 идет срач. Но вроде он некоторые вещи правильно говорит, и про геттеры и про всё остальное.

Оу, диаграму про**ал) Ну да, именно это)

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

Вообще нужно Егора Бугаенко слушать, он бы пояснил здесь за ООП, только на каждоый конференции после десяти минут его доклада остальные 50 идет срач. Но вроде он некоторые вещи правильно говорит, и про геттеры и про всё остальное.

@yegor256

У него книга еще есть.

В общем серебрянной пули нет. Если ты хотя бы наполовину угадал с осью изменений то уже жить можно. Хотя для этого нужно чтобы её определял эксперт в предметной области.

https://youtu.be/llGgO74uXMI

где то в середине вроде бы было об этом, точно не помню.

я субьективно за вариант с imutable dto который возвращает document и передает разным реализациям печати которые реализуют один интерфейс

чисто субьективно

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

но вообще надо от ситуации смотреть, если документ это уже некое dto и есть уже публичные методы или свойства необходимые для печати, то смысл делать второй dto?

это все имхо обычного негра разработчика)

а на практике я бы делал, как остальные сущности в системе печатаются, ну а если это первая то описал выше)

В общем кроме этого вариантов немного. p.s. индуса

на практике для отображения я бы дто прямиком из базы тянул)

сделал view в базе и нет проблем)

:D

на практике для отображения я бы дто прямиком из базы тянул)

В смысле прямиком? не через Dao?

В смысле прямиком? не через Dao?

Сарказм же

ERROR: S client not available

ну тогда ок

на практике для отображения я бы дто прямиком из базы тянул)

вообще то такой паттерн есть

Active Record

вообще то такой паттерн есть

Нет, active record про другое

Вопрос, нужно чтоб вернуло true

как проверить есть ли в массиве два моих элемента, ттгда труе

http://sandbox.onlinephpfunctions.com/code/0ef1d6209baac33a087e5b8b6a9162b8a4e2056f bool(false)

http://sandbox.onlinephpfunctions.com/code/0ef1d6209baac33a087e5b8b6a9162b8a4e2056f bool(false)

решено, спасибо

вы можете кидаться какими-то dto между вашими объектами

И без того разветвленная структура станет ещё более мелкогранулярной

в некоторых языках назвали это типо view-model :D

верней не в языках а подходах типо mvvm

или mvp сколько всяких сокращений

или mvp сколько всяких сокращений

моды mvc паттерна

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

а вообще наброс хороший как лучше сделать)

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

думаю что mvc не подходит под эту ситуацию, mvc состоит из нескольких паттернов и эта часть как раз observer паттерн (в модели происходит какое то событие, модель оповещает всех своих обсерверов т.е. view) т.е. будут передаватся сам обьект модели, или модель будет передавать какие то данные которые вью будет забирать.

mvc это очень очень холиварный паттерн)

поэтому проще согласится)

а вообще наброс хороший как лучше сделать)

обычная ситуация только без контекста реальной задачи хз что лучше было бы.

mvc это очень очень холиварный паттерн)

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

принцип разделения кода, данных, и визуализации хорошо

только изначально mvc использовался для построения гуй по сути

и срача на тему тонких и толстых контроллеров было масса

и я не удивлюсь что из за этих срачей появились mvvm и mvp :D

только изначально mvc использовался для построения гуй по сути

а гуй и сейчас гуй, только от того что приложение стало веб приложением к примеру суть особо не поменялась.

мне приходится в основном работать с api

и там view как такого нет

и срача на тему тонких и толстых контроллеров было масса

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

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

поздравляю ты сторонник, тонких контроллеров и толстых моделей, это не хорошо не плохо, но есть целый лагерь людей которые думают иначе)

Ну допустим: