forum.bitel.ru http://forum.bitel.ru/ |
|
Абстрактный класс vs интерфейс, мнение разработчиков http://forum.bitel.ru/viewtopic.php?f=19&t=6949 |
Страница 1 из 1 |
Автор: | Феанор [ 10 июл 2012, 08:47 ] |
Заголовок сообщения: | Абстрактный класс vs интерфейс, мнение разработчиков |
Начитался теории по java и теперь какая-то каша в голове, прошу немного помочь и объяснить =) Проблема каши - отсутсвие опыта, естественно. Конкретная область - абстрактные классы и интерфейсы. В тырнетах пишут что абстрактный/статический класс - слабое место в архитектуре приложения (почему - не до конца понял), что тру ооп это интерфейсы. Ок. А что если у меня с десяток классов будут воплощать допустим интерфейс Datable, у которого должны быть методы setDate1/getDate1 и setDate2/getDate2. Писать для каждого класса тривиальные методы установки поля дата из входной даты вроде и не сложно, но не гуд с точки зрения DRY. Хорошо было бы вынести в абстрактный класс Dated и от него наследовать мои классы. Но что если понадобится в половине классов что то еще ввести, а в другой нет. Расширять класс Dated - не гуд, получится лишний код/поля для другой половины. Вводить класс, которым расширять Dated - тоже как то палево. С одной стороны во всех классах менять объявление того, какой метод расширяем (ну ок, это-то не самое страшное). С другой стороны - такая практика может привести к тому что создастся дерево абстрактных классов, некоторые ветки которых реально реализовать будет 1 класс только (что имхо оверкилл и усложнение необоснованное структуры). Решение с абстрактными классами кажется более простым - начинаем с самого мелкого Id класса и пошли дальше добавлять title, date1 и тд. Но смысл интерфейсов тогда вообще? Судя по апи BGBilling в ru.bitel.common.model идет последовательное наследование как раз таки классов id,itttle и так далее, хотя еще куча методов воплощает различные интерфейсы, допустим Contractable. Или общий код для различных классов одного интерфейса можно в какие то статические методы утилитного класса вынести? По своему опыту - как найти баланс между обязательствами интерфейсов и использованием общего кода наследуемого класса? upd почитал про всякие практики и паттерны используемые, посмотрел что АПИ бгбиллинговское представляет... Первое это вложенные классы. По идее ведь можно объявить в интерфейсе вложенный класс и общий код вынести туда. Это не избавляет от необходимости создавать методы объявленные в интерфейсе, но сводит их к вызову метода внутреннего класса. Код: interface Dated{
public static class DateSetter{ public static void setDate(Date date,String dateToSet){ date=TimeUtils.convertStringToDate(dateToSet); } setDate(String date); } public class Example implements Dated{ private Date date; public void setDate(String date){ Dated.DateSetter.setDate(this.date,date); } } |
Автор: | dimOn [ 10 июл 2012, 12:15 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
ООП это всего лишь одна из методологий. не нужно заморачиваться) интерфейс это тоже абстрактный класс по определению. |
Автор: | dimOn [ 10 июл 2012, 12:21 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
Какой смысл в интерфейсе Datable? Как он может использоваться в контексте интерфейса? Не нужно плодить интерфейсы просто чтобы было. |
Автор: | Феанор [ 10 июл 2012, 12:36 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
dimOn писал(а): Какой смысл в интерфейсе Datable? Как он может использоваться в контексте интерфейса? Не нужно плодить интерфейсы просто чтобы было. к примеру же ) |
Автор: | dimOn [ 10 июл 2012, 12:46 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
Ну так неудачный пример. Или же удачный пример того, как делать не нужно) |
Автор: | Феанор [ 10 июл 2012, 13:33 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
dimOn писал(а): Ну так неудачный пример. Или же удачный пример того, как делать не нужно) Ну потом же можно будет сделать так, допустим Код: public ArrayList<Datable> selectDeleted(ArrayList<Datable> array){ for(Datable item:array){ if(!item.getDate2().after(new Date()) array.remove(item); } return array; } для всех классов, которые у нас реализовали Datable. Зачем - не знаю, просто как пример для чего такой интерфейс простой может понадобиться - чтобы с ним потом в каком нибудь методе едином что-то можно было делать. ну а почему интерфейс, а не класс абстрактный - чтобы не делать длиннющую цепочку наследований классов, чтобы в такой метод перекинуть, а конкретный класс объявить как воплощающий интерфейсы конкретные (интерфейсов же можно воплощать несколько, а наследоваться только от одного класса). Это из плюсов интерфейсов, что у меня иерархия будет короче, но минус в том, что код тривиальный (чаще всего) надо будет повторять. Не могу пока почувствовать что в итоге больше гемороя принесет =) |
Автор: | dimOn [ 10 июл 2012, 13:41 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
Хм... ну в целом ясно. Но всё равно бессмысленные интерфейсы - типичный антипаттерн. |
Автор: | dimOn [ 10 июл 2012, 13:46 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
Феанор писал(а): Код: public ArrayList<Datable> selectDeleted(ArrayList<Datable> array){ for(Datable item:array){ if(!item.getDate2().after(new Date()) array.remove(item); } return array; } так нельзя делать ни в коем случае, этот код не будет работать или будет работать неправильно. при удалении итератор тупо сломается. надо удалять из самого итератора, для этого надо не пользоваться enhanced foreach loop а юзать несахарный итератор. |
Автор: | Феанор [ 10 июл 2012, 13:55 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
dimOn писал(а): Феанор писал(а): Код: public ArrayList<Datable> selectDeleted(ArrayList<Datable> array){ for(Datable item:array){ if(!item.getDate2().after(new Date()) array.remove(item); } return array; } так нельзя делать ни в коем случае, этот код не будет работать или будет работать неправильно. при удалении итератор тупо сломается. надо удалять из самого итератора, для этого надо не пользоваться enhanced foreach loop а юзать несахарный итератор. да да ![]() либо создать новую коллекцию и элементы которые под условие попадают в него добавить а потом их после завершения лупа удалять dimOn писал(а): Хм... ну в целом ясно. Но всё равно бессмысленные интерфейсы - типичный антипаттерн. Угу, вот я сейчас свой код сел приводить в порядок. Накожено (почти как нагажено, хотя по сути так оно и есть =)) много, причем с типичным так у нас никогда не будет.... ну блин, ладно, сейчас мы добавим вот сюда и вот сюда и все будет как надо... а теперь эта часть нужна немного по другому поэтому здесь мы поправим а туда добавим... Сейчас вроде устаканилось все более или менее, но чтоб на будущее такого не ловить решил поспрашивать у людей более опытных =) |
Автор: | dimOn [ 10 июл 2012, 13:58 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
ну это совсем уж)) делайте как я сказалъ) |
Автор: | Cromeshnic [ 11 июл 2012, 06:24 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
Цитата: Начитался теории по java и теперь какая-то каша в голове – Вот тебя как зовут? – спросил он у официанта. – Ипполит, – ответил тот. - Так вот кстати, Ипполит, был у меня один мой знакомый наперсточник, тоже Ипполит… Тезка твой – Ипполит, перечитался книжек, естественно, впал в депрессию и решил свести счеты с жизнью. Этот придурок поехал на рынок у ДК «Горбунова» и купил гранату. Вместо того, что бы поехать на нормальный рынок и купить там пистолет... (с) Даун Хаус http://www.youtube.com/watch?v=1wAY7nJcaC8 no offence ![]() |
Автор: | snark [ 12 июл 2012, 00:50 ] |
Заголовок сообщения: | Re: Абстрактный класс vs интерфейс, мнение разработчиков |
Феанор писал(а): интерфейс Datable Datable? Data bl e[лки-палки]? (BL ~= русс. Ы) date ble[ать]? [in] da table? [bro]??? Da ta[м] ble[ать]? D[imOn] ata[ta] ble[ать]? ??? |
Страница 1 из 1 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |