Новая тема   Ответить

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 rickdeckard


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

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

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

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

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

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

 Smarty

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

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

 Smarty
S_Flash писал:
Сферическим конем в вакууме попахивает.
Просто как ни крути любой паттерн тебе не на пальцах же будут разъяснять а на каком то языке.
Взять элементарный синглтон. Вроде все понятно, но в той же джаве он несколькими правильными вариантами м.б. реализован. Не считая
public enum Singleton {
   INSTANCE;
}
к примеру от Joshua Bloch.
А потом "ну тут же не ленивая инициализация, давайте другой синглтон".

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

 Ailk
-

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

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

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

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

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

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

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

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