Отсутствие множественного наследования

@x_Alex_x · Регистрация: 07.02.2014

Author24 — интернет-сервис помощи студентам

Добрый день! У меня есть интерфейс GeometryObject, описывающий геометрические фигуры. От него наследуются такие классы как: Point и Line, и они имеют различные, свойственные для них методы. Теперь мне нужно создать расширенные классы геометрических фигур, с которыми работало бы графическое окно. То есть появляются новые классы, расширяющие функциональность прежних, а так же имеющие методы, одинаковые для всех GraphicsGeomObj (к примеру, смена цвета). GraphicsGeomObj не может быть абстрактным, а если его сделать интерфейсом, то придётся у всех потомков создавать одинаковые методы типа setColor, что опять же неправильно, так как будет дублирование кода.

@KEKCoGEN · 17.02.2015, 12:34

приведите конкретный пример проблемы в иерархии.
Например у вас есть GeometryObject --> Point --> ???

@x_Alex_x · 17.02.2015, 12:53 **[ТС]**

Не силён в UML. На рисунке схема при доступном множественном наследовании.

@KEKCoGEN · 17.02.2015, 16:07

Java

public interface GeometryObj
 
public abstract class GraphicsGeomObj implements GeometryObj
 
pubic class Point extends GraphicsGeomObj 
 
public class GraphicsPoint extends Point

@x_Alex_x · 17.02.2015, 18:05 **[ТС]**

KEKCoGEN, по моей задумке класс Point не должен ничего знать о классе GraphicsGeomObj и тем более наследоваться от него. Этот класс является реализацией двумерного вектора и ему не нужно знать о том, что его могут где-нибудь отображать. А вот класс GraphicsPoint, помимо унаследованных от Point методов, умеет так же отображать себя на экране.

@KEKCoGEN · 17.02.2015, 20:45

по вашей задумке неясно как себя ведет GraphicsGeomObj. Если например он наследует от круга и линии, то у него должны быть методы получения радиуса и вектора направления например? Это неправильно.

@x_Alex_x · 18.02.2015, 14:48 **[ТС]**

GraphicsGeomObj объединяет такие классы как GraphicsPoint и GraphicsLine, а так же содержит поля и реализованные методы, одинаковые для этих классов. Получается у экземпляра класса GraphicsPoint я могу вызывать методы как класса Point (так как Point его предок)(например метод move(), который по-разному реализован у Point и у Line), так и методы класса GraphicsGeomObj (например setColor(), который одинаков для GraphicsPoint и для GraphicsLine)

Добавлено через 17 часов 17 минут
Что-то тема тонет.

@KEKCoGEN · 18.02.2015, 18:17

Мне ваша структура кажется неверной. Может кто-нибудь ещё варианты предложит

@x_Alex_x · 18.02.2015, 18:54 **[ТС]**

Ну я и не говирил, что она верна, просто показал какой хочу результат. Но всё равно спасибо что поучаствовали)

@ne2win · 18.02.2015, 20:48

x_Alex_x, Можно попробовать выделить все методы GraphicsGeomObj в интерфейс, реализовать его, в классе GraphicsGeomObj и GraphicsPoint. Инкапсулировать объект GraphicsGeomObj в классе GraphicsPoint и делегировать ему управление.

@x_Alex_x · 18.02.2015, 21:52 **[ТС]**

Kochmarik, поправьте если я неправильно понял: нужно методы, общие для графических элементов вынести в отдельный класс и в каждом объекте типа GraphicsPoint хранить экземпляр такого класса? Таким образом становится достопным вызов:

Java

1
2
3

GraphicsPoint gp = new GraphicsPoint();
gp.move();
gp.graphicsGeom.getColor();

Хоть вызов метода идёт не напрямую, зато пропадает дублированный код.

@ne2win · 18.02.2015, 22:20

x_Alex_x, Я немного другое имел в виду, но так, кажется, даже лучше

Добавлено через 19 минут
Я говорил о реализации интерфейса таким образом

Java

interface Graphics
{
    public Color getColor();
}
class GraphicsGeomObj implements Graphics
{
    @Override
    public Color getColor()
    {
        return ...
    }
    
}
class GraphicsPoint implements Graphics
{
    private GraphicsGeomObj graphicsGeom;
    public Color getColor()
    {
        return graphicsGeom.getColor();
    }
}

Но, если для вас объем кода, показатель критический, тогда да.

@x_Alex_x · 18.02.2015, 22:34 **[ТС]**

Kochmarik, для меня главное организация правильной структуры с точки зрения ООП.

@ne2win · 18.02.2015, 22:42

x_Alex_x, ну тогда мой вариант, единственный мной известный способ подражания множественному наследованию. Если бы у вас класс GraphicsGeomObj не инкапсулировал поля, можно было бы воспользоваться дефолтными методами в интерфейсе.

@ne2win 206 / 206 / 71 Регистрация: 25.02.2014 Сообщений: 569
	18.02.2015, 20:48	10
	x_Alex_x, Можно попробовать выделить все методы GraphicsGeomObj в интерфейс, реализовать его, в классе GraphicsGeomObj и GraphicsPoint. Инкапсулировать объект GraphicsGeomObj в классе GraphicsPoint и делегировать ему управление. 0

@x_Alex_x 20 / 20 / 3 Регистрация: 07.02.2014 Сообщений: 233
	18.02.2015, 22:34 [ТС]	13
	Kochmarik, для меня главное организация правильной структуры с точки зрения ООП. 0

@x_Alex_x 20 / 20 / 3 Регистрация: 07.02.2014 Сообщений: 233
		1
	Отсутствие множественного наследования 17.02.2015, 12:11. Показов 698. Ответов 13 Метки нет (Все метки) Добрый день! У меня есть интерфейс GeometryObject, описывающий геометрические фигуры. От него наследуются такие классы как: Point и Line, и они имеют различные, свойственные для них методы. Теперь мне нужно создать расширенные классы геометрических фигур, с которыми работало бы графическое окно. То есть появляются новые классы, расширяющие функциональность прежних, а так же имеющие методы, одинаковые для всех GraphicsGeomObj (к примеру, смена цвета). GraphicsGeomObj не может быть абстрактным, а если его сделать интерфейсом, то придётся у всех потомков создавать одинаковые методы типа setColor, что опять же неправильно, так как будет дублирование кода. 0

@KEKCoGEN 2398 / 2223 / 565 Регистрация: 28.12.2010 Сообщений: 8,672
	17.02.2015, 12:34	2
	приведите конкретный пример проблемы в иерархии. Например у вас есть GeometryObject --> Point --> ??? 0

@x_Alex_x 20 / 20 / 3 Регистрация: 07.02.2014 Сообщений: 233
	17.02.2015, 12:53 [ТС]	3
	Не силён в UML. На рисунке схема при доступном множественном наследовании. Миниатюры 0

@x_Alex_x 20 / 20 / 3 Регистрация: 07.02.2014 Сообщений: 233
	17.02.2015, 18:05 [ТС]	5
	KEKCoGEN, по моей задумке класс Point не должен ничего знать о классе GraphicsGeomObj и тем более наследоваться от него. Этот класс является реализацией двумерного вектора и ему не нужно знать о том, что его могут где-нибудь отображать. А вот класс GraphicsPoint, помимо унаследованных от Point методов, умеет так же отображать себя на экране. 0

@KEKCoGEN 2398 / 2223 / 565 Регистрация: 28.12.2010 Сообщений: 8,672
	17.02.2015, 20:45	6
	по вашей задумке неясно как себя ведет GraphicsGeomObj. Если например он наследует от круга и линии, то у него должны быть методы получения радиуса и вектора направления например? Это неправильно. 0

@x_Alex_x 20 / 20 / 3 Регистрация: 07.02.2014 Сообщений: 233
	18.02.2015, 14:48 [ТС]	7
	GraphicsGeomObj объединяет такие классы как GraphicsPoint и GraphicsLine, а так же содержит поля и реализованные методы, одинаковые для этих классов. Получается у экземпляра класса GraphicsPoint я могу вызывать методы как класса Point (так как Point его предок)(например метод move(), который по-разному реализован у Point и у Line), так и методы класса GraphicsGeomObj (например setColor(), который одинаков для GraphicsPoint и для GraphicsLine) Добавлено через 17 часов 17 минут Что-то тема тонет. 0

@KEKCoGEN 2398 / 2223 / 565 Регистрация: 28.12.2010 Сообщений: 8,672
	18.02.2015, 18:17	8
	Мне ваша структура кажется неверной. Может кто-нибудь ещё варианты предложит 0

@x_Alex_x 20 / 20 / 3 Регистрация: 07.02.2014 Сообщений: 233
	18.02.2015, 18:54 [ТС]	9
	Ну я и не говирил, что она верна, просто показал какой хочу результат. Но всё равно спасибо что поучаствовали) 0

@ne2win 206 / 206 / 71 Регистрация: 25.02.2014 Сообщений: 569
	18.02.2015, 22:42	14
	x_Alex_x, ну тогда мой вариант, единственный мной известный способ подражания множественному наследованию. Если бы у вас класс GraphicsGeomObj не инкапсулировал поля, можно было бы воспользоваться дефолтными методами в интерфейсе. 0