Здравствуйте собратья по ремеслу. Хочу обратится к вам за советом, или слово утишительное от вас услышать. Я только недавно начал изучать патерны проектирования и очень злюсь на себя за то что очень долго игнорировал их существования. ну что поделаеш самаучка, нет наставника, некому правельный путь показать, стараюсь как могу и черпаю нужные знания и темы то из одной литературы то из другой. ну вот и наткнулся както на патеррны проектирования но не совсем спелым тогда видать был . Но судьба не отвернулась от меня и мне представилась вожможность снова пересечся с патернами. на этот раз я с первого прекосновения влюбился вних и ненасытно поглошяю мудрость которую они извергают. Какбы во все вник, вроде во всем разобрался, принцип на ус намотал, но вот досада, потерялся в том изобилий прелести и выбора которые паттерны мне предложили. Я уверен вы тоже через ето проходили , теже чуства, теже приграды на пути к созданию совершенного кода. может поделитесь опытом, поможете обойти колючки, наставите на путь правильный. Тутже для наглядности моего восприятия патернов я привожу пример того как я их понимаю. И так у меня стойт задача для конкретной фирмы реализовать пользовательский кабинет. пользователи делятся на три типа (во всяком случае на данном этапе) индивидуальные клиенты, юридическйе лица и корпоративные клиенты. У первих двух типов очень много сходств в методах и поведениях (надеюсь не трудно будеть прикинуть какие) что вынуждает мения склонится к приминению шаблонного метода! Правелен ли мой выбор? или есть патерн более родсвенный токому типу задания. Поправьте мения, посоветуйте, намекните почему ? Третий тип клиентов тоже имеет весомое сходство спредидущими типами, но помимо сходсва он должен обеспечить ваборочный функционал для клиента, тоесть менять функционал на свой лад, прятать различный функионал или по желанию вновь отображать. Также должно быть учтенно дальнейшее развитие функциональных возможностей. Я прекрасно отдою себе отчет в том что я должен вооружится композицией вместо наследования, инкапсуляцией изменяюшихся частей классов, возвести впочести принцып создания классов на основе интерфейсов, не допустить сильную взаимосвязь между объектами и вдобавок зделать классы дружественными к расширению и закрытими для изменения, обеспечить зависимость кода от обстракций, а не от конкретных классов. К моему изумлению понимая все это я все равно умудрился запутатся в этом изобилий прекраснейших помошников. зараанее всем спасибо за дельные отзывы.
Нет framework не изучал, кстати уже посоветовали в эту сторону копать, видать метод хорошо опробован, так что заметано буду изучать. Спасибо за помощь, к стати какой именно framework вы бы посоветовали.