концептуальные «стеки» и слои кода в программировании - PullRequest
Новая
       1

концептуальные «стеки» и слои кода в программировании

4 голосов
/ 16 августа 2010

В последнее время я много думал о том, как код организован многоуровнево.Я думал о четырех разных способах:

  1. Реализация - в частности, объекты являются экземплярами классов.Однако в некоторых языках (таких как python) классы также являются объектами, которые были созданы из метакласса.Таким образом, вы можете получить стек экземпляров объектов.
  2. Наследование - вы получите стек суперклассов.Даже если у вас есть множественное наследование, у вас, вероятно, есть способ превратить его в стек (например, MRO в python).
  3. Пространства имен - область видимости, как правило, тоже многоуровневая.стек вызовов, пожалуй, самый знакомый и самый старый концептуально.Это основа программирования.

Можно утверждать, что инстанцирование - это просто другой вид стека вызовов, а наследование - это просто еще один стек пространства имен, но независимо от того, о чем я думал.

Так есть ли у кого-нибудь какие-либо другие концептуальные стеки, которые здесь вписываются, или звонки и пространства имен суммируют все это?Есть еще мысли?

Ответы [ 3 ]

1 голос
/ 16 августа 2010

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

В последнее время я пришел к выводу, что горизонтальное наслоение - это удобная техника, но вертикальное разбиение более полезно .Примером горизонтального наслоения может служить классический сценарий DAL-> BAL-> GUI, в то время как вертикальное разбиение делит приложение на функции, которые оно поддерживает.

Модель стека явно присутствуетв модели горизонтального наслоения.Но также при вертикальном разделении вы можете найти модель стека.Что мне особенно нравится в вертикальном разбиении, так это идея о том, что каждый из моих вертикальных срезов может иметь свой собственный горизонтальный стек слоев, идея, которая напоминает шаблоны, которые становятся все более и более популярными, как CQRS.Также могут быть зависимости между вертикальными разделами вашего приложения, опять-таки смоделированные как стек.Но иногда этого недостаточно , и вам нужна более сложная абстракция , чем стек, такой как граф .

Абстрагирование от этогоЯ думаю, что причина, по которой нам нравится думать в стеках , заключается в том, что мы можем видеть вещи на различных уровнях абстракции , помещая / выталкивая вещи в стек по требованию.Другие структуры, такие как Графики , иногда более подходят для описания таких проблем, как зависимости между компонентами, но они более сложны и, следовательно, не так удобны, как стеки.

Это такжепричина, по которой было исключено множественное наследование: граф зависимостей (множественное наследование) понять гораздо сложнее, чем простой стек (одиночное наследование).

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

  • Иерархии наследования (одиночное наследование)
  • горизонтальные, архитектурные слои
  • вертикальныеархитектурные слои (композиция элементов)
  • простые линейные зависимости (последовательности вызовов, оболочки, фасады)
1 голос
/ 16 августа 2010

Я не уверен, к чему вы клоните, но другим типом "стека" могут быть зависимости.Например, если A использует классы B и C, а класс B использует D и E, а класс C использует F, то в итоге вы получите стек слоев, подобный этому: 

+---------+
|    A    |
+-----+----
| B   | C |
+-----+---+
| D E | F |
+-----+---+

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

0 голосов
/ 16 августа 2010

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

...