Inheritance (object-oriented programming)

:''See inheritance (computer science) for other computing uses of inheritance.'' In object-oriented programming of computer science, an inheritance is a way to form new class (computer science)es (instances of which will be object (computer science)s) using pre-defined objects or classes where new ones simply take over old ones' implementations and characteristics. It is intended to help reusability of existing code with little or no modification. One of the powerful advantages of inheritance is that modules with sufficiently similar interfaces can be commanded by shared controlling code, reducing the complexity of the program. Inheritance therefore has another view, a ''dual'', called Polymorphism (computer science), which describes many pieces of code being controlled by shared control code. Complex inheritances may cause the Yo-yo problem. == Applications of inheritance == There are many different aspects to inheritance. Different uses focus on different properties, such as the external behaviour of objects, internal structure of the object, structure of the inheritance hierarchy, or software engineering properties of inheritance. Sometimes it's desirable to distinguish these uses, as it's not necessarily obvious from context. === Specialization === One common reason to use inheritance is to create specializations of existing classes or objects. This is often called ''subtyping (object-oriented programming)'' when applied to classes. In specialization, the new class or object has data or behavior aspects that are not part of the inherited class. For example, a "Bank Account" class might have data for an "account number", "owner", and "balance". An "Interest Bearing Account" class might inherit "Bank Account" and then add data for "interest rate" and "interest accrued" along with behavior for calculating interest earned. Another form of specialization occurs when an inherited class specifies that it has a particular behavior but does not actually implement the behavior. Each class which inherits from that abstract class must provide an implementation of that behavior. This providing of actual behavior by a subclass is sometimes known as ''implementation (object-oriented programming)'' or ''reification (object-oriented programming)''. === Overriding === Many object-oriented programming languages permit a class or object to replace the implementation of an aspect—typically a behavior—that it has inherited. This process is usually called ''override (object-oriented programming)''. Overriding introduces a complication: which version of the behavior does code from the inherited class see—the one that is part of its own class, or the overriding behavior? The answer varies between programming languages, and some languages provide the ability to indicate that a particular behavior is not to be overridden. === Extension === Another reason to use inheritance is to provide additional data or behavior features. This practice is sometimes called ''extension (object-oriented programming)'' or ''subclassing''. In contrast to the case of specialization, with extension the new data or behaviors could have been provided in the inherited class because they are generally applicable to all instances of the class. Extension is often used when incorporating the new features into the inherited class is either not possible or not appropriate. It can also be used at the object level, such as in the Decorator pattern. === Code re-use === One of the earliest motivations for using inheritance was to allow a new class to re-use code which already existed in another class. This practice is usually called ''implementation inheritance''. In most quarters, class inheritance for the sole purpose of code re-use has fallen out of favor. The primary concern is that implementation inheritance does not provide any assurance of Polymorphism in object-oriented programming substitutability—an instance of the re-using class cannot necessarily be substituted for an instance of the inherited class. An alternative technique, Delegation pattern, requires more programming effort but avoids the substitutability issue. The notion that implementation inheritance should be avoided is not universal. One prominent object-oriented programming expert who believes that implementation inheritance has its place is Bertrand Meyer. In his book Object Oriented Software Construction, 2^nd ed., Meyer lists twelve different uses of inheritance that he considers to be legitimate, most of which involve some amount of implementation inheritance. == Examples == A program might have a class Animal that contained such data elements as whether the animal was presently alive, where it is currently located, etc.; as well as methods instructing the animal to eat, move, mate, etc. If we wanted to create a class Mammal, most of those data elements and functions would be the same as for most animals, but a few would change. We therefore define Mammal as a ''subclass'' of Animal (we then say that Animal is Mammal's ''superclass'' or ''parent'' class): Note here that we don't need to specify that a mammal has all the usual animal things: a location, ability to eat, move, etc. We do add some additional features such as hair and breasts that are unique to mammals, and we ''redefine'' the reproduce method to add functionality. Within the reproduce method, note the call super.reproduce(). This is a call to the superclass method which we are redefining. This roughly means "do whatever a member of my superclass would do", which is then followed by code specific to our new subclass. === Java programming language ===


  class Mammal extends Animal {
    Hair m_h;
    Breasts m_b;
    
    Mammal reproduce() {
      Mammal offspring;
      
      super.reproduce();
      if (self.is_female()) {
        offspring = super.give_birth();
        offspring.breastfeed(m_b);
      }
      care_for_young(offspring);
      return offspring;
    }
  }

==Limitations and Alternatives== When using inheritance extensively in designing a program, one should be aware of certain constraints that it imposes. For example, consider a class Person that contains a person's name, address, phone number, age, sex, and race. We can define a subclass of Person called Student that contains the person's grade point average and classes taken, and another subclass of Person called Employee that contains the person's job title, employer, and salary. In defining this inheritance hierarchy we have already defined certain restrictions, not all of which are desirable: ===Constraints of inheritance-based design=== *Singleness: using single inheritance, a subclass can inherit from only one superclass. Continuing the example given above, Person can be either a Student or an Employee, but not both. Using multiple inheritance partially solves this problem, as a StudentEmployee class can be defined that inherits from both Student and Employee. However, it can still inherit from each superclass only once; this scheme does not support cases in which a student has two jobs or attends two institutions. *Staticness: the inheritance hierarchy of an object is fixed at instantiation when the object's type is selected and does not change with time. For example, the inheritance graph does not allow a Student object to become a Employee object while retaining the state of its Person superclass. *Visibility: whenever client code has access to an object, it generally has access to all the object's superclass data. Even if the superclass is not a public one, the client can still cast the object to its superclass type. For example, there is no way to give a function a pointer to a Student's grade point average and transcript without also giving that function access to all of the personal data stored in the student's Person superclass. === Roles and inheritance === Sometimes inheritance based design is used instead of roles. A role, say Student role of a Person describes a characteristic associated to the object that is present because the object happens to participate in some relationship with another object (say the person in student role -has enrolled- to the classes). Some object-oriented design methods do not distinguish this use of roles from more stable aspects of objects. Thus there is a tendency to use inheritance to model roles, say you would have a Student role of a Person modelled as a subclass of a Person. However, neither the inheritance hierarchy nor the types of the objects can change with time. Therefore, modelling roles as subclasses can cause the roles to be fixed on creation, say a Person cannot then easily change his role from Student to Employee when the circumstances change. From modelling point of view, such restrictions are often not desirable, because this causes artificial restrictions on future extensibility of the object system, which will make future changes harder to implement, because existing design needs to be updated. Inheritance is often better used with a generalization mindset, such that common aspects of instantiable classes are factored to superclasses; say having a common superclass 'LegalEntity' for both Person and Company classes for all the common aspects of both. The distinction between role based design and inheritance based design can be made based on the stability of the aspect. Role based design should be used when it's conceivable that the same object participates in different roles at different times, and inheritance based design should be used when the common aspects of multiple classes (not objects!) are factored as superclasses, and do not change with time. One consequence of separation of roles and superclasses is that compile-time and run-time aspects of the object system are cleanly separated. Inheritance is then clearly a compile-time construct. Inheritance does influence the structure of many objects at run-time, but the different kinds of structure that can be used are already fixed at compile-time. To model the example of Person as an employee with this method, the modelling ensures that a Person class can only contain operations or data that are common to every Person instance regardless of where they are used. This would prevent use of a Job member in a Person class, because every person does not have a job, or at least it is not known that the Person class is only used to model Person instances that have a job. Instead, object-oriented design would consider some subset of all person objects to be in an "employee" role. The job information would be associated only to objects that have the employee role. Object-oriented design would also model the "job" as a role, since a job can be restricted in time, and therefore is not a stable basis for modelling a class. The corresponding stable concept is either "WorkPlace" or just "Work" depending on which concept is meant. Thus, from object-oriented design point of view, there would be a "Person" class and a "WorkPlace" class, which are related by a many-to-many associatation "works-in", such that an instance of a Person is in employee role, when he works-in a job, where a job is a role of his work place in the situation when the employee works in it. Note that in this approach, all classes that are produced by this design process are part of the same domain, that is, they describe things clearly using just one terminology. This is often not true for other approaches. The difference between roles and classes is especially difficult to understand if referential transparency is assumed, because roles are types of references and classes are types of the referred-to objects. ===Component-oriented design as an alternative to inheritance=== An alternative way to design the aforementioned system of persons, students, and employees would be to define helper classes Transcript and Job to store the additional information for a student and employee, respectively. Then, each Person object can contain a collection of Transcript objects and a collection of Job objects. This removes the aforementioned constraints: *A Person can now have an arbitrary number of jobs and attend an arbitrary number of institutions *These jobs can now be changed, added, and deleted dynamically *It is now possible to pass a student's Transcript to a function--for example, one that makes college admissions decisions--without also automatically passing in the student's name, age, race, and other personal information. Using composition instead of inheritance also leads to less ambiguous syntax. For example, in a inheritance-oriented design, one might encounter the following code:


Employee e = getEmployee();
print(e.jobTitle());

While one might infer that the jobTitle() function is defined in the Employee class, it is also possible that it is defined in the Person class. As the inheritance hierarchy gets deeper, this effect, known as the yo-yo problem, is magnified. A composition-based design allows the programmer to maintain a shallower inheritance hierarchy, and minimizes ambiguity, as in the following example:


Person p = getPerson();
print(p.job().title());

To a programmer that knows the Job class has no superclass, it is immediately obvious that the title() function is defined in the Job class. Component-oriented design cannot be substituted for an inheritance-based design in all cases. For example, inheritance enables polymorphism (computer science) and information hiding. Also, defining component classes instead of subclasses can increase the length of source code. ==See also== * Multiple inheritance * Virtual inheritance * class (object-oriented programming) * hierarchy (object-oriented programming) * Interface * override (object-oriented programming) * Composition in object-oriented programming Object-oriented programming Programming constructs

Inheritance (object-oriented programming)

This is the best place for this article. Despite the attempts by OO enthusiasts to hijack the concept of inheritance as their exclusive property, it can be found in use in functional programming circles as well. -- User:Derek Ross 20:10 18 May 2003 (UTC) But the article discusses oop inheritance! User:Mintguy 20:17 18 May 2003 (UTC) ------ ''Moved from Mintguy's talkpage'' :Please stop an attempt to limit usage of oo terms. Inheritance is used not only in OOP but in OO-design or other components model. What's wrong with the naming inheritance (computer science)? -- User:TakuyaMurata 20:09 18 May 2003 (UTC) :The first sentence of that article is "In computer science's object-oriented programming theory, inheritance...". So what is wrong with the current title? All of the current articles about OO theory and design are at listed as object-oriented programming. User:Mintguy 20:15 18 May 2003 (UTC) :Looks to me like the first sentence should be changed then. Inheritance can be used in any language with functions. That makes it a concept with a much bigger applicability than just OO theory and design. It's part of re-usability. -- User:Derek Ross 20:23 18 May 2003 (UTC) :The article is ALL about inheritance in OOP which is one of the fundamental aspects of all OOP languages it needs an article of its own. User:Mintguy 20:27 18 May 2003 (UTC) :The article needs more work for sure. I just didn't have time to do that. But we first have to rename the article because if I started to add mention about inheritance other than that in OOP. People will complain the article is inheritance in OOP. You know this is egg and chiken problem. To solve the problem, first we need to rename the article then we can move to change the actual text. -- User:TakuyaMurata 20:32 18 May 2003 (UTC) :Inheritance is an OO concept and not a procedural one. Now you could put the OO articles under OOD rather than OOP but I don't think it makes much difference as for the most part OOD is implemented with OOP and most of the articles about OO are under OOP. So why do you have a problem in putting Inheritance at OOP, it should either be under OOP or OOD and not computer Science. User:Mintguy 20:39 18 May 2003 (UTC) Ok, how about this question. Why inheritance should be under OOP or OOD not simply computer science? what's wrong with the title inheritance (computer science) -- User:TakuyaMurata 01:37 19 May 2003 (UTC) :Because Inheritance is a fundamental OO concept. It belongs with OOD or OOP. If you don't have objects in the first place how can you have inherited behaviour!? User:Mintguy 01:41 19 May 2003 (UTC) ::Very easily. The inheritance process might occur at a deeper level, and then not be attached to anything that amounts to being an object after all. Think of colour: green may inherit from yellow and blue, but none of them is "real" until you have an object of that colour. This makes sense - mix yellow and blue paint before they go on an object, but then put the paint on some final object that will be green. Only along comes something else, a theory of colour vision say. Now you have green light, quite separately from any object in the original sense. Or concepts of "green" in politics that don't attach to light at all. Yes, I am "just playing" - but it's serious. I'm playing with concepts, not just with words. PML. :::Ahhah... but blue doesn't inherit from green and yellow, it's a primary colour. So your theory get blown out of the water and I waltz off with a wry grin. User:Mintguy 01:58 19 May 2003 (UTC) ::::No, you just pushed the analogy beyond the limits of its value for the purposes of illustration - which was all it was there for and which I suspect you knew. Just as I suspect you took the point. PML. :Do you know some OOP language doesn't rely on inheritance at all but instead it uses delegation. Anyway, actually you didn't answer my question. what's wrong with the title inheritance (computer science)? My point is why OOP not computer science? Remember it really doesn't matter what is OOP since people have a different view about it. You think inheritance is a fundermantal OO concept while some don't. It is ok but we cannot impose our perception. Instead, we need to be more objective and nutral. In other words, it's really doesn't matter what is the truth here but what people believe the truth is. -- User:TakuyaMurata 03:42 19 May 2003 (UTC) ::The answer to your question is written clearly above but I'll repeat it - If you don't have objects in the first place how can you have inherited behaviour!? the concept of inheritance relies upon the concept of objects. The design needs objects even if the language doesn't posses them. You can mimic C++ objects in C. Whether your language has classes or not is irrelevant! User:Mintguy :First, please calm down. I don't mean to insult you or anything at all. We can just discuss about naming peacefully. No? My question is actually different than what you think. I am merely talking about why do you object naming inheritance (computer science). what's wrong with that? Do you think inheritance is NOT a computer science topic? Do you object the name inheritance (computer science) or do you think while it can be acceptable, inheritance (object-oriented programming) is better than it? -- User:TakuyaMurata 00:12 20 May 2003 (UTC) :As to your point about inheritance vs delegation. It's the old "is-a" vs "has-a" argument there are reasons for choosing one above another depending on the design. User:Mintguy :I believe it is more like implementation issue than design. (but anyway this is rather off-topic) :Taku what the hell are you doing. I've already proved to you that Inheritance is a fundamental concept of OO. Taku for goodness sake what is the matter with you? :And I thought I disproved by showing some OOP languages (called object-based languages) do not use inheritance. And you NEVER answered my question (see above). You keep the debate, otherwise you tell people you agree with the other side. -- User:TakuyaMurata 01:39 23 May 2003 (UTC) :I agree with Taku, it's much better to have the article under (computer science). It doesn't necessarily have to do with programming (consider UML for example), and as Taku says, OOP languages do not necessarily use inheritance. It might be appropriate to put it under (Object-oriented design), but this kind of excludes programming, and computer science as a whole. We can talk about inheritance without talking about objects - like the green-blue-yellow example above, or maybe inherited properties, attributes, methods, functions, etc. (which are usually talking about an object, but may be talking about a static class or some other abstract concept as well.) Better to be safe and leave it under (computer science). -- User:Wapcaplet 01:44 23 May 2003 (UTC) Wap.. read the damn article. It's about inheritance in OOD and OOP which is about inherited behavior. This is a fundamental concept of the OO paradim and doesn't exist outside of it. User:Mintguy 01:48 23 May 2003 (UTC) :Taku how many times do you have to be told. Object based languaged do NOT follow the object oriented paradigm, that is why they are called object based and NOT object-oriented and that is why object based languages do not have inheritance. User:Mintguy 01:51 23 May 2003 (UTC) ::True they don't follow object-oriend paradigm, which is yours and that of the majority. But again it is called POV. Evidence. It's a whole chapter so I cannot quote that but the chapter says in its intro "[...] we discuss two other styles of languages that are often discussed as object-oriented languages: object-based and multi-method languages. [...] The goal is to highlight differences in languages that are grouped under the umbrella label of object-oriented languages." (From Foundations of Object-Oriented Languages Kim B. Bruce) Then the chapter discusses so-called object-based languages without inheritance. Absolutely you can claim object-based language is not OOP language but there are a few people who disagree with it. And such language is categorized as OOP languages if it is wrong, or you don't like it. We don't have to dispute which side is right. Sorry about dead-link. I cannot prove but it was alive when I posted it. -- User:TakuyaMurata 02:37 23 May 2003 (UTC) :I've read some bad programming books in my time and this must be one of them. The guy is an idiot. There is such a clear distinction between object oriented and object based. Object oriented is a whole different way of thinking about programming, abstracting out from the implementation details by polymorphism through inheritance. It's not just grouping functions and data into objects for convenience and code re-use. User:Mintguy 02:46 23 May 2003 (UTC) :You might be right but it really doesn't matter because the whole point is some people who claim object-based languagesd are OOP exist. By the way if you doubt the credibility of this book, see http://www.amazon.com/exec/obidos/tg/detail/-/026202523X/qid=1053658373/sr=8-2/ref=sr_8_2/104-1500070-2293540?v=glance&s=books&n=507846. Of course we cannot count on guys in MIT are always right. -- User:TakuyaMurata 02:53 23 May 2003 (UTC) ------- :Er, yes, but the contents of the article can change. My point is that Inheritance need not necessarily be restricted to OOP or OOD. Hence I think it's better to use a (computer science) disambiguation in order to leave room for such growth in the future. Why are you so opposed to listing it under (computer science)? Do you think it is NOT computer science? -- User:Wapcaplet 01:52 23 May 2003 (UTC) I don't understand your idea about inheritance outside of OO. The abstract blue green thing doesn't really cut it does it. How does that relate to programming. Of course OOP is computer science but it's a subset and all the other articles about object oriented features are listed under object-oriented programming. User:Mintguy 01:57 23 May 2003 (UTC) :I found [http://www.modulaware.com/mdlt/mdlt84.htm this article] which discusses ways of implementing encapsulation, inheritance, and polymorphism, without using OO. Sometimes these things are implemented in C, for example, which is not an OO language (and thus it's hard to imagine programming in it using OO concepts). -- User:Wapcaplet 02:07 23 May 2003 (UTC) :It discusses proposed extensions to a non-OO language to encompass OO design methods. So what is your point? It is not very hard (but awkward) to implement OO designs in non OO languages like C. I've said so myself on another talk page. However, this isn't true OO because you lose the encapsulation and you lose the abstraction because you don't have the ability to hide implementations that an OO language gives you. User:Mintguy 02:26 23 May 2003 (UTC) ::As you say - "this isn't true OO." It's inheritance (polymorphism etc.) without object-oriented programming. -- User:Wapcaplet 02:29 23 May 2003 (UTC) ::OO programming is the implementation of OO design. In this case in a non-OO language. In fact it is a valid argument to say that C++ (which is the most common OO language out there) isn't a true OO language itself because you can break the abstraction too easily. A better example of an OO language is Eiffel programming language but no bugger uses it. User:Mintguy 02:33 23 May 2003 (UTC) :::Well, yeah. All I meant is that inheritance, while it is often part of object-oriented design and programming, need not necessarily be so. It's abstraction-oriented, but I don't see why it has to always be object-oriented. Just my POV, I may be wrong :) -- User:Wapcaplet 02:39 23 May 2003 (UTC) ::::What are you talking about when you say inheritance without objects? What is doing the inheriting and from what is it inheriting? If you are talking about extending datatypes, that's been around since the days of COBOL and has little to do with inheritance as we know it. Real inheritance involves capturing behavioural features of ... something... and passing it on to ...something.. else. User:Mintguy 02:54 23 May 2003 (UTC) ::::''What is doing the inheriting and from what is it inheriting?'' Procedures can do the inheriting of behaviour from other procedures; functions from other functions. You can even implement inheritance in FORTRAN or LISP using this technique. -- User:Derek Ross 03:04 23 May 2003 (UTC) :::::That's not inheritance that's composition and delegation. That is calling a subroutine, by another name. User:Mintguy 03:23 23 May 2003 (UTC) :::::Modern versions of LISP (Common LISP Object System) adopt OO concepts of classes and inheritance. Fortran 90 has simple classes but it doesn't possess inheritance, it has to be mimicked. I believe a proposed object oriented version of FORTRAN is in development. User:Mintguy ---- This article is just fine where it is. Inheritence(computer science) redirects here, and the current article as it exists only talks about oop inheritence. If someone wants to make a broder article, in programming, do it. This doesn't need to be moved. Refer to object-oriented programming. Look at the definition of oop. If you do create a inheritance (computer science) article, just put a link to this article where you talk about it's relation to oop. User:Mbecker 17:48 4 Jun 2003 (UTC) ---- Ok, this has clearly been discussed to death, and I can't see any consensus arising. I'm putting it to a vote: whichever option has the most votes in a month's time (5th July) will be where I move the article. User:MyRedDice 19:54 5 Jun 2003 (UTC) ''vote at bottom'' This doesn't really cover inheritance as used in CSS etc., which are also part of computer science. BTW, Taku, did you mean to vote for that? -- User:JohnOwens 20:07 5 Jun 2003 (UTC) I must admit I've played devil's advocate somewhat here. In the end I must say I'm in favor of (object-oriented programming). John makes a good point about CSS, which I hadn't considered, but then, that's not even part of Computer Science, really. Someday someone may write Inheritance (Cascading Style Sheets) but until then... -- User:Wapcaplet 01:55 6 Jun 2003 (UTC) I still don't understand why we need a separate article about inheritance for OOP and other use in cs. Why not just have a inheritance (computer science) with a section regarding that especially in oop. I am afraid some day somebody simply merges two closely-related topics into just one article. -- User:TakuyaMurata 03:39 6 Jun 2003 (UTC) Besides, please stop objecting to renaming for the reason of the current content. We cannot put inheritance in fields other than that in OOP now because of its name. It is a egg and chicken problem to add more that conflicts with the current name, we first rename the article. -- User:TakuyaMurata 03:49 6 Jun 2003 (UTC) :This is so absurd. This article exists. The inheritence article regarding all forms of inheritence (computer science) has yet to be created. Once it is created, it can link to this article. It would be too big if we included this huge article in it. We don't need to move this for someone to create Inheritance (computer science). For now, since the article doesn't exist, this is a good place to redirect it. Remember, this is an article about OOP inheritence, not all forms of CS inheritence. User:Mbecker 04:20 6 Jun 2003 (UTC) I am not sure what is absurd. You mean a voting list? We need to make sure where we can put inheritance in other than that in oop. The question is not moving or not but how to organize articles. -- User:TakuyaMurata 04:32 6 Jun 2003 (UTC) Also, I think we can talk inheritance in more general term if the article is named as inheritance (computer science). I think we still need to move this article if we have one article named inhertaicne (computer science) because if you read carefully, this article also has a general idea of inhertaince such as expansion, for instance. It is not limited to oop though the tone of the article is completely so. -- User:TakuyaMurata 04:51 6 Jun 2003 (UTC) The disambiguation tag is too specific. When I see Inheritance (object-oriented programming), I am expecting there to be a non-OOP inheritance page in programming, such as Inheritance (functional programming), which does not exist. Inheritance (computer science) is sufficient to disambiguate between inheritance in law and biology, and more specificity is unnecessary. In fact, the disambiguation page for Inheritance states "in computer science", which concedes that that is the field in which this term is apposite. User:Stephen C. Carlson 08:24 6 Jun 2003 (UTC) :You left a key part out. It says "In computer science, inheritance is a feature in object-oriented programming." User:Mbecker 14:47 6 Jun 2003 (UTC) ::Because it is incorrect. I will correct the definition in disambig page. -- User:TakuyaMurata :It is the very fact that inheritance doesn't exist in these other paradigms, that makes Inheritance (object-oriented programming) a better title. Inheritance (genetics) would be a better title than Inheritance (biology) and Inheritance (tax) would be better than Inheritance (state funding). (Although these are all pretty ugly titles in themselves, i.e inheritance tax and genetics do the job perfectly well). User:Mintguy Also John makes a good point about CSS. I must admit I hadn't thought about that myself. Inheritance (Cascading Style Sheets) would be correct for that should someone choose to wirte such an article outside of Cascading Style Sheet. It has little to do with programming and more to do with presentation and layout. It would be confusing it it was included with the rest of this article. But it is obviously part of computer science. User:Mintguy 15:21 6 Jun 2003 (UTC) Martin. The cascading style sheet note is very out of place. User:Mintguy : Remove it then. I thought it was a useful factoid. User:MyRedDice I found a sentence "Inheritance mechanisms can be also found in several language that are not usually considered object-oriented, including Modula-3, Ada 95, and Oberon." (Programming Language Programatics) -- User:TakuyaMurata 21:55 6 Jun 2003 (UTC) :Modula-3 IS an OO language it has classes and inheritance is performed by subclassing. Ada 95 IS also object oriented. Ada 83 wasn't. Oberon supports records bound to procedures and type inheritance it has been extended to be more OO with Oberon-2 and Object Oberon which features classes. User:Mintguy 22:16 6 Jun 2003 (UTC) The definition of that inheritance is an extend a base class is a typical but not quite accurate. You can say Japanese live in Japan but Japanese do live outside Japan like me too. I do admit inheritance is predomintantely used in oop and in the majority of contexts of cs, inheritance means that in CS but wikipedia is not a summary of general case but compact generalization of matters. You cannot ignore the minority. Sorry about the definiition in inheritance which is not good enough. I am looking for a better definition that is not limited only to that in oop sense. -- User:TakuyaMurata 21:55 6 Jun 2003 (UTC) :The article Inheritance (computer science) can discuss inheritance outside of the OOP context then; inheritance in an OOP context is of sufficient depth and complexity to deserve its own article, since that is where it is predominantly (or always, depending on your perspective) used; thus: Inheritance (object-oriented programming). I like the idea of having both. If treated carefully, there need not be any duplication, since inheritance in OOP is likely to be quite different from inheritance in the non-OOP context. -- User:Wapcaplet 22:03 6 Jun 2003 (UTC I can agree with this. Then the article should be named like inheritance in object-oriented programming or something because it can be seen as subtopic of inheritance article in cs. Any problem? -- User:TakuyaMurata 23:49 6 Jun 2003 (UTC) :Well beleive it or not. This article WAS originally called Inheritance in object-oriented programming as was Class in object-oriented programming, Polymorphism in object-oriented programming andAbstraction in object-oriented programming. Other articles on the subject of OOP were variously named and disambiguated to differentiate them from other uses of the pertinent words. Then, somebody decided to make the disambiguation consistent by using the parenthesis. And everybody was happy, until you decided that it had to be changed for some reason. So why move it? What is the point in breaking the consistency of disambiguation. User:Mintguy 08:21 7 Jun 2003 (UTC) Then the decision was probably wrong or right in that time but become wrong now. I remember an article called immutable object. It is mostly discussed in OOP context. But it is also important in languages that adopted reference mode rather than value model, though known far less. And I guess so are other topics that are heavily tied with oop paradigm. Besides, can you tell us the reason why you think (object-oriented programming) suffix is better than (computer science) for disambiguation purpose? To disambiguate, cs is broad enough. -- User:TakuyaMurata 21:40 9 Jun 2003 (UTC) :Taku I have told you the answer to that question too many times already and I am tired of repeating myself. User:Mintguy 03:17 10 Jun 2003 (UTC) :OK this has just occured to me and I'm thinking WTF didn't I realise this before. A possible confusion might arrise from calling the article inheritance (computer science) because of the use of inheritance in genetic algorithms. User:Mintguy 14:55 10 Jun 2003 (UTC) How about we redirect Inheritance (computer science)/object-oriented programming to here, and then when Inheritance (computer science) is created, we can permanently move this article there? I think that since OOP inheritance could be a sub-topic of computer science inheritence, this is a logical way to indicate this. What do you guys think? There really is no need to further disambiguate, until articles on other forms of computer science related inheritence are created. But when they are, I think they should be made as a sub-page of Inheritence (computer science) using a "/". What do you guys think? Is this an aceptable compromise? User:Mbecker 15:16 10 Jun 2003 (UTC) :No "/" is out for sure. Subpages are not favoured on Wikipedia. Anyway I've just thought of a good reason for not renamign the article. See above comment. User:Mintguy 15:23 10 Jun 2003 (UTC) My knowledge of genetic algorithms leads me to believe that it would make another good sub-page of Inheritence (computer science). Even though algorithms could be considered mathimatics, I think that it would be better placed in computer science. Given this, I'm not quite sure what your point is Mintguy? Also, why is / out for sure? Who says it is out for sure? Why is this person/persons right? User:Mbecker 15:32 10 Jun 2003 (UTC) :Inheritance in genetic algorithms is discussed fully in genetic algorithm there is no need to have an article sepifically about inheritance in genetic algorithms because inheritance in that context is 99% of the subject. Also it is not really related to inheritance in OOP. There are no successive generations in an OOP implementation (unless that is what you're modelling, of course). It is the same word but a different context. However a page labelled inheritance (computer science), could be about OOP inheritance or about inheritance in the context of genetic algorithms, it is therefore ambiguous. It should ethier be non-existant or a disambiguation page linking to OOP inheritance and genetic algorithms. User:Mintguy 15:40 10 Jun 2003 (UTC) ---- ====From User talk:TakuyaMurata==== Regarding Inheritance (object-oriented programming): I may be completely wrong, but it appears to me that you don't have a lot of experience with OOP? Maybe you have learned something about inheritence as related to OOP? I'm not sure. But as you can see, a number of people who are experienced feel that OOP Inheritence needs to be a seperate article than Computer Science Inheritence in general. This of course is a perfectly valid idea. You seem to be set on making it part of the (non-existent) Computer Science article? Now, you could probably convince everyone to change the name of the article, but not to Inheritence (computer science). This is b/c people beleive inheritence in an OOP sense warrents it's own article. So, if you have an idea for another name change that you would feel is less confusing to laymen, please put it in the talk. You will not find people agreeing with a move to Inheritence (computer science), however. I noticed that you say on your user page "Often, there is a controversy about my contributions." I think this is one of those cases. Thanks for your input. MB 13:55 10 Jun 2003 (UTC) Actually I do agree that inheritance in oop may deserve to be a separate article. My point is not that inheritance is foundamental or not but we don't use a parenthesis to have a subtopic or we don't disambiguate topics with narrow topic name. (computer science) is a good enough for disambiguation. This is about disambiguation not about OOP at all. -- Taku 14:08 10 Jun 2003 (UTC) Well as you can see, Inheritence (computer science) would be too vauge of a name, so if you don't like Inheritence (object-oriented programming) then maybe Object-oriented programming, inheritence? I can't think of a better name than what we have now, but Inheritence (computer science) is definately not suited. MB 14:16 10 Jun 2003 (UTC) We need to disambiguate inheritance from other completely different topics such as one in biology. It is obvious that inheritance in species have nothing to do with inheritance of classes, for instance. Because inheritance in oop is part of inheritance in cs (I think oop is part of cs), inheritance (computer science) is not a misnomer no matter the article only talks about inheritance in oop or not. I suggested the name inheritance in object-oriented programming because if we have two articles inheritance (computer science) and inheritance (object-oriented programming), the readers might wonder isn't it oop is part of cs? -- Taku 14:22 10 Jun 2003 (UTC) Alright, well this clairifies you POV to me, do you mind if I cross post this to the group discussion? MB 14:40 10 Jun 2003 (UTC) Go ahead. I thought I made a point but probably not. I've just thought of a possible confusion that might arrise from calling the article inheritance (computer science). That is in the use of inheritance in genetic algorithms. Mintguy 14:50 10 Jun 2003 (UTC) Sure. Inheritance in cs can be too vague topic to be concentrated into one article. Allow me to repeat myself for clarification. Again, it really doesn't matter much how a concept of inheritance is treated in cs. I doubt but it may be used only in oop. It may contain more. I have still failed to see the reason we want to limit parenthesis disambiguation to a narrow topic. Disambiguation is needed because sometimes it is unclear what the term refers in that context. Usually simple writting out in English language that is good enough. e.g. Japanese name. Parenthesis disambiguation is usually regarded as rather like hidden parameter. e.g. Chicago (disambiguation). Because it sounds silly if you wrote like Chicago as disambiguation or Disambiguation of Chicago. Inheritance in computer science sounds fine but the trouble is you might wonder what about inheritance in other topics of cs such as inheritance in object-oriented programming and so on. I don't have much preference about how many articles about inheritance. If the article is too long, it should be broke up. If there are too much small topics that are closely realted each other, they can be combined for the sake of readers. -- Taku 20:12 10 Jun 2003 (UTC) ---- The above text is confusing I don't know who said what. But I guess Taku you said "Sure. Inheritance in cs can be too vague topic to be concentrated into one article." :Right. Well the thing is we are talking about a single word, "inheritance" that can mean several distinct things, depending upon the context. In the context of genetic algorithms :It means ... ''the ability of modelled objects to mate, mutate and propagate their problem solving genes to the next generation, in order to produce an evolved solution to a particular problem''. Whereas in context of OOP : It means ... ''to include the pre-defined features of one or more objects in another, whereby complex objects can be modelled by creating a hierarchy of modifications of existing modelled objects. Or in the case of interface inheritance to allow the modification of predefined methods by overriding the implementation''. Do you now see that these are two very different concepts and should not be lumped together, just because they both use the word Inheritance!? User:Mintguy 20:42 10 Jun 2003 (UTC) ---- * Keep it here and make a seperate article for computer science inheritence in general:
Inheritance (object-oriented programming) -- User:JohnOwens, User:Mbecker, User:Wapcaplet, User:Mintguy, User:MyRedDice, User:MartinSpamer * Move it:
Inheritance (computer science) -- User:TakuyaMurata, User:Stephen C. Carlson : looks like the option "Keep it here and make a seperate article for computer science inheritence in general" is winning - and personally, I'm pretty convinced by Mintguy's points. Such an article would be basically a disambiguation page, I guess, but for OOP vs CSS it might want to do a bit of comparing and contrasting as well. : I said before have an end date of July 5th and then just do whatever's most popular - is everyone reasonably ok with that? User:MyRedDice 20:31 1 Jul 2003 (UTC) : I made a demo at Inheritance (computer science) to get an idea of what such a page might look like - Taku, SCCarlson, please feel free to revert it or edit heavily if you disagree. User:MyRedDice 20:41 1 Jul 2003 (UTC) ------- There isn't really inheritance in CSS. The ''document'' the CSS is attached to has a hierarchy of elements. Elements apply styles based on the Cascade. It's rather complicated. Say we have in HTML a P inside a DIV, then a regular P. In CSS we have rules for P and rules for DIV. The first P might inherit DIV rules -- if they apply. The second will not. It gets wven more complex when you throw the class="foo" attribute in -- User:Tarquin 21:39 1 Jul 2003 (UTC) :Are you saying then that professional's don't refer to this as "Inheritence" then? In any case, I think this is a step in the right direction. User:Mbecker 21:47 1 Jul 2003 (UTC) :: HTML elements inherit from their parents in the document tree. CSS rules don't inherit from anything. They may end up being combined by the HTML elements that do the inheriting. But just by looking at the CSS file, there is no way of telling. -- User:Tarquin 21:54 1 Jul 2003 (UTC) : See [http://www.w3.org/TR/REC-CSS1#inheritance W3C CSS Recommendation section "1.3 Inheritance"]. Since the CSS standard uses a word and concept inheritance, it seems safe to say that the standard terminology for CSS is inheritance. Worth noting from that section that CSS inheritance does not always follow HTML/DOM inheritance expectation - it has its own rules for it. User:JamesDay 12:56, 27 Oct 2003 (UTC) ==Wikipedia:Votes for deletion== * class (computer science) - to make a room to rename class (object-oriented programming). * inheritance (computer science) - to make a room to rename inheritance (object-oriented programming). (these were listed by User:TakuyaMurata AKA TakuyaMurata in some edit histories.) **I still cannot see why we want to make an exception for above two articles in naming. Most of programming and cs related articles are named foo (computer science). It is like we have two zero articles because it is used sighly differntly in number theory and set theory. See each talkpage for details. -- User:TakuyaMurata ** Keep inheritance (computer science), it includes two different topics. Move the other one. User:Evil saltine 03:49, 23 Oct 2003 (UTC) *** Both have multiple meanings. User:TakuyaMurata deleted one other for class at 16:12 and listed them both here at 16:20. There's more on the disagreement and more examples at Talk:Inheritance (object-oriented programming) and Talk:Class (object-oriented programming). Class could be moved to (CS) but it makes more sense to keep it with the (OOP) tag like the rest of the OOP articles. ** Rename. Apparently the chief use of inheritance is that in OOP. Wikipedia is an encyclopedia not a textbook. We should discuss as the idea not just as technique. The article should cover history, different approaches and so on. foo (computer science) makes far more sense. -- User:TakuyaMurata **keep both and do not rename OOP to generic computer science. Class (computer science) needs to disambiguate OOP, Windows and other uses for class. Inheritance is also a concept not solely related to OOP. Cascading style sheets (CSS) on web pages are not OOP but are an example of inheritance. User:JamesDay 11:55, 23 Oct 2003 (UTC) **I think you are missing my point. Because they are both not limited to OOP, I want to rename them to more generic term. The question is if we want to regard oop is part of cs or not. -- User:TakuyaMurata ***You're trying to take an article about mammals and make it the article about animals. The specific case is not the same as the general. We could call one (OOP) and the other (CS) but that would be less clear than keeping all of the OOP articles under (OOP). Based on the inaccurate claim about the design of the Windows interface in which was in class(OOP) you might usefully review the difference between structured programming and object-oriented programming. Some research into the theory called abstract data types (taught in universities during the mid 80s, while Windows was being written and before the ADT concept was widespread); callback functions (what the Windows API uses); and the history of the design and development of Windows would also be useful. It would explain why you didn't prevail in the discussons on the talk pages. The lack of OOP in the Windows API is why Microsoft developed MFC to provide an OOP wrapper around it. Living through the evolution of these things is probably why User:Mintguy and others were disagreeing with you then and is why I'm disagreeing with you now. Try adding the OOP concepts which you think are generic to the class and inheritance pages instead and let consensus between those in the field get those accurate and generic. User:JamesDay 01:15, 25 Oct 2003 (UTC) *I cannot believe that nearly 6 months after this issue was decided by a vote in which you lost 6 to 2 (see Talk:Inheritance (object-oriented programming)) you are bringing this subject up again. Please leave the pages as they were. User:Mintguy 21:00, 25 Oct 2003 (UTC)~ **Please don't get emotional. Wikipedia is not a place to contest your POV with others'. Inheritance (computer science) has been looking terrible. The article exists only for the justitifaction of POV that inheritance is not CS but OOP. We are not supposed to teach people don't mess up classes or inheritance in OOP with others in CS. It is not important to show a clear definitions if there is no such. I know in your head the idea of OOP is clear-cut and of course in my head that is clear-cut too. But they differ. Why don't we just stop disputing over the definitions of OOP but simply state general ideas instead of clear-cut definitions and views that we have disagreement. You may say I am the one who is bothering you, which might be true but the truth is the long time doesn't seem to make the situation better. What I don't like is not my POV doesn't prevail. I don't care if I am right or wrong that is why I try to minimize exposing my POVs. What I do care is that the articles are in such a sorry status thank to our dispute. If you think inheritance (computer science) is a good article or would be a good article, show me evidence not one that supports your definition of OOP. -- User:TakuyaMurata 21:37, Oct 25, 2003 (UTC) ** Keep in accordance with the opinion poll on Talk:Inheritance (object-oriented programming)) (and move this discussion there). User:MyRedDice 11:39, 26 Oct 2003 (UTC) **I'm not going to argue with you. I had enough 6 months ago. I will only say this: Myself, User:Stan Shebs, User:JamesDay, User:P3d0, User:Cadr, User:Fubar_Obfusco, User:Mbecker and others, have found it impossible to work on the computer science articles that you keep mangling. Please stop. User:Mintguy 22:02, 25 Oct 2003 (UTC) **You can count me in this list too (User:GRAHAMUK), I have also been having a few problems with some CS topics "mangled" recently. I thought I was alone! Nice to have a support group.... User:GRAHAMUK 00:06, 28 Oct 2003 (UTC) **I'd rather consolidate them each into one article at the (computer science) location. Discuss the computer science concept of class generally (without reference to specific features of either OOP or window classes), since there's a ton of overlap, and then link to sub-articles if additional explanation is necessary. Same with inheritance: the basic idea with both OOP and others (CSS, etc.) is that attributes are inherited; only details differ. --User:Delirium 03:47, Oct 28, 2003 (UTC) No. No. No, to the last anon IP editor of this article. Inheritance and OOP are NOT about code reuse. If you want to resuse code you can just cut and paste it. It;'s about maintaining an understandable and updateable model of the problem. I'm reverting. User:Mintguy 22:17, 2 Nov 2003 (UTC) ---- I absolutely agree that Inheritance is the wrong way to go for code reuse. However there are other OOP concepts that directly support code reuse ( such as subtype polymorphism (which not the topic, in a page on Inheritance)). Sorry if my edits provoked the revert. But cut and paste is not scaleable, and if OOP is not the way to go then what? There is a point where cut and paste fails an 'understandable and updateable model'. There has got to be a way for programmers to get past the cut and paste impasse. User:169.207.90.93 23:09, 2 Nov 2003 (UTC) * Perl programmers: see [http://wiki.slowass.net/assemble.cgi?PerlDesignPatterns] ---- :The point is the motivation for OOP and inheritance is not or should not be code-re-use. I've not edited this article for a while because of a dispute, but I just saw red with re-use being mentioned prominently in the first paragraph, so I just revertted it. But looking at it now (even before your last edit), I see that re-use is still over-emphasised. Promoting re-use as a motivation for inheritance completely misses the point of constructing sensible models. If an inheritance heirarchy is constructed for the sole purpose of code re-use it can lead to labyrinthine ineritance graphs that make it difficult to figure out which class control flow is going to pass to. User:Mintguy 09:03, 4 Nov 2003 (UTC) ---- :That implies that inheritance is not a 'silver bullet' for code re-use, and that some other concept be used instead, to accomplish the goal; why bother to cast things this way if inheritance just creates problems. I don't understand what you mean by the 'goal' of code re-use. Code re-use isn't an aim, it's a method of achieving the aim (of er... who knows?). What use is code-reuse in itself? I don't know. Inheritance on the other hand is principally a method of making specialist objects from generic base classes. Once a definitive specialist class has been constructed it should be the final leaf on the inheritance tree and should not be used as a base class for some kind of mutated version which ignores most of the previously defined behaviour. In other words inheritance should be generally inclusive and adaptive upon base class behavior and not exclusive of it. OO inheritance it not like genetic inheritance where attributes are lost aswell as gained. If you were writing an OO model of animal life you would be foolish to inherit Bird from Dinosaur. User:Mintguy By the way, Perl has an @ISA construct embedded in the language, which is Perl's method of implementing multiple inheritance. And you can dynamically change the hierarchy 'on the fly', in Perl. Tom Christiansen's ''perltoot'' has details, for example. User:169.207.88.201 09:19, 4 Nov 2003 (UTC) ----

See other meanings of words starting from letter:

I

IA | IB | IC | ID | IE | IF | IG | IH | IJ | IK | IL | IM | IN | IO | IP | IR | IS | IT | IU | IW | IX | IY | IZ |

Words begining with Inheritance_(object-oriented_programming):

Inheritance_(object-oriented_programming)
Inheritance_(object-oriented_programming)