2011-06-08 15 views
5

A menudo se lee cómo vale la pena diseñar su código para evitar la necesidad de hacer moldes, y cómo el hecho de que tenga que recurrir al yeso podría sugerir que hay una mejor implementación disponible. Estoy tratando de lograr este santo grial del "código sin cast" en la implementación de un motor de mundo virtual, donde muchos objetos tienen una amplia variedad de interfaces, que actúan como mediadores y datos (y a veces como ambos) de muchas formas diferentes . Como menciona una respuesta en una pregunta similar (Linkage), el objetivo es tener siempre una referencia/puntero del tipo correcto en la ubicación requerida en lugar de tratar de sacar uno de una amplia gama de objetos candidatos.Estrategias arquitectónicas para evitar moldes dinámicos

Mi última puñalada en la gestión de este gran problema implica el registro de objetos con sus mediadores, lo que tiene algunas ventajas en términos de granularidad de control (puede configurar varias correlaciones entre mediadores y sus destinos).

También hay algunos problemas ... Lo más importante que estoy viendo en este momento es la anulación del registro de los objetivos de los mediadores. Con el fin de realizar un seguimiento de quién está usando qué sin tener que sondear a todos los posibles mediadores, el programa necesita almacenar aún más datos sobre qué enlaces se han creado. Por un lado, sería posible que los mediadores se desconectaran simplemente comprobando si sus objetivos están caducados (estoy usando punteros inteligentes y punteros débiles para todo, así que esto no es difícil), sin embargo, esto simplemente maneja la expiración de los objetos y lo hace no establecer un marco para la reconfiguración significativa de la conducta.

Cuando se mira desde muy lejos, es simplemente otro caso de software que se reduce al intercambio entre tiempo y memoria. Almacene más datos para hacer menos cálculos.

Quiero preguntar cuáles son sus pensamientos sobre la estructuración de programas para evitar conversiones dinámicas, y si puede compartir cualquier estrategia/patrón que sea efectivo en estas situaciones.

+0

No estoy seguro de qué tiene que ver la descripción de su escenario con la pregunta? –

Respuesta

3

Esta es una propuesta fundamentalmente defectuosa. dynamic_cast existe por una razón. Tratar de apuntar al código sin bastidor es solo ingenuo, los juegos tienen un propósito. Claro, podría ser lo mejor para reducirlos donde sea posible, pero eso es muy diferente de tratar de prohibirlos. El código sin dynamic_cast no es una especie de santo grial, o bien no lo necesita, en cuyo caso es solo código, o lo necesita, en cuyo caso es un código que no es óptimo.

Sin embargo, para permanecer un poco más sobre el tema, personalmente encuentro que solo por no propagar la herencia como si fuera la Plaga y estoy tratando de causar el Apocalipsis, entonces la necesidad de fundición es limitada: las plantillas son una milagro aquí.

+0

Buenos puntos. Es cierto que hay pocas (si las hay) reglas absolutas en desarrollo. Parece que cuanto más extienda la herencia, más versatilidad tendrá, pero por supuesto con más complejidad. – EdF

Cuestiones relacionadas