Информация об изменениях

Сообщение Re[3]: Как назвать библиотеку для взаимодействия со сторонни от 06.01.2015 18:40

Изменено 06.01.2015 18:47 __kot2

Здравствуйте, ., Вы писали:
.>По приведённому топикстартером описанию больше подходит Facade:
.>

.> * make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;
.> * make the library more readable, for the same reason;
.> * reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system;
.> * wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).

да, возможно.

есть 4 варианта. 3 из википедии. один — от меня

Adapter Converts one interface to another so that it matches what the client is expecting
Decorator Dynamically adds responsibility to the interface by wrapping the original code
Facade Provides a simplified interface
Proxy — ведет себя как другой обьект

Decorator и Proxy это не сюда

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

Адаптер — не про систему целиком, а про один конкретный интерфейс

возможно я бы выбрал просто название Service. почему нет? мы хотим сервис — вот и сервис. а что он там делает внутри — нам не интересно
Здравствуйте, ., Вы писали:
.>По приведённому топикстартером описанию больше подходит Facade:
.>

.> * make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;
.> * make the library more readable, for the same reason;
.> * reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system;
.> * wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).

да, возможно.

есть 4 варианта. 3 из википедии. один — от меня

Adapter Converts one interface to another so that it matches what the client is expecting
Decorator Dynamically adds responsibility to the interface by wrapping the original code
Facade Provides a simplified interface
Proxy — ведет себя как другой обьект

Decorator и Proxy это не сюда

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

Адаптер — не про систему целиком, а про один конкретный интерфейс

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