Отдельный класс по сравнению с методом

Вы нашли регулярное выражение, использующее синтаксис, который модуль стандартной библиотеки Python re не поддерживает.

Когда вы посмотрите на ссылку regex101, вы увидите, что шаблон работает при использовании библиотеки PRCE , а проблемный синтаксис (?R), который выдает ошибку, использует функцию под названием [ 1114] рекурсии . Эта функция поддерживается только подмножеством механизмов регулярных выражений .

Вы можете установить библиотеку regex , альтернативный механизм регулярных выражений для Pythont, который явно поддерживает этот синтаксис:

>>> import regex
>>> pattern = regex.compile(r'\{(?:[^{}]|(?R))*\}')
>>> pattern.findall('''\
... This is a funny text about stuff,
... look at this product {"action":"product","options":{...}}.
... More Text is to come and another JSON string
... {"action":"review","options":{...}}
... ''')
['{"action":"product","options":{...}}', '{"action":"review","options":{...}}']

Другой вариант - просто попытаться декодировать любой раздел который начинается с { с использованием метода JSONDecoder.raw_decode() ; см. Как использовать модуль 'json' для чтения по одному объекту JSON за раз? для примера подхода. В то время как рекурсивное регулярное выражение может найти JSON- подобный тексту , подход декодера позволит вам извлечь только действительный текст JSON.

Вот функция генератора, которая делает именно это:

from json import JSONDecoder

def extract_json_objects(text, decoder=JSONDecoder()):
    """Find JSON objects in text, and yield the decoded JSON data

    Does not attempt to look for JSON arrays, text, or other JSON types outside
    of a parent JSON object.

    """
    pos = 0
    while True:
        match = text.find('{', pos)
        if match == -1:
            break
        try:
            result, index = decoder.raw_decode(text[match:])
            yield result
            pos = match + index
        except ValueError:
            pos = match + 1

Демонстрация:

>>> demo_text = """\
This is a funny text about stuff,
look at this product {"action":"product","options":{"foo": "bar"}}.
More Text is to come and another JSON string, neatly delimited by "{" and "}" characters:
{"action":"review","options":{"spam": ["ham", "vikings", "eggs", "spam"]}}
"""
>>> for result in extract_json_objects(demo_text):
...     print(result)
...
{'action': 'product', 'options': {'foo': 'bar'}}
{'action': 'review', 'options': {'spam': ['ham', 'vikings', 'eggs', 'spam']}}

5
задан Duncan 19 December 2008 в 23:53
поделиться

6 ответов

Здесь существует несколько эвристики.

  1. Есть ли состояние на этом классе, который выживает от вызова до вызова? Это готовится, работа сделана каждый раз, когда Вам нужно к doSomething (), или это сделано и сохранено? Если так, это приводит доводы в пользу класса.
  2. Это вычисление должно произойти в несколько раз месте? Если так, это приводит доводы в пользу класса.
  3. Могут детали реализации doSomething () метод, или работа подготовки для него, изменение, не влияя на класс включения? Если так, это приводит доводы в пользу класса.

Ну, три эвристики. Никто не ожидает испанское Расследование.

4
ответ дан 18 December 2019 в 14:52
поделиться

Какова самая простая вещь, которая могла возможно работать? Это - молитва TDD. Не пытайтесь думать слишком далеко впереди. Если время настанет для создания класса помощника, то Вы будете знать это, потому что Вы будете делать все виды связанной работы в нескольких методах в других классах. До тех пор сделайте работу в своем методе. Если это делает метод слишком длинным или громоздким для чтения, извлеките работу к ее собственному методу. Этот метод может также быть протестирован к содержанию Вашей основы без потребности в другом классе.

4
ответ дан 18 December 2019 в 14:52
поделиться

Ваш дизайн объектной модели нужно рассмотреть на своем собственном, а не в контексте Вашей стратегии развития. Если создание ListOFStuff и передача к DoSomething действительно состоят в том, как объектная модель совмещается лучше всего, сделайте это, независимо от Вашей стратегии развития.

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

Надежда, которая помогает!

1
ответ дан 18 December 2019 в 14:52
поделиться

Начиная с принятия TDD и подхода DI, я видел количество классов, которые я пишу, умножаются - я должен быть взволнован?

Если Вашей целью является процедурное программирование, да. Но так как Вы почти наверняка желаете работать способом OO, нет.

Большинство людей использует слишком мало типов, проводит слишком мало времени, думая о дизайне OO.

Ваши вопросы об ответственности за класс отражают созревание размышления (по моему скромному мнению).

1
ответ дан 18 December 2019 в 14:52
поделиться

SoC допустим, только если рассматриваемое "беспокойство" не имеет никакого отношения к классу, или Вы находите классы, разделяющие это "беспокойство" (иначе, нарушая DRY). В Вашем случае кажется, что код является внутренним классу - так возможно a private функция была бы более склонной.

Как tvanfosson сказал выше, необходимо сбалансировать SoC с YAGNI. Лично - я думаю, что Вы могли бы обдумывать это преждевременно (я знаю! Я делаю это слишком все время).

1
ответ дан 18 December 2019 в 14:52
поделиться

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

Поместите его в класс, затем используйте тот класс в другом месте. Иначе необходимо было бы записать это снова и снова в будущем.

Чтобы сделать это расширяемым, и смочь передать во всех видах различных алгоритмов, шаблона разработки Ваш после вот, Стратегическая модель. Но это для будущего...

2
ответ дан 18 December 2019 в 14:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: