Ok, so there are a few things I would advise.
1. KISS. Simple functions or several of them per module, without complex
inheritance chains.
2. Closures (the term describing the sharing scope that you are referring
to).
Keep it simple. Yes, separation of concerns is great, but what is your
ultimate goal? To separate concerns or have a server with functionalities?
You can simply attach 'methods' (not a fullly correct term, but let's roll
for a bit) to server.
So your server can have a few lines at the top:
var initialize = require('./initialize');
var attachClients = require('./attach-clients');
var functionalityA = require('./functionality-a');
var functionalityB = require('./functionality-b');
...
etc.
Then attach them to your server.
Server.prototype.initialize = initialize;
Server.prototype.attachClients = attachClients;
...
So now your server has all the methods you need. You can even namespace it
into server.ctrl.method if you like it that way, but that's just a detail.
The real thing is that those things can be simple functions that do what
you want.
That's a typical node.js approach - make a lot of small modules that each
does one thing and one thing well. Each can export maybe just one function
or another can export a "class" (though I'd move away from that concept
ASAP), or glue together a few of them to achieve something third.
Closures - that's also your friend. Given this:
function Server() {
// "close" this var inside the Server function
var myName = 'Server thing.';
function anAction() {
// this "inner" function has access to the Server closure, or all
variables reachable within server - even after instantiation.
console.log('My name is', myName); // picks up the var from outer
function
}
this.anAction = anAction; // if you really want to expose it.
return this;
};
Now you have an outer thing (Server "class"), and the inner thing (the
action). when you instantiate the server (var server = new Server();), the
Server function is ran and gone. But later when you call the 'anAction()'
of it, it will still have access to the last known value of that myName
var. And if some other action, function, "method" let's say, changes that
variable, your anAction will have access to that updated info.
And this works on module level, too.
- You have an internal variable or set of them in a module.
- You export some functions and objects.
- Each of those exported things still has access to those internal
variables.
- As you call them in the future, they can even modify the module.
And further on, require() is caching stuff, so if you require the same file
sometime later from some other module, you will get that current, modified
state of things.
That's how you would share info between your "Server" and
"ServerController".
My advice is to learn a lot about closures in JS, and
2015-03-03 20:10 GMT+01:00 Aaron Martone <[email protected]>:
> I did not want to use the util module because that prevents me from
> comprehending the concept rather than understanding what is being done. I
> want to learn the proper wording and coding rather than have something else
> do it for me first.
>
> My apologies if I do not use the right words and come across as confusing.
> One of the prime reasons why so many websites have failed to teach me these
> concepts is actually the language barrier of them referencing concepts by
> their names and being under the assumption that I am intimately familiar
> with the concept. So please correct me where I am wrong.
>
> Following on what you've said zladuric:
>
> I wanted to create an object that handled server-related functionality.
> And in hoping to keep with a "separation of concerns" mindset, felt an
> instance of a Server() object would need to have a Controller associated to
> it in order to perform the commands. In my mind, I felt the
> ServerController() should be within the Server() object (like on its
> this.ctrl property) so that when I instantiate the Server() into variable
> 'server', I could call things like:
>
> var server = new Server();
> server.ctrl.doAction();
>
> And I was thinking because the ServerController() was inside the Server()
> object, if I passed in or init'd the Server() object with the environment
> variable, the ServerController could (through a properly setup prototype,
> gain access to its parent object, and resolve any 'this.env' reference.
>
> I fully agree that it is best to conceptually determine how to 2 are
> related to one another; but I'm relatively new to knowing what patterns are
> out there (there has been a lot of stink about many JS-related resources
> teaching outdated methodologies, and I just want to make sure I'm not
> learning or invoking those types of practices).
>
> Ultimately, I'd like to understand the why of the implementation. At
> first, I had thought "If ServerController is inside Server, this is an act
> of Composition, no? Like saying Car() is composed of an Engine(), the
> Server() is composed of a ServerController(). And then I was hoping the
> composed object would be able to look at its parent environment for
> "shared" common information between them so that I didn't have to init it
> or redefine it at the lower levels.
>
> --
> Job board: http://jobs.nodejs.org/
> New group rules:
> https://gist.github.com/othiym23/9886289#file-moderation-policy-md
> Old group rules:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/cyVYXFGfAr0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/nodejs/9ba3e6c4-c8d7-4efa-af09-7b05be637fe7%40googlegroups.com
> <https://groups.google.com/d/msgid/nodejs/9ba3e6c4-c8d7-4efa-af09-7b05be637fe7%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Zlatko
--
Job board: http://jobs.nodejs.org/
New group rules:
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/nodejs/CADu3pbwCD6DUzca0Zum4Uz7TD%3DKs_HvXXRjJ_Xkzg_AnM277kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
