First of all, to better understand the point of view i'm going to propose, i would invite you to have a look at the following blog post
Not all properties are created equal, talking about Plato's "Existential vs Accidental Properties" applied to software.
For interrupt handling, I came out with two possible solutions, with different implications.
In the first one, they exist two entities the "Interrupt" and the "InterruptHandler". Modeling this scenario in C (simpler to post then UML) it is:
Code: Select all
/**
* The id is an "existential property" of an Interrupt.
*/
struct Interrupt {
uint32 id;
}
/**
* The interrupt that an interrupt handler is design to handle is, instead, an
* "accidental property" for the handler.
*/
struct InterruptHandler {
void (*handle) (struct InterruptHandler* this, struct Interrupt* interrupt);
}
This implies that an user wishing to register his/her own InterruptHandler has to test the Interrupt's id, both to avoid handling unknown interrupts and switching on different interrupts.
Code: Select all
/**
* This handler is able to handle just one interrupt.
*/
void simpleHandler_handle(struct InterruptHandler* this, struct Interrupt* interrupt) {
if ( interrupt != NULL ) {
if ( interrupt->id == HANDLING_INTERRUPT ) {
// TODO: Handle interrupt
} else {
// TODO: Unknown interrupt
}
} else {
// TODO: Panic
}
}
/**
* This one, insted, is designed to handle several interrupts.
*/
void complexHandler_handle( struct InterruptHandler* this, struct Interrupt* interrupt ) {
if ( interrupt != NULL ) {
swtich( interrupt->id ) {
// Handle several interrupts
}
} else {
// TODO: Panic
}
}
Code: Select all
struct InterruptHandler {
uint32 (*getId)();
void (*handle)(struct InterruptHandler* this);
};
uint32 myHandler_id() {
return HANDLING_INTERRUPT;
}
void myHandler_handle( struct InterruptHandler* this ) {
/**
* TODO: Just handle the interrupt, because this handler
* is guaranteed to be invoked on the right interrupt.
* Nevertheless there is no way to handle several interrupts.
*/
}
) where a class has an empty constructor and thousands of setter method. This kind of code, as you know, is hardly maintainable and hardly difficult to understand by someone new to the project. As a rule of thumb an existential property is one you wouldn't forget in your constructors and without setters, so read-only, since modify them will mean modify the modeled entity. An accidental property is, instead, generally left out constructors and editable by setters.
