C# полиморфизм

[Губитель]

75Oa6591MQ4

Это такой у тебя,милый голосочек.?

 

[dr_mousefly]

всплыл наконец-то

 

[Губитель]

всплыл наконец-то

Бестыжий он такой,корчит из себя засраннца,никакому переобучению не подводится.

 

[dr_mousefly]

Бестыжий он такой,корчит из себя засраннца,никакому переобучению не подводится.

одним словом препод.

 

[Губитель]

Айлендэ,почему ты так выразился в мою сторону.Сам то понимать,что происходит с ТС,а на меня бочка гнать ?Херню какую то советовать и вообще с толку сбивать.Это что,работаешь на цейро что ли ?

Достопримечательный Зидан,отмечу что вы осуществляете ошибочный подход к разрешению задачи.Мне создается впечатление,что вы пытаетесь приспособить задачу к возможности полиморфного средства программирования.Вам следует прежде всего обобщить задачу в двух направлениях:в создании типа данных и метода его обработки.Это и будет ваша абстракция.По форме конкретной реализации будет наследование работать как полиморфизм включения или приведения типа,обозначенного в абстракции к конкретному типу.
Самое важное и главное в использовании ООП есть всестороннее изучение обьекта,обобщение всех его текущих и предпологаемых свойств,изучение всевозможных способов обработки получаемой или отпровляемой информации,и лишь потом его приспособление к инструменту ООП.

 

[eyeland]

одним словом препод.

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

Херню какую то советовать и вообще с толку сбивать.Это что,работаешь на цейро что ли ?

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

 

[Supostat]

Цитата:Сообщение от Supostat;
А перегруженные методы не подходят для этих целей?

Вроде нет, полиморфизма неполучиться.

Это как? Перегрузка методов вообще то и придумана для поддержки полиморфизма.

Приводить object к нужному типу хуже, т.к. начнёш получать runtime ошибки если чего-то неправильно написал. Используя перегруженные методы или универсальные методы (обобщения) ошибки будут compiletime.

Но в любом случае, вы неверно подошли к реализации. Не делайте так, вам уже написали.

 

[Губитель]

Господин преподователь,вам следует четко определиться,или язык и русская литература,или программирование.
Спасибо,что уяснили статус вечного студента,я об этом даже не догадывался в отношении (теперь затрудняюсь в официальном обозначении,но примерно отметим-)
парня Музефлая.
Применяя средства полиморфизма,а именно обобщая методы обработки,доставки,приема данных,обобщая типы данных, по свойствам и характеристике обьекта,и далее приступая к реализации,через наследования(чтобы отделить реализацию от общего базового состава свойств и характеристик обьекта) ,использовать включение полиморфизма через образы производных классов,где можно практически изменить поведение обьекта(отмечу,чтобы не путать с обычным наследованием,тут речь идет о примере более чем один базовый класс),параметрический полиморфизм через обьявление типа параметра непосредственно перед выполнением(работа одного метода с параметрами разных типов),перегрузка методов,где имеем разное количество параметров или разные типы их и тут же следует отметить приведение типа.
И наконец,можно приписать к понятию полиморфизма использование средства связывания конкретного обьекта с нужным методом в процессе выполнения программы,обозначив его в базовом интерфейсе виртуальным(если метод содержит обьемную реализацию).В широком смысле слова такое связывание мы используем при создании ДЛЛ файлов. Такое применение имеет на сегодняшний день также целые отряды разработчиков(подмена истинного процесса того или иного програмного комплекса фирменного производства своей реализацие).
Заканчивая проект,отметим,такой подход Тс,даст ему возможность владеть своей собственностью и заложить в ней развитие.
Глядишь,однажды постучит в форточку Дзидану некая сотрудница НАССА,и скажет,Жора мы хотим получить от вас согласие ,использовать ваш универсальный продукт в нашей реализации.

 

[-zidan-]

Это как? Перегрузка методов вообще то и придумана для поддержки полиморфизма.

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

Приводить object к нужному типу хуже, т.к. начнёш получать runtime ошибки если чего-то неправильно написал. Используя перегруженные методы или универсальные методы (обобщения) ошибки будут compiletime.

ну в С# можно использовать as is

Но в любом случае, вы неверно подошли к реализации. Не делайте так, вам уже написали.

Почему? Я хочу сделать гибкое настраиваемое приложение, для этого и использую полиморфизм.

Попробую рассказать конкретно.
Вся суть приложения заключаеться в получении посылки из инета(допустим получил 60 байт) выделить разные данные и дальше сними работать. Я делаю базовый абстрактный класс ДАННЫЕ, производные классы ДАННЫЕИНТ, ДАННЫЕВРЕМЯ, ДАННЫЕДАБЛ и.т.д. Набераю в контейнер List<ДАННЫЕ> структуру телеграммы ДАННЫЕИНТ, ДАННЫЕВРЕМЯ, ДАННЫЕДАБЛ и потом работаю с этими данными по всему приложению.

 

[Supostat]

А зачем городить такой огород с базовым классом и производными?
Класс "посылка", в ней все эти данные в виде свойств. В нём же и определить методы обработки свойств, если нужно - статические.
Тепрь можно сделать List<посылка> ... и чем это не подходит?

 

[-zidan-]

А зачем городить такой огород с базовым классом и производными?
Класс "посылка", в ней все эти данные в виде свойств. В нём же и определить методы обработки свойств, если нужно - статические.
Тепрь можно сделать List<посылка> ... и чем это не подходит?

Так не получиться в цикле разобрать телеграмму, т.к. данные в телеграмме разные и разбирать их надо по разному. Я в классе ДАННЫЕ объявляю абстрактный метод Parse после этого в классах наследниках реализую по разному метод Parse. И теперь в цыкле могу разобрать телеграмму

foreach (ReciveData d in structTelegram)
                    {
                        d.Parse(readBuff);
                    }

при этом в контейнере structTelegram лежат наследника класса ReciveData и метод d.Parse(readBuff) работает по разному.

В этом собственно заключаеться полиморфизм в моей ситуации.

 

[Губитель]

Это как? Перегрузка методов вообще то и придумана для поддержки полиморфизма.

Приводить object к нужному типу хуже, т.к. начнёш получать runtime ошибки если чего-то неправильно написал. Используя перегруженные методы или универсальные методы (обобщения) ошибки будут compiletime.

Но в любом случае, вы неверно подошли к реализации. Не делайте так, вам уже написали.

Если при приведении типов возникает указанная ошибка,что зависит от степени контроля компилятора по операциям с разными типами данных,следует дополнительно обьявить методы,совершающие данные операции с указанием приведенных типов без их реализации.Просто повторить обьявление.

 

[Supostat]

Так не получиться в цикле разобрать телеграмму, т.к. данные в телеграмме разные и разбирать их надо по разному. Я в классе ДАННЫЕ объявляю абстрактный метод Parse после этого в классах наследниках реализую по разному метод Parse. И теперь в цыкле могу разобрать телеграмму

foreach (ReciveData d in structTelegram)
                    {
                        d.Parse(readBuff);
                    }

при этом в контейнере structTelegram лежат наследника класса ReciveData и метод d.Parse(readBuff) работает по разному.

В этом собственно заключаеться полиморфизм в моей ситуации.

Это всё понятно. Так а зачем тогда плодить классы-наследники? Сделай в базовом классе перегруженный метод Parse для каждого типа. Полиморфизм на лицо.

Если при приведении типов возникает указанная ошибка,что зависит от степени контроля компилятора по операциям с разными типами данных,следует дополнительно обьявить методы,совершающие данные операции с указанием приведенных типов без их реализации.Просто повторить обьявление.

Вот именно! Т.е. дополнительная работа. Как альтернатива - предлагается изначально проектировать код так, чтобы компилятор ловил как можно больше. Считается что это хороший стиль написания кода (по крайней мере для C#)

 

[Klez]

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

public abstract class MyClass
{
   public abstract MyMethod(ObjectHolder obj);
}

Что касается телеграммы:

public class ReceiveData
{
   public virtual void Parse(string data) { }
}

в чем вопрос? и что конкретно нужно сделать?

Я делаю базовый абстрактный класс ДАННЫЕ, производные классы ДАННЫЕИНТ, ДАННЫЕВРЕМЯ, ДАННЫЕДАБЛ и.т.д. Набераю в контейнер List<ДАННЫЕ> структуру телеграммы ДАННЫЕИНТ, ДАННЫЕВРЕМЯ, ДАННЫЕДАБЛ и потом работаю с этими данными по всему приложению.

я рекомендую соптимизировать все абстрактные и происзводные классы в один тип byte
Затем объявляешь List<byte> container, и можешь любую структуру телеграммы разбить на байты и сложить в container. А потом можешь работать с этими байтами по всему приложению... Круто?

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

 

[vlad7]

я рекомендую соптимизировать все абстрактные и происзводные классы в один тип byte
Затем объявляешь List<byte> container, и можешь любую структуру телеграммы разбить на байты и сложить в container. А потом можешь работать с этими байтами по всему приложению... Круто?

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

а для тройного ускорения при работе с container сделать наследника байта - tripleByte

 

[dr_mousefly]

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

ИБВ

Если при приведении типов возникает указанная ошибка,что зависит от степени контроля компилятора по операциям с разными типами данных,следует дополнительно обьявить методы,совершающие данные операции с указанием приведенных типов без их реализации.Просто повторить обьявление.

а какие при этом происходят процессы?

 

[-zidan-]

я рекомендую соптимизировать все абстрактные и происзводные классы в один тип byte
Затем объявляешь List<byte> container, и можешь любую структуру телеграммы разбить на байты и сложить в container. А потом можешь работать с этими байтами по всему приложению... Круто?

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

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

а для тройного ускорения при работе с container сделать наследника байта - tripleByte

Не ну это точно прикол.

Это всё понятно. Так а зачем тогда плодить классы-наследники? Сделай в базовом классе перегруженный метод Parse для каждого типа. Полиморфизм на лицо.

А как потом с этим работать?

Вот именно! Т.е. дополнительная работа. Как альтернатива - предлагается изначально проектировать код так, чтобы компилятор ловил как можно больше. Считается что это хороший стиль написания кода (по крайней мере для C#)

Помоему вы меня не поняли. Ни я ни компилятор на момент компиляции не знает какие у меня типы сидят в телеграмме.!!!

 

[HelloWorld]

айленд, может код кинете, как это по-нормальному, а мы посмеемся

 

[COM.NET]

Если уж совсем никак, то я бы посмотрел в сторону универсального метода.

универсальность всегда попахивает бооооооооооолшим swithc-ом, тонной гавнокода и мега тормозами! Вы ещё исскуственный интелект предложите ТС написать!

Ув. ТС! Было бы проще, если бы Вы описали, что необходимо реализовать и мы с радостью поможем)

Скажу только что если фцнкция принимает параметр типа object и затем вы хотите преобразовать его в нужную Вам сущность, тогда функция будет иметь вид:

void Initialize(object myMegaObject);

Затем с помощью рефлексии Вы можете преобразовать его в необходимую Вам сущность и дальше делать с ним все что душе угодно!

ООП как технология проектирования используется в случае, если Вам необходимо создать уровень Бизнес Логики, которая тесно взаимосвязана! В таком случае для начала создаётся абстрактная модель Вашего ядра а затем его логическая реализация на базе уровня абстракций. После всего этого вы реализуете интерфейс внешнего управления Вашим ядром уровнем UI или другими. Иногда некоторые узнав о ООП пытаются "всунуть" его куда угодно, даже если он там не нужен + неумеючи всё это делают - результатом такой работы всегда можно полюбоваться на сайте govnokod.ru.

 

[dr_mousefly]

ООП как технология проектирования используется в случае, если Вам необходимо создать уровень Бизнес Логики

ООП - не технология.
бизнес-логика - не имя и фамилия.
применение ООП не ограничивается бизнес-логикой.

вобщем, как обычно...