Наследование механизм объектно ориентированного программирования

Наследование механизм объектно ориентированного программирования

ребята, помогайте не очень умному как мы смогли отправить в барбершоп объекты типа cat и dog, если shear принимает в качестве параметра объекты типа animal? Почему это возможно? код из статьи: public class AnimalBarbershop < public void shear(Animal animal) < System.out.println("Стрижка готова!"); >> public static void main(String[] args) < Cat cat = new Cat(); Dog dog = new Dog(); AnimalBarbershop barbershop = new AnimalBarbershop(); barbershop.shear(cat); barbershop.shear(dog); >

полиморфизм тут описан как то странно. и вообще как правило это самая плохообъясненная часть ООП, у него нет четкого определения и везде его объясняют по разному. как я понимаю ПОЛИМОРФИЗМ — это возможность для разных классов, имеющих общее свойство, реализовать это свойство по своему. ну допустим птица и самолет, оба умеют летать, поэтому у обоих должен быть какой то метод описывающий эту способность. fly к примеру. поэтому у обеих будет интерфейс который декларирует это свойство. но летают они по разному, поэтому в каждом случае и реализация будет разной. Это и есть полиморфизм — есть классы с общим свойством, оно абстрактное, но у разных классов (конкретных объектов) есть конкретная реализация этого свойства, и она будет разной, в зависимости от объекта

Я не знаю почему абстракцию тут пишут как 4й принцип ООП. Есть разные приемы ООП, такие как ассоциация, агрегация, композиция и еще некоторые комбинации, абстракция это очень общее понятие, но в классических трудах все равно выделяют наследование, инкапсуляцию и полиморфизм. Хотя, как мне кажется, именно полиморфизм пришел с ООП, первые 2 уже были в С в виде «хаков». Сорри если оффтоп.

Читайте также:  Программирование пультов дорхан секционные ворота

Источник

Принципы объектно-ориентированного программирования

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

Вообще устроено все следующим образом: есть само объектно-ориентированное программирование. У него есть принципы. Из принципов объектно-ориентированного программирования следуют разобранные нам шаблоны GRASP (как вариант — SOLID принципы), из которых, в свою очередь, следуют шаблоны GoF. Из них же следует ряд интересных вещей, например, enterprise паттерны.

Объектно-ориентированная парадигма

Определение гласит, что «Объектно-ориентированное программирование – это парадигма программирования, в которой основной концепцией является понятие объекта, который отождествляется с предметной областью.»

Таким образом, система представляется в виде набора объектов предметной области, которые взаимодействуют между собой некоторым образом. Каждый объект обладает тремя cоставляющими: идентичность (identity), состояние (state) и поведение (behaviour).

Состояние объекта — это набор всех его полей и их значений.

Поведение объекта — это набор всех методов класса объекта.

Идентичность объекта — это то, что отличает один объект класса от другого объекта класса. С точки зрения Java, именно по идентичности определяется метод equals.

Принципы объектно-ориентированного программирования

Объектно-ориентированное программирование обладает рядом принципов. Представление об их количестве расходится. Кто-то утверждает, что их три (старая школа программистов), кто-то, что их четыре (новая школа программистов):

Инкапсуляция

Вопреки мнению многих собеседующихся (а иногда и собеседуемых), инкапсуляция это не «когда все поля приватные». Инкапсуляция является фундаментальнейшим принципом проектирования ПО, ее следы наблюдаются на только на уровне микро-, но и на уровне макропроектирования.

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

Таким образом, получается, что если класс A обращается к полям класса B напрямую, это приводит не к тому, что «нарушается информационная безопасность», а к тому, что класс A завязывается на внутренне устройство класса B, и попытка изменить внутреннее устройство класса B приведет к изменению класса А. Более того, класс A не просто так работает с полями класса B, он работает по некоторой бизнес-логике. То есть логика по работе с состоянием класса В лежит в классе А, и когда мы захотим переиспользовать класс В, это не удастся сделать, ведь без кусочка класса А класс В может быть бесполезным, что приведет к тому, что класс В придется отдавать вместе с классом А. Экстраполируя это на всю систему, получается, что переиспользовать можно будет только всю систему целиком.

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

Наследование

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

Наследование является самым переоцененным принципом. Когда-то считалось, что «У идеального программиста дерево наследования уходит в бесконечность и заканчивается абсолютно пустым объектом», потому как когда-то люди не очень хорошо понимали то, что наследование — это способ выразить такое свойство реального мира как иерархичность, а не способ переиспользовать код, отнаследовав машину от холодильника, потому что у обоих предметов есть ручка. Наследования желательно по возможности избегать, потому что наследование является очень сильной связью. Для уменьшения количества уровней наследования рекомендуется строить дерево «снизу-вверх».

Полиморфизм

Полиморфизм — это возможность использовать классы – потомки в контексте, который был предназначен для класса – предка.

За самым садистским определением кроется возможность языка программирования для декомпозиции задачи и рефакторинга if’ов и switch’ей.

Источник

Оцените статью