Technical.DesignByInterface History
Hide minor edits - Show changes to markup - Cancel
The answer to this question can lead to you into different directions. It all depends on what you mean by Interface? and by Design. An interface is something you use to interact with something that can do something for you. This is rather vaque. This website deals with software engineering. As we discussed on the Technical.Technical page, design by interface is a technique used to enable a team to better work together at the same time on different aspects of the system. When not designing by interface you are designing to a concrete class hierarchy. This creates a tight coupling within your application. When designing to interfaces to make it easier to change implementations of some part of the system. If you look at the Persistency? of your application, you can switch from a custom database implementation to one that makes use of hibernate or some other object relational mapping tool?. Another advantage of designing to interfaces is the testability of your application. Since you are using interfaces it is easy to use a Mock object? for the implementation of an object that the object under test uses. This way you can test the functionality of the object without intrusion of other objects.
The answer to this question can lead to you into different directions. It all depends on what you mean by Interface? and by Design. An interface is something you use to interact with something that can do something for you. This is rather vaque. This website deals with software engineering. As we discussed on the Technical page, design by interface is a technique used to enable a team to better work together at the same time on different aspects of the system. When not designing by interface you are designing to a concrete class hierarchy. This creates a tight coupling within your application. When designing to interfaces to make it easier to change implementations of some part of the system. If you look at the Persistency? of your application, you can switch from a custom database implementation to one that makes use of hibernate or some other object relational mapping tool?. Another advantage of designing to interfaces is the testability of your application. Since you are using interfaces it is easy to use a Mock object? for the implementation of an object that the object under test uses. This way you can test the functionality of the object without intrusion of other objects.
One of the issues with designing by interface is that you need a way to provide the right implementation to the class that only knows the interface. One of the most used solutions for this problem is to use the Factory Pattern?. A disadvantage to the factory pattern is that the component that uses the interface now most know the factory object and the method to call. Also the flexibility is less transparent when different objects need different implementations of the interface. Maybe you use different factory objects or you make the methods more intelligent by providing the class name of the caller. This is where the spring framework jumps in. Via spring it is possible to configure a general factory that the object that needs to have the implementation of the interface does not need to be aware of.
Another thing that is tightly integrated with spring and design by interfaces is Inversion Of Control. This makes the object not responsible for the creation of the other objects. Instead the instances are injected by the users of the object. This is enabled by designing by interfaces.
The answer to this question can lead to you into different directions. It all depends on what you mean by interface. An interface is something you use to interact with something that can do something for you. Since this website is about software engineering the interface can we a graphical user interface, but also an interface like used in the Java language. Then the interface is used to talk to an object or system.
(the next part is not what I expected, but it is an interesting point of view. Will be incorporating this view and mine tomorrow) Designing a (virtual) apparatus, starting by using the yet undefined entity. Working inside out from the point of view of the naive user.
That's me.
The design is done to solve a certain problem. To empower me with a given new functionality. Design by interface takes the input strategy (hoe zeg ik dat, de bediening) as its starting point.
- What do I want to happen?
- How would I like to express this wish: by pushing a button, uttering a magic sentence or tapping my left foot?
This way without regard to any technical limits you dream your desired interface. This results in the definition of your ideal interface. And this dream sets the ulimate goal for your development journey, your quest. Getting there is the challenge. To overcome alle technical cliffs and traps along the way... The economical boundarys, the semantical misunderstandings...
to be continued
The answer to this question can lead to you into different directions. It all depends on what you mean by Interface? and by Design. An interface is something you use to interact with something that can do something for you. This is rather vaque. This website deals with software engineering. As we discussed on the Technical.Technical page, design by interface is a technique used to enable a team to better work together at the same time on different aspects of the system. When not designing by interface you are designing to a concrete class hierarchy. This creates a tight coupling within your application. When designing to interfaces to make it easier to change implementations of some part of the system. If you look at the Persistency? of your application, you can switch from a custom database implementation to one that makes use of hibernate or some other object relational mapping tool?. Another advantage of designing to interfaces is the testability of your application. Since you are using interfaces it is easy to use a Mock object? for the implementation of an object that the object under test uses. This way you can test the functionality of the object without intrusion of other objects.
A framework that is build on top of design by interface is the Spring framework. This framework allows you to configure which interface implementation to use via a configuration file. This way it becomes very easy to swap different implementations. For more information about the spring framework look at the Spring framework page.
The promising heading led to an empty page... What else could i do, then answer to my own curiousity?
I hope 'design bij interface' means what i automatically expect:
The answer to this question can lead to you into different directions. It all depends on what you mean by interface. An interface is something you use to interact with something that can do something for you. Since this website is about software engineering the interface can we a graphical user interface, but also an interface like used in the Java language. Then the interface is used to talk to an object or system.
(the next part is not what I expected, but it is an interesting point of view. Will be incorporating this view and mine tomorrow)
+What is Design by Interface?+
What is Design by Interface?
to be done
+What is Design by Interface?+
The promising heading led to an empty page... What else could i do, then answer to my own curiousity?
I hope 'design bij interface' means what i automatically expect: Designing a (virtual) apparatus, starting by using the yet undefined entity. Working inside out from the point of view of the naive user.
That's me.
The design is done to solve a certain problem. To empower me with a given new functionality. Design by interface takes the input strategy (hoe zeg ik dat, de bediening) as its starting point.
- What do I want to happen?
- How would I like to express this wish: by pushing a button, uttering a magic sentence or tapping my left foot?
This way without regard to any technical limits you dream your desired interface. This results in the definition of your ideal interface. And this dream sets the ulimate goal for your development journey, your quest. Getting there is the challenge. To overcome alle technical cliffs and traps along the way... The economical boundarys, the semantical misunderstandings...
to be continued
to be done
