У меня сейчас ситуация реально что я могу любой час посвятить работе, выставить счёт и мне его оплатят

Или могу пойти книгу дописать, и потом окупится с её продаж

Помимо денег ещё есть мотивации, и конечно всё не свобидтся к тому, чтобы делать то, что выгодно

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

в оригинале было "либо хорошо, либо ничего, кроме правды"

У меня сейчас ситуация реально что я могу любой час посвятить работе, выставить счёт и мне его оплатят

а делегировать не пробовал? ведь, получается, ты — самое главное ограничение в процессе зарабатывания денег

а делегировать не пробовал? ведь, получается, ты — самое главное ограничение в процессе зарабатывания денег

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

И опять же, главная цель это не деньги (у меня). Это важно, но если посмотреть мой стратегический план на год, там всё в деньги не упирается

Дарт пропитан формалином

какими именно?

и нахера еще один мёртвый язык, если смалток никуда не делся (тоже мёртв)?

мертворождённый

какими именно?

идеей умереть

?

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

Симулякр — это подделка, не имеющая оригинала в реальности

Симулякр — это подделка, не имеющая оригинала в реальности

Я про это и говорю. Это такой успешный успех

С играми в эффективность можно не слабо провалиться в пропасть тяжелой депрессии . Короче, надо аккуратно играть с огнем.

С играми в эффективность можно не слабо провалиться в пропасть тяжелой депрессии . Короче, надо аккуратно играть с огнем.

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

Вопрос по тому же Visitor-у. Тк моя предмет. обл. замороченная - объясню на Shapes and Drawers. Есть Shape с его реализациями Circle, Triangle. И есть Drawer с CircleDrawer и TriangleDrawer. У клиента есть абстрактный Shape. Ему нужно получить соотвествующий Drawer. Те для конкретного Circle - CircleDrawer. Я хочу реализовать так: добавить фабрику DrawerFactory и передавать ее методу Shape createDrawer(DrawerFactory f){ return f.create(this) }

Это единственное, что я придумал, чтобы работало и выглядело адекватно. Но меня смущает: 1. Насколько это читабельно? Такая вот диспетчеризация(делегирование). Имхо выглядит странновато. 2. Мб лучше отнаследовать фабрику от Visitor и назвать метод и его параметры у Shape так: accept(Visitor v){ return v.visit(this) }Тогда метод не будет привязан к Drawer. Я бы хотел, чтобы Shape ничего не знал о существовании Drawer, при этом Drawer знал о Shape все и имел ссылку на него.

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

Трабла очень похожа на твою, можешь вкратце поделиться как решил?

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

У меня в итоге без визитёра как и говорил получилось

Сейчас попробую без всяких деталей рассказать

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

Тот свич превратился в такое

Точнее свитч вообще ушёл

Точнее свитч вообще ушёл

А typecheck ушел?

Да, в каком-то смысле. Он ещё остался так, как не весь код ещё зарефакторин

Я сначала зашёл со стороны создания этого типа

Когда выстрел прилетает в какой-то объект, он взаимодействует со SceneView этого объекта

У него есть абстрактный метод public abstract Hit ExtrudeHit(RaycastHit hit);

Есть несколько типов который возвращают различный производный класс TargetHit и EnviromentHit

Тот кто стрелял оборачивает это в тип SceneViewHit который содержит в себе SceneView и Hit

В итоге этого более-менее хватило

Визуализация попадания спрятана под SceneView

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

Это всё по сути обслуживает что-то похожее на сервис локатор

Все эти связи декларативно размечаются

А потом в коде разрешаются уже через var view = hit.collider.GetComponentInParent<SceneView>();

Трабла очень похожа на твою, можешь вкратце поделиться как решил?

Ходил к психотерапевту около года

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

У него есть абстрактный метод public abstract Hit ExtrudeHit(RaycastHit hit);

А что такое RaycastHit?

А все нашел, это понятие.

А что такое RaycastHit?

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

Не особо важная вещь здесь

В общем там суть в том, что есть тип - аргумент поведения системы

Поведение собираются из множества подсистем

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

Поведение собираются из множества подсистем

Да, наверное у меня сейчас другая ситуация.

Т.е это похоже на ситуацию с рисовальщиками, они работают с абсолютном разными данными

Ну те можно по идее обернуть Shape и Drawer в один объект при их создании, когда тип еще известен?

Извини, нужно сейчас отъехать. Я попозже выберу минутку, и хотел бы ещё над этим всем подумать, может чего полезного скажу

Извини, нужно сейчас отъехать. Я попозже выберу минутку, и хотел бы ещё над этим всем подумать, может чего полезного скажу

Спасибо

Вкратце у нас всё свелось к тому, что рисовальщики между собой имеют мало общего как и фигуры

Что-то типа такого: class Drawer<T>{ public Draw(T){ var context = CreateDrawContext(); Draw(T, context); } protected absrtract Draw(T, Context); }

И есть метод который решает какой рисовальщик что рисует public DynamicDraw(T t) where T : Shape { FindObjectOfType<Drawer<T>>().Draw(t); }

Все эти дженерики нужны чтобы разделять кто кого рисовать умеет

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

Да