C# Class for apples or fruit?

I am trying to get my mind around OOP in C# Winforms, but I was wondering about something.

Lets say I'm making a chat system, using a Tcp Protocol. I need atleast the following: - A TcpListener; - A TcpClient; - Something to parse/process the packet; - A packet encryption system.

My question is, do I make classes called:

• Server;
• Client;
• Encryption;
• PacketHandler.

Or do I make 2 classes called: - SendReceive; (Server and Client) - PacketControl. (Packet handler and Encryption class)

Or do I just have it all wrong?

Are there any standards for choosing what y开发者_如何学Cou put in which class? -Links are welcome too.

Thank you for your time.

You might want to look at the solid principles or this article to find some design guidenlines. First you should ask for "responsibilities" and then try to assign them to classes. Try to write tests und you will see that smaller units (with single responsibility) are easier to test. If you need a unit that handles different things it might be composed of others (it's a moderator between the smaller units then).

I'd start out with a Connection class that can Listen on a port or Connect to a ip adress/port. Add whatever code you need to that class to make it work.

Next to that i'd create two seperate classes Server and Client. (could be two seperate projects). These would set up whatever code you need to communicate and recieve Events from the Connection class.

After this I would add some ecryption to the Connection class, either by wrapping it with a EncryptedConnection class or extending the ConnectionClass into a subclass.

First of all, I object to talking about "OOP in C# Winforms". OOP is OOP regardless of language.

As for where to draw the lines between the classes, try making each class having only one responsibility. I would definitely have a separate Encryption-class. I'm not sure what you intend the ServerClass and pHandlerClass to do, but if it's just fecthing the data from the inuput stream, calling the decryption class and sending it to some business class for rendering to the GUI, it sounds like it could be in one class. One "handler-class".

First of all you can shorten your class names by not using the word Class in them, that would help makes things clearer.

One approach I was taught was to name all the things in your system, and try to name objects that only have a single responsibility -- so Server, Client, Packet, EncryptionScheme ... mixing responsibilities is a good way of getting things confused very easily, and single-responsibility objects are a lot easier to test.

SOLID is a core principles that should guide you during software development (if you want to create maintainable and extensible product).

First 'smell' telling you that something is wrong - duplication. E.g. if you will duplicate logic of sending and receiving both in client and server classes. So, the right way is to extract that logic into separate class/classes. Next 'smell' - complexity. If it's hard to understand some part of your code - than you should think how to simplify it (e.g. extract class of subclass, extract method or even just rename variable).

When you are determining responsibilities of your classes, try to avoid word 'AND', because most likely it's a 'smell' of breaking SRP (single responsibility principle). E.g. This class Is for sending packages AND encrypting them. BTW there is cool thing called 'crc cards' which might help you to do good design of classes.

BUT you always should think - do you really need all that stuff (YAGNI - You Ain't Gonna Need It) - do you need that cool maintenance and extensibility if you are writing chat for your grandma and grandpa.

About your case - in ideal world I'd probably do something like this:

Client, Server, Channel (chat channel abstraction, could be TcpChannel, MSMQChannel, etc), And probably SecureChannel - simple decorator over the basic channel functionality