Le recomiendo que lea Clean Code capítulo 6: objetos y estructuras de datos. Todo el capítulo trata sobre esto ... Puede leer un resumen si no desea comprar el libro, se puede encontrar here.
De acuerdo con eso, puede usar clases de manera eficiente de dos maneras diferentes. Este fenómeno se llama antisimetría de datos/objetos. Dependiendo de tus objetivos, debes decidir si tus clases seguirán el open/closed principle o no.
Si siguen el OCP, serán polimorfos y sus instancias se usarán como objetos. Por lo tanto, ocultarán los datos y la implementación de una interfaz común, y será fácil agregar un nuevo tipo que implemente esa interfaz también. La mayoría de los patrones de diseño cumplen con el OCP, por ejemplo, MVC, IoC, cada contenedor, adaptador, etc.
Si no siguen el OCP, no serán polimorfos, sus instancias se usarán como estructuras de datos . Entonces expondrán los datos y esa información será manipulada por otras clases. Este es un enfoque típico de la programación de procedimientos también. Hay varios ejemplos que no utilizan OCP, por ejemplo, dtos excepciones, los objetos de configuración, etc ... visitor pattern
Patrón típico cuando se debe pensar en el cumplimiento de OCP y mover el código a un nivel de abstracción más baja:
class Manipulator {
doSomething(Object dataStructure){
if (dataStructure instanceof MyType1){
// doSomething implementation 1
}
else if (dataStructure instanceof MyType2)
{
// doSomething implementation 2
}
// ...
},
domSomethingElse(Object dataStructure){
if (dataStructure instanceof MyType1){
// domSomethingElse implementation 1
}
else if (dataStructure instanceof MyType2)
{
// domSomethingElse implementation 2
}
// ...
}
}
class MyType1 {}
class MyType2 {}
//if you want to add a new type, every method of the Manipulator will change
solución: la aplicación se mueve a un nivel de abstracción más bajo y cumplir con OCP
interface MyType {
doSomething();
domSomethingElse();
}
class MyType1 implements MyType {
doSomething(){
// doSomething implementation 1
},
domSomethingElse(){
// domSomethingElse implementation 1
}
}
class MyType2 implements MyType {
doSomething(){
// doSomething implementation 2
},
domSomethingElse(){
// domSomethingElse implementation 2
}
}
// the recently added new type
class MyType3 implements MyType {
doSomething(){
// doSomething implementation 3
},
domSomethingElse(){
// domSomethingElse implementation 3
}
}
patrón típico cuando se debe pensar que viola OCP y mover el código a un mayor nivel de abstracción:
interface MyType {
doSomething();
domSomethingElse();
//if you want to add a new method here, every class which implements this interface, will be modified
}
class MyType1 implements MyType {
doSomething(){
// doSomething implementation 1
},
domSomethingElse(){
// domSomethingElse implementation 1
}
}
class MyType2 implements MyType {
doSomething(){
// doSomething implementation 2
},
domSomethingElse(){
// domSomethingElse implementation 2
}
}
o
interface MyType {
doSomething();
domSomethingElse();
}
class MyType1 implements MyType {
doSomething(){
// doSomething implementation 1
},
domSomethingElse(){
// domSomethingElse implementation 1
}
}
class MyType2 implements MyType {
doSomething(){
// doSomething implementation 2
},
domSomethingElse(){
// domSomethingElse implementation 2
}
}
//adding a new type by which one or more of the methods are meaningless
class MyType3 implements MyType {
doSomething(){
throw new Exception("Not implemented, because it does not make any sense.");
},
domSomethingElse(){
// domSomethingElse implementation 3
}
}
solución: mover la aplicación a un nivel de abstracción más alto y violar OCP
class Manipulator {
doSomething(Object dataStructure){
if (dataStructure instanceof MyType1){
// doSomething implementation 1
}
else if (dataStructure instanceof MyType2)
{
// doSomething implementation 2
}
// ...
},
domSomethingElse(Object dataStructure){
if (dataStructure instanceof MyType1){
// domSomethingElse implementation 1
}
else if (dataStructure instanceof MyType2)
{
// domSomethingElse implementation 2
}
// ...
},
// the recently added new method
doAnotherThing(Object dataStructure){
if (dataStructure instanceof MyType1){
// doAnotherThing implementation 1
}
else if (dataStructure instanceof MyType2)
{
// doAnotherThing implementation 2
}
// ...
}
}
class MyType1 {}
class MyType2 {}
o dividir las clases en subclases.
La gente generalmente sigue OCP sobre el método count uno o dos porque repetir las mismas declaraciones if-else no es lo suficientemente DRY.
No le recomiendo que use clases mixtas que cumplen parcialmente, violan parcialmente el OCP, porque entonces el código será muy difícil de mantener. Debe decidir por cada situación qué enfoque sigue. Esta suele ser una decisión fácil, pero si comete un error, aún puede refactorizar su código más tarde ...
¿Puede cualquier clase con campos no estáticos implementar una estructura de datos? ¿Una clase que contiene solo el campo foo se verá como una estructura de datos extremadamente simple? – Kelmikra