на спринге это проще... захуярил себе List<OloloInterface> services и не ебешь себе мозг

Все, кроме хаскеля, он прекрасен.

котлин практичен)

практичность = компромисы

это как инженеры vs ученые

ну экстеншены мало кто назовет здравой идеей

инженеры используют допущения, неточности, рандом

ну как рандом.. скорее реальные условия

а не лабораторные или какие-то теории

ну экстеншены мало кто назовет здравой идеей

ты о экстеншен методах?

да

я считаю что это прекрасно

если не злоупотреблять

а то код быстро превращается в непонятные вещи)

нодоело писать StringUtils, BlaBlaUtils

а выглядят они лучше, чем теже имлиситы в скале

я вот сегодня запилил себе fun Document.createElement(name: String, value: String = "", attributes: Map<String, String> = emptyMap()): Node { val element = this.createElement(name) element.textContent = value for ((attrName, attrValue) in attributes) { element.setAttribute(attrName, attrValue) } return element }

и теперь можно хреначить appendChild(createElement("RelCode", attributes = mapOf("value" to "Regular")))

вместо унылых записей в 3 строки

val relCode = doc.createElement("RelCode") relCode.setAttribute("value", "Regular") requestItem.appendChild(relCode)

короч я хз... сча попробую переписать свои тест кейсы под phpunit и посмотреть насколько тошнотворно

попробуй junit4 + mockito2 + kotlin-mockito

а вот на оборот хочу как-то производную spec попробовать

зачем?)

spock какой-то?

не знаю, spoсk выглядит довольно вкусно

его ж вроде с груви только юзают?

Нет, судя по тому что я видел, вполне удачно тестируют java код

https://github.com/JetBrains/spek/blob/master/spek-samples/src/test/kotlin/org/jetbrains/spek/samples/CalculatorSpec.kt

можно spek взять еще)

https://www.youtube.com/watch?v=ZsHMHukIlJY

оч годный видос

можно собрать список видосов которые говорят "не юзайте геттеры и сеттеры")

массивы в php в качестве DTO - это ок?

массивы в php в качестве DTO - это ок?

ну ты теряешь контроль над типами... а так ок

контроль над структурами...

я частенько так делаю)

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

и рефакторить становится сложнова-то

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

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

Тем что они не модели?)

т.е. твоим отношением к ним

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

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

т.е. твоим отношением к ним

Скорее их положением в системе

class UserDTO { public $id; public $name; public $birthday; }

вот пример DTO

если ты заметил - все проперти публичны

потому что это тупо структура данных

это не "объект" в привычном стиле

а где контроль над типами?

просто составной тип данных

а где контроль над типами?

phpdoc?) пока нет тайп хинтинга для пропертей только так)

ну ок

логично вроде

а где контроль над типами?

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

Для тех кто в танке - что есть "анемичные модели" (объекты без поведения, что ли?) и что есть "контроль над типами"?

потому что только статическая информация сильно помогает тебе при рефакторингах

Для тех кто в танке - что есть "анемичные модели" (объекты без поведения, что ли?) и что есть "контроль над типами"?

да

Для тех кто в танке - что есть "анемичные модели" (объекты без поведения, что ли?) и что есть "контроль над типами"?

да, объект без "гемоглабина" - логики

Для тех кто в танке - что есть "анемичные модели" (объекты без поведения, что ли?) и что есть "контроль над типами"?

контроль над типами.... ну... вот тебе пример.

function toDTO(): array;

контроль над типами это для языков со слабой типизацией

оно возвращает тупо массив... непонятно что внутри

или как оно проавильно называется

а если бы было toDTO(): UserDTO

то все уже намного лучше, и ты легко можешь в любимой IDE найти все места где юзается это DTO

контроль над типами это для языков со слабой типизацией

это просто возможность описать типы данных статически, в коде... что бы не надо было запускать (или интерпритировать в голове) что бы узнать "что же там"

сильно экономит время на чтение кода

@f3ath @fes0r спасибо, стало яснее.

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

ты потратишь на это DTO лишних 5 минут и возможно потом сэкономишь пол часа

такой вопрос тогда. есть слой A и слой B в приложении, которые обмениваются ДТОшками. A и B два разных модуля, к какому из них отнести ДТО?

такой вопрос тогда. есть слой A и слой B в приложении, которые обмениваются ДТОшками. A и B два разных модуля, к какому из них отнести ДТО?

что значит "обмениваются"?

ну один их производит, другой потребляет

самый такой.... "правильный" что-ли пример это архитектура портов и адаптеров

или гексагональная архитектура

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

если коротко - какой слой от какого ты хочешь изолировать при помощи DTO?

ну так... намекну что слой с UI не может не зависить от слоя с логикой... либо между этими слоями есть еще кто-то

у меня есть GitGatewayInterface, который из гита получает DTO с описанием разных сущностей (коммит, тег, итд). Есть Модели этих же сущностей, с логикой, которые используются в приложении. A - имплементация этого интерфейса, B - приложенме, которое зависит от интерфейса (получает его инстанс как зависимость). Они два разных модуля. К какому из них отнести ДТО?

ни к какому наверно?