Question about implementing interfaces and properties

[MrNorth]

I have made a silly test program which works like this(pseudo-code):

Interface IAnimal

sub Eat
sub Sleep
sub Drink
property name as string
property height as integer

I have a class called CAnimal

class CAnimal
private name
private height

get set name
get set height
end class


I have a class that inherits from CAnimal

class CBird : inherits CAnimal
implements IAnimal

'Implement the methods and properties of IAnimal

public sub Fly()
'Make the bird fly
end sub


end class


class CWatcher(byval subject as IAnimal)
Console.Write("The name of the subject is: " & subject.name)
end class



Now, what is the point of all this.. well nothing really, I just made this example to test all the features of vb.net OO, and as you notice there are a few gaps:

1) How can I make the CAnimal class more useful??? It is logical that it should be there but how can I bebefit from it further?

2) How do I make the interface work properly? For example, I don't want the CAnimal Class to implement the methods, only the properties, and the CBird class should only implement the methods because it inherits from CAnimal which implements the properties. Should I create some kind of hierarchy with the interfaces too? I mean, one interface for the animal class, and one interface for the CBird, CWolf, CDog etc...?that only implements the methods that make them unique

3)How do I implement a generic constructor??? What is the best way to implement a constructor in this scenario? I want to use the factory pattern!!


ANyway, I hope someone can take a few minutes to perfect this example, because it really contains almost all features of OO, and I really want to understand this fully...


kind regards
Henrik

[Edneeis]

Its mostly redundent to have an IAnimal interface and a CAnimal base/abstract class. Implementing Interfaces and Inheriting Classes are very similiar in purpose, only one passes along only structure (Interfaces) and the other passes along functionality and structure (inheritance). Another side note of their differences is that since an object can implement mulitple interfaces but only inherit one class. Thus often interfaces relate to a specific functionality but do not necessarily provide the base of a class. For instance ICloneable, IEnumerator, IEnumerable, IDisposable all provide a structure needed to implement a specifc function but do not really describe the purpose of the object that implements them. I mean you don't have a Dispose class, instead any class can implement IDisposable to follow the standardized clean up method. Sometimes this isn't true like the case of IDataReader, IDBConnection, IDBCommand which do pretty much embody the class purpose, but with inheritance the latter is always true the base class is always the 'basis' of the class.

Anyway I'm just rambling on now. With an interface you must always implement all of its properties/methods so you can't just implement the properties and not the methods. In the case of animals I would just use the an Animal base class since most of the functionality will be the same for all animals. Most animals drink and sleep the same even if they eat different, so you can provide a sort of 'default' functionality for all animals through the base Animal class. Make properties and methods Overridable so that derived classes can change them.

Public MustInherit Class Animal
 
    Public Enum Sizes
        Tiny
        Small
        Medium
        Large
        Giant
    End Enum
 
    'if you don't want to provide functionality for something
    'just make it mustinherit
    Public MustOverride ReadOnly Property Name() As String
    Public MustOverride ReadOnly Property Size() As Sizes
 
    'provide base functionality but with the option to override
    Public Overridable Sub Eat()
        MsgBox("Chew, chew, chew...")
    End Sub
 
    Public Overridable Sub Sleep()
        MsgBox("Zzzzzz")
    End Sub
 
    Public Overridable Sub Drink()
        MsgBox("Gulp!")
    End Sub
 
End Class
 
Public Class BirdAnimal
    Inherits Animal
 
    Public Overrides ReadOnly Property Name() As String
        Get
            Return "Bird"
        End Get
    End Property
 
    Public Overrides ReadOnly Property Size() As Animal.Sizes
        Get
            Return Animal.Sizes.Small
        End Get
    End Property
 
    Public Sub Fly()
        MsgBox("Flap, flap, flap")
    End Sub
 
End Class
 
Public Class BearAnimal
    Inherits Animal
 
    Public Overrides ReadOnly Property Name() As String
        Get
            Return "Bear"
        End Get
    End Property
 
    Public Overrides ReadOnly Property Size() As Animal.Sizes
        Get
            Return Animal.Sizes.Large
        End Get
    End Property
 
    'change functionality
    Public Overrides Sub Sleep()
        MsgBox("Shhh..I'm hibernating!")
    End Sub
 
End Class

[MrNorth]

That was a really great response! I do however wonder about the interface... Should the CAnimal class implement the interface? IAnimal?


kind regards
henrik

[Edneeis]

If you still wanted to use an Interface than I would have Animal implement it yes. Although since the base class already provides the structure (and the functionality) then it is redundant to have both an Interface and an Abstract/Base class.

Also in regards to a generic constructor, constructors are not passed with inheritance. A derived class can call its base class' constructor but the constructor itself (with any arguments) must be manually recreated in the derived class.

The factory pattern is great when you want tight controll over the creation of an object type. A good example of this is the DataRow in a DataTable. It is intended to be created via the parent objects (DataTable, DataSet) and thus has no default constructor but must be passed in the parent, builder object. Another example is the XMLNode or XMLElement, XMLAttribute classes, which must be created from the XMLDocument object. Generally, but not always, a factory pattern is helpful to ensure an object that requires a specific or controlled heirarchy. The main place I use the factory pattern is in remoting. Sometimes in remoting you can not pass arguments to the remote object's constructor so I often make the remote object just a factory that gets passed arguments in methods to create other objects.

[MrNorth]

Ok... most books I have read has always used the interface approach when different classes should share similar functionality.

With "your" approach , I pass a CAnimal object to whatever method that will perform something on for example a CBirdAnimal object.

If I have an object that will interact with any of these objects, like a human object that should feed the animal. Is the correct way to implement that (if the eat method perform some action on the object, like raising it's life property o whatever:

class human()
 
public sub FeedAnimal(byval animal as CAnimal, byval howmuchfood as integer)
   animal.eat(howmuchfood)
end sub
 
end class

"my" approach would have been to pass an interface that implements the eat method for any kind of animal... but your approach works the same way, just a different thinking pattern correct? Working with the abstract base class instead of the interface...

I fully understand how abstract classes, interfaces works, it is how to apply them I find a bit difficult... when to do this, when to do that... thats why I have taken interest in the GOF patterns... they help me a lot, but not always...

Speaking of patterns, is there any pattern that deal with this? It is a fashinating subject I think...

kind regards
Henrik

[MrNorth]

No ideas?

[Edneeis]

The two ways (using an interface and an abstract class) are ALMOST identical and both will work fine. When you would use one over the other is answered by the question of Do you want to provide 'default' functionality to each object? If the answer is yes then use inheritance, if no then use an interface. So if the content of each objects eat method is going to be the same then use a base class, since it can pass along that same code and cuts out repeatative code. If the content of the eat method is going to be different on most of the objects then use an interface since it just dictates that there IS an eat method not what it does.

Speaking of patterns, is there any pattern that deal with this? It is a fashinating subject I think...

That deals with what exactly?

[Memnoch1207]

Object-Oriented Design Patterns

[MrNorth]

That deals with how to make method implementations...


I have read that book a few times... I know C++ quite good, but smalltalk wasn't that interesting Anyway, I am really looking for books that show how I can implement the patterns in real life applications, both small and enterprise... and in .NET of course :

thanks for your explanations


Oh, can you tip me of a good book that covers design with UML from the beginning to advanced? I don't want a reference bible on UML, rather "applied UML" where for example the author will design an asp.net database driven application (the classic webshop) and uses UML and patterns to make the design...


yours/Henrik