36 respuestas en este tema

[Delphius]

La métrica MPC, nuestra aliada

Ha... perfecto. Bonitos números pero ¿De qué me sirven?
No se preocupe ni se me apresure.

En la última columna se ha calculado la Proporción entre LDC y la complejidad. En forma simple, este valor indica la cantidad de líneas de código por una unidad de complejidad. Nos permite en primer lugar comparar dos métodos y determinar cual es más complejo.
En segundo lugar nos arroja el valor parcial para el MPC.

El valor de MPC consiste en la sumatoria de todos los métodos. Añadir métodos hace más grande a la clase ¿pero que tanto? Una forma es tomar la relación entre LDC y la complejidad.

Olvidémonos por el momento de ParseSQL. Vemos en tabla que hay dos métodos que se destacan por sus valores: StripLiterals y StripChar. Por código sabemos que el segundo es un submétodo del primero.
¿Que le parece si compactamos el código y eliminamos a StripChar?. Su código se traslada ahora a StripLiterals. De este modo pasamos de un LDC de 8 a 12 y de una V(G) de 1 a 3. La tabla 2 muestra los resultados y unas primeras estadísticas para sacar nuestras primeras conclusiones:


      +-------+-------+-------------+
      | Antes | Ahora | Porcentajes |
+------+-------+-------+-------------+
| LDC  | 8    | 12    | 50%        |
+------+-------+-------+-------------+
| V(G) | 1    | 3    | 200%        |
+------+-------+-------+-------------+
| Prop | 8    | 4    | 50%        |
+------+-------+-------+-------------+

¿Que podemos decir al respecto? Que al compactar se consigue una disminución del 50% en la proporción, si bien se experimenta un incremento en la LDC y V(G).

Vamos a calcular el MPC parcial (porque no contamos con todos los métodos):

MPCantes = 1 + 1 + 1,3 + 8 + 2,1 = 13,4
MPCahora = 1 + 1 + 4 + 2,1 = 8,1

¡Conseguimos una reducción del 39,55%!

¡Que bueno! ¡Listo... me conformo!
No... amigo mío... aún no está todo dicho.

[Delphius]

El efecto acumulativo

Ahora yo le hago una preguntita, un tanto capciosa pero válida: ¿Es lo mismo que un método tenga 5 submétodos que otro que tiene 3 y un tercero que no cuenta con ninguno?
La primera impresión es decir "Pues... no"... "Si tiene 5 es mucho más largo y complicado que del que tiene 3".

Aquí se dijo muchas veces depende. Esa es la respuesta más neutral y válida. En realidad depende. No necesariamente el de 5 submétodos es más complicado que el de 3 o del que no posee submétodo; pero esta pregunta nos lleva a la reflexión de que quizá deberíamos tenerlo en cuenta.

Al calcular el MPC en el mensaje anterior lo he invitado a pensar que cada submétodo era independiente del otro. Fíjese en como se ha sumado sus proporciones. Llamemos a esa postura como el Criterio Independiente.

Ahora hagamos una pausa y pensemos ¿Y si asumimos los efectos de StripChar sobre StripLiterals y en conjunto a ParseSQL? ¿Que tanto se verá afectado el MPC?

El nuevo enfoque se lo conoce como Criterio Acumulativo o Multiplicativo.

Bajo esta premisa, la LDC real de StripLiterals está compuesta por la suma de sus submétodos y del código propio. Lo mismo sucede con la complejidad.

Haciendo cálculos llegamos a:

LDCreal = 8 + 4 = 12
V(G)real = 1 + 3 = 4
Propreal = 12/4 = 3

Ahora, si compactáramos StripChar, y a dicho código lo asumimos como parte de StripLiterals llegamos a los siguientes cálculos:

      +------+-------+-------------+
      | Real | Ahora | Porcentajes |
+------+------+-------+-------------+
| LDC  | 12  | 12    | 0%          |
+------+------+-------+-------------+
| V(G) | 4    | 3    | 25%        |
+------+------+-------+-------------+
| Prop | 3    | 4    | 33,33%      |
+------+------+-------+-------------+

Por favor, no confunda... en este escenario asumimos que estamos ante un efecto acumulativo. Por ello se ha sumado LDC y V(G). Cuando pasamos el código del submétodo, vemos que en realidad en lo que hace a LDC no hay novedades. Distinto es en V(G) que se aprecia una mejora del 25% y como contra un aumento de la proporción en un 33,33%.

Para calcular el MPC debemos multiplicar la cantidad de métodos (incluidos "padres" e "hijos") por la proporción de las suma de sus LDC y V(G). O para hacerlo más corto: sume la cantidad de líneas y las complejidades, sace la proporción y multiplique por la cantidad de métodos . Es decir:

MPCantes = 5((1 + 1 + 4 + 8 + 38)/(1 + 1 + 3 + 1 + 18)) = 5*(52/24) = 10,83
MPCahora = 4((1 + 1 + 12 + 38 )/(1 + 1 + 4 + 18)) = 4*(52/24) = 8,66

¡Tenemos una mejora del 20,03%!

El valor del MPC implica una disminución de casi de la mitad de su contraparte independista. Seguramente usted se estará preguntando "¿Porqué?" Ya analizaremos esto... por ahora podemos sacar nuestras primeras conclusiones...

[Delphius]

Conclusiones 1

Cuanto menor sea el valor de la proporción del "hijo" respecto al "padre" más ventajoso resulta, en términos promedios, eliminarlo y colocarlo como parte del padre.
Si se asume el criterio independiente, es decir que los métodos no tienen efectos inmediatos sobre su padre,se experimenta una disminución en la complejidad ponderada (proporción... del allí el término ponderado de MPC) con lo que el valor de MPC parcial decae.
Por otra parte si se optara por la multiplicativa una "compactación" del código hijo al padre en el mejor caso no introducirñia efectos en LDC pero si posiblemente en V(G). En lo general se experimentaría un aumento de la complejidad ponderada y por tanto un aumento en el MPC, en ciertas escenarios cuanto mucho un leve descenso.

¿Y si extraemos a StripChar fuera y lo dejamos como un método más? Eso lo veremos a continuación.

[Delphius]

Conclusiones 2

Params cuenta con 5 métodos privados, 5 protegidos y 11 públicos. Las estadísticas indican que:

                +----------+------------+----------+
                | Privados | Protegidos | Públicos |
+----------------+----------+------------+----------+
| Funciones      | 2        | 2          | 5        |
+----------------+----------+------------+----------+
| Procedimientos | 3        | 3          | 6        |
+----------------+----------+------------+----------+
| Porc. General  | 23,80%  | 23,80%    | 52,38%  |
| Porc. Visible  |          | 31,25%    | 68,75%  |
+----------------+----------+------------+----------+

Si sacáramos afuera a StripChar como un método (privado) más los valores serían:

                +----------+------------+----------+
                | Privados | Protegidos | Públicos |
+----------------+----------+------------+----------+
| Funciones      | 2        | 2          | 5        |
+----------------+----------+------------+----------+
| Procedimientos | 4        | 3          | 6        |
+----------------+----------+------------+----------+
| Porc. General  | 27,27%  | 22,72%    | 50,00%  |
| Porc. Visible  |          | 31,25%    | 68,75%  |
+----------------+----------+------------+----------+

En lo que hace a visibilidad pública o protegida (lo que se puede ver de la interfaz) no se ven efectos o cambios, como es de esperarse. Pero en términos generales se observa una disminución porcentual; lo cual se traduce en una menor dificultad de entender y mantener la clase.
Las estadísticas se hacen más estables, a contra de haber aumentado un método.

Muy bien... ya voy entendiendo . Con esto en mente me es suficiente ¿verdad? Porque me estoy aburriendo

Si, Usted ya cuenta con los medios necesarios para que pueda continuar por si mismo. Como queda ilustrado en los cálculos necesita evaluarlo desde diversos puntos de vistas. Pero déjeme continuar porque yo aún le guardo algunas sorpresas.
¿Más todavía?
Me temo que sí

[enecumene]

wow, tremenda exposición, mientras leía juraba que ya no estaba en Delphi , excelente amigo, excelente

[Delphius]

Sigamos compactando...

Hasta ahora hemos empaquetado StripChar dentro de StripLiterals, nos apoyamos en la idea de que al compactarlo dentro de todo estamos en valores aceptables de mejoras en el MPC.

¿Que le parece si seguimos compactando código? Eliminemos ahora a NameDelimiter, IsLiteral y StripLiterals y pongamos sus repectivos códigos en el lugar donde se los invoca. Note que NameDelimiter es invocado una sola vez, al igual que StripLiterals. En cambio IsLiteral se invoca dos veces.

Si obtenemos el valor para LDC y V(G) de este nuevo ParseSQL llegamos a los siguientes resultados:

      +-------+-------+-------------+
      | Antes | Ahora | Porcentajes |
+------+-------+-------+-------------+
| LDC  | 38    | 50    | 31,57%      |
+------+-------+-------+-------------+
| V(G) | 18    | 20    | 11,11%      |
+------+-------+-------+-------------+
| Prop | 2,1  | 2,5  | 19,04%      |
+------+-------+-------+-------------+

Al compactar se consigue un aumento de la proporción. Inicialmente pareciera ser tentador asumir que añadir 2 V(G) no sería demasiado problema, pero lo cierto es que en términos porcentuales tenemos una perdida razonable.
En forma resumida el valor de proporción 2,5 nos está diciendo que cada dos líneas y medio de código tenemos una complejidad más. Esto en términos de código puede indicarnos que tenemos un IF, un while, repeat, case, trys, o cualquier instrucción que bifurque el código por cada 2 o 3 líneas. Necesitaremos realizar muchas pruebas blancas para probar las distintos caminos.

¿Pero que nos dice el MPC?
Si tenemos en cuenta la postura independista llegamos a los siguientes valores:
MPCAntes = 8,1
MPCahora = 2,5

¡Una reducción del 69,13%!

¡Changos , amigo... eso es bueno!

He aquí una primera lección de todo esto.
Resulta muy llamativo que si bien en términos porcentuales tengamos una pérdida el valor de MPC parcial al compactar tengamos una mejora enorme.
Esto demuestra el Yin y Yang que está impreso en nuestros códigos, en nuestras decisiones.

¿Queda entonces en un depende? ¿Para qué tanto lío?
Momento, aún no he jugado mi última carta. Si, estamos en un claro escenario de "depende" pero quiero invitarlo a seguir pensando. ¿Que nos dice el citerio multiplicativo?...

[Delphius]

Algunas consideraciones

Quedamos en el último mensaje con una pregunta... ¿Y el efecto acumulativo? ¿Qué efectos tendríamos? Piense la respuesta un momento

La respuesta es Ninguno, nada nuevo.  ¡El resultado sería el mismo! Recuerde que en el efecto multiplicativo sumamos todas las líneas de código y las complejidades. Como NameDelimiter e IsLiteral sólo tienen una línea de código no provocan un aumento del LDC ni de V(G). Lo que más influencia a ParseSQL es StripLiterals.

¿Cuáles son los efectos si sacáramos estos métodos afuera?

                +----------+------------+----------+
                | Privados | Protegidos | Públicos |
+----------------+----------+------------+----------+
| Funciones      | 5        | 2          | 5        |
+----------------+----------+------------+----------+
| Procedimientos | 4        | 3          | 6        |
+----------------+----------+------------+----------+
| Porc. General  | 36,00%  | 20,00%    | 44,00%  |
| Porc. Visible  |          | 31,25%    | 68,75%  |
+----------------+----------+------------+----------+

Como es de esperar en lo visible no cambia nada. Pero véase el efecto general. La clase se estabilizó aún más. Los porcentajes son más cercanos unos a otros. Añadimos más métodos, es la otra cara del moneda. Esto repercute en otras métricas como TC(Tamaño de clase), NOI, NOA, IE, entre otras (Véase el capítulos de Métricas Orientadas a Objetos, del libro de Robert Pressman).

Cuanto más métodos y atributos tengamos más grande será la clase. Si uno quiere apreciar los efectos globales (que deberíamos tener en cuenta) de añadir métodos afuera y/o en como afecta el compactar algunos métodos puede calcular el MPC total de la clase:

MPC = c₁ + c₂ + ... + c_n

Siendo c_i la complejidad ponderada o proporción del método i-ésimo.

Para simplificar el escenario aquí solo se tuvo en cuenta el aspecto interno de ParseSQL y su valor de MPC, pero puede determinarse a simple vista que cuanto más alto sea el MPC parcial mayor será el MPC total. Lo deseable es tener un valor lo más bajo posible.

Queda ahora una pregunta, que quizá se la esté haciendo: ¿Existe un término medio?
Ha llegado el momento de jugar mi última carta

[Delphius]

Ni yin, ni yang. Alternativas

La respuesta a la última pregunta es ¡SI!.
Podemos elegir muchas combinaciones, empaquetar algunos, y/o sacar afuera a otros... Pruebe

Yo por mi parte expongo mi alternativa:

Habíamos quedado en claro que lo que más afecta a ParseSQL es StripLiterals y hemos visto el efecto que éste provoca al empaquetarlo (recuérdese los valores de proporción... note cuanto mayor es del submétodo respecto al padre). Mi propuesta es dejarlo como submétodo, y sólo compactar a NameDelimiter e IsLiteral. Aquí los resultados:

                +-----+------+-------+
                | LDC | V(G) | Prop. |
+---------------+-----+------+-------+
| ParseSQL      | 38  | 18  | 2,1  |
+---------------+-----+------+-------+
| StripLiterals | 12  | 4    | 3    |
+---------------+-----+------+-------+

            +--------+-------+------------+
            | Indep. | Acum. | Diferencia |
+-----------+--------+-------+------------+
| MPC      | 5,1    | 4,54  | 0,56      |
+-----------+--------+-------+------------+
| MPC medio | 2,55  | 2,27  | 0,28      |
+-----------+--------+-------+------------+

Comparando el 5,1 respecto al 13,4 inicial es una amplia mejora. De igual modo si consideramos el efecto multiplicativo, de 10,83 a 4,54.
Nótese la poca diferencia entre 5,1 y 4,54. ¿No debería ser mayor el MPC acumulado? La respuesta es no. Al eliminar los submétodos hemos reducido el multiplicador, por tanto el valor ha disminuido.

¿Entonces, es conveniente asumir el criterio multiplicativo por sobre el el independiente?
No. No es conveniente. En términos generales el multiplicativo tiende a tener un efecto inflacionario sobre MPC (aunque éste sea decreciente ante una compactación). Debido a una particularidad de este ejemplo es que tenemos un valor menor.
Recuerde que teníamos submétodos con apenas un LDC de 1. Lo esperado es que los subprocesos reciban más LDC y una buena parte de la complejidad V(G) de la que asumiría el método padre. Cuanto más submétodos, más alto sera MPC.
Note como la complejidad ponderada de StripChar (1,3) induce a reducir la complejidad de su padre ( 8): (8 + 1,3)/2 = 4,65

Al quitar LDC del padre y añadirlo a submétodos reducimos en un lado, pero aumentamos en otro. Lo mismo sucede con la V(G). Este efecto de "balanceo" puede jugar a ambos lados de la balanza...

[Delphius]

La carta ganadora

Aún no mostré mi carta pero seguramente ya sabe cual puede ser, ya se la presentaré.

Repasando mi alternativa uno puede verse tentado a mejorarla. IsLiteral es invocado dos veces, es quizá una buena oportunidad el que éste sea un subproceso. Un pensamiento podría ser ¿después de todo... que puede causarnos una línea de código? Pues hagamos cálculos:

MPCindependiente = 2,1 + 3 + 1 = 6,1
MPCacumulativo = 3*(51/23) = 6,65
Diferencia = 6,65 - 6,1 = 0,55

¡He aquí un contrajemplo! Observe que la diferencia prácticamente se mantiene (anteriormente era de 0,56) y donde el MPC de la postura independiente ofrece un mejor resultado.

¿Entonces cómo y cuando escoger cada postura ?¡Help!
No desespere, aquí está la carta ninja que le da de pataditas a el yin-yang.

La decisión no es fácil. Si seguimos al más puro enfoque OO deberíamos tirar una moneda, pero si recordamos la vieja escuela tenemos un arsenal con que trabajar.
¿Recuerda los términos acoplamiento y cohesión vistos en la programación estructurada?

Los módulos (métodos para este caso) deben estar lo menos acoplados posibles pero lo suficientemente cohesivos.
Aquellos submétodos con parámetros deben ser los más estables posibles, por tanto el asumir el criterio acumulativo nos ayudará a reducir de forma rápida. De este modo los subprocesos de éste tenderán a compactarse al punto en que se pierda independencia (véase el contraejemplo). Es decir: compactar desde el último al primero mientras el valor de MPC acumulativo esté a favor respecto al independista. El acumulativo nos permite reducir el acoplamiento.

Por otros lado los métodos que no tienen parámetros tienden a ser los más independientes y cohesivos. Para éstos el criterio independiente ofrece mejores resultados ya que favorece la cohesión. Aplíquelo mientras ofrezca un mejor valor de MPC que el acumulativo.

Esta es mi carta, espero que le sirva.

En resumen, es depende, depende. Pero con un sentido más lógico, y analítico podemos llegar a mejores resultados, código estable y más manejable. Espero que este documento le permita ser de mucha ayuda.

Saludos,
PD: No debe de leer la advertencia final que dejo a continuación.

[Delphius]

Advertencia

Sobre LDC

La medida LDC y las métricas basadas en ésta deben tomarse con cautela.
En el paradigma OO emplear esta medida no ofrece el mejor panorama para reflejar lo que sucede en una clase. Las mejores medidas y métricas para el OO descansa en las clases.

Las LDC tienen sentido para una visión interna, como dentro de los métodos. Pero pierde objetividad cuando elevamos la abstracción.
Además, es muy fácil engañarse con su valor. Al depender fuertemente de la manera en como se codifica resulta ambigua para analizar código cuando se trabaja en equipo. ¡Dos personas no necesariamente tienen el mismo estilo!

Por ejemplo:

delphi

if (condicion) then HacerEsto;

se contabiliza como 1. Pero esto:

delphi

if (condicion)
   then HacerEsto;

Se cuenta como 2.

Si va a llevar métricas basadas en LDC asegúrese de tener un código homogéneo.

Es por ello que las LDC no gozan de demasiada aceptación, por su ambigüedad. Pero hay que reconocer que es una buena opción, por lo simple que resulta de obtenerla, para llevar una primera medición orientativa. Además, no existen demasiadas medidas (ni intentos para proponerlas, aceptemoslo) que ofrezcan una visión interna.

Sobre MPC

El valor de MPC se obtiene mediante la fórmula citada unos mensajes antes. Es necesario aclarar que el valor de c_i se vé influenciado por el criterio de ponderación elegido. En este caso se ha optado por considerar la complejidad ciclomática pero se pueden considerar otras medidas de complejidad. Lo importante es que normalice a fin de que la complejidad nominal para un método sea de 1,0.

[escafandra]

Excelente exposición teórica o como te gusta decir, filosófica.

Tienes mucha razón cuando dices cautela, estilos de programación y depende.
 

...La medida LDC y las métricas basadas en ésta deben tomarse con cautela....

...¡Dos personas no necesariamente tienen el mismo estilo!

Por ejemplo:

delphi

if (condicion) then HacerEsto;

se contabiliza como 1. Pero esto:

delphi

if (condicion)
   then HacerEsto;

Se cuenta como 2...

El código final no sólo depende del programador, sino del propio compilador y eso siempre debe estar en mente. El programador debe saber que es lo que pasará con su código y en que se va a convertir. Los compiladores optimizan y el resultado puede ser, o no, el esperado.

Por ejemplo:

delphi

var
 i: integer;
 n: integer;
begin
  //Dos formas o "estilos"
  if i=0 then n:=1;
  
  //que en el fondo son lo mismo.
  if i=0 then
    n:=1;
end;

Si lo compilamos eliminando las optimizaciones, nos encontramos con que es lo mismo poner en una sola línea o en dos el condicional. He aquí el resultado de la compilación:



Entonces el estilo de programación no lo es tanto en cómo lo escribimos, en este caso está claro, sino en cómo resolvemos, que algoritmo encontramos y cuanto código inútil añadimos.

Así, estoy contigo en que los sistemas de medición y análisis se deben tomar con cautela.

Se ve que has estudiado a fondo el tema.   

Saludos.

[Delphius]

Gracias a todos por brindarme sus alientos.

Como bien dices escafandra, el compilador es muy inteligente y sabe optimizar nuestro código. Para el será lo mismo, pero para la mente humana no es tan sencillo.

Como he dicho en la advertencia, hay que tener mucho cuidado con la medida y métrica LDC. Si uno va a trabajar con esto, debe poner mucha atención y escribir de forma homogénea. Si escribimos código de cierta forma, es mejor no cambiarla.
Al hacer los cálculos nos estaremos engañando, al compilador no lo vamos a engañar.

El tema del código inútil es algo con lo que a diario nos enfrentamos. Parte lo que expuse nos puede servir de guía para saber si hace falta algo, o si sobra. Pero en lo que hace en términos del algoritmia esta técnica no sirve demasiado (por ejemplo, no nos ayuda a determinar si estamos haciendo un bucle extra, o si hay asignaciones innecesarias, etc). No he desarrollado técnica alguna en ese sentido (y estoy dudando si es que hay un método).

Las métricas sólo tienen sentido para el ser humano, y a quienes les interesa (hay que reconocer que llevar medidas, métricas e indicadores es un proceso lento y costoso). No nos van a resolver el código pero nos ayudarán a mejorarlo.

Pues lo que he escrito es producto de lo que vengo filosofando todos estos años que llevo estudiando informática.

Lo interesante es que esta "teoría" que expuse es igualmente válida para métodos simples, sin submétodos. Esto nos puede ayudar incluso a saber cuando estamos incorporando métodos por demás.

Saludos,

[egostar]

El tema del código inútil es algo con lo que a diario nos enfrentamos. Parte lo que expuse nos puede servir de guía para saber si hace falta algo, o si sobra. Pero en lo que hace en términos del algoritmia esta técnica no sirve demasiado (por ejemplo, no nos ayuda a determinar si estamos haciendo un bucle extra, o si hay asignaciones innecesarias, etc). No he desarrollado técnica alguna en ese sentido (y estoy dudando si es que hay un método).

Las métricas sólo tienen sentido para el ser humano, y a quienes les interesa (hay que reconocer que llevar medidas, métricas e indicadores es un proceso lento y costoso). No nos van a resolver el código pero nos ayudarán a mejorarlo.

Muy interesante y excelente análisis amigo Marcelo, me está gustando para hacerlo con el estilo de los tutoriales, un documento bien desarrollado merece un buen diseño si me lo permites lo voy a cambiar al formato que hemos creado.

Por otro lado, ¿ sabías que Delphi (en la versión enterprise y mayor) cuenta con las métricas y auditorias muy detalladas ?

Salud OS

[Delphius]

Muy interesante y excelente análisis amigo Marcelo, me está gustando para hacerlo con el estilo de los tutoriales, un documento bien desarrollado merece un buen diseño si me lo permites lo voy a cambiar al formato que hemos creado.

Por otro lado, ¿ sabías que Delphi (en la versión enterprise y mayor) cuenta con las métricas y auditorias muy detalladas ?

Salud OS

No tengo problemas amigo. Creo que este hilo evolucionó como un tutorial y quizá sea mejor darle el debido formato (y moverlo al foro correspondiente... no le pensé desde un principio ).

Si, ya lo sabía. Algo de eso se había comentado en unos de los videos y conferencias.
Creo que estas cosas fueron añadidas desde la versión 2005/06 no recuerdo bien.
Cuando vi el video y hablada de todo eso se me quedé boquiabierto. Y lo hacía tan sencillo, en dos o tres clics.
También te genera el código de acuerdo a patrones de diseño y hasta algunos diagramas UML.

¡Es todo terreno!

Saludos,

[egostar]

Me parece muy bien, en el transcurso de la semana te haré llegar el documento para que tú lo subas

Salud OS

[escafandra]

...Como bien dices escafandra, el compilador es muy inteligente y sabe optimizar nuestro código. Para el será lo mismo, pero para la mente humana no es tan sencillo.

Como he dicho en la advertencia, hay que tener mucho cuidado con la medida y métrica LDC...

...Las métricas sólo tienen sentido para el ser humano...

Ciertamente, cuando expuse la idea de que el compilador de alguna manera interpreta y modifica el código, fue para apoyar la idea que comentaste sobre el cuidado al interpretar las métricas y que su valor es orientativo, bien es verdad que de alguna forma tenemos que analizar el código y que no es tarea fácil.

Me parece, como apunta egostar, que de aquí sale un buen tutorial o si lo prefieres, un buen manual.

Muchas gracias por tu dedicación al tema.

Saludos.

[Rolphy Reyes]

Saludos.

De un "pequeño" código salio tal manual o tutorial , excelente sobre la interpretación que le da el compilador y la manera en que debemos de "escribir" nuestro código.

Y como siempre esta la palabra depende, por lo regular no escribo submétodos trato de que pertenezca a la clase como tal aunque sea privado por si en algún momento de la vida debo de reutilizar el método simplemente le cambio el nivel de visibilidad.

Muy buena exposición Delphius, como siempre al nivel deseado.