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.
This question may seem open-ended but I am not sure where or how else to ask this. When writing object-oriented code one must determine the objects, methods and properties associated with what they're writing. I have a hard time doing this and so I am wondering if there is software or some sort of template that is out there to help me out with this.
For example if my object is a Car a few methods could be .engineStart(), .closeDoor(doorNumber) and a few properties could be color, make, licensePlateNumber.
Does anyone have a format or technique that they use to identify all the objects, methods, and properties before they actually start coding?
A class should handle a single aspect of the system to be built in the context of the chosen design.
An interface should be minimal (no sugar and convenience functions). This means that if you can realize a use case with a subset of the interface a function which would realize that use case should not be a member function.
Example:
class Foo
{
public:
void TurnLeft(uint32_t radians);
void TurnRight(uint32_t radians);
// Bad - interface not minimal and this is a convenience function.
void TurnLeftThenRight(uint32_t radiansLeft, uint32_t radiansRight);
};
A class should be an abstraction of sorts. This means, that it should not require all implementation details of the class and the full understanding of all its requirements used to implement it when using the class. Using the class correctly should be easier than implementing it.
A class should not simply "export" all state it encapsulates by means of properties as then it would not be an abstraction but simply a group of data.
For a class to be of practical use, it will make assumptions about the context it finds itself in and the general architecture. (Threading, memory usage policies, stack usage (recursions yes/no), exceptions yes/no, ...). Trying to factor all that out of the class or turn it into a multiple template parameter monster usually is not an optimal strategy for application programming.
A class implementation should have a unit test and some form of documentation about it's constraints and assumptions taken.
Class methods should be implemented in a defensive style. I.e. before optimization and tuning phase, a class should check input arguments and if possible also its output arguments and state against its constraints.
When thinking about the design of your program take into account:
The classes, methods and data needed.
Relationships among and between your classes.
How the information will be stored, etc.
So just try making a very detailed description of your program and what you want it to do. Then run through your description and pick out certain nouns and verbs that could help you specify things such as objects, attributes, and methods. From here you can then see how you would like to maybe organize your classes and data. Try not to make one class too complex or too small either.
Not sure if this is what you wanted, but I hope I could help.
Well when you start coding you need to determine what needs to be associated with what. Meaning, I know I have a car with all of these properties. So I need a car class with the following properties: color, make, plate number, gas mileage. Now I want to know how much this car is average. I can make a function in the car class specifically for the object that can be called to generate a price based off of parameters I input OR by the properties of the object itself.
This might not help or make sense but as you code you will see when and where to use classes.
can i have same method name with same params and params type in a single class? how about in a different class with same name?
In response to the first part is the ans overriding? what about the second part of the questions "how about in a different class with same name?"
I think there a few examples in which the answer to both your questions is yes, but as far as my knowledge in Java and Objective C is concerned, you cannot have two methods named exactly the same with same parameter names and types in the same class. I believe that you can in two different classes, but you generally shouldn't, just to keep your code simple and easily understandable, but you can do it all the same.
I was reading a VB.NET code and there was the following:
Structure MyRecord
"some code here"
End Structure
Then he use it as if it is a Class. So, what is the "Structure" ??
IS it only in .NET ,or there are similar things in other language??
Something else,in the same code there are:
Dim num As integer=FreeFile()
what does that mean?,can we put a function in a variable in VB?
If we can, then what does that mean??
1
A structure is used to define a value type, just as a class is used to define a reference type. However, a structure is more complicated to implement correctly than a class, so you should stick to classes until you really need to implement a value type. The structure in the example should probably also be implemented as a class instead.
There are structures in other languages, but they may be handled differently. In C++ for example a structure is used to define a type, and the usage determines if it's a value type or a reference type.
2
Yes, you can put a reference to a function (i.e. a delegate) in a variable, but that's not what that code does. It simply calls the function and puts the return value in the variable.
Via startVBdotnet.com:
Structures can be defined as a tool
for handling a group of logically
related data items. They are
user-defined and provide a method for
packing together data of different
types. Structures are very similar to
Classes. Like Classes, they too can
contain members such as fields and
methods. The main difference between
classes and structures is, classes are
reference types and structures are
value types. In practical terms,
structures are used for smaller
lightweight objects that do not
persist for long and classes are used
for larger objects that are expected
to exist in memory for long periods.
We declare a structure in Visual Basic
.NET with the Structure keyword.
Generally, I would suggest implementing a class instead of a structure. This way you can use inheritance and general Object Oriented Design later, if needed.
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