Hi,

I don't even know if this can be done..

Lets say I have two objects,
---
Public Class Employee

End Class

Public Class Boss : Inherits Employee

End Class

Show quote Hide quote You may want to add a shared method to 'Boss' that takes an 'Employee'
object as an argument and returns a corresponding 'Boss' object.  In this
method's implementation you can copy property values from the passed object
to a new instance of 'Boss'.

Or (extending on Herfried's suggestion) you could add a new constructor to
the Boss class that took in the Employee instance and whatever other
property values that are "boss-specific".

Dim MyBoss as New Boss(MyEmployee, YearlyBonusAmt, PrivateParkingSpaceNum,
SlushFundAccountNum)

- Mitchell S. Honnert

Show quoteHide quote

Raterus,
In addition to the other comments.

Rather then have Boss Inherit Employee, I would consider making Boss a Role
that an Employee could have. This allows an employee to change the role they
play. Or even support multiple Roles.

Something like:

    Public Class Employee

        Public Property Role As EmployeeRole

    End Class

    Public MustInherit Class EmployeeRole

    End Class

    Public Class BossRole : Inherits EmployeeRole

    End Class

    Public Class CeoRole : Inherits EmployeeRole

    End Class


    Dim person1 As New Employee
    person1.Role = new BossRole ' promotion
    person1.Role = new CeoRole ' another promotion...

If an employee could have multiple roles, then I would define an
Employee.Roles collection that returned a collection of roles. Alternatively
you could apply the Composite Pattern to Role which would also allow
multiple roles.

For members that the Boss role could "override" in an Employee, I would
define the member in Employee, then delegate to the contained EmployeeRole.

    Public Class Employee

        Public Property Role As EmployeeRole

        Public Function CalculateSalary() As Decimal
            Return Role.CalculateSalary()
        End Function

    End Class

    Public MustInherit Class EmployeeRole

        Public MustOverride Function CalculateSalary() As Decimal

    End Class

Hope this helps
Jay


I don't even know if this can be done..

Lets say I have two objects,
---
Public Class Employee

End Class

Public Class Boss : Inherits Employee

End Class

Jay,

A Boss has at least collection of zero or more employee's

I think that with that I have said enough for you what I wanted to say

Cor

Cor,
Yes! a Boss can have zero or more employees! This might be a good place for
a Composite Pattern, as there may be other zero to many relationships
between employees, for example paired programming & programming teams. In my
original example I would consider making BossRole contain the collection of
employee's. In the above example I would consider making Employee itself
contain the collection. Depending on the requirements of the project.

No idea what you wanted to say. Or more appropriately I have no idea what
you are trying to add to this thread. As the OP wanted to change an Employee
object into a Boss object. The two common ways of doing this is copying as
Herfried & Mitchell suggested & the Role Pattern that I suggested. I don't
see a direct connection between number of employees & change an object's
type.

Hope this helps
Jay


Show quoteHide quote

Jay,

In my opinion does Boss derives from Employees when he has himself Employees
or any other reasons that does distinct him from an employee.

As I understand your solution well than looks it for me the same as giving
feathers to a mammal because more animals have that.

I think that is a very essential point in this thread and for me that what
the OP not want to do.

What in my opinion means that he want to use a Boss object as an Employee.

In code something like this very short and bad written.

\\\
Public Class Test
    Public Shared Sub Main()
        Dim a As New Employee
        a.name = "Jan"
        Dim b As Employee
        b = New Boss
        b.name = "Piet"
        DirectCast(b, Boss).Add(a.name)
    End Sub
End Class
Public Class Employee
    Public name As String
End Class
Public Class Boss : Inherits Employee
    Public employees As New ArrayList
    Public Sub Add(ByVal emp As String)
        employees.Add(emp)
    End Sub
End Class
///

Because I saw already so many messages, did I not wanted to add this,
because this is something I am sure of that it does not add much to your
knowledge and thought maybe can you tell that.

However when you don't agree will I without any problem add this to the main
thread.

Cor

Jay,

It was yesterday. I think that it was that I did not had an answer and
thought maybe you have.

Now that I thinked about it, is the question the same as "Can I make from a
combobox a listbox when I have already finstanted and filled that". Of
course I can do something like that, however than I have to deepclone most
parts and I think that that is not the question. However maybe you have.

Cor

Cor,
I am not disputing that. As I stated, Herfried & Mitchell gave the
inheritance with cloning solution.

A well know OO alternative to Inheritance is the Role Pattern. The Role
Pattern is useful when an object (Employee) needs to change its type (Boss).
Especially when copying & cloning may not be desirable! The "best"
discussion that I know of on the Role Pattern is in Peter Coad's, Mark
Mayfield's, and Jon Kern's book "Java Design - Building Better Apps &
Applets". They discuss this problem & how to implement it with Inheritance &
how to implement it with the Role pattern & why you would choose one over
the other. You can also use google to search for "Role Pattern" (include the
quotes) to find a number of useful links. I would suggest these:

http://www.cs.wustl.edu/~doc/RandD/PCES/PCESjava/PCESGraph/plop-1997-role-object.pdf
http://wiki.cs.uiuc.edu/AnalysisPatterns/Party

I'm sure there are others, the second link uses the term "actor-role
pattern".


Basically inheritance is useful when you need "is a special kind of" (a Boss
is a special kind of Employee) while the Role Pattern is when you need "is a
role played by" (Boss is a role played by an Employee). So I hope you see
both are applicable here.

I hope you agree one of the major problems with inheriting & cloning an
Employee is when you have many references to that Employee? If you clone it
you will need to change all the references, how do you know what all those
references are? If you implement the Role Pattern you just need to change
the Role property.

Another major problem with inheriting & cloning an Employee is what happens
when the Employee can hold multiple roles? What happens when the employee is
both a Boss & Administrative Assistant? Remember that .net does not allow
multiple inheritance. With the Role pattern Employee could have a
RoleCollection and/or PrimaryRole & SecondaryRole properties. Allowing that
Employee to hold multiple Roles.

Consider the example from the Java Design book:

Class Person - represents a person

Class Agent : Inherits Person - a person who sells airline tickets

Class Passenger : Inherits Person - a person who rides on the plane


Now how do you represent a person riding on a plan who sells Airline
tickets?

    Class AgentPassenger : Inherits Agent : Inherits Passenger

Oops: You can only inherit from a single base class.

Hence the use of Roles

Class Person - Represents a person

Class PersonRole - represents the roles that a person can have

Class AgentRole - Inherits PersonRole

Class PassengerRole - Inherits PersonRole

If Person can have 0 to many PersonRole objects, that Person can be both an
Agent & a Passenger.

Please take the time to fully understand the Role Pattern before commenting
further! Thank you!

Hope this helps
Jay

Show quoteHide quote

Advice needed
How can I determine WHICH exception I got in my CATCH?
using StringBuilder class for concatenation?
Using The NativeWindow Class To Draw A GDI Type Circle On Top Of A DataGrid Possibly In The Override
CSV-Datei einlesen
How to restrict the multiple opening of the Same window...
a checkbox in a datagrid
Process.Start("WinWord.exe") problem
add dsn programmatorically
tooltip on combobox selection