Some like to think of an interface like it's owned by the class that implements it.
Some like to think of an interface like it's owned by the client that uses it.
For the first time I'm starting to think either can be true.
It is true. The difference lies in semantics.
Interface owned by its own class
The core is: EVERY class has an interface aside the language construct "interface". The problem is: Sometimes it is not beneficial.
If you have a class in JAVA sometimes it is hard to ensure encapsulation. Therefore you hide the class behind an "interface" language construct.
The separate interface of a class is only an extraction of the interface the class already implicitly has. You can compare it to the header file in the programming language "C" where it provides perfect encapsulation.
In JAVA it is a helper construct which is not enforced. So nothing hinders you to use the concrete class implementation instead of the interface. In "C" you only make the header files known to other compilation units (I hope so, as I am not a C-developer).
Interface owned by the framework
The other way around: A framework provides functionality. To let your object cooperate with the framework they have to meet some requirements that are formulated as "interface" language constructs.
Here comes the complicatetcomplicated thing:
You may have a class with an extracted alternative interface AND you want to have a contract to work together with a framework. Then you have two interfaces with different semantics to handle.
The clean architecture
If you consequently follow the SOLID principle it will guide you to exact this architecture. You have no chance to miss it.
Your code
In general I do not think that pressing a button is a usecase but I think you have a correct reference implementation of clean architecture.
Some like to think of an interface like it's owned by the class that implements it.
Some like to think of an interface like it's owned by the client that uses it.
For the first time I'm starting to think either can be true.
It is true. The difference lies in semantics.
Interface owned by its own class
The core is: EVERY class has an interface aside the language construct "interface". The problem is: Sometimes it is not beneficial.
If you have a class in JAVA sometimes it is hard to ensure encapsulation. Therefore you hide the class behind an "interface" language construct.
The separate interface of a class is only an extraction of the interface the class already implicitly has. You can compare it to the header file in the programming language "C" where it provides perfect encapsulation.
In JAVA it is a helper construct which is not enforced. So nothing hinders you to use the concrete class implementation instead of the interface. In "C" you only make the header files known to other compilation units (I hope so, as I am not a C-developer).
Interface owned by the framework
The other way around: A framework provides functionality. To let your object cooperate with the framework they have to meet some requirements that are formulated as "interface" language constructs.
Here comes the complicatet thing:
You may have a class with an extracted alternative interface AND you want to have a contract to work together with a framework. Then you have two interfaces with different semantics to handle.
The clean architecture
If you consequently follow the SOLID principle it will guide you to exact this architecture. You have no chance to miss it.
Your code
In general I do not think that pressing a button is a usecase but I think you have a correct reference implementation of clean architecture.
Some like to think of an interface like it's owned by the class that implements it.
Some like to think of an interface like it's owned by the client that uses it.
For the first time I'm starting to think either can be true.
It is true. The difference lies in semantics.
Interface owned by its own class
The core is: EVERY class has an interface aside the language construct "interface". The problem is: Sometimes it is not beneficial.
If you have a class in JAVA sometimes it is hard to ensure encapsulation. Therefore you hide the class behind an "interface" language construct.
The separate interface of a class is only an extraction of the interface the class already implicitly has. You can compare it to the header file in the programming language "C" where it provides perfect encapsulation.
In JAVA it is a helper construct which is not enforced. So nothing hinders you to use the concrete class implementation instead of the interface. In "C" you only make the header files known to other compilation units (I hope so, as I am not a C-developer).
Interface owned by the framework
The other way around: A framework provides functionality. To let your object cooperate with the framework they have to meet some requirements that are formulated as "interface" language constructs.
Here comes the complicated thing:
You may have a class with an extracted alternative interface AND you want to have a contract to work together with a framework. Then you have two interfaces with different semantics to handle.
The clean architecture
If you consequently follow the SOLID principle it will guide you to exact this architecture. You have no chance to miss it.
Your code
In general I do not think that pressing a button is a usecase but I think you have a correct reference implementation of clean architecture.
Some like to think of an interface like it's owned by the class that implements it.
Some like to think of an interface like it's owned by the client that uses it.
For the first time I'm starting to think either can be true.
It is true. The difference lies in semantics.
Interface owned by its own class
The core is: EVERY class has an interface aside the language construct "interface". The problem is: Sometimes it is not beneficial.
If you have a class in JAVA sometimes it is hard to ensure encapsulation. Therefore you hide the class behind an "interface" language construct.
The separate interface of a class is only an extraction of the interface the class already implicitly has. You can compare it to the header file in the programming language "C" where it provides perfect encapsulation.
In JAVA it is a helper construct which is not enforced. So nothing hinders you to use the concrete class implementation instead of the interface. In "C" you only make the header files known to other compilation units (I hope so, as I am not a C-developer).
Interface owned by the framework
The other way around: A framework provides functionality. To let your object cooperate with the framework they have to meet some requirements that are formulated as "interface" language constructs.
Here comes the complicatet thing:
You may have a class with an extracted alternative interface AND you want to have a contract to work together with a framework. Then you have two interfaces with different semantics to handle.
The clean architecture
#The clean architecture IfIf you consequently follow the SOLID principle it will guide you to exact this architecture. You have no chance to miss it.
Your code
In general I do not think that pressing a button is a usecase but I think you have a correct reference implementation of clean architecture.
Some like to think of an interface like it's owned by the class that implements it.
Some like to think of an interface like it's owned by the client that uses it.
For the first time I'm starting to think either can be true.
It is true. The difference lies in semantics.
Interface owned by its own class
The core is: EVERY class has an interface aside the language construct "interface". The problem is: Sometimes it is not beneficial.
If you have a class in JAVA sometimes it is hard to ensure encapsulation. Therefore you hide the class behind an "interface" language construct.
The separate interface of a class is only an extraction of the interface the class already implicitly has. You can compare it to the header file in the programming language "C" where it provides perfect encapsulation.
In JAVA it is a helper construct which is not enforced. So nothing hinders you to use the concrete class implementation instead of the interface. In "C" you only make the header files known to other compilation units (I hope so, as I am not a C-developer).
Interface owned by the framework
The other way around: A framework provides functionality. To let your object cooperate with the framework they have to meet some requirements that are formulated as "interface" language constructs.
Here comes the complicatet thing:
You may have a class with an extracted alternative interface AND you want to have a contract to work together with a framework. Then you have two interfaces with different semantics to handle.
#The clean architecture If you consequently follow the SOLID principle it will guide you to exact this architecture. You have no chance to miss it.
Your code
In general I do not think that pressing a button is a usecase but I think you have a correct reference implementation of clean architecture.
Some like to think of an interface like it's owned by the class that implements it.
Some like to think of an interface like it's owned by the client that uses it.
For the first time I'm starting to think either can be true.
It is true. The difference lies in semantics.
Interface owned by its own class
The core is: EVERY class has an interface aside the language construct "interface". The problem is: Sometimes it is not beneficial.
If you have a class in JAVA sometimes it is hard to ensure encapsulation. Therefore you hide the class behind an "interface" language construct.
The separate interface of a class is only an extraction of the interface the class already implicitly has. You can compare it to the header file in the programming language "C" where it provides perfect encapsulation.
In JAVA it is a helper construct which is not enforced. So nothing hinders you to use the concrete class implementation instead of the interface. In "C" you only make the header files known to other compilation units (I hope so, as I am not a C-developer).
Interface owned by the framework
The other way around: A framework provides functionality. To let your object cooperate with the framework they have to meet some requirements that are formulated as "interface" language constructs.
Here comes the complicatet thing:
You may have a class with an extracted alternative interface AND you want to have a contract to work together with a framework. Then you have two interfaces with different semantics to handle.
The clean architecture
If you consequently follow the SOLID principle it will guide you to exact this architecture. You have no chance to miss it.
Your code
In general I do not think that pressing a button is a usecase but I think you have a correct reference implementation of clean architecture.
Some like to think of an interface like it's owned by the class that implements it.
Some like to think of an interface like it's owned by the client that uses it.
For the first time I'm starting to think either can be true.
It is true. The difference lies in semantics.
Interface owned by its own class
The core is: EVERY class has an interface aside the language construct "interface". The problem is: Sometimes it is not beneficial.
If you have a class in JAVA sometimes it is hard to ensure encapsulation. Therefore you hide the class behind an "interface" language construct.
The separate interface of a class is only an extraction of the interface the class already implicitly has. You can compare it to the header file in the programming language "C" where it provides perfect encapsulation.
In JAVA it is a helper construct which is not enforced. So nothing hinders you to use the concrete class implementation instead of the interface. In "C" you only make the header files known to other compilation units (I hope so, as I am not a C-developer).
Interface owned by the framework
The other way around: A framework provides functionality. To let your object cooperate with the framework they have to meet some requirements that are formulated as "interface" language constructs.
Here comes the complicatet thing:
You may have a class with an extracted alternative interface AND you want to have a contract to work together with a framework. Then you have two interfaces with different semantics to handle.
#The clean architecture If you consequently follow the SOLID principle it will guide you to exact this architecture. You have no chance to miss it.
Your code
In general I do not think that pressing a button is a usecase but I think you have a correct reference implementation of clean architecture.