#90 un accedente NUNCA setea nada.
#92 mejor 
.
De todas formas un buen diseño de OO se basa en la transparencia que da los accessor/mutators y tu te empeñas en lo contrario.
Si quieres te puedo poner un ejemplo de que una variable miembro o como lo quieras llamar no tiene por qué tener un accessor siempre (y sigue nuestra teoria, y a la vez la tuya), y esto desmonta las razones en las que basas que tener accessors es de mal diseño. Un ejemplo extensible a cualquier TAD, un arbol de búsqueda por ejemplo, tiene como variable privada un puntero al nodo raíz y en ningún momento tiene un accesor a ese puntero.
What was that!! una variable privada sin accesor y aún asi cumple nuestra teoria de que los accesor son buenos 
Hacer getters cuando los necesitas no es de mal diseño, lo que es de mal diseño es no hacerlos y darle mil vueltas para tenerlo de otra manera.
#69: No estoy de acuerdo.
Y ese "ataque" me parece de lo más estúpido. La notación húngara es estúpida porque las variables hablan por si solas. Y ni te cuento en los lenguajes con un buen tipado, es que es absurdo.
Si sigues profundizando en mi github sí encontrarás errores reales, y no tus pajas mentales xD
#72: Y no se trata de que sea feo o no, se trata de que si no utilizas getters / setters y cambias algo tendrás que revisar todo tu código. Que son un coñazo de usar está más que claro.
Tienes que ser un programador OOP pésimo para pensar que es un error usar getters, en serio. Y no digo que yo sea bueno eh, pero tela, tela.
EDIT: En serio, acabo de leer todos tus posts. No sabes de qué estás hablando. Eso del rectángulo que has puesto es que es de risa.
Es que lo de usar un setter doble (que sí, que es un setter) es de juzgado de guardia. Y lo de devolver un array de valores es tan estúpido que no me merece la pena ni explicarte por qué.
Insisto, si quieres buscar errores, búscalos bien, porque eso está bien hecho (al menos para mucha gente). Y si sigues buscando ahí y sabes de Android, créeme que vas a encontrar muchos errores de verdad.
EDIT2: Y aún te digo más, un error que hay ahí y que puede haberlo en mucho de mi código es precisamente que los getters de los arrays están mal hechos, porque estás dando la referencia y permites mutarlo (no he hecho la prueba pero...). Juas, y me faltan los "private", también xDDD
#94 You mad?. Una correcta encapsulación nunca debe exponer los datos de un objeto y solo permitir al exterior métodos que funcionen como "acciones" que permitan operar con los datos del mismo,.
Los objetos deben comunicarse mediante mensajes y un getter/setter son simples accesos directos a los datos privados del mismo.
se trata de que si no utilizas getters / setters y cambias algo tendrás que revisar todo tu código.
Falso, a no ser que tu diseño haga aguas por todos lados.
Es que lo de usar un setter doble (que sí, que es un setter) es de juzgado de guardia. Y lo de devolver un array de valores es tan estúpido que no me merece la pena ni explicarte por qué.
"setter doble" debe ser un nuevo término, si lo prefieres quitale el set y llamalo defineSize para que te suene mejor . Devolver un array en ese caso es tan estúpido como considerar que es la forma más óptima de usarlo.
Y no se trata de encontrar errores, se trata de una forma de entender la programación orientada a objetos. En el mundo real te las tienes que ver con librerias,apis,etc que te obligan a usarlos pero siempre es aconsejable evitarlos en la medida de los posible.
#95 " Una correcta encapsulación nunca debe exponer los datos de un objeto"
Tu misma lo has dicho, de ahí que se recomiende no usar atributos públicos, y se haga mediante privados+getters. Y no, no es lo mismo poder acceder mediante un getter o un setter, porque como digo tu no sabes a qué estás accediendo, no sabes si es un atributo o un helado, a eso se le llama transparencia, es un concepto que aún no has asimilado.
Además deberías replantearte tu último párrafo. Si miras algo de teoría de POO precisamente recomiendan usar getters y setters para lo que tú dices que no. Pero hija si vas a sufrir así, los 4 o 5 que te estamos diciendo que estás equivocada te damos la razón y punto.
#96 Si consideras que exponer un miembro privado de una clase de forma pública no es romper la encapsulación, no seré yo quien deba convencerte de nada. Cuando la expones directamente o usas una interface para modificarla directamente NO los estas abstrayendo que es el propósito principal de la POO.
Es mi opinión y no trato de evangelizar a nadie.
#97 es que te repito que no se expone.
Lo estás mirando por el lado equivocado. A una persona que va a coger tu API le suda las narices que hagas por detras, eso es encapsular. Y no, usando un get o un set de la manera que decimos no expones más que haciendolo de la manera que tu dices, es que estamos locos? xD
Y la poo te dije que abstraigas lo que puedas, no que le busques los tres pies al gato. Si yo quiero poder cambiar la coordenada Y de un punto y solo la Y, debere tener acceso a eso con un setter o no? Es que manda narices que no veas que 1+1 son 2 xD
#97: Es que esos atributos son, en realidad, de visibilidad pública. La razón por la cual se utilizan los getters y los setters es porque así tienes más control sobre la manipulación de los mismos.
Muchas veces esos getters y setters son redundantes (pero necesarios). Otras veces esos mismos getters / setters se convierten en cruciales (ya no me vale que me metas un -1 en tal valor). Cómo controlas eso a posteriori si en todo el código lo que tienes son referencias al propio atributo? Y sigo sin entender el ejecutar un método con dos argumentos como setSize cuando puedes utilizar solo uno. Y no, no considero que sea romper el encapsulamiento el saber que un rectangulo tiene base y altura, más que nada porque el propio método setSize también te lo va a decir.
Desde luego tengo muchísimo que aprender de OOP y de diseño en general, eso no te lo voy a negar, pero considero que mi opción (y la que me han enseñado y he leído en muchísimos sitios) es mejor que la tuya. Y, aunque no lo fuera, no es nada de que avergonzarse xD
#100 jajaja muy bueno eso, y el del camp nou también se sale..
un s.o. no tiene porque ser un windows, ni un mac, ni un linux, basta con que haga lo que tu quieras.
#101 un s.o. no tiene porque ser un windows, ni un mac, ni un linux, basta con que haga lo que tu quieras.
Pero si es que ESO es lo difícil. Lo fácil son los "colorcitos", ventanas y esas mierdas.
El equivalente a lo que has dicho, siguiendo el símil del rascacielos:
"Un rascacielos no tiene que ser un Empire State, Torres Gemelas o un Burj Dubai. Basta con que tenga cimientos y no se caiga."
A mí me da la impresión de que no tienes muy claro que es un SO ni para qué sirve y por eso le sigues dando vueltas al tema.
Joder como habeis desvirtuado el hilo xD.
Si viene sabiendo 4 cosas de php, no creo que se entere si habláis acerca de un lenguaje POO o que son los getters/setters xD.
#103 nooo por dios, que sigan, lo que no entiendo lo busco y así voy entendiendo la conversación, no desvirtúan!!! seguir, seguir, seguir!! jeje
