freepascal.ru

у меня программа работает с компортами(основывается на синасере), есть класик. который имеет Х свойств и методов.

сейчас мне нужен такой же классик который работает по сети а позже потребуется и по ЮЗБ. методы у них будет примерно одинаковы , ну свойства соотрветсвенно немного разные.

вопрос как это правельно организовать ?

что я вижу.

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

2, наследоваться от общего родителя. наверно самый правильный вариант , но там у меня уже предок блоксерал, в сетевом будет блоксокет, а что будет в юзб даже не знаю еще. и как это обьеденить не очень понимаю.

3, в классе перегрузить конструкторы создания , а в остальных методах смотреть условия создания и отрабатывать по своему. (минус классик будет жирный, что может увеличить кол-во ошибок и усложнить отладку.)


хочется услышать советы знатоков.

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

ЗЫ Объяснил как-то на пальцах, поскольку сам созданием НОРМАЛЬНЫХ КЛАССОВ никогда не занимался
ЗЫ2 Для решения подобных задач стоит применять UML моделирование - очень помогает при поталогическом склерозе (это я про себя)

Сначала определи интерфейс - те методы, которые будут вызываться извне. Затем два варианта:
1) Этот интерфейс оставить интерфейсом и написать три класса-адаптера, которые будут его реализовывать. При таком подходе можно первый адаптер отнаследовать прямо от блоксериала, второй от блоксокета, третий - от usb класса.
2) Оформить интерфейс в виде класса с виртуальными методами, от него отнаследовать три класса-адаптера. В каждом из них будет поле, содержащее в первом случае блоксокет, во втором -.......
Второй подход имеет то преимущество, что если в какой-то момент обнаружится, что три адаптера делают одно и то же, эту функциональность легко перенести в базовый класс в одном экземпляре. Кроме того, второй подход нисколько не мешает реализовать в базовом классе некий интерфейс.

Sergei I. Gorelkin
Хорошо расписал. Мне тоже кажется, что 2-й вариант лучше. Интерфейсы вещь конечно хорошая - но обычные классы - гибче.

alexs писал(а):Мне тоже кажется, что 2-й вариант лучше.

вот не нам пожалуй и остановлюсь =)


Sergei I. Gorelkin благодарю.

Если интересует, могу поделиться готовым. Но предупреждаю - документации нет, тестов минимум, гарантий никаких, неотделимо от собственной библиотеки.