So, I'm in Xcode and programming a small program from a friend.
I want to initialize several instances of an object, put them in an array and then iterate through it (via a function that returns a string). Each object adds some text to that string when it's iterated, depending on the variables of the object.
Let's say the class is Tree. The variables in the class are name (string), height(int) and a hasLeaves(bool)(weather it currently has leaves on it or not). I could easily print:
"This is a name that is height meters tall and has leaves.
The problem is that I want the string to be a bit different, depending on which kind of tree it is. Like this:
The oak(name) is big and lifeful, it's height meters tall and has leaves.
Apple trees(name) carries some apples, it's height meters tall and has leaves.
If you ever visit Sweden you should check out the firs(name), they are height tall and haven't got leaves.
I don't want you to write the code for me, but give me a clue. I don't know what to look for. I was thinking about creating a subclass for each Tree, but every subclass would only appear once in the program and I don't know if it's necessary or not.
As you recognize, I'm having a hard time even formulating this question, but if you understand my intentions I'm glad for any clue I can get.
Edit: So this is my attempt to show it in code:
Class:
class tree {
var treeHeight: Int?
var treeWidth: Int?
var hasLeaves: Bool
var treeString: String
init (height: Int?, width: Int?, leaves: Bool, theString: String) {
self.treeHeight = height
self.treeWidth = width
self.hasLeaves = leaves
self.treeString = theString
}
}
Main function:
var oak: tree = tree(height: 1, width: 2, leaves: true, theString:"Oh, the mighty oak")
var appleTree: tree = tree(height: 1, width: 2, leaves: false, theString: "Yummy Apples")
var treeArray: Array = [oak, appleTree]
var resultString = "This is the stories of the trees: "
for tree in treeArray {
if tree.hasLeaves == true {
resultString = resultString + tree.theString
}
}
So, I want the string added to the "resultString" to be different, depending on what kind of tree it is, but I don't want to set that string in the initialization of the object, but rather from what "kind" of tree it is. Does that make it easier to understand?
I want the string (treeString) to be static depending on what "kind" of tree it is. So if it is an oak, the string is always "Oh, the might oak".
It sounds like you want a tree class with some properties like leaves, etc. Maybe you also want to subclass leaves with additional properties like color, etc. I recommend the WWDC 2014 video:
http://youtu.be/W1s9ZjDkSN0
Somewhere around 30 minutes they have a demo of a Car class with RaceCar at subclass.
Regarding creating the objects, you can build each object individually and then collect them in an array as one option. For example, maybe in a form on your app the user inputs data for a class or subclass and then you create an object, store to a master array which you then archive to a file.
So, if anyone stumbles in to this question, this is what I learned:
I was looking for subclasses and protocols. There are methods to determining whether an object is of a certain subclass, and in my case, I could have a protocol called "Tree" with certain methods and/or methods, and then make subclasses to this protocol, called "oak" and "fir".
I am starting studying OOP and I want to learn what constitutes a class. I am a little confused at how loosely some core elements are being used and thus adding to my confusion.
I have looked at the C++ class, the java class and I want to know enough to write my own pseudo class to help me understand.
For instance in this article I read this (.. class attribute (or class property, field, or data member)
I have seen rather well cut out questions that show that there is a difference between class property and class field for instance What is the difference between a Field and a Property in C#?
Depending on what language I am studying, is the definition of
Property
Fields
Class variables
Attributes
different from language to language?
"Fields", "class variables", and "attributes" are more-or-less the same - a low-level storage slot attached to an object. Each language's documentation might use a different term consistently, but most actual programmers use them interchangeably. (However, this also means some of the terms can be ambiguous, like "class variable" - which can be interpreted as "a variable of an instance of a given class", or "a variable of the class object itself" in a language where class objects are something you can manipulate directly.)
"Properties" are, in most languages I use, something else entirely - they're a way to attach custom behaviour to reading / writing a field. (Or to replace it.)
So in Java, the canonical example would be:
class Circle {
// The radius field
private double radius;
public Circle(double radius) {
this.radius = radius;
}
// The radius property
public double getRadius() {
return radius;
}
public void setRadius(double radius) {
// We're doing something else besides setting the field value in the
// property setter
System.out.println("Setting radius to " + radius);
this.radius = radius;
}
// The circumference property, which is read-only
public double getCircumference() {
// We're not even reading a field here.
return 2 * Math.PI * radius;
}
}
(Note that in Java, a property foo is a pair of accessor methods called getFoo() and setFoo() - or just the getter if the property is read-only.)
Another way of looking at this is that "properties" are an abstraction - a promise by an object to allow callers to get or set a piece of data. While "fields" etc. are one possible implementation of this abstraction. The values for getRadius() or getCircumference() in the above example could be stored directly, or they could be calculated, it doesn't matter to the caller; the setters might or might not have side effects; it doesn't matter to the caller.
I agree with you, there's a lot of unnecessary confusion due to the loose definitions and inconsistent use of many OO terms. The terms you're asking about are used somewhat interchangeably, but one could say some are more general than others (descending order): Property -> Attributes -> Class Variables -> Fields.
The following passages, extracted from "Object-Oriented Analysis and Design" by Grady Booch help clarify the subject. Firstly, it's important to understand the concept of state:
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.
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.
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.
Class variable: Part of the state of a class. Collectively, the class variables of a class constitute its structure. A class variable is shared by all instances of the same class. In C++, a class variable is declared as a static member.
In summary:
Property is a broad concept used to denote a particular characteristic of a class, encompassing both its attributes and its relationships to other classes.
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.
Class variable is an attribute defined in a class of which a single copy exists, regardless of how many instances of the class exist. So all instances of that class share its value as well as its declaration.
Field is a language-specific term for instance variable, that is, an attribute whose value is specific to each object.
I've been doing oop for more than 20 years, and I find that people often use different words for the same things. My understanding is that fields, class variables and attributes all mean the same thing. However, property is best described by the stackoverflow link that you included in your question.
Generally fields, methods, static methods, properties, attributes and class (or static variables) do not change on a language basis... Although the syntax will probably change on a per language basis, they will be function in the way you would expect across languages (expect terms like fields/data members to be used interchangably across languages)
In C#....
A field is a variable that exists for a given instance of a class.
eg.
public class BaseClass
{
// This is a field that might be different in each instance of a class
private int _field;
// This is a property that accesses a field
protected int GetField
{
get
{
return _field;
}
}
}
Fields have a "visibility" this determines what other classes can see the field, so in the above example a private field can only be used by the class that contains it, but the property accessor provides readonly access to the field by subclasses.
A property lets you get (sometimes called an accessor) or set (sometimes called a mutator) the value of field... Properties let you do a couple of things, prevent writing a field for example from outside the class, change the visibility of the field (eg private/protected/public). A mutator allows you to provide some custom logic before setting the value of a field
So properties are more like methods to get/set the value of a field but provide more functionality
eg.
public class BaseClass
{
// This is a field that might be different in each instance of a class
private int _field;
// This is a property that accesses a field, but since it's visibility
// is protected only subclasses will know about this property
// (and through it the field) - The field and property in this case
// will be hidden from other classes.
protected int GetField
{
// This is an accessor
get
{
return _field;
}
// This is a mutator
set
{
// This can perform some more logic
if (_field != value)
{
Console.WriteLine("The value of _field changed");
_field = value;
OnChanged; // Call some imaginary OnChange method
} else {
Console.WriteLine("The value of _field was not changed");
}
}
}
}
A class or static variable is a variable which is the same for all instances of a class..
So, for example, if you wanted a description for a class that description would be the same for all instance of the class and could be accessed by using the class
eg.
public class BaseClass
{
// A static (or class variable) can be accessed from anywhere by writing
// BaseClass.DESCRIPTION
public static string DESCRIPTION = "BaseClass";
}
public class TestClass
{
public void Test()
{
string BaseClassDescription = BaseClass.DESCRIPTION;
}
}
I'd be careful when using terminology relating to an attribute. In C# it is a class that can be applied to other classes or methods by "decorating" the class or method, in other context's it may simply refer to a field that a class contains.
// The functionality of this attribute will be documented somewhere
[Test]
public class TestClass
{
[TestMethod]
public void TestMethod()
{
}
}
Some languages do not have "Attributes" like C# does (see above)
Hopefully that all makes sense... Don't want to overload you!
Firstly, you need to select a language. For example, I would recommend you to select Ruby language and community. Until you select a language, you cannot escape confusion, as different communities use different terms for the same things.
For example, what is known as Module in Ruby, Java knows as abstract class. What is known as attributes in some languages, is known as instance variables in Ruby. I recommend Ruby especially for its logical and well-designed OOP system.
Write the following in a *.rb file, or on the command line in irb (interactive Ruby interpreter):
class Dog # <-- Here you define a class representing all dogs.
def breathe # <-- Here you teach your class a method: #breathe
puts "I'm breathing."
end
def speak # <-- Here you teach your class another method: #speak
puts "Bow wow!"
end
end
Now that you have a class, you can create an instance of it:
Seamus = Dog.new
You have just created an instance, a particular dog of class Dog, and stored it in the constant Seamus. Now you can play with it:
Seamus.breathe # <-- Invoking #breathe instance method of Seamus
#=> I'm breathing.
Seamus.speak # <-- Invoking #speak instance method of Seamus
#=> Bow wow!
As for your remaining terminology questions, "property" or "attribute" is understood as "variable" in Ruby, almost always an instance variable. And as for the term "data member", just forget about it. The term "field" is not really used in Ruby, and "class variable" in Ruby means something very rarely used, which you definitely don't need to know at this moment.
So, to keep the world nice and show you that OOP is really simple and painless in Ruby, let us create an attribute, or, in Ruby terminology, an instance variable of Dog class. As we know, every dog has some weight, and different dogs may have different weights. So, upon creation of a new dog, we will require the user to tell us dog's weight:
class Dog
def initialize( weight ) # <-- Defining initialization method with one argument 'weight'
#weight = weight # <-- Setting the dog's attribute (instance variable)
end
attr_reader :weight # <-- Making the dog's weight attribute visible to the world.
end
Drooly = Dog.new( 16 ) # <-- Weight now must provide weight upon initialization.
Drooly.weight # <-- Now we can ask Drooly about his weight.
#=> 16
Remember, with Ruby (or Python), things are simple.
I discovered in my question that Properties as defined in .Net are just a convenience syntax for code, and they are not tied to underlying variables at all (except for Auto-Implemented Properties, of course). So, saying "what is the difference between class property and class field" is like saying: what is the difference between a method and an attribute. No difference, one is code and the other is data. And, they need not have anything to do with each other.
It is really too bad that the same words, like "attribute" and "property", are re-used in different languages and ideologies to have starkly different meanings. Maybe someone needs to define an object-oriented language to talk about concepts in OOP? UML?
In The Class
public class ClassSample
{
private int ClassAttribute;
public int Property
{
get { return ClassAttribute; }
set { ClassAttribute = value; }
}
}
In the Program
class Program
{
static void Main(string[] args)
{
var objectSample = new ClassSample();
//Get Object Property
var GetProperty = objectSample.Property;
}
}
I know what the enum type should look like in the middle section of a UML diagram but how should it look in the bottom section where it contains the actions/methods of the class? Isn't there accessors and mutators for enum types?
+GetTypeOfAttack:TypeOfAttack
Is probably the answer but you need to ask yourself a question about whether this is a 'classic' accessor mutator
A classic accessor/mutator (getter/setter) is usually like the following
private bool hiddenField = true;
//Accessor
public bool GetHiddenField()
{
return hiddenField;
}
//mutator
public void SetHiddenField(bool input)
{
hiddenField = input;
}
BUT you may (more often than not) have situations where you need to do some logic evaluation before either getting or setting the field... This is not a pure accessor/mutator but essentially it is.
In answer to your question:
+SetHiddenField(bool): void
+GetHiddenField:bool
See how they map to the previous code. +/- = public/private, (denoteParameters) and : denotes return type
I've been looking into the topic of creating instances of a class within its own definition. Something like this:
public class myClass
{
public static myClass aObject = new myClass();
public static myClass bObject = new myClass();
}
I kind-of understand how this is possible, but I'm confused as to why it would be useful.
Also, my logic says that it should be possible to do something like this:
aObject.bObject.someMethod();
aObject is an instance of myClass, so it should contain bObject, right? I feel like I'm missing some fundamental understanding of how classes work, so I would really like to know what's going on here, and why someone would want to do this.
aObject.bObject.someMethod() would definitely work if someMethod() was defined as a part of myClass. As to why something like that would be done, I'll give an example that is used in java.
Say you have a class called Color that represents colors. You can make a new color of of its RGB value with the constructor Color(byte r, byte g, byte b). There are also constants in the Color class that represent commonly used colors, like red or green or pink. You can quickly access the pink color just by saying Color.PINK, since PINK is a Color variable that is inside the Color class. That way you don't have to construct a new color object each time you want to use pink in a method.
aObject.bObject.someMethod();
This is like saying "of object a's object b... do something." So its like a ball (called A) has a ball inside it (called B) which has a ball inside it (called C).. ect.
A linked list is a list does something like this, in that:
class Link {
public long data; // data item
public Link next; // next link in list
// =============================================================
public Link(long value){ // constructor
data = value; // assign parameter to data's data field
}
}
Link has inside of it a pointer to another link which does the same until you make a null object.
I think this is what you were asking...
I'm writing an iPhone App, and I'm finding that as I add features, predictably, the permutations of state increase dramatically.
I then find myself having to add code all over the place of the form:
If this and that and not the other then do x and y and set state z
Does anybody have suggestions for systematic approaches to deal with this?
Even though my app is iPhone, I think this applies to many GUI cases.
In general, a user interface application is always waiting for an event to happen. The event can be an action by the user (tap, shake iPhone, type letter on virtual keyboard), or by another process (network packet becomes available, battery runs out), or a time event (a timer expires). Whenever an event takes place ("if this"), you consult the current state of your application ("... and that and not the other") and then do something ("do x and y"), which most likely changes the application state ("set state z"). This is what you described in your question. And this is a general pattern.
There is no single systematic approach to make it right, but as you ask for suggestions of approaches, here some suggestions:
HINT 1: Use as few and little real data structures and variables to represent the internal state as possible, avoiding duplication of state by all means (until you run into performance issues). This makes the "do x and y and set state z" thing shorter, because the state gets set implicitly. Trivial example: instead of having (examples in C++)
if (namelen < 20) { name.append(c); namelen++; }
use
if (name.size() < 20) { name.append(c); }
The second example correctly avoids the replicated state variable 'namelen', making the action part shorter.
HINT 2: Whenever a compound condition (X and Y or Z) appears many times in your program, abstract it away into a procedure, so instead of
if ((x && y) || z) { ... }
write
bool my_condition() { return (x && y) || z; }
if (my_condition()) { ... }
HINT 3: If your user interface has a small number of clearly defined states, and the states affect how events are handled, you can represent the states as singleton instances of classes which inherit from an interface for handling those events. For example:
class UIState {
public:
virtual void HandleShake() = 0;
}
class MainScreen : public UIState {
public:
void HandleShake() { ... }
}
class HelpScreen : public UIState {
public:
void HandleShake() { ... }
}
Instantiate one instance of every derivate class and have then a pointer that points to the current state object:
UIState *current;
UIState *mainscreen = new MainScreen();
UIState *helpscreen = new HelpScreen();
current = mainscreen;
To handle shake then, call:
current->HandleShake();
To change UI state later:
current = helpscreen;
In this way, you can collect state-related procedures into classes, and encapsulate and abstract them away. Of course, you can add all kinds of interesting things into these state-specific (singleton) classes.
HINT 4: In general, if you have N boolean state variables and T different events that can be triggered, there are T * 2**N entries in the "matrix" of all possible events in all possible conditions. It requires your architectural view and domain expertise to correctly identify those dimensions and areas in the matrix which are most logical and natural to encapsulate into objects, and how. And that's what software engineering is about. But if you try to do your project without proper encapsulation and abstraction, you can't scale it far.