Какой язык проще?

Не могу определиться с выбором языка для изучения новичку. что подскажете?

0

Сообщение от Avazart Вес, содержание сахара, и еще один параметр(выдумать) будут общими и выделены в абстрактный/базовый класс.

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

0

Сообщение от mporro Какую абстракцию этот класс будет задавать,

Абстракция, назовем это так "кондитерских изделий" или может иначе назвать это не суть...

Сообщение от mporro В конце концов, чем отличается конфета от подарка с одной конфетой?

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

Повторяюсь задание учебное.

0

Сообщение от Avazart Абстракция, назовем это так "кондитерских изделий"

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

Сообщение от Avazart А что не понятно что это работа для вашей фантазии

Собственно, о чём я и писал.
Давайте выдумывать абсолютно неприменимые иерархии помидоров! К чёрту программирование и логику! Даёшь наследование автомобилей от водителей! j/k
Ходить не научились, но уже хотим бегать.

0

Сообщение от mporro Да не надо конфеты в изделия переименовывать, нужно категорию показать. Не имя, а свойства; не данные, а взаимодействие с клиентом. Данные -- это детали реализации, может они и не нужны вообще.

да сути это не меняет, назыаайте как хотите это лишь акценты.

Добавлено через 2 минуты

Сообщение от mporro Собственно, о чём я и писал. Давайте выдумывать абсолютно неприменимые иерархии помидоров! К чёрту программирование и логику! Даёшь наследование автомобилей от водителей! j/k

Я хз о чем вы писали придумывать это нормально для учебных заданий.

Сообщение от mporro Ходить не научились, но уже хотим бегать.

Ну да давайте не будет использовать надуманые примеры с конфетами, а дадим сразу реальный пример вебкита или какой-то графической системы объектов.
Так что бы новичку мало не показалось, зато реальный пример с реальной абстракцией, вы сами себе противоречите ибо каша в голове.

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

0

Сообщение от Avazart да сути это не меняет, назыаайте как хотите

Вот именно, что переименование сути не меняет. Нет никакой абстракции конфеты.

Сообщение от Avazart Ну да давайте не будет использовать надуманые примеры с конфетами, а дадим сразу реальный пример

Дело не в "надуманном примере", а в том, что его должен "надумать" студент. Причём он должен надумать даже не иерархию, опираясь на предметную область, а надумать саму предметную область. Лучше уж реальный пример -- пусть каждый сам проанализирует и составит иерархию -- на семинаре разберём кто что навоял. Это было бы полезно.

Сообщение от Avazart это не предмет для разговора.

Это был бы не предмет для разговора, если бы в теме не было бы людей, которые предлагают реализацию процедурным подходом. Я уверен, что найти в списке записей те, которые подходят под определённое условие, студент способен и без посторонней помощи, его этому научили на первом курсе. Задание, как видно из преамбулы, акцентировано на ООП. И люди не предлагают эти манипуляторы записями от безысходности, они предлагают такое решение, потому что им кажется, будто бы это и есть объектное решение, ибо свято верят, что объектное значит собрать функции, которые манипулируют одними и теми же данными, под крышей ключевого слова class.

0

Сообщение от mporro Я уверен, что найти в списке записей те, которые подходят под определённое условие, студент способен и без посторонней помощи, его этому научили на первом курсе.

В списке содержащего полиморфные объекты (разных классов с общим интерфейсом).

Добавлено через 1 минуту

Сообщение от mporro , которые предлагают реализацию процедурным подходом.

Ок предложите "правильное" решение. Коль для вас инкапсуляци,наследование и полиморфизм это процедурное программирование, а не ООП.

0

Сообщение от Avazart В списке содержащего полиморфные объекты

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

Сообщение от Avazart для вас инкапсуляци,наследование и полиморфизм это процедурное программирование

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

Сообщение от Avazart предложите "правильное" решение

Не может быть у такой задачи правильного решения.
Но можно хотя бы попытаться собрать те абстракции, которые определены в задании. CandyBox, FilteredCandyBox и OrderredCandyBox. И у вас здесь будет и инкапсуляция, и полиморфизм, и наследование...

Попытка нагородить иерархии конфет в такой задаче подозрительна, более чем.

0

Сообщение от mporro Если эти "полиморфные" объекты не представляют различного поведения

Об этом речи не было...
Поведение может быть разным.

Сообщение от mporro Не может быть у такой задачи правильного решения.

Тогда к чему сыр-бор?
К тому что какому-то студенту посоветовали решение которое позволило бы ему получить зачет по предмету?
Как по мне было изначально не серьезно...

0

Сообщение от mporro Не бывает решения без анализа. Точка.

бывает. назыается границы разумного и тривиальные случаи.

В том, что работа с запросами и записями -- это работа с данными и алгоритмами над ними. Это не замкнутый язык.

т.е. в определении Вирта это называется программа.

Абстракция CandyBox и уточнении FilteredCandyBox или OrderedCandyBox -- это представление функционала, позволяющее построить замкнутый язык CandyBox.

а это какието ооп абстракции.
ок. что нужно для решения задачи: программа или абстракция?

Только в Индии

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

Чтобы учить ООП нужно...

в корне неверная постановка. ооп не надо учить. 2.5 макроса над структурным программированием, под названием ооп, бегло рассматриваются за 1 академ час. больше на него тратить время нет смысла

0

Сообщение от pycture границы разумного и тривиальные случаи

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

Сообщение от pycture в определении Вирта это называется программа

Это не отменяет того факта, что программа может быть построена без явного разделения на данные и операции над ними, начиная от исчисления Чёрча.

Сообщение от pycture что нужно для решения задачи: программа или абстракция

Сообщение от pycture вопрос кто полезнее становится риторическим

Одна реализация позволяет Вам найти одно решение одной задачи. Абстракция позволяет Вам описать множество решений схожих задач. Что важнее? Этот вопрос нужно решать отдельно в каждой конкретной ситуации.

Сообщение от pycture ооп не надо учить. 2.5 макроса над структурным программированием

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

0

Сообщение от pycture а это какието ооп абстракции.

Не совсем так:

The ability to create pairs whose elements are pairs is the essence of list structure's importance as a representational tool. We refer to this ability as the closure property of cons. In general, an operation for combining data objects satisfies the closure property if the results of combining things with that operation can themselves be combined using the same operation.6 Closure is the key to power in any means of combination because it permits us to create hierarchical structures -- structures made up of parts, which themselves are made up of parts, and so on.

Неплохой пример далее в той же главе.

Parser combinators из той же серии.

Собствтенно это пошло из математики.

0

Сообщение от mporro Нет, наследование от абстрактных классов избыточно. Достаточно наследования интерфейсов.

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

Добавлено через 59 секунд

Сообщение от mporro Зачем использовать целые числа, если есть действительные?

для нужд оптимизации.

а зачем нужны интерфейсы,
если весь их кейс полностью покрывается абстрактными,
и не очень классами?

Добавлено через 11 минут

Сообщение от mporro Вот супер-пупер жизненный пример! Дают человеку задание по объектно-ориентированному программированию

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

у меня был другой случай.

значит был класс "таблица" (базы данных).

в таблицу можно было что-то добавить, что-то поменять.

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

это все не так важно.

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

итого: 1 ядро, 1 базовая таблица, и наследник.
то есть модель из 3х компонентов.

на эту конструктиву глянул мой коллега, и молвил:
"просто. легко. практично. но не трушно. не по канонам ооп".

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

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

получилось ровно тоже самое,
только классов разных в несколько раз больше.
интерфейсы какие, которые нахрен никому не упали.

что бы работать с такой архитектуторой,
нужно больше знать всякой информации.

за поддержку того же по сути функционала отвечает большее количество классов.
зачем?

зачем делать сложно, если можно сделать проще?

зато афигетельно все по канонам ооп.

Добавлено через 3 минуты

Сообщение от Avazart Клиент не должен знать детали реализации, чтобы оперировать абстракцией. Абстракция не должна знать детали реализации клиента, чтобы предоставить реализацию. (ц)mporro

Сообщение от Avazart Это сокрытие данных

вы не правы. это именно инкапсуляция.
инкапсуляция не ставит перед собой цель скрывать данные.

0

Сообщение от hoggy инкапсуляция не ставит перед собой цель скрывать данные.

Ну так "детали реализации" это как раз про данные и "последействия методов" нет?

0

Сообщение от Avazart Ну так "детали реализации" это как раз про данные

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

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

Добавлено через 27 секунд

Сообщение от Avazart последействия методов

не распрасил символ "последействия"

0

Сообщение от hoggy это не только данные.

Естественно...

Сообщение от hoggy не распрасил символ "последействия"

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

0

Сообщение от Avazart после-действия что тут парсить?

символ "после-действия" не опознан.
не коррелирует ни с чем из базы знаний.

Сообщение от Avazart Т.е не только к примеру геттер или сеттер делает что либо еще кроме доступа, т.е есть еще и "последствия".

принято.

Сообщение от Avazart Ну так "детали реализации" это как раз про данные и "последействия методов" нет?

детали реализации включают в себя все побочные эффекты бизнес-логики механизма.

0

Сообщение от hoggy за поддержку того же по сути функционала отвечает большее количество классов. зачем? зачем делать сложно, если можно сделать проще? зато афигетельно все по канонам ооп.

затем что это и есть вся суть ООП. Сложно, раздуто и поднимает ЧСВ до уровня неба.

0

Сообщение от castorsky затем что это и есть вся суть ООП

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

0

Сообщение от mporro ...программа может быть построена без явного разделения на данные и операции над ними...

любое дело можно выполнить неправильно. это не повод так поступать.

предметные языки

это dsl которые?

Сообщение от korvin_ Не совсем так:

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

0

Сообщение от pycture не уловил связи. какое отношение замыкания, фвп и алгебраические структуры (в ссылке же все это описано?) имеют отношение к ооп-спагетти (мухи, котлеты, данные, функции все в одном объекте которые надо еще и абстрагировать) которое нам тут представляют?

Данные и функции в одном объекте --- это замыкания и есть (которые CS, а не Mathematics). А если ты внимательней перечитаешь, что я комментировал, то поймёшь, что то, что описал mporro (про язык CandyBox) является не "какой-то ООП абстракцией", а математическим свойством, встречающимся сплошь и рядом в ФП (обычно, даже в большей степени, чем в ООП).

0