так солид в руби не возможен

даже с этими принципами можно отхватить, так что не аргумент

ну да, но я не сказал ко всем)

насколько подавляющему тоже нельзя сказать, ну и доказать

просто мнение

так солид в руби не возможен

почему?

какие приниципы то? солид?

самые базовые

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

энкапсуляция, наследование, полиморфизм. но имхо энкапсуляция самый важный принцип

в солид то лучше написано, single responsibilty

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

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

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

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

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

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

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

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

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

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

"мы всегда так писали"

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

именно наследование реализации

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

если в методе (или даже наверное методах) родителя внести изменения

и я хз че с этим делать. только стараться не оверрайдить мб

если в методе (или даже наверное методах) родителя внести изменения

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

ой бля нет не так. щас

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

Дальше ради производительности вносим в родительский класс изменения: вставить_несколько например не использует больше через луп вставить_один, а делает как-нибудь по-своему. И тогда вот это изменение в родительском классе ломает дочерний класс, потому что вставить несколько больше не мониторится

Вот, пример вспомнил, а как обобщить правило хз

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

ну почти

близко, но не то

Может это? https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle

по-моему нет "an entity can allow its behaviour to be extended without modifying its source code."

почему нет?)

у кого-нибудь есть мысли по этому поводу? я просто слышал по сути только "наследование имплементации надо запретить, надо наследовать интерфейс"

почему нет?)

ну типа, это означает, что поведение класса можно дополнить в другом месте

не трогая его непосредственные сорцы

так

в твоём примере переписали сорцы, только родителя

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

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

не

этот принцип разрешает "расширять" поведение сущности без изменения её сорцов

всё верно

ну наследование по факту просто

ну не только, ещё можно манкипатч

вот, но он не говорит, что нельзя изменять поведение сущности в другом месте

говорит, что можно дополнять

ты про дочернюю сущность?

её нельзя переписывать?

а родителя - можно?

ну так так вообще ничо нельзя наследовать. можно даже упростить - не два метода, а один. а в наследнике super и потом ишо что-то

нет, я про родителя

меняешь parent - child сломался

каким образом? подробней плз

нет, я про родителя

тогда получается, что его (родителя) повредение переписали

ну про переписали там тожене сказано, что нельзя

суть в том что можно расширять

не изменяя сорцы

каким образом? подробней плз

а, или ты имеешь в виду, что как ты там называл вставить_несколько по сути не поменялся наружу, а только изменил свою внутренюю имплементацию - а это уже сломало чайлд?

тогда не оверрайди приватные методы =)

ну про переписали там тожене сказано, что нельзя

как это не сказано? entity can allow its behaviour to be extended without MODYFYING its source code.

а, или ты имеешь в виду, что как ты там называл вставить_несколько по сути не поменялся наружу, а только изменил свою внутренюю имплементацию - а это уже сломало чайлд?

да

тогда не оверрайди приватные методы =)

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

как это не сказано? entity can allow its behaviour to be extended without MODYFYING its source code.

>can allow

про запрет ничего же

про запрет ничего же

Как хочешь)

ERROR: S client not available

ну я не вижу запрета)

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

ну тогда айайай, его ведь удалили - а это был паблик интерфейс класса

не удалили

он остался в том и смысл

и вставить_много остался

только внутри изменился и уже не вызывает вставить_один

а другой класс мониторил тем, что оверрайдил вставить_один

и поэтому у него поломался монитор вставить_много

только внутри изменился и уже не вызывает вставить_один

а другой какой-то код все еще вызывает выставить_один?

аа все, понял

Всем загадка. Как создать и удалить в bash файд с именем -r

только что решил.

было интересно.

touch "—r."

touch "—r."

не работает же

Теперь у меня более захватывающая загадка как проверить через test в BASH сущестование файла с именем -f я ее не решил.

не работает же

➜ ~ mkdir 1 ➜ ~ cd 1 ➜ 1 touch "—r." ➜ 1 ls —r. ➜ 1 rm "—r." ➜ 1 ls ➜ 1

➜ ~ mkdir 1 ➜ ~ cd 1 ➜ 1 touch "—r." ➜ 1 ls —r. ➜ 1 rm "—r." ➜ 1 ls ➜ 1

там точка стояала в конце предложения

я удалил ее для того чтоб ошибок небыло

файл с именем '-r' как ключь для команды rm

имя из двух символов name ='-r' '-' == name[0] 'r'==name[1]

как интересно.

у меня он не создает

ладно, не ломай голову. Там не минус, там дефис %)

ладно, не ломай голову. Там не минус, там дефис %)

прикольно. а как дефис печатать?

compose + дабл минус

а, трипл :)

compose это что?)

compose + дабл минус

интеерсно, я с этим не сталкивался, я даже что такое compose гуглил, но не разобрался.