Я просто пишу сегодня вечером, чтобы получить отзывы от некоторых из вас более опытных архитекторов.Я только начинаю больше использовать интерфейсы ... уже опытный и знаю абстрактные классы, которые я использовал в своих собственных довольно симпатичных проектах.
В любом случае, я создал хак UML здесь: uml.pdf
Сначала немного о диаграмме:
>> Всеэто свойство, которое не имеет (), что, конечно, является методом
>> Все общедоступно, если не указано личное
>> поля или методы синим цветом подсвечивают дополнительные поля, специфичные для класса, в дополнение к элементам интерфейса
>> Я назвал MainPhotoUpload фабрикой, потому что я вижу, как это сейчас работает ...по крайней мере, на мой взгляд, это фабрика, потому что она захватывает определенный экземпляр службы на основе APIType
>> Два серых класса просто показывают вам, что будут другие Wrappers, которые я создаюпозже для других API, таких как Flickr и Picasa, который будет работать таким же образом ... реализуя эти основные интерфейсы и используя этот шаблон, который я показываю на примере Facebook здесь
>> Свойства, которые вы видите в сервисе, такиекак например FacebookPhotoService ... его свойство FacebookAlbumPhoto представляет экземпляр FacebookAlbumPhoto, поэтому я могу начать работать с ним.Другими словами, он создает для меня экземпляр и представляет его как свойство в FacebookPhotoService .... так что я могу использовать FacebookPhotoService.Свойство FacebookAlbumPhoto для получения экземпляра FacebookAlbumPhoto и начала вызова методов или других членов FacebookAlbumPhoto.Таким образом, сервис - это просто мост, позволяющий вам использовать базовые классы-обертки и начать их использовать.
В конечном итоге цель:
1) Создайте как можно больше повторного использования для всех API-оболочек, которые мы создаем в будущем (Facebook, Flickr и т. Д.), Относящихся к конкретной функции Photo, которая входит в объем этой модели
2) Внедрите шаблон для любого API, который мы реализуем, чтобы все они были в некоторой степени согласованы, по крайней мере, с основными членами, которые вы увидите в любом Photo API.например, IPhoto, а остальные интерфейсы обозначают общие свойства и методы, которые вы увидите в любом API Photo, например:
3) Способ в конечном счете вызывать методы-оболочки, а такжечтобы получить текущий сеанс для этого APIn или получить другие объекты Facebook, вызывая методы для этих объектов (например, FacebookAlbumPhoto и т. д.).Так, например, в Facebook я хочу иметь возможность вызывать методы facebook для определенного класса или косвенно получать доступ к свойствам определенного класса с помощью службы.Основной сервис действует как Фабрика, которая выходит и получает правильный сервис.Затем вы используете этот сервис, чтобы в конечном итоге начать вызывать методы и использовать базовые классы-оболочки (такие как FacebookAlbumPhoto и т. Д.)
Так вот, что я придумал.Вы увидите на странице 2 некоторые примеры того, как я предполагаю, что они будут позже использованы в коде для нашей бизнес-логики.
Это, конечно, не сделано.
Я хочу знать, что конкретно относится к тому uml, который я создал:
1) Является ли мой подход, по крайней мере, несколько логичным, респектабельным, применимым иимеет какой-то смысл здесь?для меня это так, но я хочу посмотреть, что там думают другие архитекторы.Я имею в виду, что я не ищу здесь совершенства ... просто что-то достаточно гибкое, и на данный момент работает и позволяет мне использовать различные сервисы, и то, как я использую эти сервисы, имеет смысл (то есть наличие свойств в этих сервисах, которыевыставить экземпляры подклассов)
2) Любые советы по улучшению или изменению этого без чрезмерного сумасшествия (мне не нужно знать о 5 шаблонах проектирования, как я могу улучшить это ... просто дайте мне несколько основных советов по интерфейсы, классы обслуживания, такие как мой, или фабрика и т. д., которые относятся к области этого)
3) Все, что я делаю совершенно неправильно, это просто "Никогда не делай этого". Например, мой друг-архитектор говорит, что я создаю здесь интерфейсы, но на самом деле не представляю никакой ценности. Однако для меня это обеспечивает некоторую ценность для обеспечения некоторой согласованности / шаблона и в конечном итоге повторного использования для базовых общностей между любыми обертками Photo API, которые мы создаем позже, а также я использую эти типы интерфейса в других классах позже, таких как свойство MainPhotoService.APIService, которое У меня тип IAPIService типа, потому что я не знаю, какой сервис я вернусь, пока не проверю входящее перечисление APIType в этом конструкторе MainPhotoService.
4) Это действительно "фабричный" паттерн? Является ли мой подход логичным, чистым и расширяемым?
Глядя на это с точки зрения понимания того, что я сейчас только начинаю по-настоящему разбираться в архитектуре жесткого ядра, если бы вы использовали этот код, вам бы а) понравился шаблон ... или хотя бы терпимо на данный момент или у b) есть некоторые проблемы с тем, как я получаю или использую сервис, или как я получаю экземпляры этих базовых классов, или как я использую (мои намерения в используя) Интерфейсы здесь.
если что-то не ясно или отсутствует здесь, пожалуйста, спросите. У меня действительно нет никого, с кем можно было бы отрицать это (нет товарищей по команде разработчиков, а друзья слишком заняты).