Зачем абстрактные классы? C# и не только #747340

Решил посмотреть другие языки программирования помимо 1с, про ООП почитал видео посмотрел. так и не понял зачем создавать абстрактный класс, а потом на основании него создавать потомка в котором должны быть описаны алгоритм методов? почему бы сразу не создать класс и в нем не прописать алгоритм методов? и при необходимости от него создавать потомков добавляя например новые методы?

Решил посмотреть другие языки программирования помимо 1с, про ООП почитал видео посмотрел. так и не понял зачем создавать абстрактный класс, а потом на основании него создавать потомка в котором должны быть описаны алгоритм методов? почему бы сразу не создать класс и в нем не прописать алгоритм методов? и при необходимости от него создавать потомков добавляя например новые методы?

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

в 1С также: Документ абстрактный класс, нельзя создавать экземпляры непосредственно данного класса. А вот ПКО, РКО и проч. - вполне конкретные классы и проведение в каждом из них реализовано по своему

а может "Млекопитающие" это не абстрактный класс, а интерфейс?

В абстрактном классе можно создавать реализацию методов. Абстрактность тебе не позволит создать экземпляр класса.

это хорошая тема обсуждения: интерфейс против абстрактный класс но если надо что-то хранить еще (поля), то только абстрактный класс, аналогично с защищенными методами

согласен, но какой практический смысл? у каждого представителя свой класс в нем метод "Кормить молоком" по любому создаваться объект будет из класса представителя и использоваться метод будет именно представителя. зачем он в абстрактном вписан?

Еддинственная разница в надежности и защиты от ошибок в разработке и в некотором смыслле улучшениии чтения кода. К примеру обстрактный класс дает понять программисту что нельзя создавать экземпляр этого класса, что некоторые методы нужно обязательно реализовать. Но работать будет одиаково с вашим вариантом

а штобы можно было взять конкретного потомка человек1 типа "Человека" и сделать такой ход конем: (Млекопитающее)человек1.ПокормитьМолоком;

В современных языках все стало размыто, но "по классике" интерфейс не может содержать реализации методов, от интерфейса нельзя наследоваться, только реализовать.

т.е. код может не знать нифига о "Человека" но зная что оно произошло от "Млекопитающее" можно вызвать метод абстрактного класса для конкрентного потомка и он как нуна отработает

тут не важно будь млекопитающее абстрактным классом, или быкновенным классом или интерфейсом

Вообще, нужно сначала понять, с какой целью был создан тот или иной механизм.

про это и речь... не факт что все млекопитающие произошли от одного потомка... у них просто есть одинаковый (похожий) метод кормления детенышей ))

возьми за пример игру space invaders. Есть корабли, есть мухи. Это летатаельные объекты. Коробли управляемые пользователем. Мухи летают сами. Считай наследники класса. Мухи, в свою очередь, летают по разному. имеют разные свойства (ХП, скорость stc)...

Что бы абстрагироваться от конкретных объектов. Вот например, ты пишешь программу для рисования векторной графики. У тебя есть объект прямая, кривая безье, круг, треугольник. Все их можно нарисовать. Но каждый из них рисуется по разному. Но эти объекты тебе придется где то хранить. Для этого нужен общий тип, который походит ко всем этим объектам. Это и есть абстрактный класс. но так как ты не знаешь, круг это будет или треугольник, ты не можешь у этого типа реализовать метод "рисовать". Но зато можешь объявить класс потомок, у которого ты его реализуешь, у каждого класса свой. И переменной типа "Абстрактный класс фигуры" ты можешь присвоить любого потомка этого класса.

метод ПокормитьМолоком может быть в общем случае реализован в абстрактном классе. Класс-потомок может его переопределить при необходимости.

А зачем вообще сделали и интерфейсы и абстрактные классы? Типо 2 команды разрабатывали по отдельности. Потом не решили что есть лучше и включили обе штуки?

ок спасибо всё понял, просто в августе в магистратуру поступаю на прикладное программирование вот и приходиться в тему въезжать

А ещё есть делегаты...

А есть еще трейты и миксины.

Могу на примере перивести допустим надо создать обработку отрисовки нескольких объектов, объекты разноплановые и единственное что их объединяет - это то что их можно рисовать. Создаем абстрактный класс GLESObject например. А от него наследуем все остальное Rectangle2D extends GLESObject Cube3D extends GLESObject CubeMap3D extends GLESObject в которых уже мы непослередственно всю реализацию и отрисовку прописываем. после создания объектом, наб будет достаточно пробижаться по массиву объектов GLESObject чтобы их все нарисовать сразу, и не потребуется перебирать массивы по отдельности для каждого класса.         for (GLESObject tekObject:sceneLayer) {             GLES20.glUseProgram(tekObject.getShaderProgramInstance.programHandler);                                     tekObject.draw(viewMatrix,projectionMatrix, timer);                                                         }

В C#, например, класс может наследовать несколько интерфейсов, а несколько классов не может. Хотя, в C++ пошли другим путем, сделали множественное наследование. А вообще, интерфейс как вариант, применяется там, где надо создать СCOM-объект.

я не понял это форум 1С-ников или "канал об аниме" ?

>в C++ пошли другим путем, сделали множественное наследование порочная практика

одинесники не программисты

Всё наблюдаемое многообразие ЯП из-за несовершенства C++

Да, действительно, там даже есть такое понятие, как виртуальный класс, что бы он два раза не наследовался.

Самый простой пример это Stream. Используя единый интерфейс ты можешь читать хоть откуда. Из файла, из WebResponse из базы данных итд

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

Абстрактные классы и интерфейсы и протоколы - для реализации одних из самых важных паттернов: Фабрика, Абсрактная Фабрика, Делегирование. Для 1Сников. у тебя один абстрактный класс, который говорит что, чтобы класс ему соответсвовал (conforms to), тот должен иметь вот такие-то обязательные свойства и методы. Потом ты например объявляешь процедуру func MyProcedure(SomeInstance: MyProtocol) А когда вызываешь эту процедуру, то уже пишешь: MyProcedure(MyInstanceOfFirstClassConformedToMyProtocol) MyProcedure(MyInstanceOfSeconfClassConformedToMyProtocol) То есть по сути Абстрактный класс ну... помогает абстрагироваться от конкретного типа.

про NULL и Неопределено еще рано?

"почему бы сразу не создать класс и в нем не прописать алгоритм методов" - а кто сказал, что так не делают? как раз так и делают. но прописывают "алгоритмы" общие для всех потомков.

Придумать правильную топологию классов для программы отнюдь не простая задача

2 Optionals?

как бы 1С-ники пользуются "абстрактными классами" совершенно об этом не задумываясь когда вызывают .Записать; для объекта справочника

пусть поближе подойдут

еще есть модуль менеджера

28+ виртуальные методы в отличие от методов интерфейсов наследуются. То есть меньше писанины

Это утинная типизация. Нет наследования

Если ты не знаешь, что такое абстрактный класс, то это тебе не надо...

это static. причем тут абстракция

можно сказать, что класс автоматически реализует "интерфейс имеющий метод Записать", как только у него есть этот метод ))) ну собственно да, утиная типизация и все абсолютно методы виртуальны ))

ближе к дельфийским class method чем к static method

А ты с самого рождения знал, что такое абстрактный класс?

В Delphi есть такое понятие как метаклассы. Виртуальный конструктор, виртуальные методы класса class Function StaticVirt:String; virtual;

Попробовал глянуть на эту ветку отстраненно... хуже только математики с их "абстракциями" он в его методе потомка родился...

забудьте уже про дельфи как про страшный сон

счего бы? точнее с удовольствием бы забыли но на чем (кроме с++ на котором слишком тормозно писать) можно сделать кроссплатформенный код который не требует туеву тучу фремворков и прочих окружений?

Вот в 1С-ке очень ОПП, кстати, не хватает. Как было бы хорошо, если бы когда мне потребовалось написать, например, свою расходную накладную, я типа объявил бы потомка класса РасходнаяНакладная и реализовал бы у нее какие то свои методы.

ну почему? реализация метакласса на уровне языка была неплохой, хотя и страдала проблемой - нельзя было сокрыть конструкторы, из-за общего предка TObject

он не хочет отпускать

начинается...

Как бы наоборот. Интерфейсы придумали, поглядев на проблемы множественного наследования в С++. Чтобы с помощью них и ряда других инструментов языка можно было безопасно решать задачи, которые в С++ решались множественным наследованием.

да ладно пусть помечтает об 1С++ для 8-ки

Вот в 1С-ке очень ОПП, кстати, не хватает. 1с тут вполне ООП... у тебя РасходнаяНакладная просто изолирована

злой ты

если почтиать мануал какой-нибудь, то ответ там будет дан. Абстрактные классы для того, чтобы просто сгруппировать набор абстрактных методов, которым не нужен ни какой инстанс для работы. Math, например, в C#, - ни какого объекта ему не придумать, а функции его нужны

Lf

опасностьЪ! тебя щас Ежов покусает

Math вроде не абстрактный, а статический класс

>Абстрактные классы для того, чтобы просто сгруппировать набор абстрактных методов, которым не нужен ни какой инстанс для работы для этого есть статика

абстрактность решает другие задачи

эмм... да, именно, я одно с другим попутал. в деза. прошу парощения

в с++ нет проблем с множественным наследованием. Они есть у тех, кто не умеет его использовать

Для этой задачи вовсе не нужна отдельная сущность. Так что нормальный новичковый вопрос в сабже.

Чем в данном случае класс лучше модуля с процедурами?

если ООП появиться в 1С, то 1с рынок ларёчников потеряет ибо настройка 1с им станет дороже, так как другого уровня спецы понадобиться.

Понятно, что в жаве например все через классы, но это не от хорошей жизни

для статических ничем, фактически это просто аналог namespace

Это двойная диспетчиризация (IDispatch), рефлексия вместо VMT

ларечникам только галочки выставлять.

"Ежов" это кто?

>Понятно, что в жаве например все через классы, но это не от хорошей жизни а от какой? зато все единообразно... все перепаковывается в Object

как собственно во всем мире и бывает. Никакой ларек не пишет для себя своего ПО

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

Тем что можно создать экземпляр класса, но вот экземпляр модуля с процедурами ты не можешь создать.

Hadgehogs

До этого сообщения я еще был в курсе обсуждения :) Придется обновлять знания.

там даже проперти нет... как уже задрали эти "геттеры" и "сеттеры" точнее когда на яве долго пишешь то привыкаешь и норм... зато когда с чего то другого возвращаешься...

+ то есть, если вопрос в том, почему нельзя без них, то ответ - да можно. Заморочек больше просто.

Модуль это и есть класс :) в c#, java нет модулей если что :)

в жаве нет проперти????

экземпляр статического класса не создашь

или что ты подразумеваешь под проперти?

да но можно скалу юзать...

Так в этом и проблема. На больших проектах самые разные люди в команду приходят и уходят. Поэтому чем грамотнее сама среда даёт по рукам - тем лучше продукт при прочих равных.

Далось вам это "ООП в 1С". Люди создают новые ЯП вообще без ООП, и ничего, прекрасно развиваются.

код работающий при присваивании/получении значения "реквизита" объекта

ну зато и нет проблемы: Obj.MyProperty.Item = 10; ой, а значение Item осталось старым

конструкию, которая для программиста, смотрящего на исходник, выглядит, как поле класса, но на самом деле компилятором разворачивается в вызов get_ и set методов для доступа к внутреннему сосотянию объекта

Вообще то ООП - самая удобная форма программирования. Во всех других подходах приходиться выворачивать мозги наизнанку, классический пример - F#, lisp.

там нуна староеЗначение = Объекта1.getЗначение и Объекта1.setЗначение(новоеЗначение)

"очень смешно"

>Люди создают новые ЯП вообще без ООП, и ничего, прекрасно развиваются. языков тьма, а вакансии все по java/c#/c++/ios/php

asm

Вообще ничего не приходится выворачивать. Ну разве что, в Haskell

не ну я конечно в курсе что на php можно с классами писать... но не одного вживую реально юзаещего (самому пишущего новые) не только готовые фреймворки полбзующего не видал...

А фреймворки нам даны высшими силами?