Sono al punto in cui mi sto dedicando allo sviluppo freelance di alcune applicazioni web complesse, e mi piacerebbe sviluppare una struttura leggera per il mio uso personale, ma mi piacerebbe avere qualche consiglio da più programmatori esperti prima di tutto su un aspetto del mio progetto di immagine per il framework.
È strongmente basato su prototipi / OOP. Il framework è impostato per sapere come gestire ciascun prototipo e per sapere che alcuni oggetti, ad esempio, un costrutto socketIO , possono utilizzare altri oggetti specifici, ad esempio IP di server e anche socketPort di quel server .
Facilita questa pratica anche con le funzionalità del programmatore, aiutando a mantenere tutto il codice disaccoppiato, orientato agli oggetti e "wireless".
Il risultato è un codice che sembra "wireless". Quello che intendo è che, invece di passare i dati come parametri di funzione, gli oggetti del framework sanno quali oggetti cercare e leggere. Lo sviluppatore può passare un oggetto come parametro, ma se non lo fa, il framework lo cercherà e lo troverà se esiste nell'ambito appropriato.
È quello che ho descritto come buona pratica di programmazione / progettazione?
Mi piace la struttura del codice che mi aiuta a raggiungere più rapidamente, ma è importante per me che non spenda tempo per qualcosa che è rotto (un modello cattivo).
Voglio sapere se questa pratica in cui i dati non sono visivamente trasferiti / trasferiti è un approccio accettabile allo sviluppo.
La mia preoccupazione è che la comunicazione tra oggetti correlati "dietro le quinte" possa confondere i programmatori che non sono al corrente del design del framework.
Ecco un codice del motore lato client "simulato" che funzionerebbe dopo il completamento di questo framework che attualmente sto chiamando Air JS. È stato commentato per spiegare se stesso, perché è il mio progetto, di sorta, quindi sentitevi liberi di sfogliarlo senza preoccuparvi di ogni dettaglio.
App.Engine = new engine({
/*
Air JS's Engine Model
---------------------
When developing web apps, the engine
gets complex quickly, both on the
client and server side. Without a
framework promoting the use of good
JS OOP coding patterns, the code can
very quickly become a tangled mess!
By utilizing object prototypes, Air
JS accesses relevant objects and will
find things like IPs, Ports,
extensions, and other information
relevant to a specific task, without
the developer needing to manually
connect things. For example, when
creating a socket.IO connection, if
a server object exists that owns a
socketPort object, Air will find the
port! No strings attached.
*/
Server : new server({
/*
The server constructor allows all
relevant server information to be
gathered into one place. Sky JS
objects such as:
socketIO object
AJAX object
that utilize server information
will dynamically locate and utilize
the information "wireless", without
the need to be passed in.
*/
location : new location({
url : new URL("www.website.com"),
IP : new IP("1.2.3.4.5"),
ports : new portList({
default : new defaultPort("8080"),
socket : new socketPort("4545")
}),
paths : new pathList({
app : "App",
login : "Login",
register : "Register",
getData : "Get"
});
}),
auth : new authentication({
username : new username(App.Client.Username),
password : new password(App.Client.Password)
}),
}),
"Socket" : new socketIO({
open : new socketListener("open", function(){
// handle event
}),
}),
/*
The socketIO object expects an object
containing socketListeners as its first
parameter.
The SocketIO object accepts a server object,
portList, socketPort, or port string / int
as its second parameter:
App
Server
App.Engine
App.Engine.Server
App.Engine.Server.ports
App.Engine.Server.ports.socket
"4545"
4545
This is an example of how Air.JS works
"wireless" -- If the relevant object exists
within the same engine, it will be found,
without the developer passing the object or
information in as a parameter. This is called
wireless association in Air JS.
Wireless association will be discussed later
on in this program, and is the primary proponent
of the clean, de-coupled code that Air JS
promotes.
In this situation, the relevant object is a
socketPort. If a server object exists that
owns a portList containing a socketPort,
it will grab the port.
If there are multiple server objects, the
framework will choose the first one that owns
a portList and / or a socketPort.
If no socketList object is found in a server
object, the framework will search the main
scope of the server object. If no socketPort
object is found in a server object, or no
server object is found in the engine object,
the framework will check for a socket object
in the engine object's main scope.
Ultimately,
if no socketObject exists, and the developer
does not provide the port via parameters, an
error will be thrown, pointing to the missing
data.
*/
});
App.init();
Le funzionalità qui dimostrate sono prototipi di oggetti assegnati all'interno del framework, come scorciatoie. Per i modelli programmatori di nuovi componenti / componenti del motore, la struttura faciliterebbe l'uso di oggetti che "conoscono" determinati prototipi. Ad esempio, l'utente crea il prototipo Car ed elenca carDoor come uno dei suoi oggetti correlati, quindi un'istanza Car cercherà qualsiasi carDoor s, senza che lo sviluppatore lo invii a carDoor attraverso i parametri.