пара мыслей на тему систем, хотя..
пара мыслей на тему систем, хотя..
Я не помню почему я заинтересовался этим, вряд ли припомню когда и при каких обстоятельствах, но, в общем, заинтересовался я как-то системами в контексте программирования.. Я думал примерно так.
Система - совокупность связанных между собой подсистем, имеющая некие входы и выходы. Свойства систем, в основном, обусловливаются связями между подсистемами. Это довольно схоже с объектами, и связь с ооп мне кажется очевидна.
Так вот, мне было интересно, как легче всего модифицировать, изменять, дополнять системы и что для этого требуется. По моему, одна из трудных задач при изменении кода системы, это понять как отразится изменения на системе в целом, отсюда же может возникнуть баги из-за зависимостей между модулями/классами систем, а другая, это когда во время переписывания (как вариант, копипасты) куска кода забыл переправить код/написал не ту переменную/забыл подправить. Несмотря на тесты, обнаружить эти и другие проблемы порой сложно, а некоторые так вообще невозможно исправить, полностью не переписав код. Если первоначальная версия не содержала ошибок, то это не значит, что последующие также не будут их иметь, поэтому написать это только полдела. Сопровождать будет труднее (примерно как по закону Парето для написания/отладки). Изменения лучше сделать локальными, исправляющими только неверную функциональность на правильную и не касающиеся других подсистем. Подсистемы должны (теоретически, не практически) абстрагироваться от предоставляемой функциональности других подсистем, а соединяются они между собой напрямую через устанавливаемые связи. Соответственно, при более крупных изменениях, то есть изменениях в архитектуре, изменяться должны связи между подсистемами (пакеты, классы, имя им легион). Лучше будет, если все связи подсистем можно визуализировать. Вотъ. Бред.
Система — оно же приложение, программа — состоит из отдельных подсистем, интерфейсов, слоев и каналов, связанных между собой.
Подсистема (==система) состоит из классов, типы, функций, переменных, константы, другие подсистемы и фактически представляет собой модуль. Подсистема может иметь входные значения, такие как переменные, функции, классы, типы, константы, кроме других подсистем (хотя..) и выходная функциональность — открытая часть подсистемы. Мне нравится идея событий, хотя там все равно идут дополнительные проверки, что может сказаться на производительности( но в целом незначительно), тк это дает большую гибкость и при отладке может помочь, да и события вполне вписываются в ооп, как неявный вызов методов, поэтому события тоже присущи подсистемам, такие как к примеру: перед/после вызова функции, присвоение определенного значения переменной и т. д. События, конечно же, могут создаваться для различных целей с различными условиями вызова события, для различных ситуаций.. Естественно, все переменные, типы и т.д. видны только в пределах данной подсистемы. При использовании в программе нескольких «объектов» подсистемы, в которой идет обращение к переменной подсистемы разные, но подобные подсистемы будут обращаться к разным экземплярам переменной. Входы подсистем делятся на обязательные и на опциональные. Для работы подсистемы обязательные входные значения должны быть установлены. Опциональными входными значениями считаются лишь, которые имеют дефолтное значение или без которых подсистема будет работать, но не будет предоставлять полную выходную функциональность. Подсистемы в отличии от классов, компонент не могут наследоваться, однако могут реализовывать интерфейсы.
Интерфейсы — ну тут и так в принципе понятно: типы, классы, константы, функции и т.д. Интерфейс может содержать и дефолтные значения.
Все подсистемы связываются между собой связями. Связь может просто приинклудить подсистему как модуль, если подсистема не требует входа или ещё дополнительно к каждому входу подсистемы привязывать переменную, функцию или выражение. Подсистемы связываются статически в одно целое. Переменные, переданные в качестве входа в подсистему может этой подсистемой изменять и/или только считывать. Выражения — не всё однозначно.. Вообще это похоже как связывание макросов или передачи по имени, но между модулями.
Мда.. это больше похоже на дамп потока сознания или какую-нибудь тупую идею нуба, хотя я себя оправдываю. В принципе, ничего нового тут нет почти всё уже придумано.. Если вы хоть что-нибудь поняли из этого или есть вопросы, предложения или ещё что-нибудь пишите, отвечу.
Система - совокупность связанных между собой подсистем, имеющая некие входы и выходы. Свойства систем, в основном, обусловливаются связями между подсистемами. Это довольно схоже с объектами, и связь с ооп мне кажется очевидна.
Так вот, мне было интересно, как легче всего модифицировать, изменять, дополнять системы и что для этого требуется. По моему, одна из трудных задач при изменении кода системы, это понять как отразится изменения на системе в целом, отсюда же может возникнуть баги из-за зависимостей между модулями/классами систем, а другая, это когда во время переписывания (как вариант, копипасты) куска кода забыл переправить код/написал не ту переменную/забыл подправить. Несмотря на тесты, обнаружить эти и другие проблемы порой сложно, а некоторые так вообще невозможно исправить, полностью не переписав код. Если первоначальная версия не содержала ошибок, то это не значит, что последующие также не будут их иметь, поэтому написать это только полдела. Сопровождать будет труднее (примерно как по закону Парето для написания/отладки). Изменения лучше сделать локальными, исправляющими только неверную функциональность на правильную и не касающиеся других подсистем. Подсистемы должны (теоретически, не практически) абстрагироваться от предоставляемой функциональности других подсистем, а соединяются они между собой напрямую через устанавливаемые связи. Соответственно, при более крупных изменениях, то есть изменениях в архитектуре, изменяться должны связи между подсистемами (пакеты, классы, имя им легион). Лучше будет, если все связи подсистем можно визуализировать. Вотъ. Бред.
Система — оно же приложение, программа — состоит из отдельных подсистем, интерфейсов, слоев и каналов, связанных между собой.
Подсистема (==система) состоит из классов, типы, функций, переменных, константы, другие подсистемы и фактически представляет собой модуль. Подсистема может иметь входные значения, такие как переменные, функции, классы, типы, константы, кроме других подсистем (хотя..) и выходная функциональность — открытая часть подсистемы. Мне нравится идея событий, хотя там все равно идут дополнительные проверки, что может сказаться на производительности( но в целом незначительно), тк это дает большую гибкость и при отладке может помочь, да и события вполне вписываются в ооп, как неявный вызов методов, поэтому события тоже присущи подсистемам, такие как к примеру: перед/после вызова функции, присвоение определенного значения переменной и т. д. События, конечно же, могут создаваться для различных целей с различными условиями вызова события, для различных ситуаций.. Естественно, все переменные, типы и т.д. видны только в пределах данной подсистемы. При использовании в программе нескольких «объектов» подсистемы, в которой идет обращение к переменной подсистемы разные, но подобные подсистемы будут обращаться к разным экземплярам переменной. Входы подсистем делятся на обязательные и на опциональные. Для работы подсистемы обязательные входные значения должны быть установлены. Опциональными входными значениями считаются лишь, которые имеют дефолтное значение или без которых подсистема будет работать, но не будет предоставлять полную выходную функциональность. Подсистемы в отличии от классов, компонент не могут наследоваться, однако могут реализовывать интерфейсы.
Интерфейсы — ну тут и так в принципе понятно: типы, классы, константы, функции и т.д. Интерфейс может содержать и дефолтные значения.
Все подсистемы связываются между собой связями. Связь может просто приинклудить подсистему как модуль, если подсистема не требует входа или ещё дополнительно к каждому входу подсистемы привязывать переменную, функцию или выражение. Подсистемы связываются статически в одно целое. Переменные, переданные в качестве входа в подсистему может этой подсистемой изменять и/или только считывать. Выражения — не всё однозначно.. Вообще это похоже как связывание макросов или передачи по имени, но между модулями.
Мда.. это больше похоже на дамп потока сознания или какую-нибудь тупую идею нуба, хотя я себя оправдываю. В принципе, ничего нового тут нет почти всё уже придумано.. Если вы хоть что-нибудь поняли из этого или есть вопросы, предложения или ещё что-нибудь пишите, отвечу.
Права доступа к этому форуму:
Вы не можете отвечать на сообщения