Вопрос дизайна Python - PullRequest
       8

Вопрос дизайна Python

1 голос
/ 10 февраля 2010

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

Вот моя текущая проблема дизайна:

Конечный «продукт» - это структура данных JSON, созданная в Python (и переданная в код Javascript), содержащая различные типы данных, такие как:

{ type:url, {urlpayloaddict) }
{ type:text, {textpayloaddict}
...

Мой Javascript знает, как анализировать и отображать каждый тип ответа JSON.

Я доволен этим дизайном. Мой вопрос связан с обработкой этих данных в коде Python.

Я получаю свои данные из различных источников: MySQL, поиск в таблице, вызов API для веб-службы ... По сути, я должен создать суперкласс responseElement и специализировать его для каждого типа ответа, а затем передать список этих объектов в коде Python ИЛИ мне просто передать список словарей, содержащих ответ данные в парах ключ-значение. Ответ, по-видимому, приводит к существенно разным реализациям.

Я немного не уверен, получаю ли я слишком объект счастлив ??

Ответы [ 5 ]

5 голосов
/ 10 февраля 2010

По-моему, это в основном так: вы должны стараться сохранять вещи одинаковыми там, где они одинаковы , и отделять их там, где они разные.

Если вы выполняете одни и те же операции с данными и с данными, и все они могут быть представлены в общем формате, то нет причин иметь для них отдельные объекты - переведите их в общий формат как можно скорее Повторите Себя, когда дело доходит до реализации вещей, которые не различают.

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

3 голосов
/ 10 февраля 2010

Представляют ли разные источники ответов принципиально разные категории или класс объектов? Они не выглядят так, как вы это описали.

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

Этот тип может быть dict или вашим собственным классом, если у вас есть специальные методы для использования с данными (но тогда этим методам было бы безразлично, какие были входные и выходные кодировки), или вы можете поместить пары кодирования / декодирования в класс. (Декодирование будет методом класса, возвращающим новый экземпляр.)

2 голосов
/ 10 февраля 2010

Ваши объекты-получатели (которые вполне могут быть экземплярами разных классов, возможно, сгенерированными шаблоном Factory в зависимости от источника входящих данных) должны иметь общий метод, который возвращает соответствующий dict (или другой напрямую-JSON'able структура, такая как список, который превратится в массив JSON).

В отличие от того, что говорится в одном ответе, этот подход явно не требует кода более высокого уровня, чтобы знать, с каким именно типом приемника он имеет дело (полиморфизм справится с этим для вас в любом ОО-язык!) - и при этом код более высокого уровня не должен знать «имена ключей» (как, впрочем, тот особый ответ, который обычно указывается в другом ответе), так как он вполне может трактовать «данные в формате JSON» как довольно непрозрачные токен данных (если он подходит в качестве аргумента для последующего вызова json.dumps!).

Создание и передача контейнера объектов «простых старых данных» (производимых и добавляемых в контейнер различными способами) для возможной сериализации (или другой такой унифицированной обработки, но вы можете видеть перевод JSON как особую форму сериализации ) - это общий шаблон ОО. В конце концов, нет необходимости носить с собой что-либо более богатое или тяжелое, чем такие данные POD, и в Python использование dict s в качестве POD часто является совершенно естественным выбором реализации.

1 голос
/ 10 февраля 2010

Лично я выбираю последнее (передавая список данных) везде и всегда, когда это возможно. Я думаю, что ОО часто злоупотребляют / злоупотребляют для определенных вещей. Я специально избегаю таких вещей, как обертывание данных в объекте просто ради обертывания его в объекте. Так что, {'type':'url', 'data':{some_other_dict}} лучше для меня, чем:

class DataObject:
    def __init__(self):
        self.type = 'url'
        self.data = {some_other_dict}

Но если вам нужно добавить к этим данным определенную функциональность, например, возможность сортировать свои data.keys () и возвращать их как набор, тогда создание объекта имеет больше смысла.

1 голос
/ 10 февраля 2010

У меня был успех с подходом ООП. Рассмотрим базовый класс с методом «ToJson» и пусть каждый подкласс реализует его соответствующим образом. Тогда вашему высокоуровневому коду не нужно знать никаких подробностей о том, как были получены данные ... он просто знает, что должен вызывать «ToJson» для каждого объекта в списке, который вы упомянули.

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

ООП я говорю!

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