The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums Back End Static Abstract and Interface Classes

  • This topic is empty.
Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • #29970

    Ok, I’ve been reading and re-reading books and articles all over the internet to try and understand these but just can’t.
    I vaguely understand static methods and properties, It’s so that you can access methods and properties from outside the class without having to class the class and create and object of it. Is that right?

    But then it moves on to abstract and i just get lost. you create an abstract class, that can’t get called as an object but that can have other classes extend of from it. Is that right? And if so what’s the point? You then have to create an abstract method in the class and the ‘children classes’ HAVE to call that method or be called abstract themselves????

    Then interface classes, i might have a better understanding of these once i can get my head around abstract ones. But from the examples I’ve seen interface classes are just filled with abstract methods??

    Can someone please shed some light on this??
    Many Thanks for your time.


    Abstract and Interface classes. Let’s go!

    You’re right about static methods and properties. You don’t have to instantiate the class to get at those methods/properties.

    Abstract and Interface classes are useful if you’re programming in a group setting because they enforce a contract for other users of your class to follow. They are also helpful if you are programming alone but you’re the type who forgets to implement a method here or there.

    First, for Abstract classes. Let’s say that you have a base class Watch that you expect other users to extend. Let’s also say that somewhere in your application you depend on the Watch class to have a Tick method, returning the sound the watch makes when it ticks. A Timex class extending the Watch class may return the string ‘click’, while the Rolex class extending Watch may return the string ‘swoosh’. In any case, you, as the class designer, must ensure that that watch ticks in some fashion. So, you mark the class Abstract and you define an abstract method Tick that your users must implement, and Boom, you’re in business.

    So, you see how that works? Now, the users (who you don’t entirely trust) are free to implement your class, but you can control whether or not they will break your application by creating a class lacking the required methods.

    On to Interfaces. These work much in the same way as abstract classes, but they have no concrete methods, only method signatures. These are nice if you’re a major control freak and you want to ensure that your users create classes which implement the methods you want, while still giving them the flexibility to define their own constructors, etc.

Viewing 2 posts - 1 through 2 (of 2 total)
  • The forum ‘Back End’ is closed to new topics and replies.