Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

(Software Engr) Encapsulate! No,no,no! Decouple!

by princepawn (Parson)
on Jun 01, 2001 at 04:35 UTC ( #84805=perlmeditation: print w/replies, xml ) Need Help??

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?

  • Comment on (Software Engr) Encapsulate! No,no,no! Decouple!

Replies are listed 'Best First'.
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.
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.

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.

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.

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

          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

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.
      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.
        My thoughts exactly.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://84805]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2022-08-16 19:08 GMT
Find Nodes?
    Voting Booth?

    No recent polls found