Подскажите паттерн пожалуйся. Режу старый класс на фунциональности. Каждая функциональность добавляет метод к интерфейсу (наследование) и расширяет существующий метод (похоже на Decorator). Но комбинировать декоратор с наследованием не получится, потому что декоратор не будет иметь доступ к внутренностям

т.е. декоратор должен вызывать какой-то protected метод базового объекта... (с++)

т.е. декоратор должен вызывать какой-то protected метод базового объекта... (с++)

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

какой то вопрос слишком непонятный

Подскажите паттерн пожалуйся. Режу старый класс на фунциональности. Каждая функциональность добавляет метод к интерфейсу (наследование) и расширяет существующий метод (похоже на Decorator). Но комбинировать декоратор с наследованием не получится, потому что декоратор не будет иметь доступ к внутренностям

осязательный пример можешь привести на конкретных объектах?

и яп сразу укажи)

1. базовый объект - state машина (режимы соединен/разъединен: методы connect(), disconnect()) disconnect() что-то делает внутри. 2. класс расширения -Трейсинг в файл. добавляет метод LogToFile(). К disconnect() надо добавить flus().

добавить вызвов flush()

а яп какой?

сделаю через обычную агрегацию, могу что на java что на пхп написать

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

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

на классы

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

можешь примерно в ideone накидать что у тебя есть?

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

сейчас покажу через агрегацию

на пыхе но переписать под любой яп можно

https://pastebin.com/gnS2H63g

Покажи

ссылка выше

https://pastebin.com/gnS2H63g

в чистом виде декоратор

в чистом виде декоратор

я знаю)

просто показал декоратор без наследования

а через агрегацию

во многих книгах его показывают именно через наследование

и люди думают что только так и можно

и так и так декоратор :)

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

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

ok, примеры они всегда полезнее слов

жду когда спс скажут ну или вопросы зададут как еще одну функциональность добавить)

Трейты?)

потом запаришься их рефакторить)

хотя дело вкуса все

и в scala они вполне норм)))

Подскажите паттерн пожалуйся. Режу старый класс на фунциональности. Каждая функциональность добавляет метод к интерфейсу (наследование) и расширяет существующий метод (похоже на Decorator). Но комбинировать декоратор с наследованием не получится, потому что декоратор не будет иметь доступ к внутренностям

вангую что ты где-то еще и LSP нарушил.

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

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

ну или я просто ничего не понял

ну или я просто ничего не понял

я тоже по началу ничего не понял

пока его неспросили про практический пример)

не могу найти

на пейстбине который7

да

я набрасал ему решение)

Похоже нарушил

Можно применить паттерн Шаблонный метод. Метод базового класса будет вызывать виртуальный метод определенный в наследующем классе tracing_flush(). Но при этом базовый класс должен предполагать какая функциональность должна быть добавлена и надо на каждую функциональность добавить шаблонных методов

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

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

паттерны ради паттернов

это определенный этап становления программиста

блин pidgin telegram мне половину сообщений не доставил

Спасибо за пример. Сейчас пытаюсь разобраться

яп с++

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

да для меня это ново. паттерны только потому чтобы повторно использовать код без правки. (а велосипеды писать - скорее всего ошибешься)

да для меня это ново. паттерны только потому чтобы повторно использовать код без правки. (а велосипеды писать - скорее всего ошибешься)

почитай про open/close

Декоратор с агрегированием - там расширять можно только последний класс, да?

Декоратор с агрегированием - там расширять можно только последний класс, да?

почему?

расширяй как хочешь

ну вот из примера https://pastebin.com/gnS2H63g , если я оберну еще одним декоратором то не будет доступа к расширеному функционалу (методы flushtofile())

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

либо этот декоратор должен иметь такой же расширенный интерфейс и транслировать дальше. вообщем муть выходит

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

Переопределение метода с super это наследование реализаций?

живые?)

:(

Шта

ку. Мне вот любопытно. Я на C# конечно не особо глубоко шарю.. приходится иногда по мелочи писать.. На счет паттерна Observer. В джаве же к примеру нет ни делегатов, ни ивентов, все как бы руками… потому обсервер в принципе как выход из положения для того чтобы триггерить разные события или подписываться на них - хороший выход. Но вот в си шарпе, нужна ли классическая реализация осбервера? я смотрю что вполне подобную логику мучу через подписку на нужные ивенты без оверинженеринга в плане наследования классов от обсервера и обсервабле.. что скажете? это так, просто теоретический момент.. любопытно..

ку. Мне вот любопытно. Я на C# конечно не особо глубоко шарю.. приходится иногда по мелочи писать.. На счет паттерна Observer. В джаве же к примеру нет ни делегатов, ни ивентов, все как бы руками… потому обсервер в принципе как выход из положения для того чтобы триггерить разные события или подписываться на них - хороший выход. Но вот в си шарпе, нужна ли классическая реализация осбервера? я смотрю что вполне подобную логику мучу через подписку на нужные ивенты без оверинженеринга в плане наследования классов от обсервера и обсервабле.. что скажете? это так, просто теоретический момент.. любопытно..

делегаты реализация обсервера в C#, так что можешь смело использовать их

вообще я на си шарп сначала блевался… а ща смотрю весьма грамотно все. Можно описывать свои геттеры/сеттеры для каждого поля, или же запрещать чтение или установку конкретного поля. И не нужно тулить кучу методов геттеров/сеттеров как в джаве.

вообще я на си шарп сначала блевался… а ща смотрю весьма грамотно все. Можно описывать свои геттеры/сеттеры для каждого поля, или же запрещать чтение или установку конкретного поля. И не нужно тулить кучу методов геттеров/сеттеров как в джаве.

еще бы, они были научены опытом java и выдали все что смогли, снабдив синтаксическим сахаром много вещей

сишарп - самый божественный ооп язык

я вообще писал на С++ еще давно когда-то немного, там еще когда только апрувили стандарт С++11