Именование регистраторов Python
Хороший вопрос. Вот некоторые мысли из моего собственного опыта; не могу сказать, согласен ли Мартин (!), но, надеюсь, полезен.
Вкратце: основное различие связано с формальностью и выбором дизайна для отношений.
Я нашел следующие полезные :
- Базовая структура: грубо отображает UML Fowler как эскиз и выполняется интерактивно на доске. Основная цель - понять общую структуру. Очень неформальный. В частности, сосредоточиться на отношениях - это просто их идентифицировать, а не формализовать - поэтому нет мощности, поведения удаления, выбора классов контейнеров и т. Д.
- Модель домена. Точная модель, ориентированная на формализацию отношений. В частности, именование ассоциации заканчивается, определяя мощность и подтверждая поведение удаления. Не учитывает навигацию или выбор классов контейнеров для мощности> 1. Один из лучших методов, которые я знаю для изучения проблемного домена.
Я почти всегда использую оба вышеперечисленных. Ключевая вещь из модели домена заключается в использовании имени, основанного на глаголах, а не на основе роли - потому что в нем описывается, почему существует связь (эффективно обрабатывает бизнес-правила: например, «Заказ должен быть размещен ровно одним Клиентом»). Я использую шаблон именования, описанный в Simsion & amp; Книга Витта .
Должна быть выполнена работа по переводу модели домена на рабочий код, в частности, в отношениях. Языки программирования не поддерживают отношения очень хорошо, поэтому ассоциации должны быть переведены в атрибуты участвующих классов. Именно в этот момент вступает в действие судоходство, а также выбор типа коллекции для множественности> 1. Здесь также должны быть указаны все операции. Я лично не считаю этот тип диаграмм особенно полезным. Модель домена плюс код дают мне все, что мне нужно.
Я использую только UML как язык программирования, если я использую исполняемый UML-инструмент.
Извинения, если это немного бессвязно, надеюсь, что это поможет ...
PS: Если вам нужен лучший пример имен на основе глагола, у меня есть сообщение в моем блоге . Пожалуйста, не принимайте это за саморекламу, просто нечего повторять здесь.
3 ответа
Я обычно не использую или нахожу потребность в регистраторах уровня класса, но я сохраняю свои модули в нескольких классах самое большее. Простое:
import logging
LOG = logging.getLogger(__name__)
Наверху модуля и последующий:
LOG.info('Spam and eggs are tasty!')
отовсюду в файле обычно получает меня туда, где я хочу быть. Это избегает потребности в self.log повсеместно, который имеет тенденцию беспокоить меня от обоих put-it-in-every-class перспектива и делает меня 5 символами ближе к 79 символьным строкам то соответствие.
Вы могли всегда использовать pseudo-class-decorator:
>>> import logging
>>> class Foo(object):
... def __init__(self):
... self.log.info('Meh')
...
>>> def logged_class(cls):
... cls.log = logging.getLogger('{0}.{1}'.format(__name__, cls.__name__))
...
>>> logged_class(Foo)
>>> logging.basicConfig(level=logging.DEBUG)
>>> f = Foo()
INFO:__main__.Foo:Meh
Это похоже на него, будет работать, за исключением того, что self не будет иметь __module__ атрибут; его класс будет. Вызов регистратора уровня класса должен быть похожим:
self.log = logging.getLogger( "%s.%s" % ( self.__class__.__module__, self.__class__.__name__ ) )
Для ведения журнала на уровне класса, как альтернатива декоратору псевдокласса, вы можете использовать метакласс, чтобы сделать регистратор для вас во время создания класса ...
import logging
class Foo(object):
class __metaclass__(type):
def __init__(cls, name, bases, attrs):
type.__init__(name, bases, attrs)
cls.log = logging.getLogger('%s.%s' % (attrs['__module__'], name))
def __init__(self):
self.log.info('here I am, a %s!' % type(self).__name__)
if __name__ == '__main__':
logging.basicConfig(level=logging.DEBUG)
foo = Foo()