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

← →
novill © (2006-07-14 13:57) [0]

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

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

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

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

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

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

← →
Игорь Шевченко © (2006-07-14 13:58) [1]

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

Зачем ?

← →
novill © (2006-07-14 14:03) [2]

Должна упроститься дальшейная поддержка и доработка.

← →
Сергей М. © (2006-07-14 14:21) [3]

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

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

← →
Игорь Шевченко © (2006-07-14 14:28) [4]

novill © (14.07.06 14:03) [2]

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

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

← →
novill © (2006-07-14 14:52) [5]

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

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

← →
novill © (2006-07-14 14:54) [6]

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

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

← →
DrPass © (2006-07-14 15:15) [7]

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

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

← →
Игорь Шевченко © (2006-07-14 15:32) [8]

Не для всех задач подходит объектная модель.

← →
Jeer © (2006-07-14 15:37) [9]

Поддерживаю Игоря - "работает - не трогай."

← →
novill © (2006-07-14 16:17) [10]

Я же не собираюсь процедурный вариант удалять.

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

← →
bowen © (2006-07-14 16:40) [11]

Значит так ты спросил:

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

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

← →
StriderMan © (2006-07-14 17:43) [12]

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

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

← →
Jeer © (2006-07-14 18:46) [13]

Каждяй отвечает на то, что знает.
Видимо bowen © знает апсолютно все об интерфейсах.

← →
Игорь Шевченко © (2006-07-14 21:51) [14]

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

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

← →
Leonid Troyanovsky © (2006-07-14 21:58) [15]

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

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

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

--
Regards, LVT.

← →
Игорь Шевченко © (2006-07-14 22:20) [16]

Leonid Troyanovsky © (14.07.06 21:58) [15]

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

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

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

← →
Leonid Troyanovsky © (2006-07-14 22:24) [17]

> Игорь Шевченко © (14.07.06 22:20) [16]

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

Спасибо, почитаем.

--
Regards, LVT.

PS: Unix для души или по службе?

← →
Игорь Шевченко © (2006-07-14 22:36) [18]

Leonid Troyanovsky © (14.07.06 22:24) [17]

> Unix для души или по службе?

Для души и для общей ерундиции.

← →
bowen © (2006-07-17 19:27) [19]

Игорь, в unix можно избежать OO-подход, поскольку unix разрабатывался без oo-модели как таковой. Если автор захотел оо-модель, то я ему рекомендовал интерфейсы. Как это реализовано в win. Если он бы попросил бы Unix-like подход, то моя рекомендация - манады. А например, Qnx-подход - это модули на основе сетевого взаимодействия.

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

Т.е. другими словами это тоже самое: мне кажется, что ЭТО косвенно иногда указывает на нечто общее... Мои рекомендации (относительно unix): Стивенс, Таненбаум, Вахалия. После прочтения оных, остальное - это повторение.

← →
StriderMan © (2006-07-17 19:41) [20]

> в unix можно избежать OO-подход

а зачем его избегать?

ИМХО с момента изобретения многозадачных ОС самым важным достижением программирования считаю ООП.

← →
Игорь Шевченко © (2006-07-17 23:03) [21]

bowen © (17.07.06 19:27) [19]

> в unix можно избежать OO-подход, поскольку unix разрабатывался
> без oo-модели как таковой

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

> Мои рекомендации (относительно unix): Стивенс, Таненбаум,
> Вахалия. После прочтения оных, остальное - это повторение.
>

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

← →
bowen © (2006-07-18 13:47) [22]

Windows давно стала не только и не столько WinAPI, а и COM, DCOM, .net. Win давно стала компонентной, следовательно интерфейсы здесь применимы и играют важную роль. Мое мнение - если средства языка вам позволяют это делать - необходимо им воспользоваться, однако "всего в меру". Насчет применения оо-подхода к конкретной ос с вами согласен, я не пытался утверждать обратное.

# Ю. Вахалия "UNIX изнутри"
# У. Стивенс "UNIX: взаимодействие процессов"
# У. Стивенс "UNIX: разработка сетевых приложений"

Последние две книги очень рекомендую.

← →
Игорь Шевченко © (2006-07-18 14:15) [23]

> Последние две книги очень рекомендую.

Собственно, мне на эту тему больше Эви Немет и Таненбаум, но все равно, спасибо.

← →
GrayFace © (2006-07-19 00:08) [24]

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

novill © (14.07.06 13:57)
Проверка почтового ящика отправителя на допуск к работе (Настройки или Заявка)
По смыслу ни к тому, ни к другому. ИМХО, оставить процедурой.

← →
Джо © (2006-07-19 00:24) [25]

> Проверка почтового ящика отправителя на допуск к работе
> (Настройки или Заявка)

Вообще отдельный класс, "Проверяющий" :) А он уже может знать о "Настройках".

> GrayFace © (19.07.06 00:08) [24]

Не согласен. Модель строится от простого к сложному. Базовые сущности и их связи подсказывает сама предметная область. Если их нельзя выделить сразу - с большой долей правды можно утверждать, что
а) ООП для такой задачи не самый подходящий инструмент или
б) Нужно сменить системного аналитика
Да, потом есть что оптимизировать, детализировать... но имея на руках постановку задачи, проблемы с начальным вариантом модели возникают только для крупных задач, к коим почтовые роботы не относятся

ООП фарева! Вот безукоризненно правильный подход:
unit IntOperations; type TIntOperand = class private FValue: integer; public property Value: integer read FValue write FValue; end; TIntOperation = class public class function GetResult(Operand1, Operand2: TIntOperand): integer; virtual; abstract; end; TIntAddition = class(TIntOperation) public class function GetResult(Operand1, Operand2: TIntOperand): integer; override; end; implementation { TIntAddition } class function TIntAddition.GetResult(Operand1, Operand2: TIntOperand): integer; begin Resullt := Operand1.Value + Operand2.Value end; ======================================= uses IntOperations; procedure TForm1.Button1Click(Sender: TObject); var Op1, Op2: TIntOperand; begin Op1 := TIntOperand.Create; try Op1.Value := 2; Op2 := TIntOperand.Create; try Op2.Value := 2; Edit1.Text := IntToStr(TIntAddition.GetResult(Op1, Op2)) finally Op2.Free end finally Op1.Free end end;
Здесь и инкапсуляция, и наследование, и полиморфизм. Красота! А учитывая, что "Windows давно стала не только и не столько WinAPI, а и COM, DCOM, .net", можно сделать еще красивше - то же самое, но навертеть сюда еще и интерфейсов. И все это запихнуть в COM-сервер. Все просто лопнут от зависти.

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

> novill © (14.07.06 13:57)

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

Не понимаю, почему так набросились на человека. Для задачи, сформулированной в [0] с учетом планирования дальнейшего развития проекта, вполне, IMO, разумно задуматься о переводе проекта в ООП-модель. Ничего общего эта задача, опять же IMO, не имеет с пародией в [27].

> Джо © (19.07.06 01:08) [28]

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

Вот если при "дальнейшем развитии проекта" сущности эти могут стать полиморфными - вот тогда действительно есть смысл подумать об ООП.

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

> [29] Юрий Зотов © (19.07.06 01:20)
> Значит, это самое "дальнейшее развитие проекта" надо знать
> хотя бы предположительно. То есть, именно с него, с такого
> анализа и надо начинать.

В общем, наверное, с этим вполне соглашусь.

GrayFace © (19.07.06 00:08) [24]

> Абсолютная ерунда. Проектирование объектной модели - весьма
> серьезная задача. То, что она начинается с путаницы - нормальная
> ситуация.

Есть хорошее выражение: GIGO - Garbage In, Garbage Out. Если на входе путаница, на выходе будет не менее запутанная путаница. ООП само по себе не является серебряной пулей, такой, что от ее применения все программы волшебным образом становятся простыми, ясными и успешно пригодными к дальнейшему развитию. Серебряной пули нету вообще, то есть, нету такой парадигмы, применяя которую при решении любых задач можно достичь успеха относительно других парадигм.

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

> Если же хотя бы одно из этих условий не выполняется, то
> стоит подумать об альтернативных подходах.

Да уж :) Недавно сдал довольно серъезную сетевую компоненту, котрую удалось написать не применив не только ООП, но и даже malloc (calloc, strdup и т.п.)...
Такое удивительное чувство легкости испытал, надо вам сказать... :)))
Никакого беспокойства насчет "а вдруг утечки памяти"....
Жаль такое редко бывает.

Удалено модератором
Примечание: Выражения выбираем

← →
Доброже(в|л)атель (2006-07-19 15:26) [34]

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

1. Всё понятно. Наследник TCustomIniFile в котором добавится функция ReRead
2.1
TRequest = class(TObject) private FStatus: Byte; FUser: TDBRecord; public procedure DownloadStart(); virtual; abstract; procedure DownloadPause(); virtual; abstract; procedure DownloadStop(); virtual; abstract; end; THTTPRequest = class(TRequest) private FUrl: String; FDownloadThread: THTTPDownloadThread; /* Для многопоточной закачки нужно будет создать список таких потоков */ FEndFile: String; /* Нужен для обработки TOutbox"ом */ public procedure DownloadStart(); override; procedure DownloadPause(); override; procedure DownloadStop(); override; end; THTTPDownloadThread = class(TThread); public FTempFile: Cardinal; Socket: Cardinal; Start, End: Cardinal; /* Указываем кусок, который надо качать */ public procedure Connect(); procedure Disconnect(); end;

2.2
TRequestInbox = class(TList) private FPOP3Server, FPOP3User, FPOP3Password: String; FPOP3SSL: Boolean; /* Ивенты */ FOnDownloadComplete: procedure(Request: TRequest); FOnDownloadStart: procedure(Request: TRequest); FOnDownloadPause: procedure(Request: TRequest); FOnEtc: procedure; public procedure CheckMail(); /* При проверке создаёт новый запрос, добавляет его в этот список */ constructor Create(FPOP3Server, FPOP3User, FPOP3Password: String; FPOP3SSL: Boolean); end;

3.
TCustomDatabase = (TObject); private FInbox: TRequestInbox; public procedure Query(SQL: String); virtual; abstract; procedure LoadRequests(); virtual; abstract; procedure SaveRequests(); virtual; abstract; procedure SaveRequest(Request: TRequest); virtual; abstract; end; TMySQLDatabase = (TCustomDatabase); private Socket: Cardinal; FMySQLHost, FMySQLPort, FMySQLUser, FMySQLPassoword, FMySQLDatabase: String; public procedure Connect(); procedure Disconnect(); procedure Query(SQL: String); override; procedure LoadRequests(); override; procedure SaveRequests(); override; procedure SaveRequest(Request: TRequest); override; constructor Create(FMySQLHost, FMySQLPort, FMySQLUser, FMySQLPassoword, FMySQLDatabase: String;); end; TCustomFilesOutbox(TList); /* Тут я уже совсем закипел... не дописал */ private FSendingThread: TSendingThread; public procedure GetNextFile(); end;

4.

TCustomLogFile = class(TObject); public procedure Write(Text: String); virtual; abstract; end; TDiskLogFile = class(TObject); private FFile: String; FFileH: Cardinal; public procedure Write(Text: String); override; constructor Create(FileName: String); end;

За кадром остались TCustomConnection, TWinsockConnection, TClientServeThread и куча всего.

СТАЛО ЛЕГЧЕ???

Если честно, то нет. Но если в твои планы входит добавить чтение запросов от пользователей через IRC, Telnet, HTTP закачку через HTTP, FTP, Шары, DCC отправку через SMTP, IMAP, в треш то вариант для тебя)

З.Ы. Прошу не стесняться показывать баги в коде =)

Игорь Шевченко © (19.07.06 10:36) [31]
Есть хорошее выражение: GIGO - Garbage In, Garbage Out. Если на входе путаница, на выходе будет не менее запутанная путаница. ООП само по себе не является серебряной пулей, такой, что от ее применения все программы волшебным образом становятся простыми, ясными и успешно пригодными к дальнейшему развитию. Серебряной пули нету вообще, то есть, нету такой парадигмы, применяя которую при решении любых задач можно достичь успеха относительно других парадигм.
Я имел ввиду другое - путаницу в голове нужно уменьшить в процессе обдумывания объектной модели, а уж потом приступать к реализации.

GrayFace © (19.07.06 18:25) [35]

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

Безусловно, никто с этим не спорит. Еще больше можно уменьшить путаницу, задавшись вопросом - а нужна ли в данном конкретном случае объектная модель ?

Помогите разобраться с объектной моделью Найти похожие ветки