Основы ООП: перегрузка, полиморфизм, абстракция, интерфейсы.
Полиморфизм детально
Переопределение методов
Приведение ссылочных типов: расширение и сужение. type cast
Динамическая диспетчеризация методов
Доступ к методам базового класса - super
instanceof
Перегрузка методов
Абстрактные классы
Интерфейсы
Что еще можно посмотреть на досуге:Глава "Полиморфизм" в Thinking in Java
Для чего нужен super - официальная версияТут можно скачать краткую инструкцию по хоткеям в IntelliJ Idea
Нашли классную ссылку к материалу данной темы? Добавьте ее сюда в виде комментария.
Возможно, именно Ваша ссылка поможет другому человеку стать программистом и улучшить свою жизнь!
Я тоже прошла уровни 11 и 12 за два дня, с легкостью решала практически все задачки. Меня не отпускает ощущение, что я о полиморфизме, интерфейсах, абстрактных методах узнала только теорию, а тренировалась на написании синтаксиса. На каждую темку несколько одинаковых задачек, расставить кодовые слова и т.п. Задачек по смыслу не было не одной! Или с таким багажом (10 уровней) нельзя пока ничего написать по смыслу, и смысловые задачки будут позже? Может кто-нибудь прокомментировать?
Сам надолго застрял на последней задачке 20 уровня. Сейчас вот дело сдвинулось с мертвой точки. Про следующие уроки слышал, что они состоят из много мелких, но объединенных в одну большую. Возможно как раз в них и возможно отработать принципы)
Помогите пожалуйста разобраться в понятиях сужения и расширения ссылочных типов. Есть разногласие в этих понятиях в лекции 12 данного курса и по ссылке http://old.intuit.ru/department/pl/javapl/7/2.html
В лекции сказано следующее:
А на intuit.ru следующее, то есть всё наоборот, поменяны понятия сужения и расширения типов:
То есть в лекции 12 переход от производного класса (дети) к базовому (родители) называют «классическим сужением типа», а на интуите «переход от детей к родителям» называют расширением. Где же правильно, или что-то я не правильно понимаю? Спасибо
Запомни главное правило:
Набор методов, которые можно вызвать у переменной, определяется типом переменной. А какой именно метод/какая реализация вызовется, определяется типом/классом объекта, ссылку на который хранит переменная
На мой взгляд ДжаваРаш в лекции имели в виду Расширение/Сужение с точки зрения выбора доступных методов у преобразованной переменной (здесь: теперь у Кита будут методы Кита и Коровы).
А вообще да — когда преобразовывают к наследнику это нисходящее преобразование и наоборот.
теперь это…
Я считаю правильно так: от общего к конкретному – сужение типов, а с точки зрения доступных методов назвали бы расширение функциональности/ возможностей/ содержимого типа.
В первом уроке этого уровня, 3-й пункт «Приведение типов», по-моему написан с грамм. ошибкой «Т.к. класс при наследовании получает все методы и данные класса родителя, то объект этого класса разрешается сохранять (присваивать) в переменные класса родителя». буква «у» слову ОБЪЕКТ в студию!
Корректен ли пример применяемый в лекции, где кит наследуется от коровы?
в «Философии Java» и других источниках написано, что наследование применяется там, где есть связь «является».
Кит ведь не является коровой.
Плюсую, тоже обратил внимание. В Дополнительных материалах к лекции 11 есть линк на статью, откуда цитата: «Если у нас есть классы А и В и если класс А „не является“ разновидностью класса В, то А не должен быть подклассом В. (Grady Booch, Object-Oriented Analysis and Design with Applications)». И в первой же лекции 12 уровня идёт пример про кита, наследующегося от коровы.
Все таки считаю некорректным утверждение «Статические методы не наследуются и, следовательно, не переопределяются» в первом уроке «Полиморфизм и переопределение». Потому как если написать класс A со статическим методом method, потом написать класс B extends A, в котором методов не создавать, после чего вызвать B.method(), то мы получим выполнение действий, указанных в реализации этого метода в классе A.
public class A
{
public static void method()
{
System.out.println(«class A»);
}
}
public class B extends A
{
}
public static void main(String[] args)
{
B.method();
}
Вывод: class A
Что это, если не наследование статического метода?
С другой стороны, напиши мы реализацию этого метода в B, то есть переопредели его, то при вызове B.method, мы получим выполнение действий, описанных в реализации класса B. Что это, если не переопределение статического метода?
public class A
{
public static void method()
{
System.out.println("class A");
}
}
public class B extends A
{
public static void method()
{
System.out.println("class B");
}
}
public static void main(String[] args)
{
B.method();
}
Вывод: class B
Да, если в этом случае создать экземпляр класса B в переменной класса A и вызвать у нее этот статический метод, то вызовется реализация, описанная в классе A
A a = new B();
a.method;
Вывод: class A
Но тут надо просто сказать, что при вызове статического метода у переменной компилятор вместо нее подставляет ее тип, и не смотрит, что в ней содержится. Т.е. следующин 2 вызова статических методов аналогичны:
Возможно, в той лекции имеется ввиду переопределение (замена) и наследование методов на уровне полиморфизма.
Для статических методов механизм динамической диспетчеризации не применим, по определению.
а значит полиморфизм для них не работает. как то так…
Думаю, каждый, кто попробует испытать код из уроков про интерфейсы, столкнется с ошибкой компиляции при объявлении методов классов, унаследованных от интерфейсов. Как написали здесь, это происходит потому, что к каждому методу интерфейса неявно приписывается публичный уровень доступа, поэтому попытка объявить метод без модификатора public приведет к ошибке.
Например
<code>interface WallBuilder
{
void buildWall();
}
class Robot implements WallBuilder
{
//void buildWall(); - ТАК НЕЛЬЗЯ
public void buildWall(); //надо так
}</code>
Наверное есть смысл упомянуть об этом в самом уроке.
Друзья, помогите, пожалуйста разобраться.
В лекции №12 сказано, что наследовать и переопределять можно только не статические методы. Так же говориться, что статические методы не наследуются и, следовательно, не переопределяются.
Решил проверить. У меня всё наследуется и переопределяется:
<code>
public class Parent {
public static void method()
{
System.out.println("Method.");
}
public static void print()
{
System.out.println("In Parent.");
}
}
public class Heir extends Parent
{
public static void print(String str)
{
System.out.println(str);
}
public static void print()
{
System.out.println("In Heir.");
}
}
public class Main {
public static void main(String[] args) throws Exception {
Heir heir = new Heir();
heir.method();
heir.print();
heir.print("In Main.");
}
}
</code>
class Parent {
public static void method()
{
System.out.println("Method in Parent.");
}
}
class Heir extends Parent
{
public static void method()
{
System.out.println("In Heir. Overridden");
}
}
public class Main {
public static void main(String[] args) throws Exception {
Parent heir = new Heir();
heir.method();
}
}
Вывод:Method in Parent.
class Parent {
public void method()
{
System.out.println("Method in Parent.");
}
}
class Heir extends Parent
{
public void method()
{
System.out.println("In Heir. Overridden");
}
}
public class Main {
public static void main(String[] args) throws Exception {
Parent heir = new Heir();
heir.method();
}
}
Вывод:In Heir. Overridden
Статик метод, который будет вызываться определяется типом, а не объектом.
И вообще вызывать статик метод от объекта неправильно.=)
Это понятно, и объясняется тем, что эти методы расположены в стеке.
Просто, прочитав «что статические методы не наследуются и, следовательно, не переопределяются» я не совсем понял о чем идёт речь.
Спасибо за ответ.
class abstract ChessItem implements Drawable, HasValue
не должен ли класс наследовать еще и интерфейс Element(описан выше данного)? или только его. Было бы логично — все методы оттуда реализованы в потомке (getX, getY + из Drawable и HasValue).
public Container (AbstractMaterial material, int cargoWeight, int width, int length, int heigth) {
if (material instanceof SolidMaterial){
this.Container(material, cargoWeight, width, length, heigth);
}
// TODO Auto-generated constructor stub
}
public Container (SolidMaterial material, int cargoWeight, int width, int length, int heigth) {
super(material, cargoWeight);
this.width = width;
this.heigth = length;
this.length = heigth;
this.cargoWeight = cargoWeight;
}
Ругается:
The method Container(AbstractMaterial, int, int, int, int) is undefined for the type Container
<code>public Container(AbstractMaterial material) {
if (material instanceof SolidMaterial)
super(material, cargoWeight);
// TODO Auto-generated constructor stub
}</code>
Такой код не проходит компиляцию, так как супер должен быть первым. Что можно предложить в замен? Класс Container является тоже наследником Абстрактного класса.
Смысл в том, чтобы в Контейнер помещались только Твердые_Материалы.
public Container(AbstractMaterial material) {
if (material instanceof SolidMaterial)
this.Cintainer(material, cargoWeight);
// TODO Auto-generated constructor stub
}
public Container (SolidMaterial material, int cargoWeight) {
super(material, cargoWeight);
}
Попробуй конструктор создай Container(SolidMaterial material, int cargoWeight) и его вызови в основном, как-то так. По коду могут быть ошибки, но мысль такая.
Ну начнем с того, что super для твоего потомка вызывается в любом случае, пишешь ты его или нет.
Ты можешь написать нужный тебе метод в родительском классе. И вызывать его вместо
super(material, cargoWeight);
Попробуй то, что hubert говорит. Создай метод в родительском классе, а в if вставь вызов метода из родительского класса(в котором будет соотв-нно использоваться родительский конструктор и произведены нужные действия).
А почему нельзя проверку перед созданием контейнера сделать? И вообще зачем вызывать конструктор, если уже создан контейнер(раз мы уже в конструкторе находимся)? Если нельзя проверить до вызова, то создай контейнер типа AbstractMmaterial, проверь на instanceof и если да, то new Container(SolidMaterial material).
И да, правильно поправили) Родительский (или другой) конструктор всегда вызывается только первой строкой, по другому нельзя никак. Даже если ты во втором конструкторе класса используешь первый конструктор того же класса, то ссылка на конструктор всё равно должна идти первой строкой:
private String name;
private int age;
public Human(int a) {
age = a;
}
public Human(String name, int a) {
this(a);
this.name = name;
}
Ссылка на:
Глава «Полиморфизм» в Thinking in Java
давно уже как не дает возможности прочитать про Полиморфизм.
Может где в другом месте можно почитать?
Что еще можно посмотреть на досуге:
Глава "Полиморфизм" в Thinking in Java
Для чего нужен super - официальная версия
Тут можно скачать краткую инструкцию по хоткеям в IntelliJ Idea
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Как Вы думаете дженерики это все-таки полиморфизм или нет?)
В лекции сказано следующее:
А на intuit.ru следующее, то есть всё наоборот, поменяны понятия сужения и расширения типов:
То есть в лекции 12 переход от производного класса (дети) к базовому (родители) называют «классическим сужением типа», а на интуите «переход от детей к родителям» называют расширением. Где же правильно, или что-то я не правильно понимаю? Спасибо
А вообще да — когда преобразовывают к наследнику это нисходящее преобразование и наоборот.
теперь это…
Я считаю правильно так: от общего к конкретному – сужение типов, а с точки зрения доступных методов назвали бы расширение функциональности/ возможностей/ содержимого типа.
@Override — означает, что мы переопределяем метод, описанный в суперклассе
в «Философии Java» и других источниках написано, что наследование применяется там, где есть связь «является».
Кит ведь не является коровой.
Вывод:
class A
Что это, если не наследование статического метода?
С другой стороны, напиши мы реализацию этого метода в B, то есть переопредели его, то при вызове B.method, мы получим выполнение действий, описанных в реализации класса B. Что это, если не переопределение статического метода?
Вывод:
class B
Да, если в этом случае создать экземпляр класса B в переменной класса A и вызвать у нее этот статический метод, то вызовется реализация, описанная в классе A
Вывод:
class A
Но тут надо просто сказать, что при вызове статического метода у переменной компилятор вместо нее подставляет ее тип, и не смотрит, что в ней содержится. Т.е. следующин 2 вызова статических методов аналогичны:
Для статических методов механизм динамической диспетчеризации не применим, по определению.
а значит полиморфизм для них не работает. как то так…
альтернативная страница — это Глава «Полиморфизм» в Thinking in Java
или это другая статья на эту же тему?
оригинал:
статья:
Например
<code>interface WallBuilder { void buildWall(); } class Robot implements WallBuilder { //void buildWall(); - ТАК НЕЛЬЗЯ public void buildWall(); //надо так }</code>Наверное есть смысл упомянуть об этом в самом уроке.
В лекции №12 сказано, что наследовать и переопределять можно только не статические методы. Так же говориться, что статические методы не наследуются и, следовательно, не переопределяются.
Решил проверить. У меня всё наследуется и переопределяется:
<code> public class Parent { public static void method() { System.out.println("Method."); } public static void print() { System.out.println("In Parent."); } } public class Heir extends Parent { public static void print(String str) { System.out.println(str); } public static void print() { System.out.println("In Heir."); } } public class Main { public static void main(String[] args) throws Exception { Heir heir = new Heir(); heir.method(); heir.print(); heir.print("In Main."); } } </code>Вот вывод:«C:\Program…
Method.
In Heir.
In Main.
Process finished with exit code 0
Где ошибка?
Вывод:Method in Parent.
Вывод:In Heir. Overridden
Статик метод, который будет вызываться определяется типом, а не объектом.
И вообще вызывать статик метод от объекта неправильно.=)
Просто, прочитав «что статические методы не наследуются и, следовательно, не переопределяются» я не совсем понял о чем идёт речь.
Спасибо за ответ.
не должен ли класс наследовать еще и интерфейс Element(описан выше данного)? или только его. Было бы логично — все методы оттуда реализованы в потомке (getX, getY + из Drawable и HasValue).
Ругается:
<code>public Container(AbstractMaterial material) { if (material instanceof SolidMaterial) super(material, cargoWeight); // TODO Auto-generated constructor stub }</code>Такой код не проходит компиляцию, так как супер должен быть первым. Что можно предложить в замен? Класс Container является тоже наследником Абстрактного класса.
Смысл в том, чтобы в Контейнер помещались только Твердые_Материалы.
Попробуй конструктор создай Container(SolidMaterial material, int cargoWeight) и его вызови в основном, как-то так. По коду могут быть ошибки, но мысль такая.
Ты можешь написать нужный тебе метод в родительском классе. И вызывать его вместо
super(material, cargoWeight);
Глава «Полиморфизм» в Thinking in Java
давно уже как не дает возможности прочитать про Полиморфизм.
Может где в другом месте можно почитать?
www.jetbrains.com/idea/docs/IntelliJIDEA_ReferenceCard_Mac.pdf
same for Win and Linux
www.jetbrains.com/idea/docs/IntelliJIDEA_ReferenceCard.pdf