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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.