Объектно-ориентированное программирование стало в настоящее время почти стандартом программирования, в вузах принципы ООП являются обязательными для изучения. 10-15 лет назад все только и говорили об ООП, потом появились паттерны проектирования, основанные на ООП. Знать паттерны считалось довольно крутым достижением.
Но сейчас в англоязычном интернете появляются статьи, направленные против ООП. Про паттерны проектирования больше никто не вспоминает, больше говорят про паттерны кода в конкретном языке программирования, либо про паттерны, не связанные с ООП. В советах, начинающим программистам больше не встречаются принципы SOLID. Давайте разберемся, а в самом ли деле ООП так нужно?
Сначала рассмотрим все принципы, лежащие в основе ООП.
1. Инкапсуляция. Если быть честным, то это не совсем принцип ООП. Скрывать поведение и выставлять наружу только необходимые методы умели и раньше и называлось это модульностью.
2. Наследование. Я сам применял не раз наследование и пришел к такому выводу, что наследование не следует применять слишком часто. Наследование - это конструкция нашего ума и в реальной природе вещей встречается редко. Обычные люди при организации информации редко применяют наследование. Например, в организации есть множество документов. Никто из документов не строит цепочки наследования, что вот этот документ наследует свойства во этого документа, хотя в каких-то случаях такие структуры наследования можно было бы применить. Если изменения вносятся в документ, то они касаются именно этого документа. Если необходимо внести изменения в группу документов, то перечисляются документы, которые должны быть изменены. Если бы программист стал использовать наследование для документов, то он бы обязательно столкнулся рано или поздно бы с тем, что задания, которые он получает сверху никак не учитывают его стройную систему классов и вынуждают его в каких-то случаях отказываться от наследования, а местами значительно переписывать код.
3. Полиморфизм. Тоже неплохое изобретение, но также страдающее недостатками, как и наследование, поскольку полиморфизм вообще не может существовать без наследования. Полиморфизм изменяет поведение объектов при наследовании. Чтобы понять, как воспринимает обычный человек полиморфизм, давайте представим себе музыканта, которому дали две пьесы, одна из которых наследует другую. Вот, говорите ему, эта пьеса играется вот так, а вот эта наследует первую. В на этой странице вместо форте играем пьяно, вот тут мы на пол-тона ниже, вот тут давайте у нас будет крещендо и вообще играем только четные страницы. Музыкант от такого наследования вас может послать вас знаете куда. Полиморфизм как и наследование вынуждает нас в случае проблем в коде обращаться ко всем предкам и разбираться в них.
Теперь о паттернах. Почему-то так получается, что когда я слышу, что человек восторженно рапортует о применении какого-то паттерна проектирования, то в большинстве случаев он излишне усложнил код. Иногда у меня даже складывается мнение о том, что лидер команды должен быть немного тупым, чтобы не делать слишком сложный код, который не поймет его команда. Но на самом деле мудрость в том, чтобы делать код простым, а не сложным.
Паттерны - это просто комбинации из объектов, использующие наследование и полиморфизм. В чистом виде паттерны практически не используются. Каждая конкретная структура классов - это не паттерн, а что-то свое. Однажды прочитав книжку про паттерны, я их тут же забыл, потому что явной пользы от них я не нашел. И где бы я не работал, из всех паттернов в общении используют только пару: синглетон и фабрика, да и про них тоже редко говорят.
Материалы по теме
Но сейчас в англоязычном интернете появляются статьи, направленные против ООП. Про паттерны проектирования больше никто не вспоминает, больше говорят про паттерны кода в конкретном языке программирования, либо про паттерны, не связанные с ООП. В советах, начинающим программистам больше не встречаются принципы SOLID. Давайте разберемся, а в самом ли деле ООП так нужно?
Сначала рассмотрим все принципы, лежащие в основе ООП.
1. Инкапсуляция. Если быть честным, то это не совсем принцип ООП. Скрывать поведение и выставлять наружу только необходимые методы умели и раньше и называлось это модульностью.
2. Наследование. Я сам применял не раз наследование и пришел к такому выводу, что наследование не следует применять слишком часто. Наследование - это конструкция нашего ума и в реальной природе вещей встречается редко. Обычные люди при организации информации редко применяют наследование. Например, в организации есть множество документов. Никто из документов не строит цепочки наследования, что вот этот документ наследует свойства во этого документа, хотя в каких-то случаях такие структуры наследования можно было бы применить. Если изменения вносятся в документ, то они касаются именно этого документа. Если необходимо внести изменения в группу документов, то перечисляются документы, которые должны быть изменены. Если бы программист стал использовать наследование для документов, то он бы обязательно столкнулся рано или поздно бы с тем, что задания, которые он получает сверху никак не учитывают его стройную систему классов и вынуждают его в каких-то случаях отказываться от наследования, а местами значительно переписывать код.
3. Полиморфизм. Тоже неплохое изобретение, но также страдающее недостатками, как и наследование, поскольку полиморфизм вообще не может существовать без наследования. Полиморфизм изменяет поведение объектов при наследовании. Чтобы понять, как воспринимает обычный человек полиморфизм, давайте представим себе музыканта, которому дали две пьесы, одна из которых наследует другую. Вот, говорите ему, эта пьеса играется вот так, а вот эта наследует первую. В на этой странице вместо форте играем пьяно, вот тут мы на пол-тона ниже, вот тут давайте у нас будет крещендо и вообще играем только четные страницы. Музыкант от такого наследования вас может послать вас знаете куда. Полиморфизм как и наследование вынуждает нас в случае проблем в коде обращаться ко всем предкам и разбираться в них.
Теперь о паттернах. Почему-то так получается, что когда я слышу, что человек восторженно рапортует о применении какого-то паттерна проектирования, то в большинстве случаев он излишне усложнил код. Иногда у меня даже складывается мнение о том, что лидер команды должен быть немного тупым, чтобы не делать слишком сложный код, который не поймет его команда. Но на самом деле мудрость в том, чтобы делать код простым, а не сложным.
Паттерны - это просто комбинации из объектов, использующие наследование и полиморфизм. В чистом виде паттерны практически не используются. Каждая конкретная структура классов - это не паттерн, а что-то свое. Однажды прочитав книжку про паттерны, я их тут же забыл, потому что явной пользы от них я не нашел. И где бы я не работал, из всех паттернов в общении используют только пару: синглетон и фабрика, да и про них тоже редко говорят.
Материалы по теме
Комментарии
Отправить комментарий