Вы можете использовать API Get Commits с необязательным параметром searchCriteria.includeWorkItems=true
, вы получите все коммиты со связанными с ними рабочими элементами.
Например:
https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repoId}/commits?searchCriteria.includeWorkItems=true&?api-version=5.0-preview.1
Результаты (вы получите все коммиты, вы можете отфильтровать результаты с помощью PowerShell):
"commitId": "60a69554c80839d631e77ea0exxxxxxxxxxx",
"author": {
"name": "Shayki Abramczyk",
"email": "email@gmail.com",
"date": "2018-10-11T14:27:55Z"
},
"committer": {
"name": "Shayki Abramczyk",
"email": "email@gmail.com",
"date": "2018-10-11T14:27:55Z"
},
"comment": "Updated README.md",
"changeCounts": {
"Add": 0,
"Edit": 1,
"Delete": 0
},
"url": "https://dev.azure.com/shaykia/7fcdafd5-b891-4fe5-b2fe-xxxxxxxxxx/_apis/git/repositories/815cc0c7-5f3e-404b-8fd7-xxxxxx/commits/60a69554c80839d631e77eaxxxxxxxx",
"remoteUrl": "https://dev.azure.com/shaykia/xxxxxxx/_git/GitSample/commit/60a69554c80839d631e77ea0ed8bxxxxxxxx",
"workItems": [
{
"id": "18",
"url": "https://dev.azure.com/shaykia/_apis/wit/workItems/18"
}
]
},
К сожалению, эта опция не существует в Get (one) Commit API.
Objective-C имеет концепцию протокола , который является спецификацией интерфейса. Через Протоколы Objective-C полностью поддерживает множественное наследование спецификации (но не реализацию). Таким образом, немного странно, что синтаксис @interface фактически определяет класс (реализацию), который поддерживает только одиночное наследование, но может указывать реализацию множественного / множественного наследования протоколов или спецификаций интерфейсов. В конце концов, это очень похоже на природу на Java.
Например:
@protocol SomeInterface
- (void)interfaceMethod1;
- (void)interfaceMethod2;
@end
@interface SomeClass:NSObject <SomeInterface>
@end
@interface AnotherClass:NSObject <SomeInterface>
@end
Экземпляры SomeClass
или AnotherClass
утверждают, что они обеспечивают реализацию, требуемую для протокола SomeInterface
.
Objective-C имеет динамическую типизацию и не требует, чтобы объект фактически определял сообщение, отправляемое ему. Другими словами, вы можете без разбора вызывать любой метод на SomeClass
, независимо от того, указан он в его интерфейсе или в любом из его протоколов или , а не (не то чтобы это обязательно было продуктивным или позитивным занятием).
Следовательно, все последующее будет компилироваться (хотя и с предупреждениями) и работать нормально, хотя сообщения / методы без реализации в этом случае в основном не работают. Objective-C имеет довольно сложный (и очень крутой) процесс обработки вызова / пересылки методов, который немного выходит за рамки этого вопроса.
SomeClass * someObject = [[SomeClass alloc] init;
[someObject someUnspecifiedMethod]; // Compiles with warning - no op
[someObject interfaceMethod1];
Если вы хотите определить что-то, что может быть любого класса ( @interface ), но реализует определенный интерфейс ( @protocol ), вы можете использовать что-то вроде этого :
id <SomeInterface> obj;
obj
может содержать объект SomeClass
или AnotherClass
.
(Если вы проголосуете, пожалуйста, проголосуйте за Романа - его ответ был первым, он правильный, просто не хватало примера).
Вы говорите о кластере классов . Для примера посмотрите на класс NSString .
Существует NSString:
@interface NSString : NSObject
И NSMutableString:
@interface NSMutableString : NSString
Оба из них объявляют чрезвычайно маленький набор методов в объявлении основного класса . Если бы вам пришлось создать подкласс NSString для реализации вашего собственного строкового класса, вам понадобилось бы реализовать только эти основные методы . Все другие методы, реализованные в NSString, реализованы в терминах этих основных методов . И, аналогично, методы мутации реализуются с использованием примитивных методов, объявленных в ядре NSMutableString.
Теперь, очевидно, реализация всей изменчивости через - (void)replaceCharactersInRange:(NSRange)range withString:(NSString *)aString
(одноядерный метод) была бы крайне неэффективной. Таким образом, во время выполнения вы заметите, что у вас никогда не будет экземпляра NSString или NSMutableString , а только экземпляры подклассов (которые на самом деле не являются подклассами ... но они могут также быть в контексте этого обсуждения).
И эти подклассы - класс реализации, используемый во время выполнения - переопределяют почти все методы NSString и NSMutableString, чтобы обеспечить высоко оптимизированные реализации конкретных операций.
Итак, вы должны сделать что-то вроде:
@interface MyAbstractClass : NSObject
... declare factory methods here ...
... declare core methods here ...
@end
@interface MyAbstractClass(AdditionalFunctionality)
... declare convenience here ...
@end
Затем, в реализации, реализовать все основные методы как @throw @"Must use subclass"
и все AdditionalFunctionality
методы в терминах основных методов.
Это может быть полностью приватно - даже не в заголовке: даже
@interface MyStackClass: MyAbstractClass @end
@implementation MyStackClass ... реализовать основные методы и переопределить методы дополнительной функциональности, которые нуждаются в оптимизации ... @end
Повторите для ваших дополнительных типов классов. Затем реализуйте фабричные методы в MyAbstractClass, которые при необходимости возвращают экземпляры подклассов.
То есть, например, вот так:
@interface MasterViewController :
UIViewController <GKPeerPickerControllerDelegate,
GKSessionDelegate,
UITextFieldDelegate,
UITableViewDelegate,
AVAudioRecorderDelegate> {
}
Возможно, вам стоит попробовать шаблон Какао под названием Class Cluster .Чтобы начать его использовать, вам необходимо создать открытый класс с именем SomeClass
и два частных подкласса SomeArrayClass
и SomeStackClass
. Когда вам нужно использовать стек, ваш конструктор открытого класса создаст экземпляр SomeStackClass
и вернет его как общедоступный экземпляр SomeClass
.