Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Помогите разобраться с объектной моделью [D6]

Страницы: < 1 2
novill © (2006-07-14 13:57:00)
Есть простая задача - почтовый робот, скачивающий файлы.
На данный момент он реализован процедурами.
Хочу перевести его на полностью на объектную модель.

Есть следющие сущности:

1. Настройки (ini - файл, со всеми параметрами, в процессе работы их надо перечитывать)
2. Заявка
2. Почтовый ящик, куда присылают заявки
3. БД, где хранятся заявки
4. Лог-файл

Заявки получаются из почтового ящика и анлизируются на допустимость, записываются в БД, потом скачиваются и отсылаются пользователю.

Начал прописывать классы. Не знаю, где разместить функции:

1. Получение заявки (почтовый ящик или Заявка)
2. сохранение заявки (БД или Заявка)?
3. Проверка почтового ящика отправителя на допуск к работе (Настройки или Заявка)

Игорь Шевченко (2006-07-14 22:20:00) [21]
Leonid Troyanovsky © (14.07.06 21:58) [15]

Эрик C. Рэймонд, "Искусство программирования для Unix",
Издательство "Вильямс", 2005
ISBN 5-8459-0791-8 (рус.)

Ссылки нету, набивал только что вручную с книжки.

Купил в доме книги на Войковской, с полгода назад, отдал 336 рублей, прочитал запоем, отличная книга.

Leonid Troyanovsky (2006-07-14 21:58:00) [22]

> Игорь Шевченко © (14.07.06 21:51) [14]

Можно полную ссылочку?
И, если можно, где купил?

Заранее признателен.

--
Regards, LVT.

Игорь Шевченко (2006-07-14 21:51:00) [23]
"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому что им известны эти способы и они умеют ими пользоваться.
Все ОО-языки несколько сколнны "втягивать" программистов в ловушку избыточной иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне затрудняется их просмотр и анализ ментальной модели, которую по существу реализует код. Всецело нарушаются правила простоты, ясности и прозрачности, а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения правила представления. С этой точки зрения множество классов приравнивается к внедрению знаний в данные. Проблема данного подхода заключается в том, что слишком часто "развитые данные" в связующих уровнях фактически не относятся у какому-либо естественному объекту в области действия программы - они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них предметных областей (GUI-интерфейсы, моделирование, графические средства), возможно, является то, что в этих областях относительно трудно неправильно определить онтологию типов. Например, в GUI-интерфейсах и графических средствах присутствует довольно естественное соотвествие между манипулируемыми визуальными объектами и классами. Если выясняется, что создается большое количество классов, которые не имеют очевидного соответствия с тем, что происходит на экране, то, соотвественно, легко заметить, что связующий уровень
стал слишком большим."

(с) Эрик Рэймонд

Jeer (2006-07-14 18:46:00) [24]
Каждяй отвечает на то, что знает.
Видимо bowen © знает апсолютно все об интерфейсах.

StriderMan (2006-07-14 17:43:00) [25]

> bowen © (14.07.06 16:40) [11]

че-то не понял зачему тут интерфейсы

bowen (2006-07-14 16:40:00) [26]
Значит так ты спросил:

> Начал прописывать классы. Не знаю, где разместить функции:
>
>
> 1. Получение заявки (почтовый ящик или Заявка)
> 2. сохранение заявки (БД или Заявка)?
> 3. Проверка почтового ящика отправителя на допуск к работе
> (Настройки или Заявка)

1. делаешь интерфейс IReader, от него наследуешь IMAPReader, TaskReader
2. аналогично, IWriter наследники DbWriter, TaskWriter
3. Это идиома(или Des. Pattern) фабрики, назвать класс можно как угодно например ReaderFactory, WriterFactory

novill (2006-07-14 16:17:00) [27]
Я же не собираюсь процедурный вариант удалять.

ЗЫ
Ну вот, так хотелось че-нить объектное слабать...
Сколько уже работаю - сплошные процедуры :(
Абидна!

Jeer (2006-07-14 15:37:00) [28]
Поддерживаю Игоря - "работает - не трогай."

Игорь Шевченко (2006-07-14 15:32:00) [29]
Не для всех задач подходит объектная модель.

DrPass (2006-07-14 15:15:00) [30]

> novill © (14.07.06 14:54) [6]
>
> так воти хочется чтобы не усложнить, а упростить.

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

novill (2006-07-14 14:54:00) [31]

> Объектная модель может с такой же легкостью усложнить дальнейшую
> поддержку и доработку.

так воти хочется чтобы не усложнить, а упростить.

novill (2006-07-14 14:52:00) [32]

> > почтовый робот, скачивающий файлы
>
>
> Будь проще - тебе нужен бридж POP3/IMAP <-> FTP ? Или что
> ?

Я не знаю, как это по-умному назвать, но видимо, да. Иногда это называют www2mail.

Игорь Шевченко (2006-07-14 14:28:00) [33]
novill © (14.07.06 14:03) [2]

Объектная модель может с такой же легкостью усложнить дальнейшую поддержку и доработку. Можно дать хороший совет, работает - не трогай.

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

Сергей М. (2006-07-14 14:21:00) [34]

> почтовый робот, скачивающий файлы

Будь проще - тебе нужен бридж POP3/IMAP <-> FTP ? Или что ?

novill (2006-07-14 14:03:00) [35]
Должна упроститься дальшейная поддержка и доработка.

Игорь Шевченко (2006-07-14 13:58:00) [36]

> Хочу перевести его на полностью на объектную модель.

Зачем ?

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »