Иерархия классов Python с вложенным расположением - имеет ли смысл?

Я столкнулся с некоторыми странными ошибками и просто задаюсь вопросом, есть ли у меня фундаментальная проблема в моей иерархии классов. Я абсолютно новичок, если дело доходит до python. Так что, если этот подход выглядит как полный дерьмо - вы знаете, почему это :-)

У меня есть несколько классов в приложении, которое я создал вокруг шаблона MVC. Контроллер приложений управляет четырьмя объектами, которые я называю «устройствами», поскольку они действуют как независимые устройства. В этом случае каждое устройство запускает действия (вычисления), обработку изображений. Эти действия предназначены для запуска внутри отдельных потоков. Поэтому каждое устройство должно открыть «собственный» поток и выполнить его вычисления в этом потоке.

Для этого я разработал базовый класс, описывающий «устройство», поэтому все устройства наследуют их базовую настройку и логику, особенно то, как они контролируются контроллером. Для потоков я реализовал класс «worker», я планирую нажимать экземпляры классов в потоки. Эта часть еще не работает. Эти рабочие классы создаются следующим образом: класс базового устройства содержит базовый класс вложенного рабочего класса. Он также реализует некоторые базовые методы управления для обработки экземпляра рабочего, который хранится как член класса базового устройства. Все специализированные классы устройств (производные от класса базового устройства) также реализуют вложенный рабочий класс. Эти классы производятся от базового рабочего класса, вложенного в класс базового устройства. Вот эскиз иерархии:

/class Device/
             /methods
             /members
             /class Worker/
                          /methods
                          /members
/class fooDevice(Device)/
                        /methods
                        /members
                        /class fooWorker(Device.Worker)/
                                                       /methods
                                                       /members
/class barDevice(Device)/
                        /methods
                        /members
                        /class barWorker(Device.Worker)/
                                                       /methods
                                                       /members

Обратите внимание, что классы fooWorker и barWorker являются производными от Device.Worker !

Мой вопрос: хотя материал, похоже, работает во время установки, я получаю ошибки времени выполнения. пока не уверены, откуда они взялись, что они означают. Но сначала я хочу понять, что макет иерархии классов, который я составил, имеет смысл вообще? Это полностью искривленная ерунда? Или широко используется?

Благодаря!

0
nl ja de
@martineau Спасибо, но я не вижу ничего нового в этих ответах. Обратите внимание, что у меня нет проблем с вложением, это прекрасно работает. Мой вопрос был, если это подход, который имеет смысл.
добавлено автор arkascha, источник
@martineau Конечно, я читал это много раз. Однако типичная причина заключается в том, что доступ к инсталляциям вложенных классов сложнее. Я действительно не вижу эту проблему, ссылки логичны и не сложны. Я был неуверен в наследовании на уровнях гнездования как набросанные работы и имеет смысл. На самом деле у меня все получилось. Вопрос был совершенно не связан с структурой наследования.
добавлено автор arkascha, источник
@martineau Конечно, я читал это много раз. Однако типичная причина заключается в том, что доступ к инсталляциям вложенных классов сложнее. Я действительно не вижу эту проблему, ссылки логичны и не сложны. Я был неуверен в наследовании на уровнях гнездования как набросанные работы и имеет смысл. На самом деле у меня все получилось. Вопрос был совершенно не связан с структурой наследования.
добавлено автор arkascha, источник
@martineau Конечно, я читал это много раз. Однако типичная причина заключается в том, что доступ к инсталляциям вложенных классов сложнее. Я действительно не вижу эту проблему, ссылки логичны и не сложны. Я был неуверен в наследовании на уровнях гнездования как набросанные работы и имеет смысл. На самом деле у меня все получилось. Вопрос был совершенно не связан с структурой наследования.
добавлено автор arkascha, источник
@martineau Спасибо, но я не вижу ничего нового в этих ответах. Обратите внимание, что у меня нет проблем с вложением, это прекрасно работает. Мой вопрос был, если это подход, который имеет смысл.
добавлено автор arkascha, источник
@martineau Спасибо, но я не вижу ничего нового в этих ответах. Обратите внимание, что у меня нет проблем с вложением, это прекрасно работает. Мой вопрос был, если это подход, который имеет смысл.
добавлено автор arkascha, источник
Хорошо спасибо, я уже разделил это приложение на несколько модулей, что действительно помогает в домашнем хозяйстве. Вложенность была естественной для меня, так как рабочие - нечто внутреннее для устройств. Но вы оба правы: я не вижу никакого технического преимущества этого дизайна. Вероятно, я должен «освобождать» рабочие классы и вместо этого ссылаться на них по уникальным именам.
добавлено автор arkascha, источник
Хорошо спасибо, я уже разделил это приложение на несколько модулей, что действительно помогает в домашнем хозяйстве. Вложенность была естественной для меня, так как рабочие - нечто внутреннее для устройств. Но вы оба правы: я не вижу никакого технического преимущества этого дизайна. Вероятно, я должен «освобождать» рабочие классы и вместо этого ссылаться на них по уникальным именам.
добавлено автор arkascha, источник
Хорошо спасибо, я уже разделил это приложение на несколько модулей, что действительно помогает в домашнем хозяйстве. Вложенность была естественной для меня, так как рабочие - нечто внутреннее для устройств. Но вы оба правы: я не вижу никакого технического преимущества этого дизайна. Вероятно, я должен «освобождать» рабочие классы и вместо этого ссылаться на них по уникальным именам.
добавлено автор arkascha, источник
Хорошо спасибо, я уже разделил это приложение на несколько модулей, что действительно помогает в домашнем хозяйстве. Вложенность была естественной для меня, так как рабочие - нечто внутреннее для устройств. Но вы оба правы: я не вижу никакого технического преимущества этого дизайна. Вероятно, я должен «освобождать» рабочие классы и вместо этого ссылаться на них по уникальным именам.
добавлено автор arkascha, источник
Иерархия классов определяется отношением наследования класса, а не их вложением. Если у вас нет особого варианта использования, не вставляйте определения классов. Если вы ищете эквивалент пространства имен, используйте модули и пакеты.
добавлено автор Ber, источник
Иерархия классов определяется отношением наследования класса, а не их вложением. Если у вас нет особого варианта использования, не вставляйте определения классов. Если вы ищете эквивалент пространства имен, используйте модули и пакеты.
добавлено автор Ber, источник
Ответы на вопрос область вложенных классов Python могут вас заинтересовать.
добавлено автор martineau, источник
Ответы на вопрос область вложенных классов Python могут вас заинтересовать.
добавлено автор martineau, источник
Ответы на вопрос область вложенных классов Python могут вас заинтересовать.
добавлено автор martineau, источник
Хотя вы можете вложить определения классов в Python, на самом деле он не предоставляет m (каких-либо) преимуществ, кроме того, что их сложно использовать.
добавлено автор martineau, источник
Ответы на вопрос область вложенных классов Python могут вас заинтересовать.
добавлено автор martineau, источник
@arkascha: Я думал, что вопрос имеет значение, потому что большинство ответов, казалось, говорили о том, что в Python вообще следует избегать вложения классов (и почему, как и как, для достижения подобных результатов в некоторых случаях).
добавлено автор martineau, источник
@arkascha: Я думал, что вопрос имеет значение, потому что большинство ответов, казалось, говорили о том, что в Python вообще следует избегать вложения классов (и почему, как и как, для достижения подобных результатов в некоторых случаях).
добавлено автор martineau, источник
@arkascha: Да, хотя его кажется (и есть) очень логичным и, безусловно, работает, в Python, внутренний класс не имеет специального доступа к области внешнего класса или получает что-то еще от него - так для большинства людей просто предоставление пространства имен не стоит проблем и может даже заставить некоторых поверить - ошибочно - между ними была какая-то зависимость.
добавлено автор martineau, источник
@arkascha: Да, хотя его кажется (и есть) очень логичным и, безусловно, работает, в Python, внутренний класс не имеет специального доступа к области внешнего класса или получает что-то еще от него - так для большинства людей просто предоставление пространства имен не стоит проблем и может даже заставить некоторых поверить - ошибочно - между ними была какая-то зависимость.
добавлено автор martineau, источник

3 ответы

Вложенные классы могут иметь смысл. Django использует их для конфигурации Meta в моделях и формах. Я иногда использую их в заводских шаблонах, например.

   class BaseFactory(object):
      class FactoryItem(object):
          pass 

      @classmethod
      def create(cls):
          return cls.FactoryItem()

   class ShoeFactory(BaseFactory):
      class FactoryItem(BaseFactory.FactoryItem):
          def laces(self):
              return 1

Но вы можете так же легко определить классы FactoryItem глобально и назначить их члену класса «FactoryItem», например.

class Shoe(BaseFactory.FactoryItem):
    ...

class ShoeFactory(BaseFactory):
    FactoryItem = Shoe

Единственная проблема, с которой я столкнулся, - десериализация объектов. Я не могу вспомнить, когда/где/почему, возможно, маринован был где-то использован, и он не смог разрешить вложенный класс.

Какие конкретные проблемы времени выполнения вы испытываете?

1
добавлено
RuntimeError: '__init__' метод базового класса объекта (Worker), который не вызывается. Он возникает, когда я вызываю self.worker.moveToThread (self.thread) , поэтому попытайтесь переместить экземпляр QThread в поток (я использую привязки pySide Qt). Это несколько смешно, так как мой вывод отладки явно доказывает, что для каждого рабочего объекта, вызванного как функциями init , вызываются: для самого рабочего класса и для базового рабочего класса. I мысль проблема может быть вызвана вложением классов. На самом деле я прочитал несколько вещей о мариновании сейчас и думаю, что стоит следить за этим чувством ...
добавлено автор arkascha, источник

Вложенные классы могут иметь смысл. Django использует их для конфигурации Meta в моделях и формах. Я иногда использую их в заводских шаблонах, например.

   class BaseFactory(object):
      class FactoryItem(object):
          pass 

      @classmethod
      def create(cls):
          return cls.FactoryItem()

   class ShoeFactory(BaseFactory):
      class FactoryItem(BaseFactory.FactoryItem):
          def laces(self):
              return 1

Но вы можете так же легко определить классы FactoryItem глобально и назначить их члену класса «FactoryItem», например.

class Shoe(BaseFactory.FactoryItem):
    ...

class ShoeFactory(BaseFactory):
    FactoryItem = Shoe

Единственная проблема, с которой я столкнулся, - десериализация объектов. Я не могу вспомнить, когда/где/почему, возможно, маринован был где-то использован, и он не смог разрешить вложенный класс.

Какие конкретные проблемы времени выполнения вы испытываете?

1
добавлено
RuntimeError: '__init__' метод базового класса объекта (Worker), который не вызывается. Он возникает, когда я вызываю self.worker.moveToThread (self.thread) , поэтому попытайтесь переместить экземпляр QThread в поток (я использую привязки pySide Qt). Это несколько смешно, так как мой вывод отладки явно доказывает, что для каждого рабочего объекта, вызванного как функциями init , вызываются: для самого рабочего класса и для базового рабочего класса. I мысль проблема может быть вызвана вложением классов. На самом деле я прочитал несколько вещей о мариновании сейчас и думаю, что стоит следить за этим чувством ...
добавлено автор arkascha, источник

Вложенные классы могут иметь смысл. Django использует их для конфигурации Meta в моделях и формах. Я иногда использую их в заводских шаблонах, например.

   class BaseFactory(object):
      class FactoryItem(object):
          pass 

      @classmethod
      def create(cls):
          return cls.FactoryItem()

   class ShoeFactory(BaseFactory):
      class FactoryItem(BaseFactory.FactoryItem):
          def laces(self):
              return 1

Но вы можете так же легко определить классы FactoryItem глобально и назначить их члену класса «FactoryItem», например.

class Shoe(BaseFactory.FactoryItem):
    ...

class ShoeFactory(BaseFactory):
    FactoryItem = Shoe

Единственная проблема, с которой я столкнулся, - десериализация объектов. Я не могу вспомнить, когда/где/почему, возможно, маринован был где-то использован, и он не смог разрешить вложенный класс.

Какие конкретные проблемы времени выполнения вы испытываете?

1
добавлено
RuntimeError: '__init__' метод базового класса объекта (Worker), который не вызывается. Он возникает, когда я вызываю self.worker.moveToThread (self.thread) , поэтому попытайтесь переместить экземпляр QThread в поток (я использую привязки pySide Qt). Это несколько смешно, так как мой вывод отладки явно доказывает, что для каждого рабочего объекта, вызванного как функциями init , вызываются: для самого рабочего класса и для базового рабочего класса. I мысль проблема может быть вызвана вложением классов. На самом деле я прочитал несколько вещей о мариновании сейчас и думаю, что стоит следить за этим чувством ...
добавлено автор arkascha, источник
Python
Python
7 654 участник(ов)

Уютный чат для профессионалов, занимающихся поиском питоньих мудростей. Как не получить бан: https://t.me/ru_python/577926

Python beginners
Python beginners
4 449 участник(ов)

Вопросы про Python для чайников. Cпам и троллинг неприемлем. Не злоупотребляйте стикерами. Частозадаваемые вопросы: https://github.com/ru-python-beginners/faq/blob/master/README.md Статистика тут: https://grstats.me/chat/x4qym2k5uvfkr3al6at7

Software Design and OOP
Software Design and OOP
1 481 участник(ов)

OOP, software design, architecture, GRASP, GoF, SOLID, separation of concerns, безысходность. Пожалуйста, придерживайтесь указанных тем. https://oopru.github.io More cool stuff: @fp_ru @tdd_ru @coding_interview_ru @coding_ru

pro.python
pro.python
1 090 участник(ов)

Сообщество разработчиков под Python Создатель: @rodgelius

Rude Python
Rude Python
971 участник(ов)

Python без „девочек”, здесь матерятся и унижают Django. Not gay friendly. Правила: t.me/rudepython/114107 @rudepython | t.me/rudepython

rupython
rupython
509 участник(ов)

Группа создана с целью оперативного получения ответов на возникающие вопросы по разработке на яп python, смежные темы, а также человеческого общения. Приветствую!

Python-programming
Python-programming
266 участник(ов)

Чат группы вконтакте https://vk.com/python_community