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

Любой объект реального мира обладает некоторыми свойствами (которые могут изменяться или не изменяться со временем) и некоторым поведением (которое может изменяться или не изменяться в зависимости от других условий). например, карандаш — это объект реального мира; который имеет следующие свойства:

Это красный цвет (не изменится со временем)
Это 10 см в длину на данный момент (может измениться при повышении резкости)

И это имеет следующие поведения:

Он оставляет след при правильном использовании.
Знак может варьироваться в зависимости от приложенного давления. (Зависит от внешнего фактора)
Его длина уменьшается при повышении резкости (постоянное поведение)

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

Программирование в OOPS, имеет свои преимущества. Например, программистам легче связать Объект с реальным миром и запрограммировать то, что ожидается. Это действительно полезно по мере того, как и когда приложение становится больше, и есть несколько объектов, взаимодействующих друг с другом. Это помогает в распределении обязанностей в объективном мире, позволяя сосредоточенное мышление.

Другая важная особенность, связанная с ООП (объектно-ориентированным программированием), — это классификация объектов. Поскольку мир (реальный / виртуальный) полон объектов, ими трудно управлять как отдельными объектами. Нам нужен способ классификации этих объектов, помогающий нам связать различные объекты и их особенности. например, черный цветной карандаш. Это все то же самое, что использовалось в предыдущем примере, но это другой объект. Но так как они оба карандаши, они принадлежат к одному и тому же классу «Карандаш». Принимая во внимание, что ручка, которая очень похожа на карандаш, принадлежит к другому классу. Хотя и Pen, и Pencil — это «пишущие инструменты».

Объектно-ориентированное программирование имеет следующие принципы:

абстракция

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

Например, если нам нужен класс, который пишет, мы можем быть уверены, что у него должен быть метод «write»

abstract class writer{
   write();
}

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

Это имеет много преимуществ

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

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

Наследование в общем английском означает, приобретать и передавать. Он существует в нашей культуре давно. Отцы и предки приобретают земли своим тяжелым трудом, а затем передают их детям, даже природа поддерживает наследство. Все особенности тела, такие как рост, цвет кожи / глаз / цвет волос и т. Д., Определяются генами, унаследованными нами от наших родителей. Это предотвращает повторное изобретение колеса и обеспечивает быстрый прогресс. То же самое и в ООП. Мы создаем родительский класс с несколькими базовыми свойствами / поведением. Все дочерние классы этого родителя будут содержать те же свойства / поведение, что и у родительского. Хотя ребенок может приобрести больше свойств / поведения или изменить реализацию поведения вместе.

class WritingInstrument{
   colour
   write(){
   }
} 
 class pen (child of parent){ 
  inkcolour
 }

В приведенном выше примере родительский класс (WritingInstrument) имеет свойство color и запись поведения. Когда дочерний класс (ручка) определен, определение цвета и повторная запись не требуются. Они присутствуют в классе ручки с помощью наследования. Однако дочерний класс может определять свои дополнительные свойства / поведение.

Итак, как мы можем использовать это на практике? Мы разработчики супер ленивые. Мы не хотим вводить что-то снова и снова. Хранение нескольких копий одного и того же кода также не является предпочтительным, поскольку

Помогает в управлении кодом, меньше копий означает меньше кода
Одно изменение места видно везде
Меньше ошибок из-за меньшего количества кода
Обобщение достигается, поскольку один код обслуживает несколько требований
Сосредоточенное кодирование
Целенаправленное тестирование

Наследование в Java достигается с помощью ключевого слова extends или реализовать.

class WritingInstrument{
}

class Pen extends WritingInstrument{
}

Полиморфизм

Слово полиморфизм происходит от двух слов

Поли : несколько / более одного
морфинг : форма / форма

Буквально слово полиморфизм относится к способности объекта вести себя по-разному в разных условиях.

В программировании полиморфизм может быть достигнут в нескольких местах

Классы
методы
операторы

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

class writingObjects{
    write(){
    // write using default colours
    }
}

class pencil extends writingObjects{
    write(){
    //write with grey colour, the text written is erasable
    }
}

class pen extends writingObjects{
    write(){
    //write with blue colour, the text written is not erasable
    }
}

class Main{
    main(){
       writingObjects wr= Object of writingObjects()
       wr.write(); // 1st call
       writingObjects wr= Object of Pen()
       wr.write() // 2nd call
       writingObjects wr2= Object of Pencil()
       wr2.write() // 3rd call
       }
}

В приведенном выше примере у нас есть реализация по умолчанию в writingObjects, которая расширяется / переопределяется дочерними классами Pen и Pencil. Метод write вызывается 3 раза в основном классе. Каждый раз вызывается другая реализация в зависимости от того, какой объект находится в контексте. Здесь метод write имеет несколько вариантов поведения, поэтому он полиморфен.

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

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

printUserProperties(username, userid, firstname, lastname, email, phone, ... ... ....)

Мы создали метод, который принимает все функции и распечатывает их одну за другой. С увеличением количества элементов списка способность идентифицировать правильное поле уменьшается, также с добавлением / удалением даже одного поля изменяется сигнатура этого метода. Следовательно, нам необходимо заменить всех клиентов этого метода, даже если добавленное поле ими не требуется. Чтобы сделать код более читабельным и упростить его модификацию, мы инкапсулируем свойства в классе и передаем его как коллективный объект.

class user{
    userName
    userId
    firstname
    lastname
    email
    phone
    ..
    ..
    ..
}

printUserProperties(user){}

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

В объектно-ориентированном программировании класс представляет собой расширяемый программный код-шаблон для создания объектов, предоставляющий начальные значения для состояния (переменные-члены) и реализации поведения (функции-члены, методы).

Аббревиатура SOLID была введена Майклом Фезерсом для «первых пяти принципов», названных Робертом К. Мартином в начале 2000-х годов. Принципы, применяемые вместе, призваны повысить вероятность того, что программист создаст систему, которую легко поддерживать и расширять с течением времени. Принципы SOLID — это рекомендации, которые можно применять при работе с программным обеспечением для удаления запахов кода, заставляя программиста проводить рефакторинг исходного кода программного обеспечения, пока он не станет разборчивым и расширяемым. Это часть общей стратегии гибкого и адаптивного программирования.

Принцип единой ответственности

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

Открытый / Закрытый Принцип

В объектно-ориентированном программировании принцип открытого / закрытого состояния гласит: «программные объекты (классы, модули, функции и т. Д.) Должны быть открыты для расширения, но закрыты для модификации»; то есть такая сущность может позволить расширять свое поведение без изменения исходного кода.

Принцип замещения Лискова

Заменимость является принципом объектно-ориентированного программирования. В нем говорится, что в компьютерной программе, если S является подтипом T, объекты типа T могут быть заменены объектами типа S (то есть объекты типа S могут заменять объекты типа T) без изменения какого-либо из желательных свойства этой программы (правильность, выполненная задача и т. д.).

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

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

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

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

Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

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

Принципы GRASP

Шаблоны программного обеспечения (или принципы) общего назначения ответственности, сокращенно GRASP, состоят из руководящих принципов для распределения ответственности между классами и объектами в объектно-ориентированном проектировании.

контроллер

Шаблон Controller назначает ответственность за обработку системных событий не-UI-классу, который представляет всю систему или сценарий варианта использования. Контроллер:

является объектом не пользовательского интерфейса, ответственным за получение или обработку системного события.
следует использовать для обработки всех системных событий одного (или нескольких связанных) случаев
является первым объектом за уровнем пользовательского интерфейса, который управляет работой системы.

Он не должен делать много работы сам по себе, кроме управления потоком событий

творец

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

Высокая сплоченность

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

косвенность

The Indirection pattern supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern.

Information Expert

Information Expert (also Expert or the Expert Principle) is a principle used to determine where to delegate responsibilities. These responsibilities include methods, computed fields, and so on. Using the principle of Information Expert, a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored. Information Expert will lead to placing the responsibility on the class with the most information required to fulfill it.

Low Coupling

Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support: lower dependency between the classes, change in one class having lower impact on other classes, higher reuse potential.

Polymorphism

According to Polymorphism, responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens. This is achieved using polymorphic operations.

Protected Variations

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

Pure Fabrication

A Pure Fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by the Information Expert pattern does not). This kind of class is called «Service» in Domain-driven design.

Criticism

A study by Potok et al. has shown no significant difference in productivity between OOP and procedural approaches.

critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP

Christopher J. Date

compared to other languages (LISP dialects, functional languages, etc.) OOP languages have no unique strengths, and inflict a heavy burden of unneeded complexity.

Lawrence Krubner

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all.

Alexander Stepanov

OOP’s popularity within large companies is due to «large (and frequently changing) groups of mediocre programmers.» The discipline imposed by OOP prevents any one programmer from «doing too much damage.»

Paul Graham

Object Oriented Programming puts the Nouns first and foremost. Why would you go to such lengths to put one part of speech on a pedestal? Why should one kind of concept take precedence over another? It’s not as if OOP has suddenly made verbs less important in the way we actually think. It’s a strangely skewed perspective.Steve Yegge

Rich Hickey, creator of Clojure, described object systems as overly simplistic models of the real world. He emphasized the inability of OOP to model time properly, which is getting increasingly problematic as software systems become more concurrent.

Eric S. Raymond, a Unix programmer and open-source software advocate, has been critical of claims that present object-oriented programming as the «One True Solution,» and has written that object-oriented programming languages tend to encourage thickly layered programs that destroy transparency.[42] Raymond contrasts this to the approach taken with Unix and the C programming language.

References

By Margaret Rouse @ WhatIs.com

Wikipedia!

inheritance is polymorphism

SOLID (Object Oriented Design)

Single Responsibility Principle Arguments against OOPS

What is OOPS (without the hype)