Запрос шаблона объектно-ориентированного проектирования

я просмотрел разные вопросы по SO и пытался выяснить, как лучше всего спроектировать приложение. Я обнаружил, что где-то было написано, что мы должны сделать объект класса, если он имеет состояние это.

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

PS ---- мой вопрос может быть непрофессионалом, потому что я новичок, пытающийся изучить/внедрить шаблоны проектирования, поэтому буду рад, если кто-нибудь может предоставить мне материал для чтения, ссылки с примерами.

Теоретически я знаю немного шаблонов проектирования.


oop design-patterns ooad
person Anil Sharma    schedule 10.04.2013    source источник
comment
Как мы можем реализовать какую функциональность? Вы ищете дизайн, который работает независимо от проблемы? Этого не существует.   -  person JB Nizet    schedule 10.04.2013
comment
Если вы сомневаетесь - идите к объекту. В общей практике - если вы создаете какой-либо статический класс, то хорошо, что любая статическая функция внутри статического класса не должна использовать какие-либо параметры/или член вне области действия функции.   -  person dekdev    schedule 11.04.2013
comment
Мне кажется, что вы боретесь с основами. Если вы не можете решить, должно ли что-то быть объектом или должен быть служебный класс, вы не готовы использовать передовые подходы к проектированию, так как не сможете понять, используете ли вы их в правильном контексте, который является обязательным, так как шаблоны проектирования не являются панацеей. Я не говорю, что вы не должны читать о шаблонах и пытаться их использовать, я говорю, что вы не должны относиться к ним как к закону на данном этапе.   -  person Zdeslav Vojkovic    schedule 11.04.2013

Ответы (1)


arrow_upward
6
arrow_downward

Вы читаете руководства и относитесь к ним как к предписаниям, что ставит вас в безвыходное положение при написании кода со слишком строгими правилами.

Рекомендации есть рекомендации, и не более того. Если полезно не использовать служебные классы, то не используйте их слишком часто. Используйте их экономно, где это имеет смысл.

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

Не относитесь к рекомендациям как к закону. Относитесь к ним как к рекомендациям и идите против них, когда это имеет смысл. Вы получите эти знания, только программируя. Так что начните делать это, делайте ошибки, учитесь на этом и улучшайте свой код по ходу дела. Вы не сделаете это идеально с самого начала.

person Bob Horn    schedule 11.04.2013
comment
Проблема с этим подходом заключается в том, что пока вы не заставите себя работать полностью без сети (из статических вещей), вы не научитесь правильно проектировать без них. Я не знаю многих людей, которые научились избегать статики и спешат добавить хотя бы несколько из них обратно. - person Amy Blankenship; 07.05.2013
comment
Обратите внимание, что новичок может быть не в состоянии бросить холодную индейку, но я думаю, что причина, по которой так много разработчиков создают большие комки грязи, заключается в том, что кто-то сказал им что-то похожее на вышеизложенное, и они так и не прошли этап опираясь на статика как костыли. - person Amy Blankenship; 07.05.2013