Задача ООП (иерархия классов, наследование, интерфейс и т. Д.)

Question

Поскольку я пытаюсь узнать больше о ООП (Java), я прорабатываю какую-то литературу, где я нашел эту «задачу». К сожалению, у меня есть трудное время, так как я довольно новичок в ООП, и у меня нет никакого образцового решения. Может быть, некоторые из вас могут дать мне некоторый вклад, поэтому я смогу пробиться через это.

---

1. Определить иерархию классов для этих классов:
   • четырехугольник
   • выпуклый четырехугольник
   • трапеции
   • параллелограмм
   • ромб
   • прямоугольник
   • площадь
2. Создать экземпляр каждого класса, если это возможно
3. Define разумные атрибуты и методы в каждом классе
4. перегрузки и переопределения методов
5. Написать разумные конструкторы для каждого класса
6. Использование модификаторов (абстрактные, статические, окончательные, общедоступные, защищенные и частные) значимым образом
7. Как можно использовать интерфейс для этой задачи?

---

01 Иерархия классов

Хорошо, это простая математика, и вы можете найти тонны информации о иерархии четырехугольники везде. Вот что я сделал:

---

Создание объектов каждого класса не большое дело, но я до сих пор есть некоторые проблемы с пониманием всех ООП-техники. Есть несколько моментов, когда я не знаю, какой был бы лучший способ сделать это ... (например, квадрат, который наследуется от двух классов, что в java просто невозможно). Кроме того, формулы (например, вычисление площади поверхности) будут перезаписываться все время в любом случае (поскольку они в большинстве случаев различны), так зачем мне наследовать в любом случае? Не могу ли я просто использовать интерфейс, использовать его во всех этих классах, заставить их реализовать эти формулы?

Greetings - Лисичка

Answer 1

В реальной жизни, вы, вероятно, было бы лучше использовать интерфейс. Глубокие структуры наследования, подобные этим, часто недовольны; обычно считается, что «предпочитают композицию над наследованием» (http://en.wikipedia.org/wiki/Composition_over_inheritance). Например, у вас может быть «четырехсторонний» интерфейс, который определяет «площадь поверхности» и «периметр», а затем другие формы удовлетворяют этому интерфейсу.

Если это вопрос о домашнем задании, то вы, вероятно, должны основывать иерархию классов на тех примерах, которые ранее предоставил ваш учебник/преподаватель.Речь идет не о разработке надежного программного обеспечения, а о том, чтобы доказать своему учителю, что вы научились делать все так, как им кажется, что вы должны их делать.

Answer 2

Абстрактный класс как основа умеренно сложной иерархии не так гибок, как интерфейс. Класс - абстрактный или нет - заставляет определенный тип реализации.

Не думая слишком много об этом, вот один из способов начать:

public interface Quadrilateral { 
    int getTopMillimeters(); 
    int getLeftMillimeters(); 
    int getRightMillimeters(); 
    int getBottomMillimeters(); 
} 

Из этого исходных данных, можно также определить

getTopLeftAngle(), getTopRightAngle(), ...

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

Я также хотел бы подчеркнуть состав над наследованием. Конечный эффект действительно может быть сложной структурой наследования.

Для меня композиция - это иерархия классов «Композитор», которые НЕ реализуют интерфейс. Такие, как

public class QuadrilateralComposer { 
    private final int iTopMM; 
    private final int iBtmMM; 
    ... 
    public QuadrilateralComposer(int i_topMM, int i_bottomMM, ...) { 
     if(i_topMM < 1) { 
     throw new IllegalArgumentException... 
     } 
     if(i_bottomMM < 1) { 
     throw new IllegalArgumentException... 
     } 
     ... 
     iTopMM = i_topMM; 
     iBtmMM = i_bottomMM; 
     ... 
    } 
    public int getTopMillimeters() { 
     return iTopMM; 
    } 
    ... 

который затем сочиненной абстрактного класса:

public class AbstractQuadrilateral implements Quadrilateral 
    private final QuadrilateralComposer qc; 
    public AbstractQuadrilateral(int i_topLen, int i_bottomLen, ...) { 
     gc = new QuadrilateralComposer(i_topLen, i_bottomLen, ...); 
    } 
    public int getTopLength() { 
     return gc.getTopLength(); 
    } 
    ... 

Абстрактные классы никогда не распространяются другие абстрактные классы, они используют только внутренние Композиторов (а на самом деле реализуют интерфейс). С другой стороны, композиторы только расширяют композиторы и используют другие композиторы внутри себя.

(три ноты: Защищенные функции в Composer как public function_4prot() и реализуются как protected function(), которые называют версию _4prot А иногда абстрактный класс может действительно реализовать все в интерфейсе В этом случае было бы бетон [.. не является абстрактным] и называться «SimpleXYZ» вместо «AbstractXYZ». Наконец, в Composer находятся статические функции полезности.)

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

Это не то, что вы просили, но изучение этой концепции изменило мой код для ПУТЕЙ лучше. Увидев это в принятом ответе, я задумался над всем этим. Я на самом деле медленно уходил от наследования к композиции за последние несколько лет, и после прочтения «Эффективной Явы» это был последний гвоздь в наследственном гробу.

Answer 3

Хорошо, теперь план заключается в том, что я пытаюсь разрешить это без какого-либо интерфейса. Итак, вот карта наследования:

Я игнорирую тот факт, что квадрат - это не только прямоугольник, но и ромб.

Абстрактный класс (четырехугольник) будет определять (но не реализовывать) методы расчета «площади поверхности» и «периметра». Переопределение методов легко, так как каждая форма имеет разные формы для вычисления, но я не совсем уверен, где я могу использовать функцию перегрузки.

---

Еще одна вещь: используя интерфейс, было бы это желательным способом?