люди подскажите. пишу класс для работы с БД. везде прочитал что в таких ситуациях лучше использовать интерфейс, а от него уже отнаследовать класс и в нем реализовать функции интерфейса.
Вопрос: для чего нужен интерфейс, если у меня будет всего один класс отнаследован от него и все функции я могу вынести просто в сам класс по работе с БД.
p.s. Если интерфейс здесь все таки не нужен то в каких практических задачах их используют?
23.08.07 13:28: Перенесено модератором из '.NET' — TK
Здравствуйте, busk, Вы писали:
B>люди подскажите. пишу класс для работы с БД. везде прочитал что в таких ситуациях лучше использовать интерфейс, а от него уже отнаследовать класс и в нем реализовать функции интерфейса. B>Вопрос: для чего нужен интерфейс, если у меня будет всего один класс отнаследован от него и все функции я могу вынести просто в сам класс по работе с БД. B>p.s. Если интерфейс здесь все таки не нужен то в каких практических задачах их используют?
В твоей задаче не нужно. Если у тебя есть требование в последующем цепляться к разным базам (MSSQL, Oracle и прочее). То тут можно уже завязываться на наследование или реализацию интерфейсов. Рекомедуют использовать реализацию интерфейсов — применять компонет можно, на зная деталей его внутренней релизации, так как этот компонет сконструирован в соотв. с заранее заданным набором операций, определенных в интерфейсе. Иными словами, это проще. ИМХО.
Здравствуйте, busk, Вы писали:
B>люди подскажите. пишу класс для работы с БД. везде прочитал что в таких ситуациях лучше использовать интерфейс, а от него уже отнаследовать класс и в нем реализовать функции интерфейса. B>Вопрос: для чего нужен интерфейс, если у меня будет всего один класс отнаследован от него и все функции я могу вынести просто в сам класс по работе с БД. B>p.s. Если интерфейс здесь все таки не нужен то в каких практических задачах их используют?
За интерфейс очень удобно спрятать логику, специфичную для конкретной базе.
К примеру у тебя есть один интерфейс IDbConnector, и несколько реализаций, для Oracle, MS SQL, MySQL и т.д.
При этом основная твоя бизнес логика, ядро твоей программы работает только с интерфейсом IDbConnector и ничего не знает о конкретной БД.
Нужную имплементацию можно выбирать на основе конфига при старте системы.
Здравствуйте, busk, Вы писали:
B>люди подскажите. пишу класс для работы с БД. везде прочитал что в таких ситуациях лучше использовать интерфейс, а от него уже отнаследовать класс и в нем реализовать функции интерфейса. B>Вопрос: для чего нужен интерфейс, если у меня будет всего один класс отнаследован от него и все функции я могу вынести просто в сам класс по работе с БД. B>p.s. Если интерфейс здесь все таки не нужен то в каких практических задачах их используют?
Самый весомый а может быть и единственный плюс от интерфейсов — с их помощью можно реализовать множественное наследования ... иначе их можно было бы и не использовать а обойтись только классами ....
Здравствуйте, torso, Вы писали:
T>Здравствуйте, busk, Вы писали:
B>>люди подскажите. пишу класс для работы с БД. везде прочитал что в таких ситуациях лучше использовать интерфейс, а от него уже отнаследовать класс и в нем реализовать функции интерфейса. B>>Вопрос: для чего нужен интерфейс, если у меня будет всего один класс отнаследован от него и все функции я могу вынести просто в сам класс по работе с БД. B>>p.s. Если интерфейс здесь все таки не нужен то в каких практических задачах их используют?
T>За интерфейс очень удобно спрятать логику, специфичную для конкретной базе. T>К примеру у тебя есть один интерфейс IDbConnector, и несколько реализаций, для Oracle, MS SQL, MySQL и т.д. T>При этом основная твоя бизнес логика, ядро твоей программы работает только с интерфейсом IDbConnector и ничего не знает о конкретной БД. T>Нужную имплементацию можно выбирать на основе конфига при старте системы.
А вот тут я тогда не догоняю немного. Раньше я думал что работаю из приложения с БД через класс. А вы пишите что "ядро программы работает только с интерфейсом" Можно тогда разъяснить, получается если б у меня был интерфейс и отнаследованный класс от него, то я бы просто мог вызывать методы интерфейса, а он бы юзал соответствующюю реализацию? У меня кажется идет небольшое изменение в мозгу Я прав (не про мозг ? Если да, то можно тогда немного развить по поводу наследования интерфейсов. Когда нужно множественное наследование интерфейсов?
...
B>А вот тут я тогда не догоняю немного. Раньше я думал что работаю из приложения с БД через класс. А вы пишите что "ядро программы работает только с интерфейсом" Можно тогда разъяснить, получается если б у меня был интерфейс и отнаследованный класс от него, то я бы просто мог вызывать методы интерфейса, а он бы юзал соответствующюю реализацию? У меня кажется идет небольшое изменение в мозгу Я прав (не про мозг ? Если да, то можно тогда немного развить по поводу наследования интерфейсов. Когда нужно множественное наследование интерфейсов?
Если у тебя класс наследуется от интерфейса, и не является абстрактным, то значит этот класс реализует этот интерфейс, т.е.
IDbConnector — интерфейс, его реализует класс OracleDbConnector.
В классе OracleDbConnector, расписана вся логика по работе с базой.
При этом у тебя есть другие классы, которые ничего не знают об OracleDbConnector, они знают, только об интерфейсе IDbConnector.
Вот возможный вариант использования.
// настраиваем работу с конкретной базой, в конфиге прописано, что нужно использовать OracleDbConnector
DbConnectorManager.Load("config.xml");
// получаем конкретный коннектор
IDbConnector conn = DbConnectorManager.Instance.GetConnector();
// работаем с базой через интерфейс...
conn.ExecuteQuery("...");
Насчет множественного наследования, к примеру ты хочешь чтобы твой класс можно было сравнивать и клонировать, для этого ты реализовываешь сразу 2 интерфейса IComparable, ICloneable.
P.S.: Но вполне возможно тебе это и не нужно совсем. Если у тебя всего лишь одна база, и не планируется использования чего другого, то ты можешь напрямую использовать OracleDbConnector и не парится.
начинаем писать большую систему, знаем что в перспективе будет юзаться БД.
но пока есть только интерфейс в архитектуре, реализаций нет.
наша группа пишет модуль, кот. использует БД через этот интерфейс
на этапе разработки, можно обойтись одними моками, но если мы хотим запустить весь модуль
мы можем не ждать пока другая группа заимплеменит этот класс + сама БД.
мы просто делаем свою реализацию, кот. просто сохраняет все в текстовом файле например
дешево и сердито, и все работает.
кстати этот тестовый класс и потом вполне может применятся.
Здравствуйте, busk, Вы писали: B>p.s. Если интерфейс здесь все таки не нужен то в каких практических задачах их используют?
Еще интерфейсы используются там, где ты хочешь работать с объектами, но не можешь или не хочешь отдавать код объекта целиком. В этом случае с объектом можно работать через интерфейс, передав (объявив) только его, например, при клиент-серверной организации кода через Remotig.
Все на самом деле очень просто. В ООП программе эта самая программа разбита (декомпозирована) на элементарные сущности, называемые классами. Как написано во всех учебниках классы обладают тремя особенностями — инкапсуляцией, наследованием и полиморфизмом. Для начала рассмотрим инкапсуляцию. Идея ее очень проста — запихиваем внутрь класса детали реализации, а наружу выставляем ... Некое формальное описание того, что снаружи с этим классом можно сделать. Это описание обысно называется контрактом (contract). В простейшем случае контракт это просто совокупность публичных методов, полей и свойств с их сигнатурой. Но поля, однако, обычно в контракт не включают, и вобще стараются избежать их использования.
Далее. Наследование. Здесь есть один важный момент, который в старых книжках по ООП мейнстриму обычно опускают. Дело в том, что бывают два вида наследования — наследование реализации и наследование контракта. Первое — по сути синтаксические сахар и призвано съэкономить на убирании дублирования кода в повторяющихся сущностей. А вот второе — фундаментальное понятие и неразрывно связано с полиморфизмом.
Полиморфизм нужен для того, чтобы написать один алгоритм, работающий с разными сущностями. В мейнстриме полиморфизм строится на наследовании контрактов. Т.е., при соблюдении LSP, алгоритм, умеющий работать с базовым контрактом, умеет работать и с любым классом, этот базовый контракт реализующим.
Теперь обратимся к .NET. В этом случае у нас есть ровно два способа реализовать базовый контракт — отнаследоваться от класса и реализовать интерфейс. В первом варианте у нас происходят сразу две вещи — наследуется реализация и контракт одновременно. Во втором — наследуется только контракт. В этом, собственно, и состоит принципиальное отличие полиморфизма с использованием интерфейсов и базовых классов.
На практике это означает буквально следующие — использование интерфейсов вместо базовых классов убирает побочные эффекты от базовой реализации. Как побочный эффект от гарантированного отсутствия наследования реализаций — множественное наследование не приводит к неприятным побочным эффектам. Еще один побочный эффект — при вынесении интерфейсов и классов-параметров в отдельную сборку эта сборка не несет реализации, а, следовательно, может быть использована в клиентском коде без зависимости от кода серверного.
Поэтому, по возможности, стоит избегать публичного наследования и вместо него использовать реализацию интерфейсов + агрегацию. Еще один важный принцип — если instance метод класса может быть вынесен за пределы класса, он должен быть вынесен за пределы класса.
+1, емко сказано.
Почти дословно с главой из GoF "Программирование в соответствие с интерфейсом, а не реализацией"; вначале показалось, сверил с книгой — действительно.
K>Самый весомый а может быть и единственный плюс от интерфейсов — с их помощью можно реализовать множественное наследования ... иначе их можно было бы и не использовать а обойтись только классами ....
Вы так аргументированно и умнО все объяснили... Наверное книшку прочитали?
Здравствуйте, torso, Вы писали:
T>Здравствуйте, busk, Вы писали:
T>...
B>>А вот тут я тогда не догоняю немного. Раньше я думал что работаю из приложения с БД через класс. А вы пишите что "ядро программы работает только с интерфейсом" Можно тогда разъяснить, получается если б у меня был интерфейс и отнаследованный класс от него, то я бы просто мог вызывать методы интерфейса, а он бы юзал соответствующюю реализацию? У меня кажется идет небольшое изменение в мозгу Я прав (не про мозг ? Если да, то можно тогда немного развить по поводу наследования интерфейсов. Когда нужно множественное наследование интерфейсов?
T>Если у тебя класс наследуется от интерфейса, и не является абстрактным, то значит этот класс реализует этот интерфейс, т.е. T>IDbConnector — интерфейс, его реализует класс OracleDbConnector. T>В классе OracleDbConnector, расписана вся логика по работе с базой. T>При этом у тебя есть другие классы, которые ничего не знают об OracleDbConnector, они знают, только об интерфейсе IDbConnector. T>Вот возможный вариант использования. T>
T>// настраиваем работу с конкретной базой, в конфиге прописано, что нужно использовать OracleDbConnector
T>DbConnectorManager.Load("config.xml");
T>// получаем конкретный коннектор
T>IDbConnector conn = DbConnectorManager.Instance.GetConnector();
T>// работаем с базой через интерфейс...
T>conn.ExecuteQuery("...");
T>
T>Насчет множественного наследования, к примеру ты хочешь чтобы твой класс можно было сравнивать и клонировать, для этого ты реализовываешь сразу 2 интерфейса IComparable, ICloneable.
T>P.S.: Но вполне возможно тебе это и не нужно совсем. Если у тебя всего лишь одна база, и не планируется использования чего другого, то ты можешь напрямую использовать OracleDbConnector и не парится.
// настраиваем работу с конкретной базой, в конфиге прописано, что нужно использовать OracleDbConnector
DbConnectorManager.Load("config.xml");
// получаем конкретный коннектор
IDbConnector conn = DbConnectorManager.Instance.GetConnector();
// работаем с базой через интерфейс...
conn.ExecuteQuery("...");
Неправильно поняли меня. Я имел ввиду что к примеру есть длл которая предоставляет интерфейс по работе с базой. Там понятно, юзаешь этот интерфейс и всё. А в вашем примере, какой смысл юзать интерфейс, если можно все тоже самое делать с объектом самого класса. И все равно для каждого класса (SqlDB, OracleDB etc) нужно будет писать свою реализацию Зачем тут интерфейс?
B>// настраиваем работу с конкретной базой, в конфиге прописано, что нужно использовать OracleDbConnector
B>DbConnectorManager.Load("config.xml");
B>// получаем конкретный коннектор
B>IDbConnector conn = DbConnectorManager.Instance.GetConnector();
B>// работаем с базой через интерфейс...
B>conn.ExecuteQuery("...");
B>
B>Неправильно поняли меня. Я имел ввиду что к примеру есть длл которая предоставляет интерфейс по работе с базой. Там понятно, юзаешь этот интерфейс и всё. А в вашем примере, какой смысл юзать интерфейс, если можно все тоже самое делать с объектом самого класса. И все равно для каждого класса (SqlDB, OracleDB etc) нужно будет писать свою реализацию Зачем тут интерфейс?
Мне кажется, что поняли правильно Для каждой базы нужно будет писать свою реализацию (интерфейса) — это да. Давай рассмотрим ситуацию, что ты решил работать с другой базой. Используя интерфейс (как показано в примере) ты можешь легко настроить свою программу для работы с другой базой (указав единожды другой класс, изменив одну строчку), без интерфейсов (в частности, а в общем — без наследования) пришлось бы все (!) вызовы старого класса изменять на вызовы нового или, как вариант, не создавать новый класс, а изменить старый, но тогда старый код будет потерян.
Never argue with a woman who reads. It's likely she can also think. (c)
Здравствуйте, Agent Smith, Вы писали:
AS>Здравствуйте, busk, Вы писали:
B>>
B>>// настраиваем работу с конкретной базой, в конфиге прописано, что нужно использовать OracleDbConnector
B>>DbConnectorManager.Load("config.xml");
B>>// получаем конкретный коннектор
B>>IDbConnector conn = DbConnectorManager.Instance.GetConnector();
B>>// работаем с базой через интерфейс...
B>>conn.ExecuteQuery("...");
B>>
B>>Неправильно поняли меня. Я имел ввиду что к примеру есть длл которая предоставляет интерфейс по работе с базой. Там понятно, юзаешь этот интерфейс и всё. А в вашем примере, какой смысл юзать интерфейс, если можно все тоже самое делать с объектом самого класса. И все равно для каждого класса (SqlDB, OracleDB etc) нужно будет писать свою реализацию Зачем тут интерфейс?
AS>Мне кажется, что поняли правильно Для каждой базы нужно будет писать свою реализацию (интерфейса) — это да. Давай рассмотрим ситуацию, что ты решил работать с другой базой. Используя интерфейс (как показано в примере) ты можешь легко настроить свою программу для работы с другой базой (указав единожды другой класс, изменив одну строчку), без интерфейсов (в частности, а в общем — без наследования) пришлось бы все (!) вызовы старого класса изменять на вызовы нового или, как вариант, не создавать новый класс, а изменить старый, но тогда старый код будет потерян.
Пример очень понятен, спасибо!
но только ради такого дела, как то даже неинтересно интерфейсы использовать
Здравствуйте, Владислав, Вы писали:
В>Здравствуйте, kisel, Вы писали:
K>>Самый весомый а может быть и единственный плюс от интерфейсов — с их помощью можно реализовать множественное наследования ... иначе их можно было бы и не использовать а обойтись только классами ....
В>Вы так аргументированно и умнО все объяснили... Наверное книшку прочитали?
Иронизируешь?
Высказал свою точку зрения, аргументировать и т.п. нет времени ... Можно пойти от противного ...
Приведите ситуацию, где обязательным является использование интерфейса, при условии что не реализуется множественное наследование ...
Я сходу не вижу такой ситуации ... Вот Вам и своего рода аргумент ...
Здравствуйте, kisel, Вы писали:
K>Здравствуйте, Владислав, Вы писали:
В>>Здравствуйте, kisel, Вы писали:
K>>>Самый весомый а может быть и единственный плюс от интерфейсов — с их помощью можно реализовать множественное наследования ... иначе их можно было бы и не использовать а обойтись только классами ....
В>>Вы так аргументированно и умнО все объяснили... Наверное книшку прочитали? K>Иронизируешь? K>Высказал свою точку зрения, аргументировать и т.п. нет времени ... Можно пойти от противного ... K>Приведите ситуацию, где обязательным является использование интерфейса, при условии что не реализуется множественное наследование ... K>Я сходу не вижу такой ситуации ... Вот Вам и своего рода аргумент ...
А я пока чай заварится смогу Вам кучу ситуаций набросать.
Три принципа OOD в основе своей подразумевают контракты (интерфейсы)
1) Gooogle -> 'Dependency Inversion Principle' -> обратите внимание на статью с обжектментор
2) AndrewVK c небольшой помощью Gamma et al. упоминал чуть раньше в этой нитке 'при соблюдении LSP, алгоритм, умеющий работать с базовым контрактом, умеет работать и с любым классом, этот базовый контракт реализующим' Чтоб надежно енфорсить LSP (Google -> Liskov Substitution) лучше скрывать все реализации контракта (интерфейса)
3) Open/Close Principle. Open часть предполагает публичный интерфейс
4) Google -> TDD Mock object
5) Чай готов...
Здравствуйте, kisel, Вы писали:
K>Здравствуйте, Владислав, Вы писали:
В>>Здравствуйте, kisel, Вы писали:
K>>>Самый весомый а может быть и единственный плюс от интерфейсов — с их помощью можно реализовать множественное наследования ... иначе их можно было бы и не использовать а обойтись только классами ....
В>>Вы так аргументированно и умнО все объяснили... Наверное книшку прочитали? K>Иронизируешь? K>Высказал свою точку зрения, аргументировать и т.п. нет времени ... Можно пойти от противного ... K>Приведите ситуацию, где обязательным является использование интерфейса, при условии что не реализуется множественное наследование ...
Тут много всего привели умного) Я спущусь на землю, банальный ремотинг. Без интерфейсов отделить сервер от клиента, не показывая клиенту весь код сервера — можно, но оооооочень геморно
Здравствуйте, busk, Вы писали:
B>люди подскажите. пишу класс для работы с БД. везде прочитал что в таких ситуациях лучше использовать интерфейс, а от него уже отнаследовать класс и в нем реализовать функции интерфейса. B>Вопрос: для чего нужен интерфейс, если у меня будет всего один класс отнаследован от него и все функции я могу вынести просто в сам класс по работе с БД. B>p.s. Если интерфейс здесь все таки не нужен то в каких практических задачах их используют?
Сам и ответил на свой вопрос — не нужен тебе интерфейс. Понадобится реализовать возможность подключения к различным БД — опишешь интерфейс, заменишь в объявлении переменной имя класса на имя интерфейса. Не усложняй себе жизнь раньше времени.
Здравствуйте, Ivan Danilov, Вы писали:
ID>Здравствуйте, kisel, Вы писали:
K>>Здравствуйте, Владислав, Вы писали:
В>>>Здравствуйте, kisel, Вы писали:
K>>>>Самый весомый а может быть и единственный плюс от интерфейсов — с их помощью можно реализовать множественное наследования ... иначе их можно было бы и не использовать а обойтись только классами ....
В>>>Вы так аргументированно и умнО все объяснили... Наверное книшку прочитали? K>>Иронизируешь? K>>Высказал свою точку зрения, аргументировать и т.п. нет времени ... Можно пойти от противного ... K>>Приведите ситуацию, где обязательным является использование интерфейса, при условии что не реализуется множественное наследование ... ID>Тут много всего привели умного) Я спущусь на землю, банальный ремотинг. Без интерфейсов отделить сервер от клиента, не показывая клиенту весь код сервера — можно, но оооооочень геморно
Почему же ... абстрактынй класс не подойдёт?
Я прав (не про мозг
? Если да, то можно тогда немного развить по поводу наследования интерфейсов. Когда нужно множественное наследование интерфейсов?
