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

ребята, помогайте не очень умному как мы смогли отправить в барбершоп объекты типа 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’ей.

Источник

Шпаргалка по принципам ООП

Чтобы стать программистом, нужно знать принципы ООП как Отче наш. Держите структурированную шпаргалку по объектно-ориентированному программированию.

Главное

Инкапсулируйте все, что может изменяться;
Уделяйте больше внимания интерфейсам, а не их реализациям;
Каждый класс в вашем приложении должен иметь только одно назначение;
Классы — это их поведение и функциональность.

Базовые принципы ООП

Абстракция — отделение концепции от ее экземпляра;
Полиморфизм — реализация задач одной и той же идеи разными способами;
Наследование — способность объекта или класса базироваться на другом объекте или классе. Это главный механизм для повторного использования кода. Наследственное отношение классов четко определяет их иерархию;
Инкапсуляция — размещение одного объекта или класса внутри другого для разграничения доступа к ним.

Используйте следующее вместе с наследованием

Делегация — перепоручение задачи от внешнего объекта внутреннему;
Композиция — включение объектом-контейнером объекта-содержимого и управление его поведением; последний не может существовать вне первого;
Агрегация — включение объектом-контейнером ссылки на объект-содержимое; при уничтожении первого последний продолжает существование.

Не повторяйся (Don’t repeat yourself — DRY)

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

Принцип единственной обязанности

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

Принцип открытости/закрытости

Программные сущности должны быть открыты для расширения, но закрыты для изменений.

Принцип подстановки Барбары Лисков

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

Принцип разделения интерфейсов

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

Принцип инверсии зависимостей

Система должна конструироваться на основе абстракций «сверху вниз»: не абстракции должны формироваться на основе деталей, а детали должны формироваться на основе абстракций.

Что думаете?

Ребят, тут собрались ноунеймы которые не работают ни на одном языке, но пишут свое очень важное мнение в комментариях. Лучше проходите мимо и не читайте их. Ах да, учите go и устройтесь в яндекс)

Как вы собираетесь искать хороших сотрудников, если (в большинстве компаний) честных кандидатов отметают даже не пригласив на техническое собеседование?Если умение лгать является обязательным, чтобы устроиться к вам на работу, то не удивляйтесь что «сложно найти хорошего сотрудника».Я знаю о чем говорю. В нашей компании для продвижения программистов на аутсорс есть целая отдельная команда, которая полностью специализируется на «продаже сотрудников». Это люди, которые пристально изучают хотелки чсв hr-ов, пишут «идеальные» резюме и отвечают на все вопросы так, «как надо». А программист приходит только на техническое собеседование в конце.Хорошие сотрудники (как правило) не станут накручивать себе 20 лет стажа, рассказывать про мотивацию «не ради денег», отвечать на глупые вопросы про квадратные люки и прочую ерунду.Вам нужно не учить людей в интернете «как правильно отвечать на наши вопросы, чтобы вы у нас прошли собес», а мыслить шире и заниматься реальным поиском толковых специалистов, которые не обязаны иметь топовые софт-скилы.В противном случае — получайте «идеальные» резюме, написанные по единому шаблону и котов в мешке. И не забудьте пожаловаться что «сложно найти хорошего сотрудника».

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

Источник