Как раз описанный в начале случай. База данных юридических лиц. В егрюл размер доли может храниться в виде денежной суммы, десятичной дроби или обыкновенной. 10000 рублей ровно на троих не разделить, поэтому по 1/3 каждому. Сложение всех долей должно давать 1 в качестве проверки.
Как всторостепенное приложение — написал калькулятор для того, чтоб ребенок мог проверять верно ли он решает школьные задачи.
Пожалуй, попробую перенести в лазарус, спасибо за наводку. А вот вопрос, здесь, как я понимаю, идет полное зеркальное отображение таблиц бд в объекты, поля бд = свойствам объектов. А как-то решена проблема маппинга связей один-ко-многим и многие-ко-многим? Я у себя добавляю к объектам свойства с типом списка для заполнения уже внутри объекта списочного свойства соответствующими объектами. Но тут только хардкодинг помогает (пока). В tiOPF паттерн relation manager пытаюсь понять, но пока никак на себе не применю. Плюс еще есть одна загвоздка. Связь многие-ко-многим при маппинге в объекты может повлечь дикую рекурсию (прямой пример: юрлицо имеет участников — юрлиц, объект юрлицо имеет свойство список участников, список состоит из объектов юрлиц, ну а как иначе?), вот такие проблемы как решали, если были?
Большое спасибо за труд)
Как раз сижу и вникаю, как в книги по проектированию, так и в ваш код. Применил его на своем другом учебном проекте. Всё же, возвращаясь к методу обучения основам ООП… Ну вот, чтобы вникнуть в ваш код, мне пришлось его повторить, чтоб понять кто кого куда и зачем). И это имея уже представление о том, что делают те или иные классы, судя по названиям. А в тот момент, когда я только начинал изучать ООП, мне трудно было даже понять реализацию полиморфизма и смысл этого. Понял, только на ходу, делая вот этот проект с рисульками. Вряд ли на первых порах обучения стоит сразу же в простейшие проекты вставлять сложные шаблоны проектирования. Это и усложняет их, и делает трудными для чтения и понимания.
Спасибо, нашел очередное подтверждение того, о чем сам всё время думаю (ну не всю жизнь, а только сейчас, пока вникаю в азы проектирования, почитывая Макконнелла (гл. 6 стр. 140-145))
Только в теории, на уровне википедии и ряда статей на Хабре, которые вот нашел утром) Но я и со списками, стеками, очередями и ассоциированными массивами познакомился только на той неделе, но уже использую в отлаженном проекте. Так что быстро учусь.
Спасибо. Я как раз продолжаю сам изучать теорию ооп.
Но в данном конкретном примере, для начинающих, так сказать, не будет ли это избыточным усложнением? То есть, когда в школе учат формулам скорости, веса, ведь никто сходу не говорит, что нужно учитывать теорию относительности взамен простых вычислений s=vt.
Всё поправил)
Интересно, а у меня одного лазарус в убунте ведет себя странно? То окна не найдешь, то новый проект сохраняет в старом (вот поэтому и вылез unit1).
Ошибка при закрытии выпала, видимо, от того, что пока удаляются объекты, успевал сработать еще раз таймер. Выключил его при закрытии.
Теперь затираемые розы не «портят» перекрытые.
А насчет деструктора — в него нельзя передать параметр, поэтому сделал метод kill.
А вообще я подумал, когда роза затирается, то можно организовать проверку пикселя перед сменой цветы на черный — если цвет не принадлежит этой розе, то и не затирать этот пиксель. Позже надо попробовать. Будет красивее.
Это не из-за цветов, просто рисуются они все на одной канве пикселями, друг на дружке, соответственно и затираются черным цветом тоже друг на дружке. У меня на работе целый год скринсейвером стоял, не придавал значения этому «дефекту».
Здравствуйте.
Большое спасибо за комментарии и то, что потратили время на такой дельный разбор. Я на самом деле этот учебный (для себя) проект делал пару лет назад, и тогда, если бы я дорабатывал его до идеала, я бы тоже решил запрятать полностью всю работу в классы. Потом забросил.
Теперь вот решил допилить, учел практически полностью Ваши замечания, новый файл в ветке lesson4.
Я только не понял в чем разница — передавать свойство Canvas или весь объект Image, я пока оставил Canvas. И отдельный метод для стирания писать не стал, т.к. считаю это избыточным, ведь нужна всего одна строчка, а ее я запрятал в аналог деструктора (метод kill), то есть в конечном итоге, как и предлагалось, обработчик таймера делает лишь DrawNext ))
Как всторостепенное приложение — написал калькулятор для того, чтоб ребенок мог проверять верно ли он решает школьные задачи.
Как раз сижу и вникаю, как в книги по проектированию, так и в ваш код. Применил его на своем другом учебном проекте. Всё же, возвращаясь к методу обучения основам ООП… Ну вот, чтобы вникнуть в ваш код, мне пришлось его повторить, чтоб понять кто кого куда и зачем). И это имея уже представление о том, что делают те или иные классы, судя по названиям. А в тот момент, когда я только начинал изучать ООП, мне трудно было даже понять реализацию полиморфизма и смысл этого. Понял, только на ходу, делая вот этот проект с рисульками. Вряд ли на первых порах обучения стоит сразу же в простейшие проекты вставлять сложные шаблоны проектирования. Это и усложняет их, и делает трудными для чтения и понимания.
Ну или я не так понял.
Но в данном конкретном примере, для начинающих, так сказать, не будет ли это избыточным усложнением? То есть, когда в школе учат формулам скорости, веса, ведь никто сходу не говорит, что нужно учитывать теорию относительности взамен простых вычислений s=vt.
Я вот только погружаюсь в структуры, кажется, вместо списка здесь даже лучше использовать очередь, и в fcl есть для такого случая класс.
Таки-пришлось TImage передавать.
Интересно, а у меня одного лазарус в убунте ведет себя странно? То окна не найдешь, то новый проект сохраняет в старом (вот поэтому и вылез unit1).
Ошибка при закрытии выпала, видимо, от того, что пока удаляются объекты, успевал сработать еще раз таймер. Выключил его при закрытии.
Теперь затираемые розы не «портят» перекрытые.
А насчет деструктора — в него нельзя передать параметр, поэтому сделал метод kill.
Большое спасибо за комментарии и то, что потратили время на такой дельный разбор. Я на самом деле этот учебный (для себя) проект делал пару лет назад, и тогда, если бы я дорабатывал его до идеала, я бы тоже решил запрятать полностью всю работу в классы. Потом забросил.
Теперь вот решил допилить, учел практически полностью Ваши замечания, новый файл в ветке lesson4.
Я только не понял в чем разница — передавать свойство Canvas или весь объект Image, я пока оставил Canvas. И отдельный метод для стирания писать не стал, т.к. считаю это избыточным, ведь нужна всего одна строчка, а ее я запрятал в аналог деструктора (метод kill), то есть в конечном итоге, как и предлагалось, обработчик таймера делает лишь DrawNext ))