My boss was sitting next to me as we closed down our
virtual database-based FTP server derived from
Net::FTPServer. Then he says "What's that file
there?. I say "it's a file that has the welcome text
that shows up upon login." He says "Well, why cant that
be in the ftpd.conf file. I say "Well, because I want
to emphasize that cornerstone of software engineering,
known as
decoupling
He then says "Well, it sort of bothers me that all the
configuration info for the server is not in one place.
Can't you put it in there?
In other words, he was saying, you should enforce that
cornerstone principle of software engineering,
encapsulation
So, here I am, left thinking, just who was right and why
did I detect a conflict in two principles which supposedly
are supposed to go hand in hand?
|
Re: (Software Engr) Encapsulate! No,no,no! Decouple!
by Sherlock (Deacon) on Jun 01, 2001 at 05:11 UTC
|
Unfortunately, this is not a very easy problem to solve. In fact, solving this exact problem is one of the reasons computer programmers are paid so well. :)
Always remember that there is always more than one way to do things. The idea behind encapsulation, as I'm sure you know, is to take all of the data and methods that belong together into a single place. Decoupling, on the other hand, is designed to break apart two distinct entities so that they don't have any ties between them. The real goal is to obtain a system that is very strongly cohesive, but very loosely coupled.
By that, I mean that each object (please forgive the strong C++ background coming through here) should be complete - every aspect of that object should be contained within the object. It should also be concise - there shouldn't be any elements within the object that don't specifically pertain to that object. Also, each object should not rely upon other objects (except, perhaps, for the objects that it contains) in order to function - that's the goal of decoupling. These two goals, decoupling and encapsulation, don't really oppose one another. They both work together to generate a system where a single object can be easily pulled from one system and put into another with minimal effort. If you've obtained that level of object independence, then you've done your job very well.
For your case, I think you need to ask yourself, simply, where does the welcome text make most sense to be? Don't worry about which principle you're stressing because they're both a means to the same end. Does the welcome text make more sense to be with the rest of the configuration info, to give a more cohesive server, or is the welcome text something that should be separated, perhaps because it needs to be changed often and it would be nice to do it apart from the rest of your code?
I guess my take on it (forgive me because I have absolutely no idea how your system works) would be to place the welcome message with the rest of the configuration information. I'm making an assumption here that the welcome message can be configured along with the rest of the options (I hope I interpreted that correctly from your post). That way, your configuration object would contain all of the pieces it needs to be complete. I think this might make your object more protable, which is what we're all really after - reusable code.
If I ever run into this case, I always make sure I'm meeting the following requirements:
- Does the object make sense?
- Is the object complete?
- Is the object concise?
If I can say yes to all three of these questions, then I usually feel pretty good about my design. My suggestion would be to put the welcome text in each place - with the rest of the configuration information and without it. Then, ask yourself these questions. ("Does the object make sense?" might not be very pertinent here - you already know that.) Whichever case gives you the most resounding "yes"s from these questions is the one I think you should go with. No matter what you decide, your solution should work, so it's really up to you to decide which design is better. I just stress that you shouldn't use an SE principle such as decoupling just for the sake of using a well respected principle. It's much more important to use whatever makes the most sense to achieve the common goal - strong cohesion, loose coupling.
I realize that this isn't a very straight answer, but it's an answer that every programmer must come up with on his/her own. The solution I might use is certainly different from what others would use. The best you can do is use the design that makes the most sense for you - after all, you'll be the one designing and maintaining the system.
- Sherlock
Update: From bikeNomad's node: "The two principles aren't really at odds with each other." Exactly right! If you can grasp that, you've got it.
Skepticism is the source of knowledge as much as knowledge is the source of skepticism. | [reply] |
Re: (Software Engr) Encapsulate! No,no,no! Decouple!
by bikeNomad (Priest) on Jun 01, 2001 at 05:01 UTC
|
I've found that, in general, encapsulation improves decoupling. I don't think your example is exactly the best example of the desire for either, though; it's more about packaging config information. Most of the discussion in SW engineering circles about encapsulation and decoupling has to do with actual program architecture.
Anyway, encapsulation lets us hide the nasty little details inside our modules (or classes, or whatever other mechanisms for encapsulation we have available). By not exposing the nasty little details (like, for instance, object data or internal methods), nothing outside can depend on them. So the coupling between your module and users of that module can be reduced.
The two principles aren't really at odds with each other. | [reply] |
Re: (Software Engr) Encapsulate! No,no,no! Decouple!
by dws (Chancellor) on Jun 01, 2001 at 05:34 UTC
|
Coupling is an aspect of Software Engineering, but decoupling is an overloaded term that many take at first to mean "separating". Coupling is more about how different things relate, and the strength of that relationship.
In your example, there are valid reasons to separate the welcome text file from other web server configuration. One reason being that you might want to have different roles edit each file.
| [reply] |
Re (tilly) 1: (Software Engr) Encapsulate! No,no,no! Decouple!
by tilly (Archbishop) on Jun 01, 2001 at 07:35 UTC
|
I would put the default welcome message in the ftpd.conf
file, as well as the spec for the search path for the
welcome message.
That centralizes your configuration while giving the
freedom for a site to have different people with different
roles control different parts of the configuration. It
also will make it possible for, for instance, users to
have their personal customized welcome message. | [reply] |
Re: (Software Engr) Encapsulate! No,no,no! Decouple!
by cforde (Monk) on Jun 01, 2001 at 08:34 UTC
|
This isn't really about encapsulation vs. decoupling.
Encapsulation is about information hiding--keeping the details hidden,
decoupling is about separating a function into smaller pieces, generally for ease of reuse.
What you are talking about is configuration information that can be separated into two places.
This might, or might not be a good thing. It could be good if you, as the administrator want to
have sole control over the server operational parameters, but want to give someone else,
say a data administrator, the ability to update the welcome message without having to bother you.
This is a nice ability to have. Having multiple files comprise the configuration of the server
is not necessarily good or bad. It depends on how you want to manage the service.
Have fun,
Carl Forde | [reply] |
|
|
Encapsulation is about information hiding--keeping the details hidden...
"Encapsulation is the process of hiding all of the details of an object that do not contribute to its essential characteristics."
- Booch, 1991
"Encrapsulation is the process of hiding all of the details of an object that do not contribute to its essential characteristics, especially the shitty parts."
- EdwardG, 2003
| [reply] |
Re: (Software Engr) Encapsulate! No,no,no! Decouple!
by John M. Dlugosz (Monsignor) on Jun 01, 2001 at 18:47 UTC
|
The central config file can contain an entry naming the hello file. That way someone reading the one file can know that this other file is involved, rather than it having a magic name that is known implicitly. | [reply] |
|
|
My two penneths worth would be that the location of the welcome text should be in the configuration file but the text itself be in a separate file.
When the server starts, it knows where to grab the text from and does so as required.
Assuming, for a minute, that the welcome text is loaded from disk as required, the server need not be manipulated in any way to change the text, only the file contents need changing.
The alternative would be a quick HUP.
| [reply] |
|
|
| [reply] |
|
|
