Reblessing

Replies are listed 'Best First'.
Re: Reblessing by dragonchild (Archbishop) on Jun 21, 2001 at 17:32 UTC
I wouldn't ask a connection about the state of a server, I would ask the server! I don't agree, not in a computer world. Humans don't think that the act of communicating is an object. Yet, programmers use objects to represent processes all the time. (Sorting is a very good example of this.) In a computer world, I would definitely do the following: Have a desire to determine the state of the server Send a message addressed to the server via my connection to the server Await a response That, to me, makes the most sense. You're going to have a connection between you and the server. You're going to make an object for it, so that it can decode the messages from the hexstream into nice message objects. (At least, I think you would want to be doing this!) Leverage the fact that you don't have a direct connection to the server. That said, I'm still confused as to your need to re-bless. I read the previous discussion and it still didn't make sense, but I didn't comment cause everyone else was making so many good points. In a C++-type language, you would be declaring a server variable of type Server::Generic and putting an instance of type Server::Foo in it (which is perfectly legal). Even though Perl doesn't have strong typing, why not do something like that? Every server class needs to agree to some core API. They won't implement those functions the same way, nor will they be limited to those functions, but they need to agree on what makes them a member of the server family. This core API should be in some abstract base class, and overloaded by every child class. That way, you now have a contract with the server, whatever class it is, that it will act in certain ways. One of these contractual actions would be to tell you what type it is. (Presumably through ref($self) or some internal variable inherited from the base class.) Unless I'm missing something big, that should help clarify your conceptual issues ... ?	[reply]
Re: Re: Reblessing by busunsl (Vicar) on Jun 21, 2001 at 18:34 UTC
dragonchild Thanks for your answer! I posted a follow-on here.	[reply]
Re: Reblessing by Sherlock (Deacon) on Jun 21, 2001 at 17:58 UTC
busunsl, Obviously, there is going to be benefits and drawback to either approach. What I think you want to do is figure out which one has the most important benefits and the least significant drawbacks for your application. I'll try to explain my take on either architecture and you can conclude whatever you'd like from there. Case 1: Use of a Connection Object This architecture gives you more flexibility. You're basically creating your own API for your application. (At least to some degree.) You're saying that if all objects that need to access the server use these methods, they will be supported by the connection object. The connection object then handles and data requests that are made of the server. The bonus to this is that if your server needs to change, all of your "outer" objects (those that talk to the connection object) can be totally ignorant of those changes. They're still chatting happily away with the connection object. So what's the downside? Imagine you want to ask a friend of yours if they want to go out for a round of golf? Is it faster to ask your friend directly or to ask someone else to ask your friend for you? Obviously, it'd be faster to ask your friend driectly. This analogy is trying to point out that the first architecture is going to have higher overhead - things are just going to take a little longer. If speed isn't of critical importance in this application, this probably isn't a big deal, but if you're crunched for milliseconds, this could be a crucial decision. Case 2: Talking directly to a server In the second architecture, you're cutting out the middleman, which in some cases is very good. The overhead that I was discussing before is gone. By speaking directly to the server, you get instant feedback which can be very important to time-critical applications. The downside (as you seem to have already spotted) is that if your server ever needs to change, you need to change all of the objects that talk to the server (unless you can manage to support all of the same methods used to speak to your server). This takes away some of your flexibility at the cost of speed. If you don't plan on changing this application ever COUGH WARNING! EVERYTHING CHANGES COUGH, I think you could get away with this approach and save some time, but if your server hasn't been very well thought out and planned, it may change. The more changes it needs, the less feasible this solution becomes. Conclusion (Finally) As far as I can tell, this is a simple question of "What's more important? Speed or Flexibility? That's a question that you need to answer according to your application. This answer might vary from this application to the next one you write, as well. I'd like to take a second to discuss your point on OO design, though. You said: Since I tend to think that OO should represent the real world and how we think about it, I find model two more plausible. I wouldn't ask a connection about the state of a server, I would ask the server! Indeed, OO design is supposed to model the real world, but not to the point where it hinders your ability to design a robust and flexible system. The real "selling point" of OO is that you can pick up an object from one system and drop it into another, just as you can pick up one "real world" object and drop it somewhere else. Could you grab that connection object in this system and use it elsewhere - I would sure hope so! I've used many such objects in my experience. As long as the methods it uses are well thought-out, you should be able to grab that object and use it anywhere with only minimal changes - at least the interface should remain constant. If you can achieve this level of reusability in your code, you've done an excellent job of OO design. So, even if your design doens't exactly match what you might do in the real world, that doesn't mean that it's a bad design. I guess you can probably tell which solution I lean toward - I generally opt for greater flexibility in my applications. The one thing you can generally be sure of is that things will change - the more you plan for that, the easier your life will become. Of course, if you're piched for time, sometimes you need to throw that flexibility out the window and hope it doesn't bite you in the a** later. ;) Well, that's just what I think about the situation - you can make your own conclusions about your particular application. I'd be very interested to see which architecture you decided to use and why you used it, though. Good luck! - Sherlock Skepticism is the source of knowledge as much as knowledge is the source of skepticism.	[reply]
Re: Re: Reblessing by busunsl (Vicar) on Jun 21, 2001 at 18:31 UTC
You, dragonchild and the other monks voting for the Connection Model got me almost convinced. But then I thought about the interface of the connection object and something struck me like lightning: You are missing something! And that's because I made it not clear enough in the original question: The types have serveral things in common, like 'show overall status' and the like, but do also several things different. That wants to say: I will ask every server the same questions, like 'what is your status?' or 'are you alive?'. But I will also ask servers of different type different questions. E.g.: A Replication Server will be asked 'is any of your connections down?' or 'is your stable device full?'. And a database server will be asked 'is any of the databases full?' od 'is the cpu load very high?'. I cannot ask all the questions through the connection object, because the connection object will know nothing about 'cpu load' or 'stable devices'. I have to ask the server directly. Or I have to reduce the question to 'tell me what you have to tell, I'll just show it'. This would lead to a complete redesign, but since I just started, that wouldn't hurt much. :-) I'll keep thinking about it and listening to you monks!	[reply]
Re{3}: Reblessing by dragonchild (Archbishop) on Jun 21, 2001 at 18:46 UTC
A lot of this depends on how you're talking to your server. I'm assuming that you're connecting to the server over some IP connection (presumably TCP). That means you're passing messages back and forth through some socket. These messages have to be defined somewhere, either for you or by you. Now, if you're given a message set, you have to work within it (for the most part). If you're designing the message set, you have to take into account the various types of servers you know about, as well as the various types of servers you haven't even thought of. This means that your message set has to be flexible enough to handle expansions. I would recommend SNMP for this, but that's just me. Now, you're also making a very big conceptual error - you are not asking the connection objects anything. They simply are there to facilitate communication. They do two things: Take a message object and convert it to hexstream, then send it down the socket Be told to harvest a message from a socket, read the hexstream, and convert it to a message object. Oh, yes, there are two connection objects - one for the server and one for you. Now, from the client point of view, you are simply sending messages down a pipe, waiting for a response, then reading the response. You simply do not care what's on the other end(s). From each side's end, there's a magical place on the other side of the connection that magically sends messages back. Your client also has to know what to do if there's a given response. Now, this isn't saying that the client knows about a given server type ... not really. The client knows what to do if given a certain message. Think state machines. For example, the following sequence happens: You send a message saying "What is your type?" You receive a response saying "Replication" At this point, you would then send a series of messages, awaiting a response for each, to ask about connections and stable devices. If, on the other hand, you receive a response saying "Database", you would then ask about CPU load and the like. Your client has to be intelligent enough to know about different server types, just like a human has to be intelligent enough to ask the right questions when it encounters different situations. (If you think about it for a moment, you'll understand what I'm talking about.)	[reply]
Re: Re: Re: Reblessing by Sherlock (Deacon) on Jun 21, 2001 at 19:21 UTC
dragonchild hit on a very good point - it seems to me as if you're defining your own message set. If that's the case, it doesn't matter what you need to ask your server, you can define your own way of doing it. It's somewhat like defining your own network protocol. You make a request, your connection object interprets that request and sends it off to the server, then it simply funnels back the reply. I tried to point out in my first post: As long as the methods it uses are well thought-out... The connection object, along with your message set is, by no means, trivial. Far from it! With this sort of architecture, I tend to allow the "smarts" of the application to sit on the outer edge of the application, that being mostly within the client and somewhat within the connection object. But when you're creating this new message set for yourself, heed dragonchild's advice when he/she says that you need to account for server types that you haven't even thought of yet. Obviously, if you're considering the connection object approach, you're thinking about future expansion and adaptation of this project. That might very well include the use of a new type of server and your message set had better be able to adapt to that easily or your connection object's design is going to go down the tubes in a hurry. I'd spend some serious time contemplating the message set and where you want to put the "smarts" of this application. - Sherlock Skepticism is the source of knowledge as much as knowledge is the source of skepticism.	[reply]
Re: Re: Re: Re: Reblessing by frag (Hermit) on Jun 22, 2001 at 09:17 UTC
Re (tilly) 3: Reblessing by tilly (Archbishop) on Jun 21, 2001 at 21:35 UTC
The connection object can dynamically expose methods in the server object fairly easily if you want. See Re (tilly) 1: Reverse Inheritance Irritance for an example of how to do that.	[reply]
Re: Reblessing by busunsl (Vicar) on Jun 22, 2001 at 13:54 UTC
Hi Monks! You opened my eyes, many thanks! I changed the design to the 'connection model' and everything is working just fine. Well, almost. There are still two minor problems: 1. The GUI part has to display a menu which may contain serverspecific entries. 2. The connection class must know the available servertypes in advance. But I can handle this (I think ;-) Again, many many thanks!	[reply]