Python-сообщество

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

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

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

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

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

Отредактировано 4kpt (Авг. 21, 2013 10:05:11)

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

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

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

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

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

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

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

self.del_abonent = self.del

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

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

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

Отредактировано 4kpt (Авг. 21, 2013 12:13:08)

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

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

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

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

Отредактировано Budulianin (Авг. 21, 2013 12:38:49)