Как должен выглядеть объект?

Question

Я постоянно спорю, как лучше создавать свои классы.

Под этим я подразумеваю, почему мы не всегда создаем класс, который реализует INotifyPropertyChanged и IDataErrorInfo, так что «если» мы хотим, мы можем связывать непосредственно в наших формах, и почему мы не всегда украшаем их атрибутами, чтобы, если мы хотим, чтобы мы могли использовать класс в WCF?

Я имею в виду, помимо очевидного дополнительного кода, и больше тестирование не даст нам большую гибкость?

Я всегда слышу - «создай один раз» и используй «везде», но я также настроен на «ЯГНИ» (тебе это не понадобится).

Полагаю, мой вопрос здесь заключается в том, что идея «бизнес-класса» может быть использована мертвым? и говорим ли мы «создать самое основное», которое работает на данный момент, и опираться на него при необходимости?

R

Answer 1

Я думаю, что обычно лучше сделать ваши классы более сфокусированными на небольшом наборе конкретных задач, чем создавать объекты, которые можно использовать в различных сценариях. Например, у вас могут быть объекты уровня данных, которые имеют все специфические атрибуты / поведения уровня данных, объекты уровня представления со всеми компонентами уровня представления и объекты уровня обслуживания и т. Д.

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

Answer 2

Если вы сделаете это, где вы проведете линию? Собираетесь ли вы сделать все ваши классы исключениями, потому что однажды вы захотите их бросить откуда-нибудь? Собираетесь ли вы сделать их все сериализуемыми?

Еще один способ думать о том, что разработчики языка уже приняли это решение за вас - все классы автоматически наследуются от Object, который содержит все, что нужно «общему» объекту.

Наконец, не путайте повторное использование кода с написанием ненужного кода. В общем, вы должны писать только тот код, который вам нужен прямо сейчас, но проектируйте его так, чтобы его было легко использовать / изменять в будущем.

Answer 3

Прежде всего, программисты ленивы, наша задача - автоматизировать скучные задачи. (нет, я не отрицаю). Обычно мы пишем классы для определенной цели, которая определяет, какие дополнительные биты в нее входят. Вы задаете основной вопрос, на который пытается ответить аспектно-ориентированное программирование. Мой класс - serivce? Является ли мой класс контейнером данных? Наблюдается ли мой класс? Это аспекты, которые ваш класс может включать в себя все эти вещи в зависимости от использования. Или это может быть только один из них.

Answer 4

Я создаю много-много классов, которые очень далеки от интерфейса. Реализация этих интерфейсов каждый раз была бы тяжелым бременем с минимальным вознаграждением.