Работаю над чужим проектом на C# под Unity3d, занимаюсь приведением в порядок кода. До меня принципы ООП лишь отдаленно соблюдены в некоторых местах. В частности - сейчас есть гланый статический класс, который имеет доступ к различным объектам, все остальные классы сцены бесцеремонно, по-требованию лезут в главный класс, обращаются к его свойствам и методам, а так же через него к свойствам и методам объектов, к которым есть доступ у главного класса. В качестве альтернативы я предложил инверсию связей, когда мелкие классы, в случае необходимости оповещают главный класс о том, что им необходимы какие-то данные и главный класс либо выдает свои данные, либо запрашивает их у других объектов и передает тем, кому они понадобились. Собственно реализация через события - все мелкие при инициализации публикуются, главный подписывается и ждет события запроса данных, когда видит событие - передает данные. Вопрос в том, не угробится ли к чертям вся производительность при реализации этих подписок и публикаций, если сейчас количество классов, использующих главный класс чуть больше 50, соответственно и число подписок и публикаций будет такое же? Как лучше поступить?

Пока настоящие программисты причесывают код и рассуждают про ООП, 1Сники молча рубят бабло...

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

даешь ООП срач!

(2) не очень понял при чем тут ооп и производительность некоего проекта на юнити?

И как это "есть гланый статический класс, который имеет доступ к различным объектам"
а объект у нас разве не экземпляр класса?

(0) Да ты делай как хочешь. Главное чтобы работало быстро и правильно. А если будет работать медленно или неправильно, то следующий за тобой всё напишет заново. Почему напишет заново? Потому что ты так всё запутаешь со своим ООП, что лень будет всё распутывать.

2(0) Все мобильные приложенияработают через подписку-нотификацию. И в любой момент времени таких объектов может быть масса. В конце концов, зачем придумали этот паттерн? Чтобы у прога срабатывала рефлексия по поводу - а зачем я буду делать правильно? Может пусть я сделаю гамняно, но зато прога будет работать работать быстрее в два раза? И каждая атомарная операция вместо того, чтобы выполняться 0.01 с будет выполняться 0.005 с? Точно. так и сделаю, зато потом если понадобиться внести изменение в код, я потрачу не не полчаса, а 4, а если это будет делать другой прог, так и все 8, и в результате клиент заплатит больше денег. Здорово ведь!

(1) Это, кстати, моя фраза.

(6) Вот поэтому я и не женюсь(с) Собственно по этому и стоит сейчас вопрос... либо делать через нотификации, тогда придется инициализировать при старте все объекты и делать подписки, боюсь что угроблю быстродействие, либо есть какой то другой способ, который я не знаю, который позволит более качественно реализовать архитектуру.

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

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

+(8) вопрос о том, есть ли еще какие то паттерны, либо методы, либо идеи как лучше это сделать.

Помнится когда попер С++ с библиотекой Turbo Vision, все было красиво и умно, но только больше по размеру. Вот и надо было тогда начинать рубить бабло 1С помнится 5.0 для DOS была. Был бы сейчас полноценный франч где нибудь в Челябинске.

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

(11) это кстати мысль. Надо покурить эту тему... Я чет забыл про ленивую инициализацию.

(0) все остальные классы сцены бесцеремонно, по-требованию лезут в главный класс, обращаются к его свойствам и методам, а так же через него к свойствам и методам объектов, к которым есть доступ у главного класса.

Мне кажется все нормально. Ты пытаешься усложнить. А вообще все зависит от объемов

(13) это нарушает один из главных принципов ООП - слабые связи.

1С-ники любят неопределено и пустые ссылки
а ты тут про ООП

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

(15) я сам 1Сник, но хочу запустить второе направление по разработке игр, соответственно сейчас пашу в три лица на студию, делаю свой проект и еще и во франче основная работа. Вопрос по-прежнему открыт, жду грамотных ООПшников.

(16) Буду проверять... Просто игра в браузерах, а слабые компы могут и покривиться.

(7) Приведите оригинал, чтобы я смог выверить и поставить твой (R) у себя в файлике девизов...
.
у меня это сграблено так:
"1Сники молчаливо согласились, что они "неполноценные программисты" и втихаря гребут бабло лопатой в то время, как "настоящие программисты" обсуждают отсутствие ООП в 1С." - но авторстов утеряно

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

(19) v8: OFF: Конфигурастов бьют! Требуется подкрепление в этом тяжком бою за правое дело!:)

(19) Там ещё и продолжение есть:
Я думаю, это молчаливый заговор. Программисты 1С не сильно спорят, что у них нет ООП. Во-первых, в холиваре никого не переубедишь, а во-вторых, чтобы "настоящие программисты" не покусились на их кусок пирога да бутербродик с маслицем и с икорочкой.

(0)почему бы не разместить вопрос на тематических форумах по юнити и геймдеву? там все таки люди шишек набили уже. кстати, читал помниться пару статей, что для юнити нужно не ООП парадигму применять, а КОП(компонентно-ориентированное программирование).

(23) почитаю про КОП, спасибо. А по поводу других сообществ - уважаю только Мисту.

(20) типа того, только вот тут так нельзя - тут этот главный должен всех остальных управлять.

(0) друг ты не тот форум выбрал для обсуждения ООП, сейчас тебе скажут, что ООП это усложнение и вообще оно не нужно

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

(0) У тебя же игра, она должна быть в один момент времени в одном состоянии. Какие еще подписки и события. Главный класс через sington. Это же не сервер с транзакциями к базе данных.

Какое ООП, осваивать надо ООБД
https://ru.wikipedia.org/wiki/Объектно-ориентированная_база_данных

Без этого тру-программистом точно не станешь!

есть гланый статический класс, который имеет доступ к различным объектам

типа синглетон с блекджеком

(0) присылай проект посмотрим, может ты чё не понимаешь

У меня ощущение, что у нас серьезное количество вакансий есть по :
1. 1С
2. Web
3. Сисадминство

Всё остальное - "для души". А лучше просто забыть, и "для души" заниматься чем-нибудь иным. Прыгать с вертолёта или вышивать крестиком... ;)

(31) фотографировать тощих моделей в темноте

(32) Тоже понятный вариант развлекухи. А вот развлекуха с ООП в C# - это странное занятие... ;)

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

"например в главном классе происходит расчет физики,"

физика в юнити расчитыается вне главного класса.

(35) хм, ну может быть.

(36)там добосляешь компонент "боди" и он сам всё считает.

(31) Зато узкие редкие специалисты подчас могут стоит очень и очень дорого.

(32) как только "для души"# начинает приносить денег больше чем 1основная работаС даже с учетом перспективы, начинаешь задумываться. Ни в коем случае не хочу чтобы тред превращался в деньгосрач, поэтому просто оставим эту тему.
Просто с 5 лет я играл в игры и к сегодня наиграл уже достаточно, чтобы авторитетно высказывать свое мнение по каким-либо вопросам, а когда тебе еще и везет с возможностями углубляться в этом направлении, надо брать и использовать такие возможности. Это что касается души.

По поводу состояний игры и расчетов, управлений главным классом: игра танки, риалтайм, многопользовательская, главный класс управляет дофига чем, соответственно и все подряд службы, UI, механика, передвижения, клиент-серверная часть и обмен данными, полно всего лезет в главный класс сцены

(39) В общем я бы не стал переделывать все, если лезет, значит надо :) мало мальски бы привел просто с порядку, если там уж адский бардак, но ломать то что работает только потому что не по принципам ООП, не стал бы.

(39)блицкриг 3 переписываешь?

(38) Чистая правда. Одна проблема - не долго... ;) Чел сперва укакается, чтобы туда пролезть, потом чуть-чуть побудет в желаемом качестве, потом окажется, что нужны уже совсем другие "узкие специалисты" и совсем в другом месте...

Я специализировался на C++ MFC в начале "нулевых". Был в команде "писателей ГИСа". Моё имхо - по соотношению деньги/усилия по сравнению с 1С - полный отстой...

Есть такая жутко глупая вещь - погоня за "успехом"... ;)

(42)как-то встречали специалиста по прокладке кабелей.
кабелей карл!!!

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

(43) Кста, это лучше, чем учить C#. Тут микрософт не изменит все принципы в будущем году... ;)

Кстати, к разговору о никому не нужной работе :)
Я вот пишу движок сам :) никак не могу бросить и взять Unity или на худой конец libgdx :) Причем периодически поглядывая в исходники libgdx понимаю что он написан значительно лучше, чем то что рожаю я, но бросать жалко :)))

Даёшь ООП в 1С!

ООП не нужен!

(47) Ой да вы с процедурным программированием то справится нормально не можете, какое вам ООП :)))

(49) больше функциональщины в массы!
а так, да, но я стараюсь - за год не написал ни одного GOTO

прямо god object какой-то из антипаттернов

(47) А можно пример того, что можно было бы лучше сделать, будь в 1С ООП ? (кстати, я бы ещё и поспорил о заслуге 1С, что ООП применять при конфигурастии в общем-то и не требуется вовсе от слова совсем)

Пример или примеры. Что особо требуется заООПить?, в будничном кодинге, разрабинге?

(50) а надо писать гото?

(50) Фу быть таким...

Хм... А Ф12 на гоуту работает?

(52) Например замыкание это конечно не ООП, но его очень не хватает, так же как и IntelliSense. Учитывая транчсляцию 1С в JS я бы предпочел язык типа TypeScript

>так же как и IntelliSense.

за это спасибо неявной типизации - тут ооп вообще сбоку

(57) Я сейчас не трогаю ООП. Я говрю чего не хватает.
Сейчас языки совмещают в себе и ООП и функциональщину и статическую и динамическую типизацию.
TypeScript в этом плане очень симпатичный язык. И при этом для него перевели кучу JS библиотек.

(56) "Например замыкание" - вот уж чего, а мест где 1С "замыкает" - предостаточно!, казалось бы, при чём тут ООП ))

(59)  Что и кого 1С замыкает?
Немодальные диалоги без замыканий это еще то извращение.
Или создание универсальных функций различными условиями
v8: Отбор с условием

(60) Я отвечу уклончиво...: если замыкание короткое - просто удлините его!