с утками решите сначала

Ну, мам, ну решил

Только не с такой постановкой как у уток

плевать с какой постановкой

public interface Utka { boolean krak (); boolean swim(); /* true == likereal */ } public class RealUtka implements Utka { /* returns true both */ } public class NotReal implements Utka { /* returns false both */ } public class Utochka { private Utka utka; public void chooseUtka (Utka utka) { this.utka = utka; } }

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

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

поэтому это не стратегия

и не композиция, ибо оверхед для уток

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

Так уточка вспомогательный класс

"Есть утка, которая крякает и плавает. Ученые создали искусственную утку, которая может искусственно крякать, искусственно плавать. Как сделать уточку, которая будет искусственно плавать и крякать по-настоящему, без трех реализаций абстрактного класса уточки" » искусственно плавать и крякать по-настоящему

в вашей реализации, уточка не умеет ни плавать, ни крякать

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

ps в реальности я бы делал третью реализацию интерфейса

Ну можно вот так извратиться: abstract Strategy { public act() } RealKryaStrategy extends Strategy{ public act(){ } } FakeKryaStrategy extends Strategy{ public act(){ } } RealSwimStrategy extends Strategy{ public act(){ } } FakeSwimStrategy extends Strategy{ public act(){ } } class Utka() public set swimStrategy(str:Strategy) { this.swimStrategy = str; } public set kryaStrategy(str:Strategy) { this.swimStrategy = str } public swim() { this.swimStrategy.act(); } public krya() { this.kryaStrategy.act(); } }

public interface Utka { boolean krak (); boolean swim(); /* true == likereal */ } public class RealUtka implements Utka { /* returns true both */ } public class NotReal implements Utka { /* returns false both */ } public class Utochka { private Utka utka; public void chooseUtka (Utka utka) { this.utka = utka; } }

Нет

Ну можно вот так извратиться: abstract Strategy { public act() } RealKryaStrategy extends Strategy{ public act(){ } } FakeKryaStrategy extends Strategy{ public act(){ } } RealSwimStrategy extends Strategy{ public act(){ } } FakeSwimStrategy extends Strategy{ public act(){ } } class Utka() public set swimStrategy(str:Strategy) { this.swimStrategy = str; } public set kryaStrategy(str:Strategy) { this.swimStrategy = str } public swim() { this.swimStrategy.act(); } public krya() { this.kryaStrategy.act(); } }

Слишком извращено

Слишком извращено

Если паттерн стратегия, то..

Слишком извращено

почему?

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

Если паттерн стратегия, то..

Зачем вам класс стратегия? SwimStrategy, CrackStrategy

interface для метода act

если уж по полной

Сам класс стратегии не несет в себе смысла, потому что его содержимое - действие. Что как бы не совпадает с названием

чутка перепутал - поправил

Ну можно вот так извратиться: abstract Strategy { public act() } RealKryaStrategy extends Strategy{ public act(){ } } FakeKryaStrategy extends Strategy{ public act(){ } } RealSwimStrategy extends Strategy{ public act(){ } } FakeSwimStrategy extends Strategy{ public act(){ } } class Utka() public set swimStrategy(str:Strategy) { this.swimStrategy = str; } public set kryaStrategy(str:Strategy) { this.swimStrategy = str } public swim() { this.swimStrategy.act(); } public krya() { this.kryaStrategy.act(); } }

что вы к стратегии прицепились, складывается впечатление, что не знаете сценариев использования этого паттерна

Сам класс стратегии не несет в себе смысла, потому что его содержимое - действие. Что как бы не совпадает с названием

Можно заменить на ф-ции. В JS так бы и сделал

сразу ф-ция действия

и никаких проблем

Можно заменить на ф-ции. В JS так бы и сделал

Суть не в этом. Вы нарушаете посыл вашего кода

Класс Strategy неочевиден

что вы к стратегии прицепились, складывается впечатление, что не знаете сценариев использования этого паттерна

Предложили поизвращаться. Попробовали. Такое себе

Предложили поизвращаться. Попробовали. Такое себе

)

Я правда не понимаю до конца вашей задачи скорее всего, ну как бы зачем мутить так воду, если я могу создавать каких мне угодно уток так ( ДАВАЙТЕ УЖЕ ВЕРНОЕ РЕШЕНИЕ В СТУДИЮ НЕ ТОМИТЕ public class Utka { boolean kra, swi; public Utka (boolean kra, boolean swi) { this.kra = kra; this.swi = swi; } }

Я правда не понимаю до конца вашей задачи скорее всего, ну как бы зачем мутить так воду, если я могу создавать каких мне угодно уток так ( ДАВАЙТЕ УЖЕ ВЕРНОЕ РЕШЕНИЕ В СТУДИЮ НЕ ТОМИТЕ public class Utka { boolean kra, swi; public Utka (boolean kra, boolean swi) { this.kra = kra; this.swi = swi; } }

+

Я правда не понимаю до конца вашей задачи скорее всего, ну как бы зачем мутить так воду, если я могу создавать каких мне угодно уток так ( ДАВАЙТЕ УЖЕ ВЕРНОЕ РЕШЕНИЕ В СТУДИЮ НЕ ТОМИТЕ public class Utka { boolean kra, swi; public Utka (boolean kra, boolean swi) { this.kra = kra; this.swi = swi; } }

+

Автор, ты сам то помнишь правильный ответ?)

class QuackStrategy { abstract doQuack(); } class RealQuackStrategy : QuackStrategy{ doQuack(){ /* do real quack*/ } } class FakeQuackStrategy : QuackStrategy{ doQuack(){ /* do fake quack*/ } } ///по аналогии - SwimStrategy, с соответствующими реализациями real и fake class Duck { private QuackStrategy quack; private SwimStrategy swim; Duck(QuackStrategy _quack, SwimStrategy _swim) { this.quack = _quack; this.swim = _swim; } doQuack() { this.quack.doQuack(); } doSwim() { this.quack.doSwim(); } }

не автор, но вот правильный ответ

class QuackStrategy { abstract doQuack(); } class RealQuackStrategy : QuackStrategy{ doQuack(){ /* do real quack*/ } } class FakeQuackStrategy : QuackStrategy{ doQuack(){ /* do fake quack*/ } } ///по аналогии - SwimStrategy, с соответствующими реализациями real и fake class Duck { private QuackStrategy quack; private SwimStrategy swim; Duck(QuackStrategy _quack, SwimStrategy _swim) { this.quack = _quack; this.swim = _swim; } doQuack() { this.quack.doQuack(); } doSwim() { this.quack.doSwim(); } }

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

верно

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

Та хорош) Нужен единый предок

нет

что-то вы от ангуляра отдалились... го лучше конкурс на самую большую директиву

Чтобы мог обращаться к методу act()

и зачем?

чтобы код красивее был

и все

по сути не нужен

красивее - когда читабельнее

а act слишком обобщенный

doQuack и doSwim понятнее

swimStrategy.act() - исчерпывающая информация

swimStrategy.doSwim() - все равное что mycomponent.component

:)

ну, короче, я бы так сделал. А правильно это или нет - дело второе

Я тут покурить вышел, а потом залип на ерроры шарповские. Но вот: using System; public class Program { public static void Main(string[] args) { var duck = new Duck(new NativeCrackStrategy(), new FakeSwimStrategy()); duck.Crack(); duck.Swim(); } public interface ICrackStrategy { void Crack(); } public interface ISwimStrategy { void Swim(); } public class Duck { private ICrackStrategy _crackStrategy; private ISwimStrategy _swimStrategy; public Duck(ICrackStrategy crack, ISwimStrategy swim) { this._crackStrategy = crack; this._swimStrategy = swim; } public void Crack() { this._crackStrategy.Crack(); } public void Swim() { this._swimStrategy.Swim(); } } public class NativeCrackStrategy: ICrackStrategy { public void Crack() { Console.WriteLine("crack like a native"); } } public class FakeCrackStrategy: ICrackStrategy { public void Crack() { Console.WriteLine("crack like a fake"); } } public class NativeSwimStrategy: ISwimStrategy { public void Swim() { Console.WriteLine("swim like a native"); } } public class FakeSwimStrategy: ISwimStrategy { public void Swim() { Console.WriteLine("swim like a fake"); } } }

class QuackStrategy { abstract doQuack(); } class RealQuackStrategy : QuackStrategy{ doQuack(){ /* do real quack*/ } } class FakeQuackStrategy : QuackStrategy{ doQuack(){ /* do fake quack*/ } } ///по аналогии - SwimStrategy, с соответствующими реализациями real и fake class Duck { private QuackStrategy quack; private SwimStrategy swim; Duck(QuackStrategy _quack, SwimStrategy _swim) { this.quack = _quack; this.swim = _swim; } doQuack() { this.quack.doQuack(); } doSwim() { this.quack.doSwim(); } }

Я конечно хотел написать класс на кваки и плавцы, но это же простите как то тупо

Ну мда

Ну мда

Задачки чаще всего абсурдны

swimStrategy.act() - исчерпывающая информация

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

и мало применимы к реальности

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

+

и мало применимы к реальности

А еще наверн, repository мало применим к реальности:)

и фабрики

А еще наверн, repository мало применим к реальности:)

ты прям мне войну сегодня объявил, я смотрю

Писать класс для метода, т.е. метод-класс, что? По моему это противоречит ООП

Писать класс для метода, т.е. метод-класс, что? По моему это противоречит ООП

Нет, в данном случае наша стратегия просто отвечает всего за одно действие

Писать класс для метода, т.е. метод-класс, что? По моему это противоречит ООП

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

Я тут покурить вышел, а потом залип на ерроры шарповские. Но вот: using System; public class Program { public static void Main(string[] args) { var duck = new Duck(new NativeCrackStrategy(), new FakeSwimStrategy()); duck.Crack(); duck.Swim(); } public interface ICrackStrategy { void Crack(); } public interface ISwimStrategy { void Swim(); } public class Duck { private ICrackStrategy _crackStrategy; private ISwimStrategy _swimStrategy; public Duck(ICrackStrategy crack, ISwimStrategy swim) { this._crackStrategy = crack; this._swimStrategy = swim; } public void Crack() { this._crackStrategy.Crack(); } public void Swim() { this._swimStrategy.Swim(); } } public class NativeCrackStrategy: ICrackStrategy { public void Crack() { Console.WriteLine("crack like a native"); } } public class FakeCrackStrategy: ICrackStrategy { public void Crack() { Console.WriteLine("crack like a fake"); } } public class NativeSwimStrategy: ISwimStrategy { public void Swim() { Console.WriteLine("swim like a native"); } } public class FakeSwimStrategy: ISwimStrategy { public void Swim() { Console.WriteLine("swim like a fake"); } } }

public class Utka { boolean kra, swi; public Utka (boolean kra, boolean swi) { this.kra = kra; this.swi = swi; } } А теперь сравним

>не забывай, что у тебя сейчас задача Хорошо

Смотри, ты передаешь всего функцию

Писать класс для метода, т.е. метод-класс, что? По моему это противоречит ООП

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

Я и говорю, что в реальности для реаизации подобного я бы не стал делать то же, что сделал для этой задачи. А не то что factory и т.п. не применимы к реальности, как решил передернуть Вадимир

Что, если в нашей стратегии будет ветвление? И там уже одной функции не будет, стратегия будет нести в себе определенные свойства

Смотри, ты передаешь всего функцию

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

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

:D я просто писал пример, в которой одной функции будет недостаточно

:D я просто писал пример, в которой одной функции будет недостаточно

Правда, ненавижу такие задачи, когда кажется, что нужно написать ответ в пару строк, а писать овермного. Но энивей спасибо за задачу с: Присылай еще

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

KISS

И если кандидат подумает об этом "если" - шанс на оффер выше

Если ты конечно не гребцом на галеру идешь

Кто-нибудь работал Angular2 + Firebase?

а если всё время думать о "если", можно закончить в бесконечной premature optimisation

а если всё время думать о "если", можно закончить в бесконечной premature optimisation

+ Довольно вредная привычка у многих программистов все усложнять. Только тут не оптимизация, а по структуре. Сразу вспоминается принцип Keep it Simple Stupid.

да я чисто вбросить... не читал даже о чём речь))

да я чисто вбросить... не читал даже о чём речь))

аа))

+ Довольно вредная привычка у многих программистов все усложнять. Только тут не оптимизация, а по структуре. Сразу вспоминается принцип Keep it Simple Stupid.

это когда у тебя pet-project

а когда у тебя суровый прод

у которого еще 2 года развития впереди

Просто ООП оно как бы по такой интерпрайз, когда у тебя есть ТЗ и оно не меняется.... один раз подумал, всё написал

лучше быть где-то посередине. Особенно если спек часто меняется

Просто ООП оно как бы по такой интерпрайз, когда у тебя есть ТЗ и оно не меняется.... один раз подумал, всё написал

Вотерфолл

а в реале очень часто всё и вся меняется

а в реале очень часто всё и вся меняется

+

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

Вывод - пока можешь - делай просто. Усложнить время будет

так что частенько если это не core, особо заморачиваться не стоит

Всем привет! Подскажите, плиз, как работать с BehaviorSubject? http://stackoverflow.com/questions/42055888/work-with-a-global-variable-initialized-via-behaviorsubject-angular2/42055905#42055905