Структурный вопрос - функции VS методы

← →
Черный Шаман (2007-11-29 17:38) [0]

Есть некоторые функции для работы с классическим Canvas, по типу хитрого рястягивания картинки с отступами масштабирования, отражением картинки, альфауровнем картинки...

Функции используются для рисования в нескольких классах, которые имеют не одного предка для всех, а несколько(имеется три ветви наследования, общего предка создать невозможно).

Как правильнее организовать.

1. Сделать классические функции в стиле процедурного программирования.
2. Откопировать их в 3 предка в качестве методов.
3. Стиль Java - создать класс и оформить их в классическом стиле классовых функций.

Вот, страдаю. Не знаю как красивее и правильнее.

← →
clickmaker © (2007-11-29 17:41) [1]

1 - в отдельном юните

← →
wicked © (2007-11-29 17:44) [2]

задача звучит примерно так

> есть унитаз и ершик
> какую бумагу подобрать - наждачную, газетную или обычную?
> как правильнее?

← →
Черный Шаман (2007-11-29 17:46) [3]

> clickmaker © (29.11.07 17:41) [1]
>
> 1 - в отдельном юните

Оно понятно что в отдельном юните, но посмотрев на Java, процедурное программирование мне кажется варварством.

← →
Черный Шаман (2007-11-29 17:47) [4]

> wicked © (29.11.07 17:44) [2]
>
> задача звучит примерно так
>
> > есть унитаз и ершик
> > какую бумагу подобрать - наждачную, газетную или обычную?

Тоесть 3?

← →
wicked © (2007-11-29 17:48) [5]

> Черный Шаман (29.11.07 17:47) [4]

>
> Тоесть 3?

то есть, ты мало рассказал в первом постинге
иногда - 1
а иногда - навалять кучку интерфейсов и общаться через них

← →
clickmaker © (2007-11-29 17:48) [6]

> процедурное программирование мне кажется варварством

почему? Ты же WinAPI юзаешь. Вот твои функции - тоже некое апи

← →
Черный Шаман (2007-11-29 17:59) [7]

> wicked © (29.11.07 17:48) [5]
>
> > Черный Шаман (29.11.07 17:47) [4]
>
> >
> > Тоесть 3?
>
> то есть, ты мало рассказал в первом постинге
> иногда - 1
> а иногда - навалять кучку интерфейсов и общаться через них

Например такие функции
procedure DrawMarginsTransparent(MCanvas: TCanvas; const Dest, Margins: TRect; Bitmap: TBitmap);
procedure MirrorImage(Bitmap: TBitmap; Horizontal, Vertical: Boolean);

Отлично подходит под 1, но не люблю я процедурное. В классовых функциях есть еще удобное различие по namespace.

← →
iZEN © (2007-11-29 18:17) [8]

Создать утилитарный класс Transform по образцу java.lang.Math.

(Класс в Java считается модулем)

← →
Alkid © (2007-11-29 18:44) [9]

Создай отдельный визитор, который бы умел обрабатывать все эти классы.

P.S. А процедурное программирование не замай :) Вообще не люблю, когда берут одну парадигму (щас модно ООП и ФП) и превозносят, отвергая остальное.

← →
Черный Шаман (2007-11-29 18:56) [10]

> iZEN © (29.11.07 18:17) [8]
>
> Создать утилитарный класс Transform по образцу java.lang.
> Math.
>
> (Класс в Java считается модулем)
>

Тоесть 3?

← →
Gadenysh (2007-11-29 19:18) [11]

имхо, класс(какой-нить TImageOperator) и методы. преимущество перед процедурами - их можно сделать виртуальными

← →
@!!ex © (2007-11-29 19:21) [12]

> имеется три ветви наследования, общего предка создать невозможно

Множественное наследование?

← →
Черный Шаман (2007-11-29 19:42) [13]

> @!!ex © (29.11.07 19:21) [12]
>
> > имеется три ветви наследования, общего предка создать
> невозможно
>
> Множественное наследование?

В Delphi?

Наследники от TСontrol, TWinControl, Tform.

> В Delphi?

Интерфейсы.

> Наследники от TСontrol, TWinControl, Tform.

Это одна ветка, кстати.
TForm наследние TWinControl наследник TControl

← →
Черный Шаман (2007-11-29 19:59) [15]

> @!!ex © (29.11.07 19:47) [14]
>
> > В Delphi?
>
> Интерфейсы.
>
> > Наследники от TСontrol, TWinControl, Tform.
>
> Это одна ветка, кстати.
> TForm наследние TWinControl наследник TControl

Угу и мне тупо копировать все процедуры с WinControl и TCustomForm в свой TSkinControl

← →
Черный Шаман (2007-11-29 20:01) [16]

> @!!ex © (29.11.07 19:47) [14]
>
> > В Delphi?
>
> Интерфейсы.

Интрефейсы определяют правила вызова методов, а вот код в интерфейсе задать нельзя.

> Черный Шаман (29.11.07 17:59) [7]
> функциях есть еще удобное различие по namespace.

Нек забываем, что отдельный юнит - это отдельный namespace. Его (название юнита) можно (а иногда нужно) смело приписывать перед именем объявлений юнита через точку.
Беда только, что одновременно с uses в дельфи автоматически как бы происходит и аналогичный using...

> Черный Шаман (29.11.07 17:38)

> Есть некоторые функции для работы с классическим Canvas, по типу
> хитрого рястягивания картинки с отступами масштабирования,
> отражением картинки, альфауровнем картинки...

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

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

Поэтому стоит сделать отдельные функции, а из Ваших классов просто вызывать их.

А вот чего НЕ стоит делать, так это:

1. Упираться в какую-то одну методологию, заведомо отметая другие.

2. Искусственно привносить в Delphi несвойственные ей ограничения - в том числе, ограничения джавы. В джаве, как известно "все есть класс", поэтому там невозможно использовать ни отдельные константы, ни отдельные функции - все приходится заворачивать в классы. А в результате начинается плождение классов, содержащих лишь поля и методы в духе public static final. И что же тут хорошего? Только лишние накладные расходы и лишние тормоза, ничего более.

Структурный вопрос - функции VS методы Найти похожие ветки