DjangoBB LoFi version

Начало » Python для экспертов » Обратное наследование

1 2 3 4 5

Андрей Светлов

Фев. 17, 2011 01:40:06

Медитирую…
Нет, всё ещё не понял. Системы А и Б, набор классов К… Это хорошо при доказательстве теоремы, если вы предварительно строго оговорили, что есть эти занятные буквы.
- И что у вас означает “инстацирование” и “изменение поведения”?
- Какие изменения системой Б поведения классов К имеются в виду?
- Насколько это должно отражаться на А?
Остальные пункты уже не так важны.

Ей-же-ей. Либо давайте строгие условия, либо предоставляйте простой и понятный пример.

В аватарах - гаватарах я уловил какой-то смысл, но до сих пор не понял: а что же таки требуется?

Даже наводящий вопрос многоуважаемого Ed не сильно помог.

Мне припомнился десяток способов замены методов - и каждый раз это было вызвано внешними условиями.

Так что, извините, всё ещё понимаю не больше, чем в самом начале обсуждения.

zheromo

Фев. 17, 2011 01:51:50

Андрей Светлов
И что у вас означает “инстацирование” и “изменение поведения”?

Инстанцирование - создание экземпляра класса user = User(…)
изменение поведения - изменился результат вызова метода

Андрей Светлов
Какие изменения системой Б поведения классов К имеются в виду

Грубо - изменение алгоритма работы метода или методов классов К (их подмена, например, в общем то что происходило с граватарами)

Андрей Светлов
Насколько это должно отражаться на А

Ну… если вначале get_avatar_path выдавал одно, то теперь должен другое

Андрей Светлов
Так что, извините, всё ещё понимаю не больше, чем в самом начале обсуждения.

Не за что. Тут видимо - либо из меня плохой объяснятор, либо я сам не понимаю :) Как говорится - правильно заданный вопрос - это 95% ответа.

Андрей Светлов

Фев. 17, 2011 02:08:02

А вы попробуйте стать хороши рассказчиком.

Опишите задачку. Если она исчерпывается аватарками - используйте этот пример. Нет - возьмите другой или прямым текстом расскажите, что вам нужно.

“Грубо говоря, моя система обязана покорить мир. Ну… Если вначале я был должен вам $10, то теперь - вы должны мне.”

Я не могу воспринимать такие построения в контексте программирования. В жизни бывает разное - но писание кода это более или менее формализованная процедура.

zheromo

Фев. 17, 2011 03:03:38

Попробую…

Разрабатываю систему представляющую что-то типа мультиблога. Архитектура классическая - MVT.
Использую GAE, Flask с расширениями, WTForms, Babel, Markdown и по мелочи.
Задача - написать систему подключения и использования плагинов которая должна расширять и изменять поведение базовой системы.
Основной затык, понятно, не в добавлении нового функционала, а в изменении уже реализованного.
(Пресловутый пример с граватарами)
Ряд задач для плагинов чтобы было более понятно:
- Изменение языка разметки топиков с маркдауна, например на текстиле
- Изменение способа хранения и доступа к изображениям - например альбомы пикасса, blobstore, внешний фотохостинг
- Добавление пингбэка или пинга на яндекс, гугл и т.д.
- Нотфикация пользователям при наступлении некоторых событий (без натыкивания, например сигналов куда ни попадя)
- Возможность добавления новых видов контента, например альбом, фотоотчет и т.д. (Здесь проблем в принципе нет)
- Прикрепление файлов к топику
В общем продолжать можно долго

В данном случае я вижу два варианта развития:

1. Предусмотреть ряд интерфейсов для вмешивания в работу системы (типа Шаблонного метода) на все случаи жизни
Ряд классических задач решается будет именно так. Это управление темами оформления, i18n и l18n, система контроля доступа и т.д.
2. Придумать как можно добавить новый функционал и изменить существующий без “грязных хаков” - чтобы все было красиво и стройно.

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

o7412369815963

Фев. 17, 2011 09:53:38

вообщем тема плагиностроения.

я видел как встраиваются плагины на РНР (не помню, то ли джумла, то ли друпал), дак там патч ложится на исходники движка. Так что в данном случае “грязный” хак выглядит как пушистый.

zheromo
класс фабрики можно заменить на метод, будет компактней.

class Factory(list):

а пример с декораторами, пока не лучше прямой подмены.

zheromo

Фев. 19, 2011 04:13:36

В общем, почти определился
Скорей всего буду использовать TCA
http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

o7412369815963

Фев. 19, 2011 08:32:45

zheromo
В общем, почти определился
Скорей всего буду использовать TCA
http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

по сути это тоже самое

from trac.core import ComponentManager, Interface, ExtensionPoint, Component, implements

class ITodoObserver(Interface):
    def todo_added(name, description):
        """Called when a to-do item is added."""

class TodoList(Component):
    observers = ExtensionPoint(ITodoObserver)

    def __init__(self):
        self.todos = {}

    def add(self, name, description):
        assert not name in self.todos, 'To-do already in list'
        self.todos[name] = description
        for observer in self.observers:
            observer.todo_added(name, description)

class TodoPrinter(Component):
    implements(ITodoObserver)

    def todo_added(self, name, description):
        print 'TODO:', name
        print '     ', description

comp_mgr = ComponentManager()
todo_list = TodoList(comp_mgr)

todo_list.add('Make coffee','Really need to make some coffee')
todo_list.add('Bug triage','Double-check that all known issues were addressed')

Тут 2 минуса:
- нельзя изменить функционал, только дополнить
- в каждый метод нужно впихивать специальный код (код для поиска выполняеймой ф-ии)

        for observer in self.observers:
            observer.todo_added(name, description)

zheromo

Фев. 19, 2011 15:03:28

Есть еще один вариант, основанный на генерации классов по их описанию
Грубо говоря выглядеть на мой взгляд должно это примерно так:

class MyModel(db.Model):
    prop1 = db.StringProperty()
    prop2 = db.IntegerProperty()
    def meth1(self):
        return do_something(self.prop1, self.prop2)

В плагине

class MyModelExtend(MyModel):
    def method1(self):
        return 'overrided'
    def new_method(self):
        pass

Процесс настройки будет происходить в конфиге

MyModel:
    extend:
        - MyModelExtend
        - MyModelExtend2
    properties:
        someprop1
            type: boolean
            default: true
            required: false

Будет одна фабрика классов, наример models, используемая как:

from ... import models

model = models.MyModel(...)

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

zheromo

Фев. 19, 2011 16:10:13

Андрей Светлов
Хотелось бы услышать ваше резюме…

Андрей Светлов

Фев. 19, 2011 16:36:43

Дайте немного подумать.