<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Abstract Class &amp; Interfaces in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991128#M706470</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Abstract classes&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Abstract classes are normally used as an incomplete blueprint for concrete (that is, non-abstract) subclasses, for example to define a uniform interface. &lt;/P&gt;&lt;P&gt;Classes with at least one abstract method are themselves abstract. &lt;/P&gt;&lt;P&gt;Static methods and constructors cannot be abstract.&lt;/P&gt;&lt;P&gt;You can specify the class of the instance to be created explicitly: CREATE OBJECT &amp;lt;RefToAbstractClass&amp;gt; TYPE &amp;lt;NonAbstractSubclassName&amp;gt;. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Abstarct classes themselves can&amp;#146;t be instantiated ( althrough their subclasses can)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Reference to abstract classes can refer to instance of subclass&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Abstract (instance) methods are difined in the class , but not implemented &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;They must be redefined in subclasses &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;CLASS LC1 DEFINAITION ABSTARCT&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;PUBLIC SECTION &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;METHODS ESTIMATE ABSTARCT IMPORTING&amp;#133; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;ENDCLASS.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;Interfaces&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Interfaces only describe the external point of contact of a class (protocols), they do not contain any implementation. &lt;/P&gt;&lt;P&gt;Interfaces are usually defined by a user. The user describes in the interface which services (technical and semantic) it needs in order to carry out a task.&lt;/P&gt;&lt;P&gt; The user never actually knows the providers of these services, but communicates with them through the interface.&lt;/P&gt;&lt;P&gt; In this way the user is protected from actual implementations and can work in the same way with different classes/objects, as long as they provide the services required. This is known as polymorphism with interfaces.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Sat, 10 Nov 2007 06:22:55 GMT</pubDate>
    <dc:creator>Former Member</dc:creator>
    <dc:date>2007-11-10T06:22:55Z</dc:date>
    <item>
      <title>Abstract Class &amp; Interfaces</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991126#M706468</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Can anyone please tell me as to why we need both an abstract class &amp;amp; an interface? I was asked in an interview as to why we need 2 separate concepts when we can get the similar functionality of an interface by using an abstract class. I had just sited their differences like:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1) An abstract class can have both abstract &amp;amp; normal methods &amp;amp; that we can specify different access specifiers for its class members.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;2) ABAP does not support Multiple inheritance but that we could simulate the same using interfaces concept in ABAP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;But he wasnt satisfied with the answer. I guess he was expecting something from a practical point of view. I did try searching the old threads but there wasnt anything similar to this. Anyone please explain by citing a scenario as to why we would need 2 separate concepts &amp;amp; not just one . &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks in advance&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 09 Nov 2007 10:40:52 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991126#M706468</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-11-09T10:40:52Z</dc:date>
    </item>
    <item>
      <title>Re: Abstract Class &amp; Interfaces</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991127#M706469</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;The difference you might have missed is that in case of interfaces, there is no implementation part. So the DEFINITION for INTERFACE is not required.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Moreover some discussions on the OO principles behind Classes and Interfaces might clarify such requirements.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When designing OO applications, sometimes you need to ensure that some Object needs to follow some standardization in terms of behavior. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Example can be birds fly, airplanes fly, mosquitoes also fly. Using abstract class design what you need to do is basically create an abstract class in the name of FLY and attach it some behavior (using methods).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Now create other sub classes (BIRD, AIRPLANE, MOSQUITO). This creates an OO design which says BIRDS IS A FLY, AIRPLANE IS A FLY and MOSQUITO IS A FLY. (Inheritance provides "IS A " kind of relationship in OO) This not only looks odd also asks you to have unwanted relationship.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A better and cleaner approach adopted during later stage of OO development is through interfaces. You can orthogonally attach any interface to a class so you can get "vehicles that can fly as well as move on road" in a better OO way.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 09 Nov 2007 15:56:44 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991127#M706469</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-11-09T15:56:44Z</dc:date>
    </item>
    <item>
      <title>Re: Abstract Class &amp; Interfaces</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991128#M706470</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Abstract classes&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Abstract classes are normally used as an incomplete blueprint for concrete (that is, non-abstract) subclasses, for example to define a uniform interface. &lt;/P&gt;&lt;P&gt;Classes with at least one abstract method are themselves abstract. &lt;/P&gt;&lt;P&gt;Static methods and constructors cannot be abstract.&lt;/P&gt;&lt;P&gt;You can specify the class of the instance to be created explicitly: CREATE OBJECT &amp;lt;RefToAbstractClass&amp;gt; TYPE &amp;lt;NonAbstractSubclassName&amp;gt;. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Abstarct classes themselves can&amp;#146;t be instantiated ( althrough their subclasses can)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Reference to abstract classes can refer to instance of subclass&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Abstract (instance) methods are difined in the class , but not implemented &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;They must be redefined in subclasses &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;CLASS LC1 DEFINAITION ABSTARCT&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;PUBLIC SECTION &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;METHODS ESTIMATE ABSTARCT IMPORTING&amp;#133; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;ENDCLASS.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;Interfaces&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Interfaces only describe the external point of contact of a class (protocols), they do not contain any implementation. &lt;/P&gt;&lt;P&gt;Interfaces are usually defined by a user. The user describes in the interface which services (technical and semantic) it needs in order to carry out a task.&lt;/P&gt;&lt;P&gt; The user never actually knows the providers of these services, but communicates with them through the interface.&lt;/P&gt;&lt;P&gt; In this way the user is protected from actual implementations and can work in the same way with different classes/objects, as long as they provide the services required. This is known as polymorphism with interfaces.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 10 Nov 2007 06:22:55 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991128#M706470</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-11-10T06:22:55Z</dc:date>
    </item>
    <item>
      <title>Re: Abstract Class &amp; Interfaces</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991129#M706471</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Naresh,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;don't forget that ABAP Objects does not support multiple inheritance. Therefore you can only have a single super-class. However a class can implement multiple interfaces.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Cheers&lt;/P&gt;&lt;P&gt;Graham Robbo&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 10 Nov 2007 22:25:40 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/abstract-class-interfaces/m-p/2991129#M706471</guid>
      <dc:creator>GrahamRobbo</dc:creator>
      <dc:date>2007-11-10T22:25:40Z</dc:date>
    </item>
  </channel>
</rss>

