Мастера 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-19 21:28:00) [1]
GrayFace © (19.07.06 18:25) [35]

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

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

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

Доброже(в|л)атель (2006-07-19 15:26:00) [3]
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, в треш то вариант для тебя)

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

StriderMan (2006-07-19 13:00:00) [4]
Удалено модератором
Примечание: Выражения выбираем

Verg (2006-07-19 11:43:00) [5]

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

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

Игорь Шевченко (2006-07-19 10:36:00) [6]
GrayFace © (19.07.06 00:08) [24]

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

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

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

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

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

Юрий Зотов (2006-07-19 01:20:00) [8]
> Джо © (19.07.06 01:08) [28]

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

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

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

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

Юрий Зотов (2006-07-19 01:03:00) [10]
ООП фарева! Вот безукоризненно правильный подход:
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)

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

DrPass (2006-07-19 01:00:00) [11]

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

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

Джо (2006-07-19 00:24:00) [12]
> Проверка почтового ящика отправителя на допуск к работе
> (Настройки или Заявка)

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

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

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

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

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

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

bowen (2006-07-18 13:47:00) [15]
Windows давно стала не только и не столько WinAPI, а и COM, DCOM, .net. Win давно стала компонентной, следовательно интерфейсы здесь применимы и играют важную роль. Мое мнение - если средства языка вам позволяют это делать - необходимо им воспользоваться, однако "всего в меру". Насчет применения оо-подхода к конкретной ос с вами согласен, я не пытался утверждать обратное.

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

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

Игорь Шевченко (2006-07-17 23:03:00) [16]
bowen © (17.07.06 19:27) [19]

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

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

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

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

StriderMan (2006-07-17 19:41:00) [17]

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

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

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

bowen (2006-07-17 19:27:00) [18]
Игорь, в unix можно избежать OO-подход, поскольку unix разрабатывался без oo-модели как таковой. Если автор захотел оо-модель, то я ему рекомендовал интерфейсы. Как это реализовано в win. Если он бы попросил бы Unix-like подход, то моя рекомендация - манады. А например, Qnx-подход - это модули на основе сетевого взаимодействия.

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

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

Игорь Шевченко (2006-07-14 22:36:00) [19]
Leonid Troyanovsky © (14.07.06 22:24) [17]

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

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

Leonid Troyanovsky (2006-07-14 22:24:00) [20]

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

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

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

--
Regards, LVT.

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

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

Наверх

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