C # Класс для яблок или фруктов?

Question

Я пытаюсь сосредоточиться на ООП в C # Winforms, но мне было интересно кое о чем.

Допустим, я создаю систему чата, использующую протокол Tcp.Мне нужно по крайней мере следующее: - TcpListener;- TcpClient;- что-то для разбора / обработки пакета;- Система шифрования пакетов.

У меня такой вопрос: я делаю классы:

• Сервер;
• Клиент;
• Шифрование;
• PacketHandler.

Или я могу сделать 2 класса с именем: - SendReceive;(Сервер и клиент) - PacketControl.(Обработчик пакетов и класс шифрования)

Или я просто все неправильно понял?

Существуют ли какие-либо стандарты для выбора того, что вы помещаете в какой класс?-Ссылки тоже приветствуются.

Спасибо за ваше время.

Answer 1

Возможно, вы захотите взглянуть на твердые принципы или эту статью, чтобы найти некоторые руководящие принципы проектирования. Сначала вы должны спросить об «обязанностях», а затем попытаться распределить их по классам. Попробуйте написать тесты, и вы увидите, что меньшие единицы (с единственной ответственностью) легче тестировать. Если вам нужен юнит, который обрабатывает разные вещи, он может состоять из других (тогда это модератор между меньшими юнитами).

Answer 2

SOLID - это основные принципы, которыми следует руководствоваться при разработке программного обеспечения (если вы хотите создать обслуживаемый и расширяемый продукт).

Первый «запах» говорит вам, что что-то не так - Дублирование . Например. если вы дублируете логику отправки и получения как в клиентском, так и в серверном классах. Таким образом, правильный путь состоит в том, чтобы извлечь эту логику в отдельный класс / классы. Следующий «запах» - сложность . Если вам трудно понять какую-то часть вашего кода - вам следует подумать, как ее упростить (например, извлечь класс подкласса, извлечь метод или даже просто переименовать переменную).

Когда вы определяете обязанности своих классов, старайтесь избегать слова «И», потому что, скорее всего, это «запах» ломающегося SRP (принцип единой ответственности). Например. Этот класс предназначен для отправки пакетов и их шифрования. Кстати, есть классная вещь под названием « crc cards », которая может помочь вам сделать хороший дизайн классов.

НО вы всегда должны думать - вам действительно нужны все эти вещи ( YAGNI - вам это не нужно) - вам нужно это крутое обслуживание и расширяемость, если вы пишете чат для своей бабушки и дедушка.

О вашем случае - в идеальном мире я бы, вероятно, сделал что-то вроде этого:

Клиент, Сервер, Канал (абстракция канала чата, может быть TcpChannel, MSMQChannel и т. Д.), И, возможно, SecureChannel - простой декоратор над основными функциями канала

Answer 3

Прежде всего вы можете сократить свои имена классов, не используя в них слово «класс», это поможет сделать вещи более понятными.

Один из подходов, которым меня учили, состоял в том, чтобы назвать все вещи в вашей системе и попытаться назвать объекты, на которые возложена только одна ответственность - так что сервер, клиент, пакет, EncryptionScheme ... смешивание обязанностей - хороший способ получить вещи запутываются очень легко, а объекты с одной ответственностью намного проще тестировать.

Answer 4

Прежде всего, я возражаю говорить о «ООП в C # Winforms». ООП - это ООП независимо от языка.

Что касается того, где провести черту между классами, попробуйте назначить каждому классу только одну ответственность. Я бы определенно имел отдельный класс шифрования. Я не уверен, что вы намерены делать ServerClass и pHandlerClass, но если он просто обрабатывает данные из входного потока, вызывает класс дешифрования и отправляет его в какой-то бизнес-класс для рендеринга в GUI, звучит так в одном классе. Один "хендлер-класс".

Answer 5

Я бы начал с класса Connection, который может прослушивать порт или подключаться к IP-адресу / порту.Добавьте любой код, необходимый для этого класса, чтобы он работал.

Кроме того, я бы создал два отдельных класса Server и Client.(может быть два отдельных проекта).Они будут устанавливать любой код, который вам нужен для передачи и получения событий из класса Connection.

После этого я добавлю некоторое шифрование в класс Connection, либо заключив его в класс EncryptedConnection, либо расширив ConnectionClass доподкласс.