SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 90

Thread: inheritance

  1. #26
    PEACE WILL WIN abalfazl's Avatar
    Join Date
    Feb 2005
    Location
    Beyond the seas there is a town
    Posts
    711
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello

    We could use an abstract class here but we use an interface because it allows more flexibility.

    May you tell me advantages of using interface instead of abstract class?
    (By code ,Please)


    Of course what you posted was interesting,But my discussion is:

    What are advantages of using interface instead of Multiple inheritance?

    Ok?

    It seems what you posted is about multiple interfaces.

    Thanks

  2. #27
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Imagine this: classes B and C inherit class a; class D inherits classes B and C. Or, simpler: classes A and B both have a method called X; class C inherits them both, but provides no implementation for X -- which implementation should it inherit? For more on the subject, read http://en.wikipedia.org/wiki/Diamond_problem.

    In effect, there is not much difference between interfaces and parent classes, except that interfaces have no implementations -- all their methods are abstract. Therefore it is possible to inherit several interfaces at once without fear of diamond of death, because you must make your own implementations anyway.

    The behavior is the key word here, because it defines a class' methods -- not their implementations, but signatures, i.e. what parameters do they receive, what types do they return etc. A collection of such signatures make a type of an object, and basically this is what an interface is.

  3. #28
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by abalfazl
    May you tell me advantages of using interface instead of abstract class?
    Because PHP does not support multiple inheritance:

    PHP Code:
    abstract class AbstractBaseOne {
      abstract function 
    do_this();
    }

    abstract class 
    AbstractBaseTwo {
      abstract function 
    do_that();
    }

    class 
    Concrete extends <no way to extend AbstractBaseOne and AbstractBaseTwo > {
      function 
    do_this() {
        echo 
    "this";
      }
      function 
    do_that() {
        echo 
    "that";
      }

    But this does work:

    PHP Code:
    interface AbstractBaseOne {
      function 
    do_this();
    }

    interface 
    AbstractBaseTwo {
      function 
    do_that();
    }

    class 
    Concrete implements AbstractBaseOneAbstractBaseTwo {
      function 
    do_this() {
        echo 
    "this";
      }
      function 
    do_that() {
        echo 
    "that";
      }

    What are advantages of using interface instead of Multiple inheritance?
    Beyond the conceptual simplicity of interfaces, I can't think of any advantages.

    Multiple inheritance lets you include functionality in otherwise hetrogenious classes. Mixins (mixing functionality into a class) and duck typing (if it walks like a duck, and walks like a duck.. it might as well be a Duck) provide the advantages of multiple inheritance without the conceptual overhead.

    PHP supports duck typing for user objects, but does not support mixins. I believe there are people working on mixin support for PHP.

    Douglas
    Hello World

  4. #29
    PEACE WILL WIN abalfazl's Avatar
    Join Date
    Feb 2005
    Location
    Beyond the seas there is a town
    Posts
    711
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    That was the answer

    Hello



    Imagine this: classes B and C inherit class a; class D inherits classes B and C. Or, simpler: classes A and B both have a method called X; class C inherits them both, but provides no implementation for X -- which implementation should it inherit? For more on the subject, read http://en.wikipedia.org/wiki/Diamond_problem. In effect, there is not much difference between interfaces and parent classes, except that interfaces have no implementations -- all their methods are abstract. Therefore it is possible to inherit several interfaces at once without fear of diamond of death, because you must make your own implementations anyway. The behavior is the key word here, because it defines a class' methods -- not their implementations, but signatures, i.e. what parameters do they receive, what types do they return etc. A collection of such signatures make a type of an object, and basically this is what an interface is.

    That was the answer,clear and nice,Thanks BerislavLopac



    But please explain for me that :

    What are advantages of using interface instead of abstract class?

  5. #30
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by abalfazl
    What are advantages of using interface instead of abstract class?
    An abstact class implies you are using inheritance. You can only inherit from one class. You can support many interfaces.

    Perhaps instead of asking about a language feature, you might try to ask about the problem you are trying to solve. I find that using composition with a design pattern like the Strategy pattern is able to solve most issues where a naieve look might have you wishing for multiple inheritance.

  6. #31
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by abalfazl
    What are advantages of using interface instead of abstract class?
    Basically, there is no difference between an interface and an abstract class with *all* the methods abstract. However, a class by definition *can* have implementation, at least in some methods; interfaces were introduced to prevent *any* methods from being implemented.

    When you design a class, on an abstract level you don't need the implementations, only the signatures of methods -- those signatures collectively define behavior, and an object with a certain behavior is said to be of a certain type. With interfaces, you say: my class will belong to all of these types. Interfaces are more abstract than classes, even abstract classes.

  7. #32
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by abalfazl
    May you tell me advantages of using interface instead of abstract class?
    I'm just reiterating what has been said but interfaces give the flexibility of multiple inheritance without the restrictions. In the abstract class/concrete class model changes in the abstract class would have to be made in all concrete classes whereas with interfaces 'fine-tuning' changes can be made on a class by class basis.

    Also since PHP knows the object is_a() type of the interface this can be used to enforce the contractual relationship between class and interface.

  8. #33
    PEACE WILL WIN abalfazl's Avatar
    Join Date
    Feb 2005
    Location
    Beyond the seas there is a town
    Posts
    711
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    This article

    Hello firends

    I read this article and someparts of this article aren't clear to me:

    http://c2.com/cgi/wiki?ConfusionAboutInheritance

    Claiming inheritance is fundamental to OO (as is demonstratably incorrect - there are OO techniques and languages without inheritance), when its used in different ways for several different things
    May someone explain more about that?



    What different things are done with inheritance (and how)?

    various means of polymorphism and encapsulation:
    delegating state, behavior, or interface definition to a super-class, see InterfaceInheritance and ImplementationInheritance
    delegating behavior to a derived class (virtual method calls)

    various means of encapsulation?
    delegating state, behavior, or interface definition to a super-class, see InterfaceInheritance and ImplementationInheritance

    delegating behavior to a derived class ?

    May someone give me example for these three statements?

    Good Luck

  9. #34
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Claiming inheritance is fundamental to OO (as is demonstratably incorrect - there are OO techniques and languages without inheritance), when its used in different ways for several different things
    May someone explain more about that?
    I think this message sums it up pretty well: http://mumble.net/~jar/articles/oo.html

    Depending on what the background of the person is, you will get different explanations and definitions of the term "Object-Oriented".
    At some point this was so bad, that this paper made it into acm:
    http://portal.acm.org/citation.cfm?id=66469 ("My cat is object-oriented")
    Though that was '89. Given the commercial success of certain OO languages in the 90's, for a lot of people their attributes are what defines OO and you'll hear less debate over it (again, depending on who you talk with).

  10. #35
    PEACE WILL WIN abalfazl's Avatar
    Join Date
    Feb 2005
    Location
    Beyond the seas there is a town
    Posts
    711
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Composition versus Inheritance

    Hello

    Interesing article:



    http://www.artima.com/designtechniques/compoinh.html

    Good luck

  11. #36
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Simplicity. If you have multiple inheritance, and you inherit from two or more classes which define the same method, which one do you use?

    Java got out of that particular nightmare by providing support for interfaces, a model which PHP5 has adopted as well.
    Interfaces don't really save you anything, especially considering the loosely typed nature of PHP. They ultimately add up to nothing more than syntactic sugar. Multiple inheritence wouldn't be an issue in PHP if you called parent methods by the class name rather than with parent::

    Of course, you can just use composition, and avoid these nasty things altogether.

    In most cases, though, the overlapping issues with MI are caused by overdoing it more than anything.

  12. #37
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    Interfaces don't really save you anything, especially considering the loosely typed nature of PHP. They ultimately add up to nothing more than syntactic sugar.
    Documentation, perhaps. They don't actually do anything except in type hinting. And I'm not convinced it's a good idea to use type hints, at least until (if) we get namespace support.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  13. #38
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    Documentation, perhaps. They don't actually do anything except in type hinting. And I'm not convinced it's a good idea to use type hints, at least until (if) we get namespace support.
    As I said earlier, interfaces make no sense without type hinting, and type hinting has only a limited use without interfaces. So they need each other, but PHP could do very well without either and just go on with duck typing.

  14. #39
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Interfaces in php are useful for reflection-related tasks, for example when creating service object without knowing class name:
    PHP Code:
    $klass find_class_that_implements("MailFunctions");
    $mailer = new $klass

  15. #40
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can you give an example of a find_class_that_implements implementation?

    Douglas
    Hello World

  16. #41
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  17. #42
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The main benefit of interfaces and type hinting in PHP is that they enforce compliance. If something is not compliant, it is known sooner rather than later. For example, if a engine is passed in to a Car (via its constructor), and it doesn't implement IEngine, then we know there is an error. If we didn't use interfaces, then the error would occur when we try to call a method we expected to be implement in the Engine, but isn't. This stops things going wrong before they do, and ensures everything is how it should be.

    This helps in projects with a large amount of developers (and 3rd party code) and, as somebody already mentioned, in documentation. Also, there are other uses that seem to be more advanced options that prop up from time to time (like Dependancy Injection). Still, PHP being a weakly typed language, the uses of interfaces and Type Hinting are not as obvious as in a strongly typed langauge (like Java), where they are a neccessity.

  18. #43
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It strikes me that statically checking interfaces in a dynamically typed language is misguided, a better solution than copying Java would have been to use dynamic interfaces.

    You don't need to statically declare an interface, you can dynamically compare method signatures. Example:

    PHP Code:
    interface IEngine
    {
        function 
    start();
    }

    class 
    Engine
    {
       function 
    start() { /* ... */ }
    }

    class 
    Car
    {
       function 
    Car IEngine $engine )
       {
          
    # works, as Engine::start() exists... 
       
    }

    You don't need "implements IEngine" if you compare interfaces instead of types.

    </rant off>

    Douglas
    Hello World

  19. #44
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    Interesting, I'm not sure I want the initialization of classes to be based on the order of my requires though

    Douglas
    Hello World

  20. #45
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    class Car
    {
    function Car ( IEngine $engine )
    {
    # works, as Engine::start() exists...
    }
    }
    And if it doesn't? Calling unknown method is a Fatal, i.e. there is no chance to catch it... With interfaces we can check contract assertions relatively smart (at least it's smarter than prepending each method call with "if method_exists").
    PHP Code:

    // extreme primitive
    // Reflection-based improvements possible 

    function supports($klass$interface) {
        return !
    array_diff(
            
    get_class_methods($interface),
            
    get_class_methods($klass)
        );
    }

    // usage

    interface IEngine {
        function 
    start();
        function 
    rattle();
        function 
    stop();
    }

    // note there is no "implements" clauses

    class GoodEngine {
        function 
    start(){}
        function 
    rattle() {}
        function 
    stop(){}
    }

    class 
    FaultyEngine {
        function 
    start(){}
        function 
    stop(){}
    }

    function 
    letsDrive($something) {
        if(!
    supports($something'IEngine'))
            return print 
    "no valid engine";
        print 
    "here we go.........";
        
    $something->start();
        
    $something->rattle();
        
    $something->stop();
    }

    letsDrive(new GoodEngine());
    letsDrive(new FaultyEngine()); 
    Interesting, I'm not sure I want the initialization of classes to be based on the order of my requires though
    Right, but there must be a reason why they introduced intefaces... I'm just searching for it.

  21. #46
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    And if it doesn't? Calling unknown method is a Fatal, i.e. there is no chance to catch it...
    Isn't that what type hinting does at the moment? (If not, I'll have to take another look at it )

    I'd rather have it throw an exception than fatal on me.

    Quote Originally Posted by stereofrog
    Right, but there must be a reason why they introduced intefaces... I'm just searching for it.
    It might be a bit cynical, but here's my theory: Java is statically typed, and you want to get polymorphism from more than just subclasses via inheritance, so you add interfaces (nothing wrong with that, it is just one step closer to dynamic typing). Java got "enterprise" acceptance. PHP3/4 had a poor object model (arrays), and Zend saw the $$$ so wanted to move out of small developers and into "the enterprise". They thought they'd fix their object model by making it more like an "enterprise" Java one, and so we got interfaces and type hinting.

    Interfaces are great in statically typed languages, I'm not sold on them for dynamically typed languages. They feel like cruft, I might be wrong. Proove me wrong please

    Using them for dependancy injection is an interesting hack, but I'd rather have real metadata. Currently I'm trying to fake that by using init methods called by ancestor classes, but I'm not loving it. Got any ideas on that? PHPDoc uses formated comments to get documentation out of the code, which is really just another type of meta-data. I wonder if there is a way to write a preprocessor for PHP, not sure it's worth the work though.

    Later,
    Douglas
    Hello World

  22. #47
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Isn't that what type hinting does at the moment? (If not, I'll have to take another look at it )

    I'd rather have it throw an exception than fatal on me.
    That's exactly my point. If you don't want a fatal, you have to check contracts before engine does this for you.

    It might be a bit cynical, but here's my theory:
    I'd say it's pretty much common. It's really frustrating to see zends hunting corporate money instead of improving engine and language itself.

    Interfaces are great in statically typed languages, I'm not sold on them for dynamically typed languages. They feel like cruft, I might be wrong. Proove me wrong please
    Well, it seems that the whole typing/inheritance concept is just a bit obsolete.
    I wonder if there is a way to write a preprocessor for PHP,
    with builtin lexer this shouldn't be that hard...
    not sure it's worth the work though.
    no

  23. #48
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    And if it doesn't? Calling unknown method is a Fatal, i.e. there is no chance to catch it... With interfaces we can check contract assertions relatively smart (at least it's smarter than prepending each method call with "if method_exists").
    So this is fixing a platform issue by adding an unnecessary language issue...

    Well, I guess this is what we get when we mix a platform and a language into an common lump.

    I've recently discovered CherryPy, which has quite similar concepts to PHP, although based on Python. Which got me thinking about a platform which would take the concepts straight from PHP (such as $_REQUEST, $_SERVER and other suberglobals, default error reporting etc.), but use Python as the language of choice instead of PHP. I even got a name for it -- Phaeton.

  24. #49
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you don't want a fatal, you have to check contracts before engine does this for you.
    Yer, I made a note of that myself, and started a thread about it a while back. For example, with PHP you can't do this, as you can in Java

    PHP Code:
    class ClickMe {
    public function 
    __construct() {}
    public function 
    doesNotThrowAnExceptionIResponse $response throws IllegalParameterException {
    // ... if not typeof IResponse, then throw an exception
    // ... as apposed to dying with an error
    }
    // ... rest of class

    Which in todays languages I would have expected at the very least as well. I would have liked to handle the error myself, surely that isn't too much to ask for huh? Huh?

  25. #50
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Which in todays languages I would have expected at the very least as well. I would have liked to handle the error myself, surely that isn't too much to ask for huh? Huh?
    What are you saying?

    Quote Originally Posted by BerislavLopac
    Which got me thinking about a platform which would take the concepts straight from PHP (such as $_REQUEST, $_SERVER and other suberglobals, default error reporting etc.), but use Python as the language of choice instead of PHP.
    That's one of the things Rails does for Ruby, taking a dynamic scripting language and adding web-aware features. I've not used it, but I assume Django does for Python, you should probably give it a try if you already like Python, though personally I wouldn't want to use a framework that I don't know how to pronounce! I'll have to find a Python podcast and find out

    Douglas
    Hello World


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •