locked
Class Design RRS feed

  • Question

  • User357616875 posted

    Hello forum, 

    I have a website in asp.net that works well with a DAL / BO / BLL 3 tier design. My 3 tier design is based on function so for example I will have a DAL class for FAQs and a seperate one for mailing lists etc etc.

    I am trying to get a better understanding of best practises when designing a class. I have read loads and loads on the subject. I understand if you have a class called dog, you will have properties and methods public and private.

    One of the things I dont  seem to be able to get straight in my head is when to use a property and when to use a value in a method. I have kind of done it so that if a value is required for my than one method then it provided into the class by a property, and if it is only one then it is done using a method varable.

    I find it hard to translate the discussions on classes into real work examples, I have read the one about the dog and the car, with properties for make and colour, and methods for park, and sit but this is a physical thing. For examples my FAQs are not a physical thing

    If I am writing a class for FAQs that can appear in several positions on my website, for example specific business FAQ for global website FAQs is it benifical to build this into one class or one class for each possibility. If it is one class then I am going to have properties that depending on where the class is set to an object that might not have a value at all.

    Is this just a case of their are no strict rules, and it is down to personal preferances. I dont have problems getting working, just I think I need to tidy things up a bit

    Graham










    Tuesday, May 11, 2010 7:15 AM

Answers

  • User2019981500 posted

    Best question for me too,even i was confused for long..

    my understanding now says

    Well designed classes that take advantage of encapsulation hide the class' data members. The only way to access the class' data is through access (get/set) functions. Access functions expose class properties. Here's an example:

     

    struct Numner
    {
        Number();
        float get() const;
        void set(float value);
        ...
    };
    

    Properties are like smart fields. A property generally has a private data member accompanied by accessor functions and is accessed syntactically as a field of a class.

    Now comes to changing virtual things like FAQ to class defintion like we can change for DOG or CAR

    FAQ is comething which has properties and will definitely behave like physical thing if you think in very simple way like.

    FAQ Class can contant Questions characters like what type of questions ? whether Objective or descriptive

    so same way if you think you will get answers for everything..yes,don't think that you will understand this in one shot,just go throgh examples and with time you will understand all this.

    Nothing to worry

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 11, 2010 10:51 AM

All replies

  • User2019981500 posted

    Best question for me too,even i was confused for long..

    my understanding now says

    Well designed classes that take advantage of encapsulation hide the class' data members. The only way to access the class' data is through access (get/set) functions. Access functions expose class properties. Here's an example:

     

    struct Numner
    {
        Number();
        float get() const;
        void set(float value);
        ...
    };
    

    Properties are like smart fields. A property generally has a private data member accompanied by accessor functions and is accessed syntactically as a field of a class.

    Now comes to changing virtual things like FAQ to class defintion like we can change for DOG or CAR

    FAQ is comething which has properties and will definitely behave like physical thing if you think in very simple way like.

    FAQ Class can contant Questions characters like what type of questions ? whether Objective or descriptive

    so same way if you think you will get answers for everything..yes,don't think that you will understand this in one shot,just go throgh examples and with time you will understand all this.

    Nothing to worry

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 11, 2010 10:51 AM
  • User-952121411 posted

    A lot of your comfort level with building good classes will come with time and experience.  You can read books and understand the principals of good OOD, but it just takes time and implementing several projects, constantly refining and improving your work to make it better and better.

    In a simple class properties will hold the data and methods may generate the definition of those properties from business rules, calling another layer to retrieve data, etc.  The methods will be much more involved where the properties tend to be more basic accessors of the data that gives your class its behavior.  This is obviously a layman's term description but it may help more to give a small example of your example FAQ class.  Take a look to the following code:

    Public Class Faq
    
        Private mDescritpiton As String = String.Empty
        Private mID As Integer = 0
        Private mType As Integer = 0
    
        Public Sub New()
    
            'Default Class Constructor
    
        End Sub
    
        Public Sub LoadFAQ(ByVal RecordID As Integer)
    
            'Use the ID passed in to build the object of the current calling instance
    
            'Call some other layer; possibly returns an ADO.NET DataSet
            ds = SomeOtherLayer.GetData(RecordID)
    
            'Use LINQ, looping, etc. to populate this instance based on ID provided
            Dim MyFaq As New Faq()
            MyFaq.ID = RecordID
            MyFaq.Description = ds.Tables("MyData").Rows(0).Item("Description").ToString()
            MyFaq.Type = ds.Tables("MyData").Rows(0).Item("Type").ToString()
    
        End Sub
    
        Public Property Description()
            Get
                Return mDescritpiton
            End Get
            Set(ByVal value)
                mDescritpiton = value
            End Set
        End Property
    
        Public Property ID()
            Get
                Return mID
            End Get
            Set(ByVal value)
                mID = value
            End Set
        End Property
    
        Public Property Type() As Integer
            Get
                Return mType
            End Get
            Set(ByVal value As Integer)
                mType = value
            End Set
        End Property
    
    End Class


     This class is barebones, not tested, and has some pseudo code in it, but the point is to show you some responsibility differences between how properties are used and how methods are used as well.  Another useful tool for you will be to create a generic list of your class type as you mentioned having multiple instances of the FAQ and each one will have its own 'Property' values.  Once you get a little more familiar and have begun to build out your application, take a look to the following for some more help on this topic:

    .NET Object Collections Using Generics 101: 

    http://allen-conway-dotnet.blogspot.com/2009/11/net-object-collections-using-generics.html

    Hope this helps a bit! Smile

    Tuesday, May 11, 2010 4:37 PM