class - the_content - llamar una clase desde otro archivo php

Clases vs. Funciones (8)

Las funciones son fáciles de entender, incluso para alguien sin experiencia en programación, pero con una base matemática justa. Por otro lado, las clases parecen ser más difíciles de entender.

Digamos que quiero hacer una clase / función que calcule la edad de una persona dada su año de cumpleaños y el año actual. ¿Debo crear una clase para esto o una función? ¿O la elección depende del escenario?

PD. Estoy trabajando en Python, pero creo que la pregunta es genérica.

Antes de responder a tu pregunta:

Si no tiene una clase Person , primero debe considerar si desea crear una clase Person . ¿Piensas reutilizar el concepto de Person mucha frecuencia? Si es así, debes crear una clase Person . (Usted tiene acceso a esta información en forma de variable pasante y no le importa que sea desordenado y descuidado).

Para responder tu pregunta:

Usted tiene acceso a su año de nacimiento, por lo que en ese caso es probable que tenga una clase de Person con un campo de someperson.birthdate . someperson.birthdate . En ese caso, tiene que preguntarse a sí mismo si someperson.age un valor reutilizable.

La respuesta es sí. A menudo nos preocupa la edad más que la fecha de nacimiento, por lo que si la fecha de nacimiento es un campo, la edad debería ser definitivamente un campo derivado. (Un caso en el que no haríamos esto: si estuviéramos calculando valores como someperson.chanceIsFemale o someperson.positionToDisplayInGrid u otros valores irrelevantes, no ampliaríamos la clase Person ; solo pregúntese: "¿A otro programa le importarían los campos que ¿Estoy pensando en extender la clase? "La respuesta a esa pregunta determinará si amplías la clase original o si realizas una función (o tu propia clase, como PersonAnalysisData o algo).)

Depende del escenario Si solo tiene que calcular la edad de una persona, entonces use una función ya que desea implementar un comportamiento específico único .

Pero si desea crear un objeto, que contiene la fecha de nacimiento de una persona (y posiblemente otros datos), permite modificarlo, entonces calcular la edad podría ser una de las muchas operaciones relacionadas con la persona y sería sensato usa una clase en su lugar.

Las clases proporcionan una forma de fusionar algunos datos y operaciones relacionadas. Si solo tiene una operación en los datos y luego utiliza una función y pasa los datos como argumento, obtendrá un comportamiento equivalente, con un código menos complejo.

Tenga en cuenta que una clase del tipo:

class A(object): def __init__(self, ...): #initialize def a_single_method(self, ...): #do stuff

no es realmente una clase, es solo una función (complicada). Una clase legítima siempre debe tener al menos dos métodos (sin contar __init__ ).

Las clases (o más bien sus instancias) son para representar cosas. Las clases se usan para definir las operaciones soportadas por una clase particular de objetos (sus instancias). Si su aplicación necesita hacer un seguimiento de las personas, entonces Person probablemente sea una clase; las instancias de esta clase representan a las personas particulares a las que está rastreando.

Las funciones son para calcular cosas. Reciben entradas y producen una salida y / o tienen efectos.

Las clases y las funciones no son realmente alternativas, ya que no son para las mismas cosas. Realmente no tiene sentido considerar hacer una clase para "calcular la edad de una persona dada su año de cumpleaños y el año actual". Puede o no tener clases para representar cualquiera de los conceptos de Person , Age , Year y / o Birthday . Pero incluso si la Age es una clase, no debe considerarse que calcule la edad de una persona; más bien, el cálculo de la edad de una persona da como resultado una instancia de la clase Age .

Si está modelando personas en su aplicación y tiene una clase Person , puede tener sentido hacer que el cálculo de edad sea un método de la clase Person . Un método es básicamente una función que se define como parte de una clase; así es como "defines las operaciones soportadas por una clase particular de objetos" como mencioné anteriormente.

De modo que podría crear un método en su clase personal para calcular la edad de la persona (probablemente recuperaría el año del cumpleaños del objeto de la persona y recibiría el año actual como parámetro). Pero el cálculo todavía lo hace una función (solo una función que resulta ser un método en una clase).

O simplemente podría crear una función independiente que reciba argumentos (ya sea un objeto personal para recuperar un año de nacimiento, o simplemente el año de nacimiento). Como nota, ¡esto es mucho más simple si aún no tiene una clase a la que este método pertenece naturalmente! Nunca debe crear una clase simplemente para mantener una operación; si eso es todo lo que hay en la clase, entonces la operación debería ser solo una función independiente.

Crea una función Las funciones hacen cosas específicas, las clases son cosas específicas.

Las clases a menudo tienen métodos, que son funciones que están asociadas con una clase en particular, y hacen cosas asociadas con lo que la clase es, pero si lo único que quieres es hacer algo, una función es todo lo que necesitas.

Esencialmente, una clase es una forma de agrupar funciones (como métodos) y datos (como propiedades) en una unidad lógica que gira en torno a un cierto tipo de cosas. Si no necesita esa agrupación, no hay necesidad de hacer una clase.

Voy a romper con la manada en este y proporcionar un punto de vista alternativo:

Nunca crees clases.

La dependencia de las clases tiene una tendencia significativa a causar que los codificadores creen código lento e hinchado. Las clases que se pasan (ya que son objetos) consumen mucha más potencia computacional que llamar a una función y pasar una o dos cuerdas. Las convenciones de nomenclatura adecuadas sobre las funciones pueden hacer casi todo lo que puede hacer una clase, y con solo una fracción de la sobrecarga y una mejor legibilidad del código.

Sin embargo, eso no significa que no debas aprender a entender las clases. Si está codificando con otros, la gente los usará todo el tiempo y tendrá que saber cómo hacer malabares con esas clases. Escribir su código para confiar en las funciones significa que el código será más pequeño, más rápido y más legible. He visto enormes sitios escritos usando solo funciones ágiles y rápidas, y he visto sitios pequeños que tenían una funcionalidad mínima que dependía en gran medida de las clases y se rompían constantemente. (Cuando tienes clases que extienden clases que contienen clases como parte de sus clases, sabes que has perdido toda apariencia de fácil mantenimiento).

Cuando se trata de eso, todos los datos que va a querer pasar pueden ser manejados fácilmente por los tipos de datos existentes.

Las clases se crearon como una muleta mental y no proporcionan ninguna funcionalidad adicional real , y el código excesivamente complicado que tienen una tendencia a crear derrota el punto de esa muleta en el largo plazo.

Sé que es un tema controvertido, y es probable que me queme ahora. pero aquí están mis pensamientos

Para mí, pensé que lo mejor es evitar las clases el mayor tiempo posible. Si necesito un tipo de datos complejo, utilizo struct simple (C / C ++), dict (python), JSON (js) o similar, es decir, sin constructor, sin métodos de clase, sin sobrecarga del operador, sin herencia, etc. Al usar la clase, puede dejarse llevar por el propio OOP (qué patrón de diseño, qué debería ser privado, bla bla) y perder el enfoque en las cosas esenciales que quería codificar en primer lugar.

Si su proyecto se vuelve grande y desordenado, entonces OOP comienza a tener sentido porque se necesita algún tipo de arquitectura de sistema de vista de helicóptero. "función vs clase" también depende de la tarea que tiene por delante.

función

propósito: procesar datos, manipular datos, crear conjuntos de resultados.
cuándo usar: siempre codifique una función si desea hacer esto: "y = f (x)"

struct / dict / json / etc (en lugar de clase)

propósito: almacenar attr./param., mantener attr./param., reutilizar attr./param., usar attr./param. luego.
cuándo usar: si se trata de un conjunto de atributos / params (preferiblemente no mutable)
diferentes idiomas lo mismo: struct (C / C ++), JSON (js), dict (python), etc.
siempre preferiría struct / dict / json / etc simple sobre clases complicadas (¡es sencillo!)

clase (si es un nuevo tipo de datos)

una perspectiva simple: es una estructura (C), dict (python), json (js), etc. con métodos adjuntos.
El método solo debería tener sentido en combinación con los datos / param almacenados en la clase.
Mi consejo: nunca codifique cosas complejas dentro de los métodos de clase (llame a una función externa en su lugar)
advertencia: ¡no use mal las clases como espacio de nombres falso para las funciones! (esto sucede muy a menudo!)
Otros casos de uso: si desea sobrecargar mucho al operador, utilice clases (por ejemplo, su propia clase de multiplicación de matriz / vector)
pregúntese: ¿es realmente un nuevo "tipo de datos"? (Sí => clase | No => puedes evitar usar una clase)

array / vector / list (para almacenar una gran cantidad de datos)

propósito: almacenar una gran cantidad de datos homogéneos del mismo tipo de datos, por ejemplo, series de tiempo
consejo n. ° 1: solo use lo que ya tiene su lenguaje de programación. no lo reinventes
consejo n. ° 2: si realmente desea su "clase mysupercooldatacontainer", sobrecargue una clase existente de matriz / vector / lista / etc (por ejemplo, "clase mycontainer: public std :: vector ...")

enum (clase enum)

solo lo menciono
consejo n. ° 1: utilice enum plus switch-case en lugar de patrones de diseño OOP excesivamente complicados
consejo # 2: use máquinas de estado finito

Nunca crees clases. Al menos se está discutiendo el tipo de clases de OOP en Python.

Considera esta clase simplista:

class Person(object): def __init__(self, id, name, city, account_balance): self.id = id self.name = name self.city = city self.account_balance = account_balance def adjust_balance(self, offset): self.account_balance += offset if __name__ == "__main__": p = Person(123, "bob", "boston", 100.0) p.adjust_balance(50.0) print("done!: {}".format(p.__dict__))

vs esta versión namedtuple:

from collections import namedtuple Person = namedtuple("Person", ["id", "name", "city", "account_balance"]) def adjust_balance(person, offset): return person._replace(account_balance=person.account_balance + offset) if __name__ == "__main__": p = Person(123, "bob", "boston", 100.0) p = adjust_balance(p, 50.0) print("done!: {}".format(p))

El enfoque namedtuple es mejor porque:

namedtuples tiene una sintaxis más concisa y un uso estándar.
En términos de comprender el código existente, las tilturas con nombre son básicamente fáciles de entender. Las clases son más complejas. Y las clases pueden ser muy complejas para que los humanos las lean.
namedtuples son inmutables. Administrar el estado mutable agrega complejidad innecesaria.
la inheritance clase agrega complejidad y oculta la complejidad.

No puedo ver una ventaja única al usar clases OOP. Obviamente, si está acostumbrado a OOP, o tiene que interactuar con un código que requiere clases como Django.

Por cierto, la mayoría de los otros idiomas tienen alguna característica de tipo de registro como namedtuples. Scala, por ejemplo, tiene clases de casos. Esta lógica se aplica igualmente allí.

Como lo que dice Amber en su respuesta : crea una función. De hecho, cuando no tienes que hacer clases si tienes algo como:

class Person(object): def __init__(self, arg1, arg2): self.arg1 = arg1 self.arg2 = arg2 def compute(other): """ Example of bad class design, don''t care about the result """ return self.arg1 + self.arg2 % other

Aquí solo tienes una función encapsular en una clase. Esto solo hace que el código sea menos legible y menos eficiente. De hecho, el compute la función se puede escribir así:

def compute(arg1, arg2, other): return arg1 + arg2 % other

Debe usar clases solo si tiene más de 1 función y si mantener un estado interno (con atributos) tiene sentido. De lo contrario, si desea reagrupar funciones, simplemente cree un módulo en un nuevo archivo .py .

Puede ver este video (Youtube, aproximadamente 30 minutos) , lo que explica mi punto. Jack Diederich muestra por qué las clases son malas en ese caso y por qué es un diseño tan malo, especialmente en cosas como API.
Es bastante largo, pero es una visita obligada