Soteric
Авг. 21, 2013 12:53:52
4kpt
SotericНу не знаю. По-мне понятнее и проще написать свой пользовательский тип наследуя от уже существующего. Зачастую большая часть задач уже реализована в стандартных типах. Необходимо лишь небольшое допиливание или докручивание. Зачем изобретать велосипед и писать большую часть методов заново. Не рациональнее ли использовать уже созданную функциональность.P.S. Это спорный вопрос. Он просто касается подхода к проектированию :)P.S.S. Я бы писал два класса. Один - хранилище (ведь у абонента может быть несколько номеров). Другой хранил бы два списка. Один - ФИО. Другой - список экземпляров первого класса. И именно во втором бы классе и была реализована вся фукнциональность. Как-то так…Хотя можно, чтобы второй класс был словарем (в смысле наследовался от словаря), где по фамилии хранится ссылка на экземпляр класса-хранилища. Не уверен. Нужно пробовать :)Мало того, хранилище можно было бы допилить. Если появится необходимость хранить еще и адрес.Реально нужно пробовать и смотреть :)
Ничего не потребуется изобретать и переписывать
class PhoneBook(object):
def __init__(self):
self.subscribers = {}
def addSubscriber(self, name, number):
self.subscribers[number] = name
def removeSubscriber(self, number):
del self.subscribers[number]
Клиент видит два понятных ему метода. Он не знает, что это словарь. При этом внутри у вас может храниться два словаря с маппингом абонент на номер и номер на абонента (для быстрого поиска). Или вы можете использовать сторонний компонент, реализующий такую функциональность. Таким образом будет выполняться
Open/closed principle, т.е. класс будет оставаться открытым для расширений, но закрытым для изменений.
4kpt
Авг. 21, 2013 13:06:41
Soteric
Смотрите. Опять же, Вы написали два метода, которые уже реализованы в словаре. Имеет ли смысл?
Хотя если объект имеет столь простое поведение и состояние, то действительно, зачем наседовать его от более сложного объекта и клеить к нему кучу ненужных методов. Может Вы и правы. Просто у меня все объекты имеют более сложное состояние и поведение. В результате это выливается в серьезную мозготряску относительно проектирования их структуры :)
P.S. Я писал выше, что предпочел бы использовать сторонний компонент (свой класс). Идея совпадает с моей (это второй класс о котором я говорил), но отлична в принципе. Я предлагал строить через наследование (от списка или словаря) - Вы с нуля :)
Soteric
Авг. 21, 2013 13:18:13
Почему же с нуля? Это тот же словарь, только не торчащий наружу всеми своими методами. А если надо, то из словаря он безболезненно станет списком, массивом или, как я уже говорил, превратится в десяток словарей, индексируя свойства абонента и позволяя осуществлять быстрый поиск. Я уж не говорю про многопоточность.
Хорошо, вы отнаследовались от словаря. Через какое-то время пришли к выводу, что словарь медленно и эффективнее будет сделать через какое-нибудь красно-черное тернарное дерево на основе графа по принципу Монте-Карло. Ваш класс больше не словарь. Но клиенты вашего класса уже понаписали кучу кода, который работает с ним как со словарем и ваши изменения сломают их код.
Ладно, такие дискуссии вечны. Ухожу :)
4kpt
Авг. 21, 2013 13:21:30
Soteric
Согласен. Разница в подходах. Можно общаться и общаться на эту тему. Из дисскусии мне стало ясно, что идея минимализма хороша, когда объект обладает 2-3 методами. Если мы говорим о серьезном поведении, где задействованы хотя-бы 15 методов да еще и часть из них реализована в существующем базовом типе, то можно конкретно “перетрудиться” всех их вылизывая :)
Тоже ушел. Начали явно спамить :)
dimy44
Авг. 21, 2013 18:41:07
Такая телефонная книга, что здесь обсуждается, это раве что для тренировки, несерьёзно, в симбиане например sql база для этого, а начавши со словарей итп, велика вероятность что придется все с нуля переписать.
4kpt
Авг. 21, 2013 19:26:31
dimy44
Так точно КЭП :)
Кончено, я бы базу поднимал на Postgree + GUI (Tkinter). Кто-то бы делал по-другому.
Просто обсуждались два подхода. Конечно же только в учебных целях или для очень маленьких баз. Вопрос о сохранении этого словаря также не поднимался. Лучше, в учебных целях, тогда использовать модуль shelve так как взаимодействие с ним очень напоминает словарь. Короче. Просто поспамили с Soteric чуть-чуть и разбежались :)
P.S. В реале, нужно было бы и веб прикручивать :)
P.S.S. Кстати, никто Вам не запрещает при этом подходе использовать в качестве первого класса какой-нибуть ORM :)
dimy44
Авг. 21, 2013 19:49:06
Это понятно)). А ещё в телефонной книге нет НИ ОДНОГО уникального параметра. Ни номера, ни имени. На один и тот-же номер можно назначить несколько человек (живут в коммуналке например, телефон один на всех), ну и с именами тоже ясно. В телефонах так и релизовано, там и дубли можно сделать… Не годится тут словарь.
py.user.next
Авг. 21, 2013 20:49:08
4kpt
Soteric
Смотрите. Опять же, Вы написали два метода, которые уже реализованы в словаре. Имеет ли смысл?
это не просто два метода словаря, а два читаемых метода
4kpt
Если мы говорим о серьезном поведении, где задействованы хотя-бы 15 методов
то ты просто через какое-то время перестанешь понимать, что они делают, потому что их названия ни о чём не говорят
Soteric
Но клиенты вашего класса уже понаписали кучу кода, который работает с ним как со словарем и ваши изменения сломают их код.
и это тоже
но главное, что реализуя это на методах словаря, нужно постоянно держать этот словарь в голове и помнить, что означают ключи и значения, тогда как думать нужно про другое
4kpt
Авг. 21, 2013 21:09:18
py.user.next
это не просто два метода словаря, а два читаемых метода
Про это мы говорили. Можно методы переназвать. Лишь бы эти методы имели одинаковые сигнатуры…
py.user.next
то ты просто через какое-то время перестанешь понимать, что они делают, потому что их названия ни о чём не говорят
Как названия стандартных методов встроенных типов могут ни о чем не говорить?
py.user.next
но главное, что реализуя это на методах словаря, нужно постоянно держать этот словарь в голове и помнить, что означают ключи и значения, тогда как думать нужно про другое
Господи. А пропринтовать его нельзя. Кроме того, никто не отменял __doc__.
P.S. Проблемы надуманы :) Без обид…
P.S.S. А педорить тонны кода, который практически удар в удар повторяет уже существующий, только лишь с отличием в названии методов для лучшего понимания - это хорошо? Еще раз повторюсь. Каждому свое. Мне так больше нравится :)
P.S.S.S. Я выскочил. Это уже в какой-то холивар превращается :)
py.user.next
Авг. 21, 2013 23:00:42
4kpt
А пропринтовать его нельзя.
пропринтовать что ?
4kpt
Можно методы переназвать. Лишь бы эти методы имели одинаковые сигнатуры
телефонная книга может иметь любые методы, а привязывать её к синтаксису словаря - это лишнее связывание кода
оно обязательно потом где-нибудь вылезет
4kpt
Кроме того, никто не отменял __doc__.
во-во, код должен быть понятным без всяких комментариев
когда будешь писать что-нибудь больше ста строк, тогда и поймёшь
__doc__ предназначен для интерактивной помощи
4kpt
Как названия стандартных методов встроенных типов могут ни о чем не говорить?
очень просто - они ничего не означают в контексте телефонной книги, потому что это методы словаря