-
Хочу попрактиковаться проверить себя, нужны нетривиальные задачи на ООП на Delphi.
-
Задачи на ООП решаются с помощью теорем и аксиом на ООП.
-
Текстовый редактор с раскраской кода.
Векторный редактор с разными примитивами.
Гоночки с тюнингом автомобиля.
Тренажёр(имитатор) Линукса или сетевого администратора.
-
Мне б больше конкретики в заданиях. )
-
Написать визуальный просмотрщик файлов любого типа.
-
Есть квадрат, круг, прямоугольник и квадрат со скруглёнными углами. Кого от кого следует наследовать?
-
> Pavia © (22.05.17 12:00) [5]
> Есть квадрат, круг, прямоугольник и квадрат со скруглёнными
> углами. Кого от кого следует наследовать?
1. Всех от TShape. (Ну не тот что в VCL ессесно)
2. Квадрат от Прямоугольника.
-
> K-1000 © (22.05.17 11:04)
> Хочу попрактиковаться проверить себя, нужны нетривиальные
> задачи на ООП на Delphi.
GoF прочел?
https://en.wikipedia.org/wiki/Design_PatternsЯ к тому, что имхо крайне сложно придумать из головы задачи.
Тут, скорее, надо хорошо знать примеры.
Плюс, думать об этом много. Ибо, имхо, ООП нельзя эффективно использовать, если много об этом не думал)))
Если сейчас старшие товарищи, скажут, что всякая философия - ерунда, а есть только инкапсуляция, наследование и полиформизм, то предлагаю им в одном абзаце описать различие Стратегии и Состояния (технически оба паттерна зачастую реализуются, если не идентично, то крайне близко).
-
> одном абзаце описать различие Стратегии и Состояния
Просто отличие в интерфейсе. В Delphi состояния реализуются на proprty, а стратегия на методах Function.
-
> K-1000 © (22.05.17 13:02) [6]
> Квадрат от Прямоугольника.
Тогда у Квадрата появляется неиспользуемое поле.
А чем Вам [4] не нравится? Вы же хотели нетривиальную задачу - так вот она и есть. Притом и не слишком сложная.
Расширяемая и гибкая архитектура. Регистрация плагинов и фабрика классов. Интерфейсы и наследование - все это придется использовать. Чем не ООП в полный рост?
-
> А чем Вам [4] не нравится?
где там ООП, кейс и всех дел.
-
> ухты © (22.05.17 15:15) [10]
> кейс и всех дел.
Самое "пионерское" решение. Понадобилось добавить новый просмотрщик или изменить старый - и вперед, переделывать и перекомпилировать.
-
Напиши игру типа пакмана.
-
> новый просмотрщик или изменить старый - и вперед, переделывать
> и перекомпилировать.
а как без перекомпиливания у вас без кейса но с ООП? ))
-
> ухты © (22.05.17 17:24) [13]
Не хотелось бы описывать всю архитектуру подробно, пусть ТС сам подумает (иначе что же это за задачка получится?). Но в двух словах подскажу.
> а как без перекомпиливания
Плагины.
> без кейса но с ООП
Фабрика классов.
-
> а как без перекомпиливания у вас без кейса но с ООП? ))
А как в Delphi новые компоненты устаналиваются ?
-
Какое отношение плагины/адоны/расширения/.. имеют к "Задачи на ООП"?
-
> Не хотелось бы описывать всю архитектуру подробно
там все в одно предложение помещвется )
-
> ухты © (22.05.17 17:58) [16]
> Какое отношение плагины/адоны/расширения/.. имеют к "Задачи на ООП"?
Наследование. Интерфейсы.
> там все в одно предложение помещвется
Ну так и напишите это предложение.
-
Пакман интереснее и разностороннее :)
-
> Kerk © (22.05.17 19:03) [19]
Забыл уже - это где пауки за колобком бегают?
-
-
Не вижу никакого особого ООП в "Пакмэне".
Ну где же вы задачки, задачки, короткие задачки??
-
> Юрий Зотов © (22.05.17 15:10) [9]
> > K-1000 © (22.05.17 13:02) [6]
>
> > Квадрат от Прямоугольника.
>
> Тогда у Квадрата появляется неиспользуемое поле.
У него Width = Height всего-то.
-
> K-1000 © (22.05.17 20:28) [23]
Ну да, всего-то неиспользуемое поле. Подумаешь, лишней памяти немножко отъели, но ведь работает же.
Знаете, как такой код называют? На букву "Г". Даже если он работает.
-
Юрий Зотов
> > K-1000 © (22.05.17 20:28) [23]Ну да, всего-то неиспользуемое
> поле. Подумаешь, лишней памяти немножко отъели, но ведь
> работает же.Знаете, как такой код называют? На букву "Г".
> Даже если он работает.
Покажите мастер класс как вы вделываете 4
(Библиотека программиста) Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес-Приемы объектно-ориентированного проектирования. Паттерны проектирования-ДМК Пресс (2010)
Если что они советуют в родительский объект включать все методы дочерних.
Ровно как и «Принцип подстановки» Барбары Лисков.
-
> Pavia © (22.05.17 20:58) [25]
> они советуют в родительский объект включать все методы дочерних.
Вы, извините, немножко не в кассу. Поскольку между методом и полем есть некоторая разница. Это раз.
Включать в родительский класс ВСЕ методы ВСЕХ дочек - глупость. В родителя надо включать лишь общие методы - то есть те, которые есть у всех дочек. Это два.
Не сотвори себе кумира, даже если он написал книгу. Это три.
-
взявшись за задачу через применение ООП
и запариваться про транжир памяти на целое одно лишнее поле в предке.
это как продать цистерну спирта, а вырученные деньги пропить.
столь же логично
-
> K-1000 © (22.05.17 20:28) [22]
>
> Не вижу никакого особого ООП в "Пакмэне".
Ну нифига себе. Там куча объектов, которые по сути похожи, но ведут себя по-разному. И всё это надо уметь держать в памяти, управлять и отрисовывать. Не суперзадача конечно. Но вроде чего-то глобального и не требовалось.
-
Pavia © (22.05.17 20:58) [25]
> Если что они советуют в родительский объект включать все
> методы дочерних
Ты спутал
-
ООП помогает людям в писать. Всего лишь.
И не помогает процессорам выполнять (плюс множество других вещей о которых оно не заботится).
вот и все.
-
> Ну где же вы задачки, задачки, короткие задачки??
Когда активно использовать дженерики начал - увидел что там код необузданно дублируется. Решил сходный функционал вынести в базовый от которого и наследовать конкретный T-класс. Но вот с классовыми переменными засада. Напрашивается их тоже в базовый, чтобы не копи-пастить, но нужны они то для каждого Т-класса свои.
Поможешь?
-
> Включать в родительский класс ВСЕ методы ВСЕХ дочек - глупость.
> В родителя надо включать лишь общие методы - то есть те,
> которые есть у всех дочек. Это два.
Видно что не читали, но уже осуждаете. Там это описание на нескольких десятков листов почему именно и как. Я конечно преувеличил, что прям всё.
Но большинство методологов следует включить в родителя, даже если они не везде есть. Это позволит сохранить кейсы внутри вашего фремворка. Иначе это грозит тем, что эти кейсы будут вываливаться во внешние объекты.
Это в учебной задаче уровень наследования малый, а в реальной где у вас фабрика объектов сложность кейса растёт по экспоненте от уровня наследования. Поэтому и следует их помещать внутрь объектов - инкапсулировать. А не тащить наружу в другие объекты.
> Вы, извините, немножко не в кассу. Поскольку между методом
> и полем есть некоторая разница. Это раз.
Я конечно понимаю старая школа. Но сейчас цена байта очень мала по сравнению с временем программиста.
> Не сотвори себе кумира, даже если он написал книгу. Это
> три.
Математика сэр.
-
> Pavia © (22.05.17 20:58) [25]
> Если что они советуют в родительский объект включать все
> методы дочерних.
Наоборот.
> Ровно как и «Принцип подстановки» Барбары Лисков.
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.
Ну да. Наоборот.
-
> Kerk © (23.05.17 00:00) [33]
> Наоборот.
Если вас могут понять не правильно, значит вас поймут неправильно. Обратите внимание на слова.
Выбор наследование или перепоручения решается заранее. Когда мы разбиваем все методы на постоянные и изменяющиеся. Для неизменных когда мы применяем наследование. Если есть наследование то есть родители и дочки, А если нет наследование то и никаких дочерей нет.
В самом простом случае мы можем использовать только, то что знаем. Почему это так?
В алгоритме функции вы обязаны указать имя метода который вы вызываете - её сигнатуру.
Можно ли сделать иначе? Можно только это уже не наследование. Хотя в книге оно и обозвано наследованием(правда в одном месте видимо ощимка?!). Решается это через класс с шаблоном-стратегии.
В умных книжках это называется делегированием. Переведём на русский так это же попросту перепоручения!
К чему это приводит? А приводит к тому что теперь тому кому перепоручили работу приходиться разбираться, а кто-же его вызвал и с кем он должен работать! Вот от этого и растёт кейс, только теперь у нас, а у него.
Хорошо когда у вас есть шаблон-прораб. Он подтаскивает близко-родственные классы так сказать из одного села. Тогда если как в примере с графическим редактором у нас три системы чётко разделённых. Вот тогда можно избавиться от кейсов внутри кода. Просто описав три реализации для каждой системы свою.
Только я повторюсь к наследованию это не имеет отношения.
Выбор наследование или перепоручения решается заранее. Когда мы разбиваем все методы на постоянные и изменяющиеся.
-
> Pavia © (23.05.17 00:49) [34]
Да я как раз обратил внимание на слова:
Если что они советуют в родительский объект включать все методы дочерних.
Ровно как и «Принцип подстановки» Барбары Лисков.
Судя по [34], у меня ощущение возникает, что ты взял какой-то частный случай и невероятно широко обобщил его зачем-то.
-
вот задачка для ооп.
сделать скелет приложения работающего с бд.
классы форм с dbaware спроектировать так, чтобы они ничего не знали ни про конкретный сервер, ни про библиотеки доступа.
специфику реализовать в абстрактном датамодуле и его потомках.
в результате переезд приложения с ora/odac на fb/fibs (mssql/ado и т.д.) не должен затрагивать гуи и занимать пару часов.
-
> Выбор наследование или перепоручения решается заранее. Когда
> мы разбиваем все методы на постоянные и изменяющиеся. Для
> неизменных когда мы применяем наследование. Если есть наследование
> то есть родители и дочки, А если нет наследование то и никаких
> дочерей нет.
>
> В самом простом случае мы можем использовать только, то
> что знаем.
"А эти, которые больше всех, где они? Сказал бы, этими вот, как говорится, руками. И до сих пор, и всегда буду, есть и был… Хотя иной раз бываю. Но сейчас не об этом надо думать. Сейчас надо всем вместе. У нас ведь всё общее. И судьба, и труба, и песни. Да, трудно, да, плохо, но мы-то здесь. "
Навеяло
-
> в результате переезд приложения с ora/odac на fb/fibs (mssql/ado
> и т.д.) не должен затрагивать гуи и занимать пару часов.
>
ну а биндинги (лайвбиндинги) разве не про это?
-
ну а биндинги (лайвбиндинги) разве не про это?
может и про это но только это подразумевает что надо ковыряться в конечных формах при смене сервера и движка. плюс заново отлаживать бизнес-логику. целиком.
а предлагается этим не заниматься.
чтобы после смены датамодуля было такое-же отлаженное приложение но на другом двигле
-
> Kerk © (22.05.17 21:37) [28]
>
> > K-1000 © (22.05.17 20:28) [22]
> >
> > Не вижу никакого особого ООП в "Пакмэне".
>
> Ну нифига себе. Там куча объектов, которые по сути похожи,
> но ведут себя по-разному. И всё это надо уметь держать
> в памяти, управлять и отрисовывать. Не суперзадача конечно.
> Но вроде чего-то глобального и не требовалось.
>
>
Ну я делал "Танчики" с ООП.
Не вижу там "сложного ООП".
-
-
-
> Pavia © (22.05.17 14:14) [8]
> > одном абзаце описать различие Стратегии и Состояния
> Просто отличие в интерфейсе. В Delphi состояния реализуются
> на proprty, а стратегия на методах Function.
А если у тебя не дельфи, а скажем PHP?
Или вообще Pascal махровых годов, где только recordы?
Смогешь реализовать Stategy и State и объяснить, почему первое есть именно Strategy, а второе - State?
-
> rrrrr © (23.05.17 08:31) [36]
С точки зрения архитектуры, [4] и [36] - почти одно и то же.
Есть новые 
Нет новых [118696 +35][b:0][p:0.001]