Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
В общем, такая тема. в джаве есть класс А, у него метод а б в.
я хочу чтоб когда я из объекта класса А дергал метод а у меня исполнялся чуть-чуть мой код, а потом код метода а.

ну очевидно делаем типО обёртку Б наследуемся от интерфейса класса А, как вариант. и переписываем метод а, присовывая туда свой код а потом вызывая метод экземпляра объекта класса А.

во внешнем классе делаем Б б, б.а

работает.

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

если не ошибаюсь, это всё же адаптер. (или адаптор?).

теперь берем скалу. в скале можно сделать как в джаве. и оно даже будет работать. но еще в скале есть неведомя вырвиглазная фигня под названием имплисит класс. т.е. я могу без интерфейсов наследований и прочего барахла на экземпляры класса А навешивать уже свои методы. Не совсем то что выше, но пойдет. т.е. у меня заюзан объект класса А, и мы к этому объекту класса А добавляем метод "аМодифайдСомхау", внутри которого вызывается собссно, кастомный код, а потом вызывается метод объекта класса А. Т.е. я в своем кастомном классе создал имплисит класс (ну или просто сразу имплисит класс если контекст не нужен) с нужной сигнатурой, потом в класс-жертву заимпортил его и вуаля у меня появляется на всех объектах этого класса-жертвы метод "аМодифайдСомхау".

теперь вопрос, этот имплисит класс он по категории шаблонов как называется? по-идее, если добавляем новый метод это уже не делегат. и не адаптор (или адаптер?). тогда кто он? наследование тут тоже сказать как то не хочется бо это в позиции ООП не наследование ИМХО.
27 янв 19, 16:02    [21795209]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Scala является мультипарадигменным языком.
И это позволяет ей выкидывать фортели которые могут непрокатить в других языках.

По виду то что ты описал похоже на duck typing хотя я не уверен что это оно.
27 янв 19, 18:55    [21795288]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
ну типа того.

если образно есть репозиторий хибера. туда можно класть ТОЛЬКО сущность (объект заданного типа) что хибер положит в базу.

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

мы в тот же метод кладём просто другого класса объект и оно его принимает не смотря на то что у нас даже метода с такой сигнатурой нет.
27 янв 19, 19:01    [21795290]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Приведи лучше фрагмент кода. Реально. 1 строчка кода стоит десятка текстовых каментов.
27 янв 19, 19:35    [21795302]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
maxkar
Member

Откуда:
Сообщений: 154
andreykaT
теперь вопрос, этот имплисит класс он по категории шаблонов как называется?


Никак класс не называется. Потому что сам по себе класс никому не интересен (он в сигнатурах методов не используется). А то, что вы описываете, называется extension method (метод расширения).

И не надо путать extension method с implicit conversion (неявное приведение типа) - эти механизмы решают разные задачи (добавить метод или привести значение к другому типу), хотя оба и могут быть реализованы с использованием implicit class (implicit conversion не всегда может быть реализована через implicit class).
27 янв 19, 21:14    [21795355]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
maxkar, прав, это называется extension method.,
369
Это такой маленький шажок в сторону паттерна typeclass, почитать можно здесь, который позволяет решить весьма известную проблему, которая состоит в том, чтобы найти решение как расширить функционал, не меняя исходный код и не теряя
type safety.

Вообще subtyping не очень дружит с имплиситами, есть множество corner cases. Если вы планируете использовать скалу как better-java, то не стоит, лучше возьмите Kotlin. В скале наивные рассуждения вроде "В общем, такая тема. в джаве есть класс А, у него метод а б в.
я хочу чтоб когда я из объекта класса А дергал метод а у меня исполнялся чуть-чуть мой код, а потом код метода а. " вызывают лишь улыбку. Классы, методы это все вторичное, это детали имплементации. Если брать идиоматический ФП в скале, то объект это всего лишь неймспейс для функций. ФП и наследование по большей части несовместимы, для расширения кода используется паттерн typeclass, что я упомянул вначале
27 янв 19, 22:40    [21795387]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
эээ. в отпуске не могу пока. ) постараюсь попозже как комп с иде в руки получу. в общем верно. именно то что описано тут:

автор
maxkar, прав, это называется extension method.,
369
Это такой маленький шажок в сторону паттерна typeclass, почитать можно здесь, который позволяет решить весьма известную проблему, которая состоит в том, чтобы найти решение как расширить функционал, не меняя исходный код и не теряя
type safety.


и именно это я и сделал.

делал я это поверх плея с гуис ди.

что собссно я сделал:

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

далее, я уже ЭТОТ внешний класс заинжектил в сервисный класс (где требуется небольшой доп-функционал) и заимпортил методы заинжекченного класса в теле сервисного класса, чтоб у меня появились доп-методы из имплисит класса.

собссно вопрос - а) насколько это каряво? (не будь драных инжектов гуиса всё было бы сильно красивее)
и б) какому шаблону это соответствует
29 янв 19, 13:32    [21796796]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
собссно код (сорян по памяти)

class MyTrickyServiceExtension @Inject()(dbRepo:DbRepository){

 implicit class OriginalClassExtension(someObj:SomeObjToWrap) {
   def extraMethodForOriginalClass:SomeResultObj = {
   //some activity calling methods from injected beans
  //some original activities with someObj
  println(someObj.toString)
 }
}

class VictimService @Inject()(whateverBean:WhateverBean, originalClassBean:OriginalClassBean, myTrickyServiceExtension:MyTrickyServiceExtension) {
 import  myTrickyServiceExtension._
def whateverMethod = {
   originalClassBean.extraMethodForOriginalClass
 }
}
29 янв 19, 13:42    [21796810]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
Оо
myTrickyServiceExtension:MyTrickyServiceExtension
зачем его параметром передавать? Да и имплисит класс тут нафиг не нужен. Имплиситы это вообще не про это. Какой-то адовый микс ООП и ФП. Еще раз повторяю, забудьте про наследование и объекты. Используйте ФУНКЦИИ, которые можно кастомизировать коллбэками, что-то вроде:
def logic(onStart: => Unit = (), onFinish: => Unit = ()) = {
   onStart
   .......
   onFinish
}


В принципе это есть подобие АОП на ФП
29 янв 19, 23:10    [21797342]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

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

да можно было бы имплисит класс не делать нестедом НО как я выше уже сказал требуется функционал блинов которые иначе не заинжектить в имплисит класс

вы верно сказали про аоп по сути он и нужен

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

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

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

в чем плюс скального имплисита? в том что он дает очень простой способ расширить функционал существующего нешатаемого класса при этом сохранив оригинальные методы. тут ооп решение не очень удобно потому что не все и не всегда можно легко отнаследовать и расширить
29 янв 19, 23:45    [21797355]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
andreykaT
которые иначе не заинжектить в имплисит класс

Четя совсем потерялся в вашем замысле. В Имплисит? Инжектить? WTF?
Смысл имплиситов как раз чтобы сделать абсолютно независимыми и ортогональными старый и новый код.

Мой код, конечно работает только в случае pure функций, когда нет зависимостей на внешний мир, ваши инжекты это по сути и есть зависимости.

В целом, если у вас императивный код,а судя по всему так оно и есть, вам ФП подход(с имплиситами) только усложнит жизнь, тут наследование самое правильное решение. Просто в ФП нет такого понятия, как вызвать что-то и как-то обернуть. Есть чистые функции, которые можно комбинировать, в зависимости от сигнатуры, и они не зависят от внешнего мира, поэтому и имплиситы ни от каких бинов и инжектов зависеть не могут. И в таком случае достаточно просто импорта, чтобы они оказались в скоупе.

Если вам интересно как решить вашу задачу именно в ФП подходе, попробуйте дать больше деталей, не упираясь в "бины. инжектеды" и тд, я попробую расписать как это делается идиоматически с помощью ФП
30 янв 19, 12:07    [21797623]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Меня всегда интересовал motivation к использованию. Чтобы тема топика была
не из серии "хочется странненького…."

Кто может пояснить когда и где этот шаблон полезен?
30 янв 19, 12:28    [21797659]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
забыл ник
andreykaT
которые иначе не заинжектить в имплисит класс

Четя совсем потерялся в вашем замысле. В Имплисит? Инжектить? WTF?
Смысл имплиситов как раз чтобы сделать абсолютно независимыми и ортогональными старый и новый код.

Мой код, конечно работает только в случае pure функций, когда нет зависимостей на внешний мир, ваши инжекты это по сути и есть зависимости.

В целом, если у вас императивный код,а судя по всему так оно и есть, вам ФП подход(с имплиситами) только усложнит жизнь, тут наследование самое правильное решение. Просто в ФП нет такого понятия, как вызвать что-то и как-то обернуть. Есть чистые функции, которые можно комбинировать, в зависимости от сигнатуры, и они не зависят от внешнего мира, поэтому и имплиситы ни от каких бинов и инжектов зависеть не могут. И в таком случае достаточно просто импорта, чтобы они оказались в скоупе.

Если вам интересно как решить вашу задачу именно в ФП подходе, попробуйте дать больше деталей, не упираясь в "бины. инжектеды" и тд, я попробую расписать как это делается идиоматически с помощью ФП


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

в общем, вот пример задачи по-сути такой же.

у плея есть WS клиент. это хрень обычный хттп клиент где он делает вызовы колбаской типа:

ws(url).params(params).post() возвращает футуру резалт. так вот, в последнем вызове .post() мне нужно перед тем как отдать футуру резалт сделать некое действие - положить этот резалт в базу. или вообще не ходить на удаленный сервис (исходя из запроса) и взять этот резалт из другой базы.

как это сделал я -- код собссно сверху.

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

всё работает.

но по-сути, как вы верно заметили -- это ооп подход с плюшками и сахарком скалы. и не более того.
30 янв 19, 12:57    [21797701]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
и, имхо, поправьте меня если я не прав, но имплиситы это всё же сахарок а не часть ФП. вообще, имхо: не уверен что имплиситы сами по себе это здравая задумка.
30 янв 19, 14:55    [21797836]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
mayton
Меня всегда интересовал motivation к использованию. Чтобы тема топика была
не из серии "хочется странненького…."

Кто может пояснить когда и где этот шаблон полезен?

Ну имплиситы и typeclasses это самая мощная и интересная штука, которая есть в скале, уже одно это мотивирует к изучению) Ну а если вам хочется понять практический выхлоп, то попробую обьяснить на понятном примере.
Возьмем Java, и методы определенные на Object(hashCode, equals..), так вот, согласитесь, не каждому типу нужна эта функциональность, а если и нужна - то зачастую имплементация должна быть кастомной. Реализация Java - это костыльный костыль, каждый класс наследует дефолтную реализацию от Object, что не дает словить ошибку компиляции, когда мы кладем в мапу типы, которые не должны быть сравниваемы, ну допустим Connection или FileSystem ит.д и это потенциальный источник миллионов багов. А сделано это затем, чтобы вы могли еще ненаписанные классы использовать в HashMap.

Что же позволяет сделать скала и typeclass? - Для начала можно определить trait с некой операцией, допустим

trait Equal[A] {
def equals(obj:A, other:A):Boolean
}


Это подобие Java-интерфейса, с одной операцией, можно даже сделать дефолтную имплементацию

object DefaultEquals {
   implicit class EqualsOps(equal:Equal[A]){
   def equals(other:A) = equal == other
}
}


Implicit здесь указывает компилятору, что если у произвольного объекта с типом A есть интсанс-обертка с типом Equal[A], то в коде вы можете спокойно написать
val a = new A
 a.equals(new A) // компилятор преобразует во что-то типо new Equals(a).equals(new Equals(new A))

 

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

Пока я думаю до сих пор непонятно в чем прикол, те же яйца, вид сбоку. Чтобы понять, давайте перейдем к самому интересному, допустим у нас есть HashMap[A] и нам надо определить метод
add[A](obj:A)

в который можно передать любой объект.
НО, если этот объект не имеет враппера Equal - то это будет ошибка компиляции, а не молчаливое проглатывание, как в случае Java. Если вам нужно кастомизировать вашу логику сравнения, вам нет никакой необходимости модифицировать чужой\свой код. Вы можете просто написать в своем проекте

 object Implicits{
   implicit val eq:Equal[User] = new Equal[User]{
    override def equal(u:User, u2:User) = u.name == u2.name
}
}


Метод add будет иметь следующую сигнатуру -

def add[A](obj:A:Equal)


то есть акцептается только объект с типом A, у которого определен враппер Equal[A]. Соотвественно, если вы кладете в мапу Coneection = ошибка компиляции.

Заметьте, User может быть из сторонней либы, и вы можете не иметь доступа к исходникам. Таким образом мы расширили функционал, не трогая текущий. Вообще, чем-то напоминает Visitor.

В ООП проблема расширения решается созданием общего интерфейса и наследованием от него новых имплементаций, но какой общий предок у UserDTO и Email? Поэтому в Java и ввели Object. Этот подход кривой и имеет минимум два недостатка - 1) Все классы, иначе никак не связанные должны наследоваться от единого предка 2) Когда вы пишите код, вы должны имплементировать интерфейс\экстендить класс и если класс уже написан, то его может быть проблематично поменять.

Пример с equals тривиален, теперь представьте что у вас есть задача иметь сериализатор\десериализатор json, который выдает ошибку компиляции(НЕ РАНТАЙМ), если класс не имплементирует логику сериализации. В Java это скорее всего будет рефлекшен, который свалится в рантайме, поскольку не найдет сериализатора для какого нибудь JodaTime.
С помощью typeclass делается так -

trait Serializator[A]{
def serialize(a:A):String
}

и объявлены сериализаторы для Int, Double, String.
в таком случае код
case class User(name:String, age:Int)
case class User2(name:String, age:Int, bd:Date)
serialise(User("mayton", 40)) //Compile OK
serialise(User2("mayton", 40, new Date)) // Compile ERROR


Особая прелесть в том, что если юзаются case class, состоящие из полей Int, Double и тд, которые имеют сериализаторы, то scala автоматически сгенерит сериализатор и для всего класса, без единой строки кода.
30 янв 19, 17:43    [21798108]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
andreykaT
и, имхо, поправьте меня если я не прав, но имплиситы это всё же сахарок а не часть ФП. вообще, имхо: не уверен что имплиситы сами по себе это здравая задумка.

Создатели scala лоханулись, у слова implicit слишком много семантических значений, в последних версиях они пытаются исправить этот косяк. Из-за него идет очень много непонимания.
К ФП как таковому, implicits конечно же не относятся. Но благодаря имплиситам, в скале можно реалиовать typeclasses, которые как раз и есть ФП в чистом виде.
И да, некоторые применения implicit опасны и имеют плохую репутацию(implicit conversion), но люди не разобравшись автоматически переносят на все остальные применения. Ну примерно как в Java модификатор final имеет как минимум три семантически разных варианта использования(для переменной, метода и класса в целом)
30 янв 19, 17:47    [21798117]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Это типа. Если бы у нас было-бы 10 разных типов (классов) и мы захотели-бы их всех сравнивать
то надо было бы написать 10 * 10 = 100 имплементаций equals(...) по принципу от каждого типа
к каждому. Ну ... минус диагональ это 90 штук. И минус нижний треугольник 90 / 2 = 45 имплементаций.

А с неявным кастингом мы можем просто доверится машине этих неявных имплиситов.

Верно?
30 янв 19, 17:48    [21798118]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
andreykaT

ws(url).params(params).post() возвращает футуру резалт. так вот, в последнем вызове .post() мне нужно перед тем как отдать футуру резалт сделать некое действие - положить этот резалт в базу. или вообще не ходить на удаленный сервис (исходя из запроса) и взять этот резалт из другой базы.
.


Да зачем усложнять вообще? Это ж классика, делается все на фильтрах реквеста. Что является видоизмененным onStart;logic;OnEnd, зачем вам в фильтре какие-то внешние зависимости?
30 янв 19, 17:56    [21798126]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
mayton
Это типа. Если бы у нас было-бы 10 разных типов (классов) и мы захотели-бы их всех сравнивать
то надо было бы написать 10 * 10 = 100 имплементаций equals(...) по принципу от каждого типа
к каждому. Ну ... минус диагональ это 90 штук. И минус нижний треугольник 90 / 2 = 45 имплементаций.

А с неявным кастингом мы можем просто доверится машине этих неявных имплиситов.

Верно?

Нет, так как там много букаф, вынесу сюда resume

Основной поинт в том, что если у класса нет implicit враппера Equals, то при вызове метода, будет ошибка компиляции
def add[A](a:A:Equal) - дословно тут сказано что метод принимает любой объект, который может вести себя как Equals

Рассматривайте Equal как behavior, как маркер аля Serialisable. Вы можете писать некие методы, ожидающие параметром объект, который обладает Equal behavior, если объект им не обладает - то получите ошибку компиляции.
30 янв 19, 18:27    [21798156]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
забыл ник
andreykaT
и, имхо, поправьте меня если я не прав, но имплиситы это всё же сахарок а не часть ФП. вообще, имхо: не уверен что имплиситы сами по себе это здравая задумка.

Создатели scala лоханулись, у слова implicit слишком много семантических значений, в последних версиях они пытаются исправить этот косяк. Из-за него идет очень много непонимания.
К ФП как таковому, implicits конечно же не относятся. Но благодаря имплиситам, в скале можно реалиовать typeclasses, которые как раз и есть ФП в чистом виде.
И да, некоторые применения implicit опасны и имеют плохую репутацию(implicit conversion), но люди не разобравшись автоматически переносят на все остальные применения. Ну примерно как в Java модификатор final имеет как минимум три семантически разных варианта использования(для переменной, метода и класса в целом)

ну давай так с этим финалом как мниимум всё ясно и однозначно. а имплиситы это каша какая то. спасибо иде. хоть как то помогает.

вообще в скале не тока с этим лоханулись. с теми же налл насинг нан эниреф энивал да это реально какие то костыли которые прикрутили потому что иначе задачу решить не смогли.
30 янв 19, 22:12    [21798315]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
или кейс классы с ограничением в 24 поля емнип как трейты по дефолту шта? )))
30 янв 19, 22:13    [21798316]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
забыл ник

Особая прелесть в том, что если юзаются case class, состоящие из полей Int, Double и тд, которые имеют сериализаторы, то scala автоматически сгенерит сериализатор и для всего класса, без единой строки кода.


а еще прелесть в том что джейсон конвертеры требуют явного имплисит объявления сериализатора(форматтера) или десереализатора. и если ты оба объявляешь то этот дебил начинает пытаться зацепить имплиситли сериализатор там где десереализатор нужен. и никак ему не объяснить как это сделать наоборот. кроме как явно. т.е. или мы класс сериализуем или наоборот. или один неявно другой явно.
30 янв 19, 22:17    [21798318]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
чот молчание.. так и не понял как мою задачу решить с ФП подходом.. если вообще можно конечно же.

собссно вопрос.

как постигнуть дзен ФП и на него перейти? может книжки какие то посоветуете. читаю одерского книжку скала но там особо подходы не описаны там в целом вот типа скала вот она умеет фп няхи а еще она реактивная и в ней есть сахарок, вот как делать класс вот как наследоваться и всё.

пытаюсь смотреть его курс на курсере пока не понял.
4 фев 19, 14:42    [21801323]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
...много математики. и не очень понятно объясняет.

так что почитать по скале? кроме скала фор импатентс. и скала камплит референз одерского.
4 фев 19, 14:43    [21801326]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
andreykaT
так и не понял как мою задачу решить с ФП подходом
разве тема топика про это?
Стартуй новый топик и изучай erlang
4 фев 19, 14:58    [21801351]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42343
Я присоединяюсь к твоему вопросу. Но для меня важнее не увидеть решение. А понять мотивацию.

Пока неочевидна мотивация - и применение не впечатляет.
4 фев 19, 15:05    [21801360]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
ты про что сейчас? про решение ФП которого нет? или про решение в целом? если про мое - то без инжектов оно выглядело бы здорово. с инжектами как то с подпорками )))
4 фев 19, 15:42    [21801399]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
забыл ник
andreykaT
ws(url).params(params).post() возвращает футуру резалт. так вот, в последнем вызове .post() мне нужно перед тем как отдать футуру резалт сделать некое действие - положить этот резалт в базу. или вообще не ходить на удаленный сервис (исходя из запроса) и взять этот резалт из другой базы.
.


Да зачем усложнять вообще? Это ж классика, делается все на фильтрах реквеста. Что является видоизмененным onStart;logic;OnEnd, зачем вам в фильтре какие-то внешние зависимости?

Это не ответ чтоли? Ну ты сам указал что Play такой себе ФП фреймворк..
Возможно я не вчитался в задачу, но я не вижу там неоходимости в имплиситах вообще, я сейчас просто в бизнес типе, пока нету времени на вдумчивый ответ.
Что касается почитать по ФП, то для меня это два must-read.
1) Functional programming in Scala. Но она не для ленивых. Там по пути надо решать упражнения. Я первый раз пропустил их, и где-то к странице сотой полностью потерялся. Упражнения крутые, я потом оценил и скилл прямо на глазах ползет вверх. У этой книги есть один недостаток - там нету примера приложения от начала и до конца, потому иногда не понимаешь о чем авторы вообще, особенно ближ к концу. Ее надо читать вперемежку с практикой. Я начал понимать что к чем где-то на третьем прочтении(не потому что там что-то сверх сложное, просто есть моменты, которые ты считаешь тривиальными и скипаеь их, но на самом деле они crucial)
2) Functional and Reactive Domain Modeling
Тут как раз наоборот, человек показывает как правильно писать ФП, начиная от domain modelling до валидации, модулей, тестов и тп. Вполне вероятно тоже понадобится прочитать пару раз.


Вообще изучение ФП, по собственному опыту дело своеобразное. Сначала ты понимаешь только введение у статей, через месяц ты начинаешь доходить до понимания кода, через 3 месяца ы начинаешь думать что понял кое что. Через полгода ты понимаешь что нифига не понимаешь. Через 9 месяцев тебе уже все равно на чем читать примеры - Haskell или Scala, но ты все еще ощущаешь что пропустил что-то важное Где-то через год(может меньше) случается вспышка в голове, и твой мозг полностью перестраивается с ООП на ФП, ты все еще не понимаешь некоторые детали, но понимаешь общий direction.

Зачем это надо? Хотя бы для самосовершенствования, ну и очевидно что ООП-языки перенимают ФП фишки, а не наоборот, так что мир плавно и неуклонно движется в эту сторону, хотя и нефакт что этот переход полностью осуществится. Что касается меня, то мой ООП Java код стал в разы лучше, компактнее и понятнее. Начинаешь четко видеть где side effect, как лучше реюзать код, использовать функции высшего порядка и т.д. О нуллпоинтерах я и не говорю, видел их за два года ровно три штуки, из сторонних java библиотек.
4 фев 19, 17:42    [21801480]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
спасибо. посмотрю. на самом деле сейчас сижу на проекте который вроде как на скале но по сути это простой классический мвс на том же плее который мало чем от спринга отличается. ну чуть-чуть реактивщины да и всё. потому вроде как и скала а заюзать ее там особо и негде (или я не вижу). сахарок только но это не фп.
4 фев 19, 17:55    [21801491]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
andreykaT,
Ну это и раньше было, при внедрении ООП половина писала в процедурном стиле.
Вполне возможно что у тебя проект такой же.
"Не ломай свой танец взяв костыли".
Для ФП найди или начни новый проект и тему топика.
4 фев 19, 18:45    [21801518]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
rfq
Member

Откуда: Санкт-Петербург
Сообщений: 228
andreykaT
я хочу чтоб когда я из объекта класса А дергал метод а у меня исполнялся чуть-чуть мой код, а потом код метода а.

В сторону аспектно-ориентированного программирования смотрели?

Другое возможное решение - использование java.lang.reflect.Proxy.
4 фев 19, 18:59    [21801529]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
ЗабылНик, вторая книжка прямо таки очень понравилась!
5 фев 19, 13:30    [21801911]     Ответить | Цитировать Сообщить модератору
 Re: Шаблон делегат не делегат?  [new]
andreykaT
Member

Откуда:
Сообщений: 2420
rfq
andreykaT
я хочу чтоб когда я из объекта класса А дергал метод а у меня исполнялся чуть-чуть мой код, а потом код метода а.

В сторону аспектно-ориентированного программирования смотрели?

Другое возможное решение - использование java.lang.reflect.Proxy.

как вариант да. по-сути, имплисит классы это и есть суррогат аспекта. но в моем случае хотелось бы решить это не брутально в лоб и не средствами джавы.
5 фев 19, 13:31    [21801913]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Java Ответить