Skip to content

Commit dd3bb60

Browse files
feat: implement device interfaces and development guidelines for issue #25 (#30)
Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
1 parent 2a38af2 commit dd3bb60

13 files changed

+1047
-67
lines changed

.cursor/rules

Lines changed: 184 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,184 @@
1+
# DAQiFi Core - Cursor AI Rules
2+
3+
## Project Context
4+
You are working on the DAQiFi Core library - a .NET library that provides foundational interfaces and implementations for interacting with DAQiFi hardware devices. This library serves as the core foundation that will be used by desktop applications, web services, and other DAQiFi software.
5+
6+
## Architecture & Patterns
7+
8+
### Device Interface Pattern
9+
- All device classes should implement `IDevice` or `IStreamingDevice` interfaces
10+
- Use event-driven architecture with `StatusChanged` and `MessageReceived` events
11+
- Implement virtual methods that can be overridden for testing and customization
12+
- Use generic `Send<T>(IOutboundMessage<T>)` methods for type safety
13+
14+
### Message System
15+
- All outbound messages implement `IOutboundMessage<T>` with strongly-typed data payloads
16+
- All inbound messages implement `IInboundMessage<T>`
17+
- Use `ScpiMessageProducer` for creating SCPI command messages
18+
- Support multiple message formats: SCPI strings, Protocol Buffers, JSON
19+
20+
### Connection Management
21+
- Use `ConnectionStatus` enum for device states: Disconnected, Connecting, Connected, Lost
22+
- Implement connection state transitions with proper event notifications
23+
- Always check `IsConnected` before sending messages
24+
- Throw `InvalidOperationException` for operations on disconnected devices
25+
26+
## Code Style & Standards
27+
28+
### C# Conventions
29+
- Use nullable reference types (`#nullable enable`)
30+
- Prefer `var` only when type is obvious from right-hand side
31+
- Use expression-bodied members for simple properties and methods
32+
- Follow Microsoft C# naming conventions (PascalCase for public members, camelCase for private)
33+
34+
### Documentation
35+
- ALL public classes, interfaces, and members MUST have XML documentation
36+
- Use `<summary>`, `<param>`, `<returns>`, `<exception>` tags appropriately
37+
- Include code examples in documentation for complex APIs
38+
- Document thread safety characteristics
39+
- Use `<see cref=""/>` for cross-references
40+
41+
### Error Handling
42+
- Use specific exception types (`InvalidOperationException`, `ArgumentException`, etc.)
43+
- Include clear, actionable error messages
44+
- Document all exceptions that public methods can throw
45+
- Validate parameters and throw appropriate exceptions early
46+
47+
### Testing Patterns
48+
- Create testable versions of classes using inheritance and virtual methods
49+
- Use `TestableDaqifiDevice` pattern for mocking device behavior
50+
- Test all public methods, properties, and events
51+
- Include tests for error conditions and edge cases
52+
- Use meaningful test method names: `MethodName_Scenario_ExpectedResult`
53+
54+
## Naming Conventions
55+
56+
### Classes & Interfaces
57+
- Device interfaces: `IDevice`, `IStreamingDevice`, `IDiscoveryService`
58+
- Device implementations: `DaqifiDevice`, `DaqifiStreamingDevice`
59+
- Event args: `DeviceStatusEventArgs`, `MessageReceivedEventArgs`
60+
- Message types: `ScpiMessage`, `ProtobufMessage`
61+
- Producers: `ScpiMessageProducer`, `DeviceDiscoveryService`
62+
63+
### Methods & Properties
64+
- Connection methods: `Connect()`, `Disconnect()`, `IsConnected`
65+
- Messaging: `Send<T>()`, `OnMessageReceived()`
66+
- Events: `StatusChanged`, `MessageReceived`, `DeviceDiscovered`
67+
- Status: `Status`, `ConnectionStatus`, `IsStreaming`
68+
69+
## File Organization
70+
```
71+
src/Daqifi.Core/
72+
├── Device/ # Device interfaces and implementations
73+
├── Communication/ # Message types and producers
74+
│ ├── Messages/ # IOutboundMessage, IInboundMessage implementations
75+
│ └── Producers/ # Message factory classes
76+
├── Discovery/ # Device discovery services (future)
77+
└── Connection/ # Connection management (future)
78+
```
79+
80+
## Multi-Targeting
81+
- Target both .NET 8.0 and .NET 9.0
82+
- Use `#if` directives sparingly and only for platform-specific code
83+
- Prefer feature detection over version detection
84+
- Test on both target frameworks
85+
86+
## Hardware Domain Knowledge
87+
88+
### DAQiFi Device Types
89+
- Basic devices: Connection, messaging, status monitoring
90+
- Streaming devices: Add real-time data acquisition capabilities
91+
- Discovery: Network scanning, mDNS, USB enumeration
92+
93+
### Communication Protocols
94+
- SCPI (Standard Commands for Programmable Instruments)
95+
- Protocol Buffers for binary data
96+
- TCP/UDP for network communication
97+
- USB for direct connection
98+
99+
### Device Operations
100+
- Connection lifecycle: Discover → Connect → Configure → Stream → Disconnect
101+
- Status monitoring: Connection health, error states, device capabilities
102+
- Message flow: Commands (outbound) → Responses (inbound)
103+
- Streaming: Start/stop, frequency control, data consumption
104+
105+
## Best Practices
106+
107+
### Performance
108+
- Use async/await for I/O operations
109+
- Implement proper disposal patterns for connections
110+
- Consider connection pooling for multiple devices
111+
- Buffer streaming data appropriately
112+
113+
### Threading
114+
- Document thread safety of all public APIs
115+
- Use locks judiciously and avoid deadlocks
116+
- Consider using `ConcurrentCollections` for shared state
117+
- Event handlers should be thread-safe
118+
119+
### Extensibility
120+
- Use interfaces for dependency injection
121+
- Make methods virtual when inheritance is expected
122+
- Provide clear extension points for custom implementations
123+
- Support plugin architectures where appropriate
124+
125+
## Code Examples
126+
127+
### Device Implementation Template
128+
```csharp
129+
/// <summary>
130+
/// Represents a [specific device type] that [brief description].
131+
/// </summary>
132+
public class CustomDevice : DaqifiDevice, ICustomInterface
133+
{
134+
/// <summary>
135+
/// Initializes a new instance of the <see cref="CustomDevice"/> class.
136+
/// </summary>
137+
/// <param name="name">The device name.</param>
138+
/// <param name="ipAddress">The device IP address.</param>
139+
public CustomDevice(string name, IPAddress? ipAddress = null)
140+
: base(name, ipAddress)
141+
{
142+
}
143+
144+
/// <summary>
145+
/// Custom operation specific to this device type.
146+
/// </summary>
147+
/// <exception cref="InvalidOperationException">Thrown when device is not connected.</exception>
148+
public void CustomOperation()
149+
{
150+
if (!IsConnected)
151+
throw new InvalidOperationException("Device is not connected.");
152+
153+
// Implementation
154+
}
155+
}
156+
```
157+
158+
### Test Method Template
159+
```csharp
160+
[Fact]
161+
public void MethodName_WhenCondition_ShouldExpectedBehavior()
162+
{
163+
// Arrange
164+
var device = new TestableDevice("TestDevice");
165+
166+
// Act
167+
var result = device.MethodName();
168+
169+
// Assert
170+
Assert.Equal(expectedValue, result);
171+
}
172+
```
173+
174+
## Integration Guidelines
175+
- This library will be consumed by `daqifi-desktop` and other applications
176+
- Maintain backward compatibility within major versions
177+
- Consider migration paths when making breaking changes
178+
- Provide clear upgrade documentation
179+
180+
## Git Conventions
181+
- Feature branches: `feature/descriptive-name`
182+
- Commit messages: `feat:`, `fix:`, `docs:`, `test:`, `refactor:`
183+
- Include issue numbers: `feat: implement device discovery (#123)`
184+
- Keep commits focused and atomic

0 commit comments

Comments
 (0)