Should I be using inhertance for this?

[Jacob D Dixon]

I think using a web service would make the task easier. I just want to get a handle on Sockets and a good "design" of a client / server model. Erik also suggested the same thing as you about the communication layer. Saying that the server should handle anything thrown at it pretty much. I just haven't been able to wrap my head around his suggestions on how to make it work for me for this particular project. I mean technically right now it does handle everything. It detects if it is a Commons[] object, and if it is then does something with it. If it isn't a Commons[] object then it just does nothing with it. But the way I have it designed.. any future updates would require the server to be updated (which would mean the agents couldn't check in at that time), and the agents to be updated depending on what is being added. Like if I wanted to make v2 be able to reboot the agents to safe mode, then most likely it would require a server & agent upgrade. I just don't see how to get around doing this task without an upgrade later on. I hope that makes sense. I guess I'm just looking for pointers on making my classes more "professional" and easier to manage. I mean I think they are easy to manage because I built them lol.

[PIEBALDconsult]

The socket-oriented communication to a third-party system that I had to do on my last job was very simplistic (circa 1980s?). It was strictly ASCII text -- the first two characters were the number (type) of message, the next four characters were the length of the message, followed by the data of the message. I used an enumeration (as you did) to hold the message types, but I had no need of defining a hierarchy of message classes. I just took a quick look at my code and I see that I defined one class, which derives from EventArgs; it is used for sending and receiving the messages. Received messages are passed up the chain by events. Sent messages are passed along to the log via events. Otherwise I probably wouldn't defnie a class at all. The Windows Service that performs this communication merely reads new messages from a table, sends them, and marks them as sent; and reads messages from the socket and inserts them into the database (marked as received). Other Services handle entering messages to send and dealing with responses.

[nortee]

Hello :), While I use a different coding platform, I've worked a bit with inheritance and client/server applications. The examples described below is pseudocode (okay, I lie, it's a hack of mostly Delphi mixed with pseudocode, so sue me :P), so you should be able to make a decision as to whether you would want to use inheritance or not. Your particular scenario involves transporting data between a client and a server. What data is being transported (for argument's sake) isn't actually what's important, how you *interpret* the data, on either side of the protocol, is. The core functionality of your base class involves just putting the data into a stream and reading the data from a stream. Nothing else. You don't want your objects to do more than it needs to. The specialisation of each (derived) class will contain the specific enhancements that you would want from it. So for my example, you have your class defined like so:

TYourBase = class(TObject)
protected
procedure WriteToStream(AStream : TMemoryStream); virtual;
procedure ReadFromStream(AStream : TMemoryStream); virtual;
public
function ToStream : TMemoryStream;
procedure FromStream(AStream : TMemoryStream);
end;

With your implementation for this class looking something like this:

procedure TYourBase.WriteToStream(AStream : TMemoryStream);
begin
// do some basic writing to the stream...
end;

procedure TYourBase.ReadFromStream(AStream : TMemoryStream);
begin
// do some basic reading from the stream...
end;

function TYourBase.ToStream : TMemoryStream;
begin
Result := TMemoryStream.Create;
WriteToStream(Result);
end;

procedure TYourBase.FromStream(AStream : TMemoryStream);
begin
// maybe do some checks here...
ReadFromStream(AStream);
end;

Now for the inheritance part. Let's say that your derived class needs to contain a few accessors (a string, an integer and a float). You would define it something like this:

TSomeDescendant = class(TYourBase)
protected
procedure WriteToStream(AStream : TMemoryStream); override;
procedure ReadFromStream(AStream : TMemoryStream); override;
public
SomeString : String;
SomeInteger : Integer;
SomeFloat : Real;
end;

With the implementation looking something like this:

procedure TSomeDescendant.WriteToStream(AStream : TMemoryStream);
begin
// You would want to call this because the ancestor will most probably
// have done it's own bit of writing to the stream...
inherited WriteToSt

[Spectre_001]

Have your client code use reflection and generics to dynamically invoke your object's methods: #region Libraries using System; using System.Collections.Generic; using System.Reflection; #endregion namespace Utilities { // T is the type of the object containing the method to be invoked. // R is the type of the return value expected. // Methods that fail to return a value, or are declared as void, // will return default(R), which in many cases (depending on typeof(R)) will be null. public class DynamicMethodInvocation { // The methodParameterValues dictionary requires the parameter's name as the key // and the parameter's value as the object. If ParameterValues == null, no // parameters are passed to the method invocation. public R Invoke(string MethodName, IDictionary methodParameterValues) { return Invoke(MethodName, methodParameterValues, null); } // constructorParameters are the parameters required by the object T's constructor // if any. If T's constructor requires no parameters pass null, or use the // overload. public R Invoke(string MethodName, IDictionary methodParameterValues, object[] constructorParameters) { T instance = (T)Activator.CreateInstance(typeof(T), constructorParameters); MethodInfo mi = instance.GetType().GetMethod(MethodName); if (methodParameterValues != null) { ParameterInfo[] parameters = mi.GetParameters(); object[] values = (object[])Array.CreateInstance(typeof(object), parameters.Length); foreach (ParameterInfo parameter in parameters) { values[parameter.Position] = methodParameterValues[parameter.Name]; } return (R)mi.Invoke(instance, values); } else { return (R)mi.Invoke(instance, null); } } } }

Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower

[Steve Naidamast]

Inheritance should be used sparingly in business applications. In reality, in terms of these applications, inheritance has limited value compared to the internals, military, and scientific sectors. Developers who use inheritance for the most part use it unnecessarily add a lot of ambiguity to the systems they are working on. Nonetheless, there are reasonable situations where inheritance can be of value; the most important being where you have numerous different types of constructs that basically belong within a same set of data (ie: security types; employee types). That being said here are a few axioms that you should always follow when using inheritance as described by Tom Patton a number of years ago in his second edition of his COM+ Component programming manual: 1) Never use more than three levels of inheritance. Once this rule is broken inheritance hierarchies tend to become too complicated for easy maintenance. 2) Never use a "Protected" access modifier for a variable or method implementation. This attribute has been the bane of many inheritance hierarchies causing them to fail. The reason being is that they tend to break such hierarchies when updated during maintenance. 3) Test your inheritance hierarchy thoroughly to make sure that it works in all scenarios as expected. 4) Test your inheritance hierarchy for its level of "black-box reuse". The more an inheritance hierarchy can be used without any understanding of anything but the public API, the more concrete your structure will be. Most inheritance hierarchies tend to fall in the "white-box reuse" range meaning that there are higher levels of maintenance required, which is not what you want. 5) If you find that your hierarchy is causing more issues than warranted either redesign it or drop the implementation all-together. It will only get worse as it enters a production mode.

Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com

[Jacob D Dixon]

I've been thinking a lot about this and looking at some of the other post. In my situation I am leaning towards leaving it the way it is. (As in not using inheritance). I mean if you really think about it, any update would require the server to be updated along with the agent on the systems. I don't see a way around this. I do like the idea of sending the four characters to specify the type of message that was being sent.

[mbb01]

Err ... I could go a lot about the pros and cons of inheritance and interfaces. Good and bad design is all a matter of taste anyway. Or to put it another way, no two programmers will ever agree. What I will say is it is important to be consistent, at the very least, and if you find you are posed with these types of questions then in all likelyhood you haven't done enough preparation in your design. I'll point you in the direction of a book called "Head First Design" patterns. It is easy to read and gives you a good understanding of the issues involved in OOP&D. At least, it helped me bridge the gap between structured/procedural programming and OOP.

[nortee]

Hi mbb01, I totally agree with you there. In programming we have the gift (or curse - whichever way you look at it) of a plethora of implementations that will provide you with a multitude of solutions to your given scenario. The real test of a good developer is to select the solution/implementation which is not necessarily the 'best' solution, but the one that is the most correct given the tools that you have at your disposal. What I've found through my years of coding, as I'm sure most of the people here have, is that the solution which usually ends up being used, is a cross between 2 or more methodologies meshed into a symbiotic balance of using the pros from them to the solution's advantage, while mitigating the cons of these methodologies. The bottom line is: there is no "silver bullet". Wrt books, my poison of choice is "Design Patterns: Elements of Reusable Object-Oriented Software" by TGoF, with ISBN-10: 0201633612 or ISBN-13: 978-0201633610. This book provides a overall approach to understanding in (relatively simple) laymen's terms the bulk of the most popular design patterns that are out there.

Cheers, Glen Vlotman

[Jacob D Dixon]

Thanks guys! I really didn't plan any of this to be honest. I was just trying to learn and figure out Sockets. Either way I would like to design a product like the LabTech software I was speaking of, but like you mentioned I should plan it out before trying such a project.

[James Lonero]

Jacob, there is nothing wrong with using inheritance. This is one of the pillars of OOD/OOP. Through inheritance, you also get polymorphism, one of the other pillars. You want to use an interface vs. a base class. An interface is a "base class" in theory, but has no definition. Rather it is a contract. The interface you derive your class from says that the derived class will define (host) these methods. A true base class (even abstract base class) holds common methods and data that derived base classes use. Think back to biology, when they discussed about the various classes, species, etc. of plants and animals. We all know that dogs and monkeys are types of mammals. This signifies inheritance, since mammals have certain attributes common to both dogs and monkeys. Then both dogs and monkeys have their differences. (And C# and Java can only have a single base class makes it easier.) The fact that both dogs and monkeys are mammals signifies polymorphism. This also signifies the "is a" relationship. A dog is a mammal. Therefore, the dog inherits traits and attributes (methods and data) from the mammal. There is also the "has a" relationship where the class contains (encapsulates) a data item. Much like your Commons class contains two Task objects. A dog has four paws instead of hands and feet. Of course, these could be specialized derived objects in the base mammal object. In the case of your Commons and Printers classes, it can stand as it is, since all it carries is data. If your properties are going to do more processing with the internally stored data, then an interface would be good if you plan to have other ways of holding your Commons data. The main arguments for using inheritance that I have run up against is the "has a" vs. "is a" relationship. If your class "is of" another class, then use inheritance. If you class contains another class/object, then add that object as a data object. I have also found that as I create objects/classes, sometimes I find that two or more of the objects have similar methods and data. That is a good place to use inheritance. Take the common methods and data and re-factor them into a base class and have both the old classes inherit from the base class. Also, if I find that I do need to inherit from two or more classes (as back in the old C++ days), see which one is the best choice to inherit from and encapsulate the others.