Чистый ООП

Где почитать пучиться стратегии использования ООП без единого if (других условных операторов) на чистом полиморфизме и наследовании? Ну и остальные перегибы в области ООП.

а что только без if, лучше на чистейшем OOP вообще без единого оператора


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

и что за каша в голове, какая связь между ООП и оператором if ?

dizziness: значит ты плохо шаришь в теме.

S_Flash: то есть ты хочешь сказать, что хочешь писать код, на php, в котором не будет ни единого if оператора? ок я плохо шарю, удачи!

dizziness писал:

S_Flash: то есть ты хочешь сказать, что хочешь писать код, на php, в котором не будет ни единого if оператора? ок я плохо шарю, удачи!

1) Я не говорил про php.
2) Я не собираюсь имменно писать код, я хотел почитать.
3) Да, есть такой стиль ООП, где нет if. Так же, как в чистом функциональном подходе нет не единого цикла. Надеюсь хоть тут ты знаешь как обходиться без циклов!!

Хз на счет книг конкретно по этой теме, но можно для начала погуглить тему "if-less programming" и попробовать поизучать Smalltalk для расширения, так сказать, кругозора.

dizziness писал:

хочешь писать код, на php, в котором не будет ни единого if оператора?

Не обязательно без единого. Можно начать с того, чтобы не сувать if-else в любую щель. Как пример:
https://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html

S_Flash: плиз, покажи хоть один реально работающий софт/скрипт(на гитхабе например) на любом языке, где нет ни одного if или его аналога, хочу посмотреть , для общего развития.

Mika: "сувать if-else в любую щель" это одно, а "без единого if (других условных операторов)@SFlash" это мне кажется совсем другое.

Mika: спасибо, я в этом направлении и хотел копать.

ну крутое ООП это когда if заменится на объекты благодяря полиморфизму - но имхо объекты в данном плане оверинженеринг - хуже как по производительности так и по потреблению памяти. а так же в поддержке.

if это примитивы, конструкции языка
объекты же должны представлять некую доменную логику а не пытатся заменять примитивы языка

меньше кода -> крепче сон

когда был студентом и после завершения универа тоже обмазывался ООП
да так что преподы или например на экзамене задавали вопросы - зачем все усложняеш? на этот вопрос я не мог дать ответа - кроме такого "типа так делают крутые дяди".
повзрослев и поработав с реальными проектами - познал дзен того что ООП не нужно вообще.

Последний раз редактировалось: rickdeckard (14/03/17 в 21:05), всего редактировалось 1 раз

Интересовал именно теоретический аспект.

дак всеми известная книга банды четырех

rickdeckard писал:

дак всеми известная книга банды четырех

Да вот лежит передо мной. Была б она на выбор в смысле на разных языках! Или хотябы на Java, а то что-то мне не хочется снова окунаться в указатели и ссылки.

Недавно, тоже решил обмазываться.

Вот классные рекомендации: https://www.reddit.com/r/PHP/comments/5ycrzx/anyone_use_vanilla_php/dep2zp9/

ООП ООП
вот пока плюс это не увидел - написал на PHP использую ООП дорген для себя, прикольно. Но скрипты небольшие по быстрому на функциях собираю. Да ещё и если размер кода функций не расширять а делать в 20-30 строк кода, то вообще красиво получается и читаемо )
Я как бы не против ООП, просто если не понимаешь зачем это, то не дорос ещё. Думаю на больших проектах ООП даёт результаты лучше чем на функциях софт. Но какой то генератор, парсер, бродилку и тп имхо проще по быстрому на функциях реализовать. Хотя думаю если куда то наймом идти, где работа с чужим кодом, да и просто при собеседовании для понта ООП нужно знать.
На счёт данного в топике линка https://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html
глянул - сейчас, по правилам чистого кода, без запаха, case некрасиво использовать из за затруднения чтения кода и непоняток break забыл кодер или не нужен и тп, это несколько секунд задержки анализа когда и необязательно другим человеком, может самому через 2 года придется код свой же читать.

Давайте в темах ООП забудем про php

Тяжело говорить об ООП безотносительно конкретного языка. К примеру - множественное наследование классов. В JAVA его нет, зато есть множ наследование интерфейсов.
И т.д.
Да и "чистые перегибы" в сторону ООП могут привести к полнейшей непролазной хуйне. Бацхуякс и перед тобой уже какая нибудь фабрика абстрактных фабрик.

Smarty писал:

Тяжело говорить об ООП безотносительно конкретного языка.

Тяжело, но никто не говорил, что будет легко. Просто большинство не рубит в самом ООП, а только умеют дёргать методы через точки, стрелочки и двоеточия. Я же хочу познать дзен. Имею право? Думаю, да.
Топик называется "Чистый ООП", странно, что многие путают его с "Практическим ООП".

S_Flash писал:

Топик называется "Чистый ООП", странно, что многие путают его с "Практическим ООП".

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

Код: [развернуть]

public enum Singleton {    INSTANCE; }

к примеру от Joshua Bloch.
А потом "ну тут же не ленивая инициализация, давайте другой синглтон".

Посмотри синтаксис языка erlang , там похожий вынос мозга как ты хочешь

-

Последний раз редактировалось: Ailk (21/09/17 в 10:14), всего редактировалось 1 раз

Православный Gof
ООП

В ФВ сразу смотреть с целью понять лаконичный подход к ООП это утопия имхо. Скорее всего ничего вы не поймете почему что то сделано именно вот так и почему автор принял такое решение. В другом ФВ решение такой же задачи может быть другим и тоже правильным. Из стана yii-стов к примеру в Ларавелистов и обратно можно кучу плевков набрать и в принципе согласиться с мнением и тех и других. Написать свой велосипед и гордиться им.

Если начинать приучать себя к правильному программированию на ООП то прежде всего нужно понять имхо СОЛИД подход и оглядываться на него при построении архитектуры приложения.
Конкретно по курсам можно Головача посмотреть. Они для джавистов конечно, там есть вода, самолюбование автора но в принципе человек живым языком рассказывает что и как применять. Там же он и литературу приводит. ГОФ-ов тех же самых.
Надеюсь вам хватит того же Головача чтобы понять, что истина не в правильных паттернах и том как вы красиво вот тут декоратор влепили и без ифов остались.

В программировании здравый смысл все таки более важен чем следование прямой линии генпартии от паттернов и тд. И прочитать несколько книжек по паттернам, посмотреть обучающие лекции даст знания для прохождения собеседования но не подскажет вам как построить правильную архитектуру приложения с ходу.
Это как смотреть рекламу форекс клубов. Типа вот тут вы купили доллар по такой цене а тут продали по другой и получили профит. В реальности это редко бывает.
Как будто у вас не было никогда заказчиков которые в середине проекта хотят куда-то пятое колесо влепить в типа вашу идеальную модель.
Поэтому ну нету православного ООП. Даже в Jave создатели Spring местами поклали болт на ООП и выдали концепцию АОП. Имели право.

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

Smarty: то что я знаю функциональное программирование и хвостовые рекурсии, не факт, что я применяю его на практике всегда в чистом виде. Всё же цикл, как и другим кодерам, так и машине будет проще для проглатывания. То же отношение у меня к чистому ООП, что он может где-то даже отжирать производительность, не говоря уже про то, что время на проектирование мелочей.
Но у меня проблемы с частью паттернов ООП. Хотел бы познать полный дзен. А там где надо быстрый и реальный продакшн, я и в императивном стиле накатаю, и не дрогнет у меня!..

Мне по СОЛИД кстати лекции от Pluralslight понравились - SOLID Principles of Object Oriented Design. Разбирается каждый принцип с плохим примером, объясняется почему это плохо в том числе и с UML диаграммами, добавляются интерфейсы, рефакторится пример.
Вот там приямо с опен-клозед принципа начинают мастерски от ифов избавляться xD