2013-06-13 5 views
0

У меня есть класс, который добавляет некоторые функциональные возможности в текстовое поле формы Windows. Например, он обрабатывает событие с ключевым словом keybox и основан на какой-то логике, если было нажато «Enter», появится специальная сетка, позволяющая пользователю выбрать один объект из большого числа объектов. Поэтому я называю этот класс «Textbox Extender» и текстовое поле «Extended».Одинокий принцип ответственности, нарушенный или нет

Теперь я хочу сообщить пользователю, что, если текстовое поле расширено, изменив его цвет назад, довольно легко добавить эту функциональность в класс BUT: Я очень подозрительно, что это против принципа единой ответственности. Любая идея высоко ценится.

ответ

0

Не против ssr. Ваша ответственность за класс состоит в том, чтобы расширить функциональность textbox.

+0

Но теперь у него есть две обязанности: расширение текстового поля, изменение цвета backcolor. Возможно, завтра меняем шрифт. Еще один день изменил forecolor. Каков ваш идеал? – Alireza

+1

Hah! Затем подумайте о обычном текстовом поле - у него есть ZILLIIONS обязанностей: нажмите кнопку «a», нажмите «символ», нажмите кнопку «b», напечатайте символ «b» и т. Д. – athabaska

+0

Я думаю, что в вашем случае вы можете более широкий взгляд на то, что несет ответственность. Кроме того, в конце дня вы хотите работать с рабочим приложением, а не с приложением, которое удовлетворяет всем правилам «правильной разработки», но не работает. – athabaska

0

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

+0

Что вы подразумеваете под «Anyway capsuling UI от объекта пользовательского интерфейса, похоже, слишком сложно». В классе расширителя ничего не закрывается. – Alireza

+0

вы хотели изменить свой интерфейс, теперь, если бы это было против srp, это означало бы, что вам придется поместить его в другой класс. И изменение пользовательского интерфейса вашего текстового поля из другого класса, а не самого себя, кажется бесполезной работой. – Master117