Calcular objetos dinámicos a partir de un vector

Introducción

Digamos que tenemos un conjunto de objetos con algunos datos y necesitamos manipular estos objetos.





Digamos que el ejemplo más común es llenar una canasta con fruta. Implementaremos una cierta clase art, a la que agregaremos frutas. A continuación, necesitamos la clase base Fruit, para poder definir el parámetro de volumen, al que asignaremos un valor en función de la fruta. El problema se soluciona, se agregan las frutas hasta que el volumen de la canasta alcanza el umbral.





Después de varias iteraciones, cuando nuestro programa, para llenar cestas, haya agregado algunas peras podridas, manzanas con gusanos o algo más salga mal, ampliaremos la clase Fruit base, agregando parámetros de frescura, pureza, etc. Aparecen las condiciones de verificación.





Y aquí es donde comienza el problema. Sí, nuestra clase se ha vuelto más versátil, pero no solo puede aumentar la cantidad de problemas con las frutas, sino que las situaciones de recolección de frutas en sí pueden ser diferentes. Por ejemplo, recolectamos frutas donde absolutamente todas las frutas son frescas. ¿Por qué, en este caso, necesitamos un campo responsable de la frescura, si se sabe que todas las frutas son frescas? ¿Limitar la funcionalidad adicional para indicar tipos obligatorios y opcionales? - Por supuesto no. Ponemos varios tipos opcionales en una matriz (diccionario), donde cada tipo no es directamente parte de la clase. Nuestra funcionalidad es más inteligente de nuevo, genial.





Sin embargo, decidí ir más allá y desarrollar un poco este tema.





Idea

Definimos un tipo que se encargará de almacenar variables opcionales en formato de cadena. De hecho, es un contenedor sobre una matriz. Como conjunto mínimo de información, almacenaremos el nombre de la variable, el tipo (puede ser básico, int, string, bool o una composición de varios básicos) y valor.





Los métodos de este objeto pueden ser variables, pero he resaltado lo siguiente para mí:





  • obtener una lista de variables y sus tipos en formato de cadena (en general, puede limitarse a los nombres). Esto puede ser útil si queremos marcar algún objeto con el "origen".





  • getter que devuelve nuestra matriz con información sobre variables en formato constante.





  • obteniendo la identificación del tipo y el valor por el nombre de la variable (necesario para convertir a un tipo específico).





class IVariable
{
	public:

		using Type = std::variant < int, double, bool, std::string>; //     
				 

		virtual std::vector < std::pair < std::string_view, std::string_view > > abstract() = 0;
				  
		virtual std::vector < std::tuple < std::string_view, VarTypes, std::string_view > > released() = 0;

		virtual std::pair < VarTypes, std::string_view > released(const std::string_view& name) = 0;

				    
};
      
      



, , :





  • , "" , .





, ""





bool tryVector(const std::string_view& dX)
{
	auto type = range.front()->released(dX); 

	if(type.first == VarTypes::_null) 
	{
    	return false;
	}

	for(auto&& var : _range)
	{
		if(var->released(dX).first != type.first) 
 		{
			return false;
		}
	}

	return true;  
}
      
      



  • , ( tryVector).





, , , .





  • , , .





  • La capacidad de ajustar el alcance de trabajar con objetos, cuando, dependiendo de la situación, necesitamos más parámetros, o viceversa, menos.





  • No piense en cómo diseñar un objeto, sino en qué acciones se deben realizar con el objeto.





desventajas

  • No apto para calcular una gran cantidad de objetos del mismo tipo. Por ejemplo, para alguna clase que define el componente rgb de un píxel, será más eficiente definir explícitamente las propiedades.





  • Tal enfoque consumirá mucha memoria y, en consecuencia, tiene sentido usarlo solo para trabajar con objetos, cuya esencia no se puede expresar en términos de varias variables simples, es decir, más para el procesamiento lógico de objetos que para los cálculos directos.








All Articles