VB.NET OOP Interface / Implements clarification .. Thank you!

[wildman]

Looking at an asp.net website with a lot of OOP and I am trying to
understand where the benefit of all this might be.


There is a user control with codebehind properties that looks like
this:


Partial Class uc
Inherits System.Web.UI.UserControl
Implements UM.IUIBuildingBlock

Public Property Checked() As Boolean Implements
XX.IUIBuildingBlock.Checked
Get
Return Nothing
End Get
Set(ByVal Value As Boolean)
End Set
End Property
.
==

IUIBuildingBlock.vb looks like this:

Namespace XX

Public Interface IUIBuildingBlock
ReadOnly Property DataType() As XXDataTypes
Property Checked() As Boolean
End Interface

End Namespace

===

XXDataTypes.vb looks like this:

Namespace XX
Public Enum XXDataTypes
[String]
[Integer]
[Double]
[Date]
[DateTime]
[Currency]
[Boolean]
[DropDownList]
[CheckBox]
[RadioButton]
End Enum
End Namespace



Why do you suppose the developer might have gone through all of this?
Rather than just coding like this?

Public Property Checked() As Boolean
Get
Return Nothing
End Get
Set(ByVal Value As Boolean)
End Set
End Property



Thanks for any help or information! Can you explain in lea mans terms
with a simple example of why we would benefit from all this extra
code? Also keeping in mind that my example does not show all the DAL/
BAL code where we create a collection class and object class for every
single table in another probject that was referenced in.

 

[Just Me]

I think your missing the point of interfaces.


An interface is a contract with the caller that the class in which that
interface has been implemented will respond as expected.

The caller does not need to know how this has been handled, simply that it
has. This allows developers to communicate oridnally across a range of
classes independently of their position in the inheritance chain.
Hope that makes sense.

 

[sloan]

http://www.google.com/search?source=ig&hl=en&rlz=&q=code+to+an+interface+not+an+implementation

OO isn't something you can grasp in a few hours.

I'd get a good book. Head First Object Oriented Design and Analyis is a
good one.

Follow the link above. Today, read about 5 of the articles. Tomorrow, read
about 5 of the articles.
3 days from now, read 5 more.
Then about a month of doing OO development, go back and reread them.

I'm not trying to be a butt, just letting you know that it takes a bit to
start to see it.


One of the reasons you write to an interface,..is that one day you can swap
out the implementation completely....and not touch the code that uses the
interface.

Check
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!126.entry
and work through the IAnimal sample.

As the other person mentioned, you don't care about what got called on the
other end (the concrete class), you care that it got called.

That is only one aspect of OO programming.
But that one alone is pretty powerful.

You can write better, more maintainable code.....without alot of "if
clientName="acme" then" stuff in it. Aka, when you write workarounds for
special needs.

Good luck. I encourage you to stay on the road of OO learning.