You can't have methods with the same name in the same class in Smalltalk. Why?
I don't understand why methods can't have same name in same class.
You are probably thinking about function overloading in languages like C++ in which you can have multiple functions/methods with the same name but different parameter types or count. The difference is that in dynamic programming languages like Smalltalk the type is associated with the object not the variable and so a variable can hold any type and the compiler doesn't know the type. So there would be no way to distinguish between functions/methods with the same name.
Is it correct to define a type within an interface? And what about an attribute?
Some programming languages only allow method signatures for an interface, but in ABAP I was considering doing something like the code below, even adding more attributes, and I'm not sure if the approach is a correct OOdesign:
INTERFACE zif_notif_note.
TYPES: BEGIN OF ty_note_id,
notif_num TYPE qmnum,
activity_key TYPE aknum,
END OF ty_note_id.
DATA: id TYPE ty_note_id READ-ONLY.
METHODS get_id
RETURNING VALUE(r_id) TYPE ty_note_id.
ENDINTERFACE.
What if I need to use this type as an input parameter for another class? Should I better define DDIC structure then?
To your first question: nothing speaks against defining a type in an interface.
To your second question...
You can do many things in ABAP OO that you cannot do in other object oriented languages like Java or C++. For example you can define a FINAL ABSTRACT CLASS which is nonsense, you can define static methods (CLASS-METHODS) in an interface which is in my opinion a heresy towards the object oriented programming.
I have never defined attributes unless they were CONSTANTS within an interface, because there is no reason for doing it. They will be automatically marked as PUBLIC which breaks in fact the encapsulation principle.
So the answer would be: It is possible but think twice before going that way because it might be breaking the encapsulation of the classes that implement the interface.
I'm having trouble finding the standard way a class diagram should be drawn for objective C applications. Mostly:
Do I incude field types or just the var name?
Do I include method return types and parameters?
Thank you!
Many of the Objective-C diagrams I have seen do not include types or parameters. Only the field and method names are placed in the diagram.
However, I would strongly encourage you to include all this information, regardless of what the norm may be. By doing so, the class diagram is not only useful for modelling, but also serves as documentation. It's not particularly difficult to add the type annotations, and the end result is a far more complete (and useful) picture of the class.
Document them the same way you would document a class in any other object oriented language. Class properties should include the field type, property name and multiplicity. Class methods should include return types and parameters.
Suppose you have an imaginary type system for an imaginary scripting language which is written in C++ (for example), and each type (and object) in the scripting language has a corresponding type (and object) in the underlying implementation language. The base class in this imaginary type system is a class called Object, and all other classes must derive from this class. Now, you have another class called HashTable, which is the basis for all variable storage (I might have said that wrong): namespaces are implemented via HashTables (associating one object with another object), global variables are stored via HashTables, and, to the point of the problem, instance variables are also stored in HashTables.
Instance variables are such that every Object has an HashTable in which to store its instance variables. However, HashTable necessarily derives from Object, therefore each HashTable has an HashTable in which to store its instance variables. And every HashTable for every HashTable has an HashTable, and so on ad infinitum.
My question is, can this type system be implemented in an object-oriented way in the underlying C++ code? If no precautions are taken, the program will enter an infinite loop and cause a stack overflow on the mere instantiation of an Object, because it will instantiate an HashTable which will call its parent constructor for Object, which will instantiate an HashTable...
Are there any viable workarounds for this design flaw which don't involve breaking the desired OO design (each type has its corollary type in the underlying code)?
Pardon the grammar in this post, English is not my first language and I might not have explained something in a comprehensible manner.
implement two different HashTable types: one for user code (UserHashTable), derived from Object and so no violating your "everything is Object" rule, and another for internal use (CoreHashTable) to implement your type system.
[EDIT] CoreHashTable can be automatically convertible to UserHashTable, e.g. UserHashTable can contain internal smart pointer to CoreHashTable.
Yes. You can emulate your own "object system" with another programing language.
That concept its called a "virtual object system".
O.O. Programming languages have its own "Object System". By an "Object System", I don't mean "O.O. libraries or O.O. Class hierarchy". By an "Object System" I mean its way of declaring and using classes and objects.
But, sometimes, your programming language its not object oriented, or even if its object oriented, some stuff is missing. C# and Java doesn't have real properties & events, C# and Object Pascal does.
When O.O. started, many programmers use non O.O. programming languages, and learn about O.O. Some make their own "plain C" to "C++" preprocessors (Objective-C maybe), some did full compilers.
And some emulate them. The programmer, conceptually, thinking, he was using classes and objects, but, in code, use structures & pointers.
I have seen several "virtual object system (s)", where a group of classes or objects is simulated by another programming language.
Once, I worked with a database conectivity tool called "Borland Database Engine", where developers read and write data into objects like "databases", "tables", "fields".
One famous, is the GLib library ("GObject" is the root object), used in the GNome visual interface for GNU/Linux. It's done in "plain C", but simulates objects and classes, using pointers.
More Info:
http://en.wikipedia.org/wiki/Gobject
You want to use a group of objects conceptually speaking, but in code, you won't have a class declaration for your conceptual class, but, some data stored in hash tables, using another O.O. programming language. Yes it can be done.
A friend who is new to OO programming asked me the difference between a Member and Property, and I was ashamed to admit that I couldn't give him a good answer. Since properties can also be objects themselves, I was left with a general description and list of exceptions.
Can somebody please lay out a good definition of when to consider something a member vs. a property? Maybe I'm bastardizing the concept, or is it just that a member is just the internal name I use, and the property is what's exposed to other objects?
I don't think that not knowing the answer to this question has affected the quality of my programming, and it's just a semantics point, but it still bothers me that I can't explain it to him.
A property is one kind of member. Others might be constructors, methods, fields, nested types, conversions, indexers etc - depending on the language/platform, of course. A lot of the time the exact meaning of terminology depends on the context.
To give a C#-specific definition, from the C# 3.0 spec, section 1.6.1:
The following table provides an overview of the kinds of members a class can contain.
(Rows for...)
Constants
Fields
Methods
Properties
Indexers
Events
Operators
Constructors
Destructors
Types
Note that that's members of a class. Different "things" have different kinds of members - in C#, an interface can't have a field as a member, for example.
Neither of the two terms has any defined meaning whatsoever in Object-Oriented Programming or Object-Oriented Design. Nor do they have any defined meaning in the overwhelming majority of programming languages.
Only a very small number of programming languages have a concept called property or member, and even fewer have both.
Some examples of languages that have either one of the two are C++ (which has members), ECMAScript (which has properties) and C# (which has both). However, these terms don't necessarily denote the same concepts in different programming languages. For example, the term "member" means roughly the same thing in C++ and C#, but the term "property" means completely different things in ECMAScript and C#. In fact, the term "property" in ECMAScript denotes roughly the same concept (ie. means roughly the same thing) as the term "member" in C++ and C#.
All this is just to say that those two terms mean exactly what the relevant specification for the programming language says they mean, no more and no less. (Insert gratuitous Lewis Carroll quote here.)
Properties is one kind of members.
In C#, for example, a class can have the following members:
Constructors
Destructors
Constants
Fields
Methods
Properties
Indexers
Operators
Events
Delegates
Classes
Interfaces
Structs
MSDN: C#: class
Members are just objects or primitive types belonging to a class.
Properties give you more power than members. It's like a simplified way to create getters and setters letting you make, for instance, public getters and private setters; and put whatever logic you want in the way it will be read or written to. They can be used as a way to expose members, being possible to change the reading and writing policy later more easily.
This applies to C#. Not sure if this is true for the other languages though.
A member (variable) is just some part of the object. A property is (I'll qualify this with "usually" - I'm not sure that it's a technically clear word that has unambiguous meaning across multiple languages) is a publicly accessible aspect of the object, e.g. through getter and setter methods.
So while (almost always) a property is a reacheable member variable, you can have a property that's not really part of the object state (not that this is good design):
public class Foo {
public String getJunk()
{ return "Junk";}
public void setJunk(String ignore){;}
}
}
Both properties and methods are members of an object. A property describes some aspect of the object while a method accesses or uses the owning object.
An example in pseudo-code:
Object Ball
Property color(some Value)
Method bounce(subroutine describing the movement of the Ball)
Where the ball is defined and given a color(property) while the method bounce is a subroutine that describes the how the ball will react on hitting another object.
Not all languages have properties, i.e. Java only has fields that must be accessed by getters and setters.
Properties are a way to expose fields, where fields are the actual variables. For example (C#):
class Foo {
private int field;
public int Property {
get { return field; }
set { field = value; }
}
}
from PHP manual:
Class member variables are called "properties". You may also see them referred to using other terms such as "attributes" or "fields". They are defined by using one of the keywords public, protected, or private, followed by a normal variable declaration. This declaration may include an initialization.
Member is a generic term (likely originated in C++, but also defined in Java) used to denote a component of a class. Property is a broad concept used to denote a particular characteristic of a class which, once the class is instantiated, will help define the object's state.
The following passages, extracted from "Object-Oriented Analysis and Design" by Grady Booch help clarify the subject. Firstly, it's important to understand the concepts of state and behaviour:
The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties. By properties, we mean the totality of the object's attributes and relationships with other objects.
Behaviour is how an object acts and reacts, in terms of its state changes and message passing (methods); the outwardly visible and testable activity of an object.
So, the behaviour of an object depends on the available operations and its state (properties and their current values). Note that OOP is quite generic regarding certain nomenclature, as it varies wildly from language to language:
The terms field (Object Pascal), instance variable (Smalltalk), member object (C++), and slot (CLOS) are interchangeable, meaning a repository for part of the state of an object. Collectively, they constitute the object's structure.
An operation upon an object, defined as part of the declaration of a class. The terms message (Smalltalk), method (many OO languages), member function (C++), and operation are usually interchangeable.
But the notation introduced by the author is precise:
An attribute denotes a part of an aggregate object, and so is used during analysis as well as design to express a singular property of the class. Using the language-independent syntax, an attribute may have a name, a class, or both, and optionally a default expression: A:C=E.
An operation denotes some service provided by the class. Operations (...) are distinguished from attributes by appending parentheses or by providing the operation's complete signature, composed of return class, name, and formal arguments (if any): R N(Arguments)
In summary, you can think of members as everything that composes the class, and properties as the members (attributes) that collectively define the structure of the class, plus its relationships to other classes. When the class is instantiated, values are assigned to its properties in order to define the object's state.
Cheers