I know for static variation we use inheritance and for dynamic we use Object composition. Can someone provide me short examples whether how Object composition is Dynamic and Inheritance is Static?
A Component(module) can be replaced, removed, or added at runtime (dynamic binding). On the contrary, inheritance can't or very hard (depending on the programming language) to be replaced, removed, or added features at runtime (static binding).Please refer below link for example [link]http://www.kbasm.com/oop-prefer-composition-over-inheritance.html
Related
I am following gobject tutorial and I see there is one method which is install_proprties() which installs properties which later can be used to by set_properties and get_properties. My question is why do we need install_properties instead can we have fields directly in instance structure like in C++ or Java ?
GObject is an object oriented framework on top of C; this means that it has to provide functionality on top of a smaller language, without the syntactic sugar of higher level languages, such as C++ or Java.
In the case of properties, GObject has to define "named fields" at run time, to allow introspection — i.e. the ability to query an object type for its capabilities — as well as generic access and change notification. These named fields do not necessarily map to a field in the instance structure: they can be read-only or write-only; they can be computed on the fly; they can be used only at construction time.
Other languages may have these capabilities as well, but they are usually exposed through the language's own syntax; this cannot happen in GObject/C.
I'm currently learning Smalltalk in the Squeak environment and I'm reading "Squeak - A Quick Trip To ObjectLand". I enter the object-oriented paradigm with some prior knowledge from Python and Java and this sentence from the book on page 36 has made me think:
Smalltalk is a class-based implementation of an object-oriented language.
Short sentence but very interesting. In OO all terms like class, object, instance seem to be well-defined and seem to point to the one and only true meaning and you're likely to come across generic sentences like "objects are instances of a class".
But you hear seldom about implementation strategies. What does implementation of the object-oriented concept mean in this case? Are there implementations of OO languages other than classes?
Javascript is a prototype based implementation of an OO language.
Instead of subclassing a class and creating an instance of that new class, you inherit behaviour by cloning a prototype.
As a historical note I should add that while Javascript is probably the most widely used prototype-using language, the first was David Ungar's and Randall Smith's Self language.
There are several implementations of prototypes floating around for Squeak. I haven't used them, so I can't comment on the libraries.
I never saw, but read about Emerald, that is object-oriented but neither class- nor prototype-based but seems to construct objects "one by one" with the help of a special constructor:
However, Emerald objects do not require a Class object for their creation. In most object-based systems, the programmer first specifies a class object that defines the structure and behavior of all its instances. The class object also responds to new invocations to make new instances.
In contrast, an Emerald object is created by executing an object constructor. An object constructor is an Emerald expression that defines the representation, the operations, and the process of an object.
See Andrew Black, Norman Hutchinson, Eric Jul, and Henry Levy: "Object Structure in the Emerald System".
In the discussion on The Myths of Object-Orientation, Tim Sweeney describes what he thinks is a good alternative to the all-encompassing frameworks that we all use today.
He seems most interested in typeclasses:
we can use constructs like typeclasses to define features (like persistence, introspection,
identity, printing) orthogonally to type constructs like classes and
interfaces
I am passingly familiar with type classes as "types of types" but I am not sure exactly how they would be applied to the fore-mentioned problems: persistence, printing, ...
Any ideas?
My best guess would be code reuse through default methods and orthogonal definition through detachment of type class implementation from type itself.
Basically, when you define type class, you can define default implementations for methods. For example Eq (equality) class in Haskell defines /= (not equal) as not (x == y) and this method will work by default for all implementation of the type class. In a similar way in other language you could define a type class with all persistence code written (Save, Load) except for one or two methods. Or, in a language with good reflection capabilities you could define all persistence methods in advance. In practice, it is kind of similar to multiple inheritance.
Now, the other thing is that you do not have to attach the type class to your type in the same place where you define your type, you can actually do it later and in a different place. This allows persistence logic to be nicely separated from the original type.
Some good examples in how that looks like in an OOP language are in my favorite paper ever: http://www.stefanwehr.de/publications/Wehr_JavaGI_generalized_interfaces_for_Java.pdf. Their description of default implementations and retroactive interface implementations are essentially the same language features as I have just described.
Disclaimer: I do not really know Haskell so I might be wrong in places
I am reading an article on extension of interface at following link.
http://wiki.hsr.ch/APF/files/ExtensionInterface.pdf
It has been mentioned here on page 142
Over time the addition of these requests can bloat the interface with
functionality not anticipated in the initial framework design. If new
methods are added to the "universalComponent" interface directly, all
client code must be updated and recompiled. This is tedious and
error-prone.
My question is (Assume we are using C++ to develop)
Why we have to compile client code if we add new methods to interface and not
modifying any existing functions in interface?
Thanks!
I haven't read the article, but for starters, I would suggest to de-emphasize the terms "method" and "interface" in C++. Those terms are popular in strict OO languages like Java, but C++ is a broader, multi-paradigm language.
With that said, "adding methods to interfaces" is really just adding more virtual member functions to a base class. Changing the base class changes the definition of all derived classes, and thus all code that requires the complete type of any derived class or of the base class must be recompiled.
C++ types are not a runtime feature. Types only exist at compile time, and the compiler must have full access to the type definitions. (Again in contrast to other languages!) The interface-implementation relationship exists purely at compile-time and cannot be "precompiled". So there's really no such thing as "modifying the interface" that would produce runtime-modularity. The "interface" concept is just a neat mnemonic that you can use when designing your application, but it does not save you from recompiling. Changing a class definition changes the internal representation of the class, and you cannot (in general) make a correct C++ program unless all parts of the program see the same class definitions.
Adding a method to a class that is involved in polymorphism (means it has at least one virtual member function) potentially changes the binary layout of objects of that class and it's subclasses.
I do not understand how to simulate genericy using inheritance, I am consulting the article "Genericity versus Inheritance" of Bertand Meyer, but I still do not understand it. I would apreciate a clearer explanation.
In some programming languages you can simulate genericy using inheritance with abstract type members.
Here is an example using scala. It should be understandable even if you don´t know scala.
class Collection {
type T;
//all methods are using T for the contained type.
}
I´m not sure but in c++ type would be typedef.
Following this approach you can get a collection with elements of type A by subtyping the collection and specifying type T to A:
class IntCollection extends Collection {
type T = Int;
//...
}
This solutions has some shortcomings in relation to generics or templates but also offers benefits.
If you are interested then consider reading this:http://www.artima.com/weblogs/viewpost.jsp?thread=270195
Abstract Type Members versus Generic Type Parameters in scala.
again you don´t have to know scala to understand the post.
edit: to cite just one sentence:
At least in principle, we can express every sort of parameterization as a form of object-oriented abstraction.
Hope that helped
Generics are needed only in static typed languages (or those with type-hinting) - because you do not want to lose that hardly acquired type-safety.
If your (static) language does not have them, it's probably time to think about different one - simulating using inheritance is ugly hack.
Or better - think about dynamic languages and test driven development. You'll gain much more power (everything is generic, no need for typing) and tests will represent your contract - including concrete examples - which is what even the best type-safe abstraction simply can't do. (because it's abstract)
In the general case, you can't do it. That's why OO languages have had things like templates and generics added to them. For example, all attempts to create generic containers in C++ prior to the introduction of templates foundered or were almost completely unusable.