OOP Terminology across languages?

I am trying to learn OOP best practices. My language is PHP, but I know it is not an OOP-first language. So I frequently read things like java articles on oop methodology and become lost on terminology.

For example, some languages refer to the parent class as the base class or the super class (I think).
PHP refers to variables within a class as properties, and functions as methods, and the collection of both as a classes members.

I am looking for things like that. Same thing for abstract classes, traits, namespaces, interfaces, etc. Just a general reference for OOP terminology so I can learn from other language’s OOP practices.

In fact, “parent class” isn’t quite the same as either “base class” or “super class”.

The way I use these terms, the “parent” is the immediate parent: the one on which a class is directly based. The “base” class is the ultimate ancestor, going back as far as you can go. A “super class” is any ancestor; so that might be the parent, the base class, or anything in between.

As I said, that’s the way I use those terms. But I don’t know if that usage is strictly correct. But I’m not sure if it matters all that much. It’s not as if those particular words form part of the syntax of the language. In any case, I’ve never had a problem in understanding the terminology when moving from one language to another.

Perhaps someone else will answer your main question: where to find a general reference to these terms. My advice would be not to worry too much about it.

Mike

I am trying to understand OOP better, and much of the theoretical material is written for other languages. I am having trouble understanding OOP design materials I occasionally come across. So that’s why I am (still) interested in this.

It’s fine if you only mention the language that you know. I doubt anyone knows the terminology across modern languages.

“I doubt anyone knows the terminology across modern languages” should read: “I doubt anyone knows the terminology across all modern languages.”

I think the edit time expired for my post so I couldn’t revise.

Honestly, why not learn Java while learning OOP principle? I understand you may or may ever use Java but I really think it’s a MUST skill to have as it’s #1 demanded IT technology in current job market. Since you know PHP, you should be able to easily pickup Java. I can understand how you get lost in OOP just by talking about concepts w/o real example coding. Best way to learn OOP is to actually write the code and understand inside out. Once you become comfortable in Java and then you can get some books that focuses on Java Design Patterns (it’s just basic OOP design patterns). It will be very fun.

I agree that by learning Java one would learn OOP.

But it is different from PHP
It is not as “loose” and it is not as forgiving of mistakes. (oh those stack traces!)
It is compiled so it requires an extra step or two to test changes.

That said, I like Java a lot, I think the documentation is good (once you get used to it), and I do find it fun to work with.
If you don’t mind working from the command line, (or with an IDE) give it try.

Thats an interesting point of view, I kinda agree with you I must say. I personally prefer the terms parent/child class better since it clearly demonstrates the idea of ‘Inheritance’. Not saying that the other terminologies do not give rises to inheritance, just not as much as when you are calling class relationship as parent/child.

I’ll try and define some of those terms as I understand them.

[indent]

abstract class
a class that cannot be instantiated directly but only once subclassed with all the necessary parts of its implementation (abstract methods) supplied.

traits
In Ruby and some other languages these are called mixins. They are basically collections of methods that can be included, so to speak, into a class. A class can include more than one mixin which is a pretty big deal

namespaces
bounding box for declarations of all kinds. Before namespaces in PHP everything declaration could be thought of as existing in a single, global, namespace. The ability to name and create namespaces explicitly allows declarations to be divided up greatly reducing the chance of name collisions. Multiple namespaces can be imported into any one scope

interfaces
a set of method signatures that act as a type for purpose of type-checking. Any class that implements those methods can declare itself as such and instances of that class will then type check as instances of the interface. Interestingly Golang doesn’t have the requirement of a class having to explicitly state it implements a particular interface; the compiler just checks if the required methods are there and if they are then the instance will pass as a instance of that interface.[/indent]

My language is PHP, but I know it is not an OOP-first language.

No PHP isn’t purely object-oriented but the distinction really isn’t very important from your standpoint. PHP has a butt-load of OOP features. You can do OOP in PHP just fine. That’s all that matters.

I am trying to understand OOP better, and much of the theoretical material is written for other languages. I am having trouble understanding OOP design materials I occasionally come across. So that’s why I am (still) interested in this.

Can you post an example of a specific thing you are having difficulty understanding? Perhaps we could help you with that.

Honestly, why not learn Java while learning OOP principle? I understand you may or may ever use Java but I really think it’s a MUST skill to have as it’s #1 demanded IT technology in current job market.

You can get jobs doing functional programming or UI stuff without any experience with OO so I don’t think you can really call it a must skill. But then I suppose programming as a whole isn’t a must skill either so it really depends what you want to do. There are enough jobs in programming that you do have some choice where you want to put your focus. If you like to be safe and go with what is popular than, yes, learning OOP, and probably Java, is a very good idea indeed. Personally speaking, I’m quite happy to deviate from convention but nevertheless spent a long time trying to figure out how to do OOP robustly on the basis of what it was supposed to do. I ended up concluding that it doesn’t live up to its claims and its limitations cannot be easily surpassed without starting to do something resembling some other kind of programming, at which point you might as well just do that other kind of programming.

A very useful post, Parallelist. You’ve made some good points.

I’d only take issue with one very minor point. You said an abstract class is a "class that cannot be instantiated directly but only … subclassed … ". I would prefer to say “is not intended to be instantiated directly”, rather than cannot be instantiated directly. In the languages where I work, there would be nothing to stop you instantiating an abstract class, but it would defeat the purpose to do so. In other words, it’s a design feature rather than a language rule. But no doubt that varies across languages. Perhaps in some languages you explicitly declare a class to be abstract?

Mike

In the languages where I work, there would be nothing to stop you instantiating an abstract class
Sure. Not all languages allow you to make the intent explicit. (The intent in this case being that instantiating the class without subclassing it first is a pretty useless thing to do).

You can in PHP explicitly declare a class as abstract:



php > abstract class Foo {}
php > $a = new Foo;

Fatal error: Cannot instantiate abstract class Foo in php shell code on line 1

I always presumed this was an idea borrowed from Java. It’s quite nice because it tells you want the intent of the class is and gives you a guarantee that no-one else has come along later and undermined that original intent.

There are downsides to this restriction occasionally though. It is really annoying is something has been declared as abstract when it isn’t. And languages where adding methods at runtime is normal are unlikely to have an equivalent of an abstract keyword. It would get in the way of their metaprogramming.

Thanks for clarifying that, Parallelist. It’s an interesting point.

MIke