LINUX.ORG.RU

ООП в Python

 


0

1

Добрый день, ЛОР.
Учусь ООП (точнее, его подобию) в Питуне.

Сходу вопрос: как можно разбить класс на несколько файлов?
Очевидное наследование, однако голова кипит и пока не могу сообразить, как и куда его пихать.

Допустим, есть класс, в нём есть метод logger(), который формирует и возвращает лог-строку с полезной информацией:

class BotInstance:

    chat_id = None
    users = []
    bot_debug = False

    def logger(self, message = ''):
        info = "[Chat {0}] [{1} users]".format(self.chat_id, len(self.users))
        return info + message


Как правильнее всего вынести эту функцию в отдельный файл?

★★★★☆

Последнее исправление: annerleen (всего исправлений: 1)

Ответ на: комментарий от bread

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

Потом я испортировал все модули в каталоге plugins и делал что-то вроде

class Plugin(object):
    pass

class MainWindow(object):
    def log(self, text):
        print text

class MyPlugin(Plugin):
    def log(self, text):
        print 'foo'

window = type('MainWindow', tuple(Plugin.__subclasses__()+[MainWindow]), {})()
window.log('')
# outputs: foo

Но есть куда более кошерные способы это сделать.

pawnhearts ★★★★★
()
Ответ на: комментарий от pawnhearts

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

bread
()
Ответ на: комментарий от pawnhearts

Нет, ты сам выше видел как реализовать миксин вообще без наследования.

bread
()
Ответ на: комментарий от pawnhearts

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

bread
()
Ответ на: комментарий от annerleen

Это метод «бот» тоже по-идее не должен уметь? Или всё же должен..

Сделайте отдельный класс, который будет работать с телеграмом - при инициализации вы ему передаете токен\логинпароль (как там?), он умеет отправлять и принимать сообщения (ну и еще конеект\дисконект и прочие служебные штуки). Отдельно описываются процедуры обработки сообщений (классы, отдельные функции - пофигу), которые на вход получают сообщение, на выходе - говорят боту что и куда отправить (вот в что-то подобное приведенному reply). Связь - через декораторы, например, то есть в итоге "цепляется" это все к боту, но логически это - разные компоненты. Логгирование вообще делается отдельным "модулем", туда же всякие служебные штуки типа записей\чтения файлов и прочее.

Учусь ООП (точнее, его подобию)

Идея в том чтоб написать работающее приложение или чтоб вникнуть в концепцию? Если второе - берите сферические примеры в вакууме из книжек - про ученик<>класс<>школа, стол<>стул<>табуретка и прочую оторванную от жизни белиберду. С пониманием того какие профиты в этом случае дает ООП и опытом "как лучше это все организовать" сможете натягивать парадигму и на реальные задачи. Если нужно таки полезное приложение сейчас - пишите как умеете, с наскоку все равно все идеально не сделаете, а опыт уже будет, и в следующем проекте уже сможете от чего-то отталкиваться.

в Питуне.

КЛБ!

micronekodesu ★★★
()

Учусь ООП (точнее, его подобию) в Питуне

Тебя заставляют что-ли? Есть более подходящие для этого языки.

Допустим, есть класс, в нём есть метод logger()

Тебе нужно выкинуть питон и взять жабку, там тебя быстро научат родину любить нормальной декомпозиции и абстрактным фабрикам. Если с жабкой трудно, бери php, там сейчас мода делать «как у больших дядек в жабке». А иначе так и будешь лепить godobject-ы как дурак прожжёные питонисты.

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

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

self.logmethod=otherfile.LogObj().loginfo
self.logmethod()

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

genryRar ★★
()
Ответ на: комментарий от annerleen

Да, для меня инкапсуляция — неотъемлимая часть ООП

Понятие «ООП» намного шире и глубже чем то, что ты о нём представляешь.

Советую тебе почитать, что такое вообще ООП в изначальном его понимании, а не в том каличном уродстве, которое пошло от С++ и подобных языков, и почему инкапсуляция не имеет вообще никакого отношения к ООП.

E ★★★
()
Ответ на: комментарий от bvn13

немного вброшу. в С# уже есть такое: partial классы.

Немного выброшу: это тот костыль, которые любезно разрешает разработчику дописать чо-нить своё в джаваподобную кашу, оставшуюся после энтерпрайзных(р)(тм) кодогенераторов? Какое отношение это имеет к вопросу ТС?

E ★★★
()
Ответ на: комментарий от E

немного подброшу: причем тут java? я про шарп. истинного смысла этого не знаю, но когда класс разбросан по 10 файлам - неудобно.

к ТС имеет отношение: расширение кругозора по вопросу

как можно разбить класс на несколько файлов?

bvn13 ★★★★★
()
Ответ на: комментарий от bvn13

немного подброшу: причем тут java? я про шарп.

Все известные мне продукты на шарпе используют шарп для генерации CRUD обёрток для энтерпрайзных вебсервисов или гуёв по xml, в точности как и java. О других приложениях на шарпе я не слышал в принципе, но, возможно, они действительно есть, поэтому ладно, вопрос снимаю.

E ★★★
()
Ответ на: комментарий от pawnhearts

скопирован как раз с джабки

Что можно «скопировать с жабки» в язык где нет интерфейсов? Можно только закостылить какое-то подобие, которое выглядит похоже. Всё равно что купить бентли, взяв пожизненный кредит.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

В питоне не было ооп изначально вообще. Потом приделали сбоку костыль, в котором даже наследования не было. Потом сделали наследование и там стало 2 разных типа классов old-style и new-style. Короче все плохо. Примерно как в perl.

pawnhearts ★★★★★
()
Ответ на: комментарий от no-such-file

язык где нет интерфейсов?

А какую практическую пользу принесут интерфейсы в языке с динамической типизацией?

E ★★★
()

Подгорает от количества тех, кто не слышал про mixins и ни слова не знает, ни концепции, но что-то точно «нинужна!».

t184256 ★★★★★
()
Ответ на: комментарий от pawnhearts

Потом сделали наследование и там стало 2 разных типа классов old-style и new-style.

А че ты на прошлом десятилетии остановился?

t184256 ★★★★★
()
Ответ на: комментарий от no-such-file

В питоне полноценное ООП по Кею, а вместо симптомов ООП, которые вы по своим утячьим причинам считаете ООП - их отсутствие.

t184256 ★★★★★
()
Ответ на: комментарий от no-such-file

Я серьезно и спокойно повторю: то, что эти слова ты услышал в одном курсе с ООП, еще не значит, что они являются необходимым языковым конструктом для его реализации.

t184256 ★★★★★
()

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

yvv ★★☆
()
Ответ на: комментарий от t184256

В питоне полноценное ООП по Кею

Вот никак не получается в питоне рассуждать в терминах сообщений. И даже вредно так делать, потому что при взаимодействии с объектом требуется различать методы и поля. Так что объектная модель питона более всего близка к так любимому Кеем C++.

bread
()
Ответ на: комментарий от bread

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

И что именно мешает? Динамика скорее даже помогает, утиность типизации? Чем?

t184256 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.