4kpt
P.S. По-моему, лучше сразу наследовать от словаря, а не от object…

Чем лучше ?

ntkirt
Теперь он выдает: …

Марк Лутц “Изучаем Python” стр 693

Как чем? Вы шутите? Вы используете словарь внутри класса как основное хранилище данных. Не лучше ли будет наследовать словарь и добавить к нему 2-3 новых метода. При этом старые методы остануться неизменными и ими можно будет пользоваться.

Хотя, по-большому, словарь здесь не подходит. Так как существует много “Ивановых Иван Ивановичей” с разными телефонами. В это случае лучше использовать синхронные списки :) Или создать свой тип данных (пользовательский)…

P.S. Чтобы методы были понятней, можно переопределить только их названия, а механизмы оставить без изменения.

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

Кстати, к вопросу об удобстве динамической типизации. Поменялся интерфейс в стороннем компоненте, то есть изменились сигнатуры методов. Как вы узнаете об этом? В юнит тестах сторонние объекты обычно заменяют мок объектами. Или на использование сторонних объектов тоже придется написать юниты?

4kpt
Как чем? Вы шутите?

Не, не шучу, просто уточняю :)

4kpt
Хотя, по-большому, словарь здесь не подходит. Так как существует много “Ивановых Иван Ивановичей” с разными телефонами.

А у меня ключ словаря это телефон, так что может быть много Ивановых, номера телефонов уникальны

4kpt
P.S. Чтобы методы были понятней, можно переопределить только их названия, а механизмы оставить без изменения.

Это как? Если мы переопределяем метод, то нам же его заново писать надо

Budulianin
А у меня ключ словаря это телефон, так что может быть много Ивановых, номера телефонов уникальны

Офигенный справочник. Зачем такое надо???
Как потом найти телефон Иванова? Искать по values()?

Budulianin
Это как? Если мы переопределяем метод, то нам же его заново писать надо

Имелос ввиду…
Главное, чтобы параметры у методов совпадали и они были логичными :)

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

P.S. Это спорный вопрос. Он просто касается подхода к проектированию :)

P.S.S. Я бы писал два класса. Один - хранилище (ведь у абонента может быть несколько номеров). Другой хранил бы два списка. Один - ФИО. Другой - список экземпляров первого класса. И именно во втором бы классе и была реализована вся фукнциональность. Как-то так…
Хотя можно, чтобы второй класс был словарем (в смысле наследовался от словаря), где по фамилии хранится ссылка на экземпляр класса-хранилища. Не уверен. Нужно пробовать :)
Мало того, хранилище можно было бы допилить. Если появится необходимость хранить еще и адрес.
Реально нужно пробовать и смотреть :)

4kpt
Офигенный справочник. Зачем такое надо???
Как потом найти телефон Иванова? Искать по values()?

Если использовать словарь, то да, только по values() искать

4kpt
Имелос ввиду…
self.del_abonent = self.del
Главное, чтобы параметры у методов совпадали и они были логичными :)

Спасибо :)

Budulianin
Если использовать словарь, то да, только по values() искать

Это при каждом поиске придется вынимать все данные из словаря? Не очень gut :)

4kpt
Это при каждом поиске придется вынимать все данные из словаря? Не очень gut :)

Я привёл простой пример на простой вопрос :)
Можно перебрать только {}.values()

с обычным словарём ничего больше не сделаешь