ладно, в php все равно нет явного объявления и краха с памятью или аодобным не случится

в PHP или любых других языках с динамической системой типов ты это из коробки имеешь: function add() { $args = func_get_args(); if (count($args) > 1) { $numbers = $args; } else { $numbers = $args[0]; } return array_reduce($numbers, function($sum, $number) { return $sum + $number; }, 0); }

конечно не так красиво как может показаться но в целом работает так же. Просто ифы явные вместо сравнения по сигнатуре

веселуха, че

а что про LSP

ну в целом все просто. LSP как бы тебе говорит что если у тебя система завязана на какую-то абстракцию с типом T, если ей подставят любую реализацию этой абстракции являющейся типом T', система должна продолжать работать корректно. То есть никаких "новых" исключений, никаких доп проверок на входящие аргументы.

> Be conservative in what you send, be liberal in what you accept"

это просто термин чтобы посоны не беспокоились и применяли чаще

то есть мы можем ослаблять прекондишены но инварианты оставляем теми же

это просто термин чтобы посоны не беспокоились и применяли чаще

не, это весьма важный принцип который иногда нарушают)

например в PHP комьюнити многие бесились что мол return type hinting нельзя переопределить в дочерних классах

это как раз таки последствие LSP

если ты обязался выплевывать тип SomeParent то уж изволь продолжать это делать

хм, хорошо, видимо я с этим еще столкнусь

хм, хорошо, видимо я с этим еще столкнусь

про LSP могу видос дать

спасибо за обяснение LSP! а то я его сразу так и не понял

что за видос? :)

https://www.youtube.com/watch?v=bVwZquRH1Vk

у этого чувака весьма годные объяснения

а что насчет OCP и ISP? ха видос спасибо, схоронил, днем посмотрю

OCP это "расширяй функционал не меняя код"

ISP - "лучше маленькие специализированные интерфейсы чем жирные и много функциональные"

про это в другой раз) а то я уже чет спать хочу

OCP это "расширяй функционал не меняя код"

это вообще как?

это вообще как?

декорация, полиморфизм)

ISP - "лучше маленькие специализированные интерфейсы чем жирные и много функциональные"

это очевидно, можно не объяснять

декорация, полиморфизм)

декорация...

это очевидно, можно не объяснять

там есть нюансы небольшие. Быстрый пример

декораторы?

class Base64 implements Encoder, Decoder

где надо encode делать - юзаешь Encoder. Где decode - Decoder

ну мол идея в том что твои объекты... они как бы живут себе в капсулах в ус не дуют и делают себе работу

но иногда им надо с другими объектами общаться, то есть в их капсулу могут приходит всякие там свидетели иеговы и т.д. и отвлекать по всяким глупостям о боге

а им только декодировать base64 иногда надо

ну мол идея в том что твои объекты... они как бы живут себе в капсулах в ус не дуют и делают себе работу

небольшие, но вместе составляют нужный функционал

небольшие, но вместе составляют нужный функционал

по отдельности скорее)

ну мол у тебя интерфейсы и так самодостаточны

по отдельности скорее)

а, даже так, хм, есть какие-то ограничения по самодостаточности?

а, даже так, хм, есть какие-то ограничения по самодостаточности?

SRP)

ну то есть... один интерфейс - одна задача

например "подсчет стоимости товара"

SRP)

Ааа, свинью подложили! этого в списке нет :)

или там "рекалькуляция НДС"

по сути идеально интерфейс с одним публичным методом

иногда надо 2

3 - ну очень редко но может быть будет полезным

но больше лучше не делать

класс , у которого 2-3 метода и не более?

интерфейс.

иногда бывает так что с точки зрения coheasion удобне поместить реализации 5-ти интерфейсов в одном классе

ладно, что такое интерфейс? из чего он состоит?

пример - опять же тот же Base64

если ты поменяем реализацию encode то и реализацию decode надо править

потому логично пихать это в отдельный класс

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

ладно, что такое интерфейс? из чего он состоит?

есть классы с методами, а интерфейс реализуется через абстракции?

есть классы с методами, а интерфейс реализуется через абстракции?

интерфейс и есть абстракция

интерфейс и есть абстракция

Бинго! мой мозн еще соображает

это "апишка" твоих объектов. поведение

то как ты можешь взаимодействовать с объектом. Публичные методы

можно объявить интерфейс без реализации (interface, abstract class)

но у всего так или иначе будет интерфейс

ладно, пока думаю достаточно, если хотите донести что-то еще, то приму, а так не хочу задерживать :)

про абстракции надо будет почитать, на выходных книг накачал

ладно, пока думаю достаточно, если хотите донести что-то еще, то приму, а так не хочу задерживать :)

интересный факт. Когда Алан Кей говорил что "все есть объект" он не говорил "все есть инстанс какого-то класса".

интересный факт. Когда Алан Кей говорил что "все есть объект" он не говорил "все есть инстанс какого-то класса".

инстанс...?

"экземпляр"

ERROR: S client not available

"экземпляр"

это имеет отношение к абстракциям?

все буквально есть объект. И та штука объект, и эта штука объект. И скаляры в php объекты, просто без поведения.

это имеет отношение к абстракциям?

это я к тому что бы ты не зацикливался на ключевых словах class, interface и т.д.

у всех этих вещей вполне себе конкретная история почему так сделали

это я к тому что бы ты не зацикливался на ключевых словах class, interface и т.д.

предстоит многое узнать

скажем те же модификаторы доступа - это кастыли которые нужны были в C++ потому что там объявление реализации интерфейса уехало туда же где интерфейсы живут - в заголовочный файл

у всех этих вещей вполне себе конкретная история почему так сделали

но особенности то необходимо знать, ведь есть разгица между класс и интерфейс

а оттуда пошло дальше)

но особенности то необходимо знать, ведь есть разгица между класс и интерфейс

это детали конкретного языка.

разлица лишь "абстракция" и "реализация"

скажем во всяких там ruby/python чуваки для абстракций делают просто классы с методами и оттуда кидают исключения.

абстракция полезна в крупном проекте только?

что мол "низя меня просто так юзать"

абстракция полезна в крупном проекте только?

декомпозиция полезна в крупном проекте только?

абстракция, это способ декомпозиции проблемы из большой на более мелкие

и вот с декомпозицией у нынешних разработчиков большие проблемы)

и вот с декомпозицией у нынешних разработчиков большие проблемы)

то что на несколько интерфейсов напихано много всего?

любят они снизу вверх на проблемы смотреть.

следовательно нарушение SRP

блин чувак ты сейчас просто гадаешь)

но в целом да - выливается это в нарушение SRP, нарушение закона деметры, нарушение инкапсуляции... полиморфизм - не не слышали

как мне кажется большая проблема в том что когда чуваки начинают писать например какой-то класс, то начинают с пропертей

как буд-то бы это самое важное что есть

а следует начинать с поведения. Что будет делать объект. А проперти - потом разберемся что там надо

ну и начинать надо с объекта под названием Application раз уж на то пошло)

а следует начинать с поведения. Что будет делать объект. А проперти - потом разберемся что там надо

мне без опыта этого не понять, если честно

мне без опыта этого не понять, если честно

можешь почитать про Actor Model

https://en.wikipedia.org/wiki/Actor_model

просто модель поведения?

разве не составление алгоритма? или это относится к процедурно-функц стилю?

ну твоя система это ничто иное как модель поведения

разве не составление алгоритма? или это относится к процедурно-функц стилю?

поведение может реализовывать какие-то алгоритмы