Средства доступа в Python когда-нибудь выровнены по ширине?
Я понимаю, что в большинстве случаев, это предпочтено в Python просто атрибутам доступа непосредственно, так как нет никакого реального понятия инкапсуляции, любят существует в Java и т.п.. Однако я задаюсь вопросом, нет ли никаких исключений, особенно с абстрактными классами, которые имеют разрозненные реализации.
Скажем, я пишу набор абстрактных классов (потому что я), и что они представляют вещи, имеющие отношение к системам управления версиями как репозитории и изменения (потому что они делают). Что-то как SvnRevision и HgRevision и GitRevision очень тесно семантически связано, и я хочу, чтобы они смогли сделать то же самое (так, чтобы у меня мог быть код в другом месте, который действует на любой вид Объекта репозитария и является агностиком подкласса), который является, почему я хочу, чтобы они наследовались абстрактному классу. Однако их реализации значительно варьируются.
До сих пор подклассы, которые были реализованы, совместно используют много названий атрибута, и в большом количестве кода за пределами самих классов, прямой доступ атрибута используется. Например, каждый подкласс Пересмотра сделал, чтобы автор приписал, и атрибут даты, и так далее. Однако атрибуты не описаны нигде в абстрактном классе. Это кажется мне как очень хрупкий дизайн.
Если кто-то хочет записать другую реализацию класса Пересмотра, я чувствую, что они должны смочь сделать так только путем рассмотрения абстрактного класса. Однако реализация класса, который удовлетворяет все абстрактные методы, почти наверняка перестанет работать, потому что автор не будет знать, что им нужны атрибуты, названные 'автором' и 'датой' и так далее, таким образом, код, который пытается получить доступ к Revision.author, выдаст исключение. Вероятно, не трудно для нахождения источника проблемы но раздражающий, тем не менее, и просто похоже на неэлегантный дизайн.
Мое решение состояло в том, чтобы записать методы доступа для абстрактных классов (get_id, get_author, и т.д.). Я думал, что это было на самом деле довольно чистым решением, так как оно устраняет произвольные ограничения на то, как атрибуты называют и хранят, и просто ясно дает понять, к каким данным объект должен смочь получить доступ. Любой класс, который реализует все методы абстрактного класса, будет работать..., который чувствует себя хорошо.
Так или иначе команда, с которой я работаю, ненавидит это решение (по-видимому по причине, что средства доступа являются unpythonic, который я не могу действительно обсудить с). Так..., какова альтернатива? Документация? Или проблема, я воображаю надуманный вопрос?
Примечание: Я рассмотрел свойства, но я не думаю, что они - более чистое решение.
4 ответа
Примечание: я рассматривал свойства, но не думаю, что они являются более чистым решением.
Но это так. Используя свойства, вы получите нужную вам сигнатуру класса, но при этом сможете использовать свойство как атрибут.
def _get_id(self):
return self._id
def _set_id(self, newid):
self._id = newid
Скорее всего, это похоже на то, что у вас есть сейчас. Чтобы успокоить вашу команду, вам просто нужно добавить следующее:
id = property(_get_id, _set_id)
Вы также можете использовать property в качестве декоратора:
@property
def id(self):
return self._id
@id.setter
def id(self, newid):
self._id = newid
А чтобы сделать его доступным только для чтения, просто опустите set_id/ бит id.setter.
Вы упустили суть. Не отсутствие инкапсуляции устраняет необходимость в аксессорах, а тот факт, что, перейдя от прямого атрибута к свойству, вы можете добавить аксессор в более позднее время, никак не изменяя опубликованный интерфейс.
Во многих других языках, если вы выставляете атрибут как публичный, а затем хотите обернуть некоторый код вокруг него при доступе или мутации, вам придется изменить интерфейс, а всем, кто использует этот код, придется как минимум перекомпилировать, а возможно, и редактировать свой код. В Python все не так: вы можете сколь угодно долго переключаться между атрибутом и свойством, и никакой код, использующий класс, не сломается.
"они должны быть в состоянии сделать это, просто взглянув на абстрактный класс"
Не знаю, что это должно быть правдой. Мне кажется уместным "руководство программиста", документ "как расширить", плюс некоторое обучение.
"автор не будет знать, что ему нужны атрибуты 'author', 'date' и так далее".
В этом случае документация неполная. Возможно, абстрактный класс нуждается в лучшей документации. Или "руководство программиста", или документ "как расширить".
Кроме того, не кажется очень сложным (1) документировать эти атрибуты в docstring и (2) предоставить значения по умолчанию в методе __init__.
Что плохого в предоставлении дополнительной поддержки программистам?
Похоже, что у вас социальная, а не техническая проблема. Написание кода для решения социальной проблемы кажется пустой тратой времени и денег.