AM
А конструктор класса сделать единым, самым простым. Функции-конструкторы будут приводить свои параметры к этому простому варианту, который понимает конструктор класса
Убивает полиморфизм в клиентском коде.
Size: a a a
2020 June 23
AM
А что значит, протекает в клиентский код? И как это в принципе предотвращать? В питоне всё в общем-то публичное
Вот код, который вызывает мой класс:
В какой-то другой части приложения надо накой-то знать что есть метод
Т.е. мне потом придется городить подобный метод во всех возможных реализациях этого класса, даже если они читают не из файла. Это раздумает интерфейс.
Я пришёл к тому что теперь там будет
Но вызывающему коду всё равно придется знать что есть несколько разных классов на не 1.
TextStream("content").process()
# vs
TextStream.from_file("t.txt").process()
В какой-то другой части приложения надо накой-то знать что есть метод
from_file.Т.е. мне потом придется городить подобный метод во всех возможных реализациях этого класса, даже если они читают не из файла. Это раздумает интерфейс.
Я пришёл к тому что теперь там будет
FileStream("t.txt").process()
Но вызывающему коду всё равно придется знать что есть несколько разных классов на не 1.
SA
Ну то есть ты таким образом просто ифчик спрятал в init, и делаешь вид, что фабрика классов - это и есть сам класс.
Я пытался использовать singledispatch, но он выглядит и работает как-то странно, пользоваться им стремно и неудобно. Вообще, на мой взгляд, если в языке нет паттернматчинга, то лучше не пытаться его такими вот неявностями присобачить
Я пытался использовать singledispatch, но он выглядит и работает как-то странно, пользоваться им стремно и неудобно. Вообще, на мой взгляд, если в языке нет паттернматчинга, то лучше не пытаться его такими вот неявностями присобачить
SA
А если паттернматчинг в языке есть, то это не значит, к слову, что им прикольно и удобно пользоваться. Чуть в сторону от примеров из учебника, и получаем ебнутую кашу, определяющую, как правило, стейт-машину. См, например, попытки стримить ответ в эрланге (или вообще с сокетами там работать). Особенно люто получается, если сверху еще навешивается компрессия или что-то типа того. Итак раком стоишь, там тут тебе еще пару блинов на спину кладут, гирю и гантелю, и весело лупят хлыстом, пока ты все это говно отлаживаешь.
KK
Вот код, который вызывает мой класс:
В какой-то другой части приложения надо накой-то знать что есть метод
Т.е. мне потом придется городить подобный метод во всех возможных реализациях этого класса, даже если они читают не из файла. Это раздумает интерфейс.
Я пришёл к тому что теперь там будет
Но вызывающему коду всё равно придется знать что есть несколько разных классов на не 1.
TextStream("content").process()
# vs
TextStream.from_file("t.txt").process()
В какой-то другой части приложения надо накой-то знать что есть метод
from_file.Т.е. мне потом придется городить подобный метод во всех возможных реализациях этого класса, даже если они читают не из файла. Это раздумает интерфейс.
Я пришёл к тому что теперь там будет
FileStream("t.txt").process()
Но вызывающему коду всё равно придется знать что есть несколько разных классов на не 1.
Мысль в сторону...
Оптимальнее было бы принимать не путь к файлу, а file-like объект. Это более композабельно и позволяет использовать не только "файлы" из системной FS.
Оптимальнее было бы принимать не путь к файлу, а file-like объект. Это более композабельно и позволяет использовать не только "файлы" из системной FS.
KK
А с учётом того что относительно легко любую строку завернуть в StringIO или BytesIO, то можно даже отказаться от варианта, когда данные приходят в виде строки.
AM
Ну то есть ты таким образом просто ифчик спрятал в init, и делаешь вид, что фабрика классов - это и есть сам класс.
Я пытался использовать singledispatch, но он выглядит и работает как-то странно, пользоваться им стремно и неудобно. Вообще, на мой взгляд, если в языке нет паттернматчинга, то лучше не пытаться его такими вот неявностями присобачить
Я пытался использовать singledispatch, но он выглядит и работает как-то странно, пользоваться им стремно и неудобно. Вообще, на мой взгляд, если в языке нет паттернматчинга, то лучше не пытаться его такими вот неявностями присобачить
Нет, я сделал вообще без IF. Теперь каждый раз когда используешь в своё коде сам решаешь какой класс для этого взять.
SA
фабрику сделал?
AM
Мысль в сторону...
Оптимальнее было бы принимать не путь к файлу, а file-like объект. Это более композабельно и позволяет использовать не только "файлы" из системной FS.
Оптимальнее было бы принимать не путь к файлу, а file-like объект. Это более композабельно и позволяет использовать не только "файлы" из системной FS.
Ну ты же понимаешь что со стримом это был пример просто. Но в целом да.
AM
фабрику сделал?
Нет вообще просто 3 отдельных класса. Какой хочешь тот и бери.
AM
Сам. Руками.
SA
Понял. Паттерн Мануфактура
ИК
Нет вообще просто 3 отдельных класса. Какой хочешь тот и бери.
А почему не обернуть просто значение в какой-нибудь класс?
AM
Понял. Паттерн Мануфактура
Декоратор который oop.
AM
А почему не обернуть просто значение в какой-нибудь класс?
Раздувается вызывающий код. Чтобы не плодить обертки аргументов в нескольких местах.
ИК
Раздувается вызывающий код. Чтобы не плодить обертки аргументов в нескольких местах.
Это правда, зато интерфейс удобный)
ИК
Магия, все дела...
KK
тоже мнения прошу, есть у меня импорты циклические снова, и чтоб их разрулить по хорошему, нужно вообще всё расфигачить, но этого не хочется.
насколько хорошо или плохо использовать importlib для их разруливания?
насколько хорошо или плохо использовать importlib для их разруливания?
А чем тебе importlib поможет? Хочешь его использовать внутри функций и методов? Так по моему проще вместо него там же использовать обычный import