# Contract Structure

Having now understood the layout of a Solidity file and values, we will tackle the concept of the smart contract itself. While there are many different ways to approach learning about the structure of a smart contract, we will approach it from the perspective of *object-oriented* programming; as it will become evident later on, Solidity itself is an object-oriented programming language (perhaps one can call it *contract-oriented programming*)

### A Primer on Object-Oriented Programming

Object-oriented programming is defined by... well, objects. In particular, developers of object-oriented programming lanugages are able to leverage *classes* - blueprints that one can *instantitate* to create *objects*. 

A great example of understanding object-oriented programming is by looking at dog breeds. Consider the Poodle; if we consider poodles to be a *class*, then any living poodle can be consider *an instance* of the Poodle class.

<div align="center"><figure><img src="/files/z94MuKUqgfTua90Yn6qo" alt=""><figcaption><p><a href="https://www.animalblueprintcompany.com/product/poodle/">Source</a></p></figcaption></figure> <figure><img src="/files/st27zQUQygjWiUykDMpu" alt=""><figcaption><p>Lucho, my pet poodle</p></figcaption></figure></div>

Approaching object-oriented programming from a technical perspective, classes are defined by the following two characteristics:

* Fields: the *state* of objects
* Methods: the *behavior* of objects

### Contracts and Classes

Contracts, like classes in object-oriented programming, consist of both *fields* and *methods*. In practice, the fields of smart contracts come first and is followed by the contract methods.

```solidity
contract Rectangle {

    // Contract Fields
    uint256 length;
    uint256 width;
    
    // Contract Methods
    function compute() public pure returns(uint256) {
        return length * width;
    }

}
```

Above, we have a contract called **Rectangle** which represents... a rectangle. All contracts start off with a *contract header*, which, in the case of **Rectangle**, is defined by `contract Rectangle`. Following the contract header, we have the definition of **Rectangle** enclosed in curly brackets; this is where we will find the contract fields and methods.&#x20;

Contract fields are *stateful*; as an example, if we deployed an instance of the **Rectangle** contract, its associated `length` and `width` fields would forever persist on the blockchain, and any changes to said fields would be peristed as well.

Contract methods are the specified *behavior* of smart contracts; in the case of **Rectangle**, the function `compute()` calculates the area of the rectangle contract.&#x20;

{% hint style="info" %}

#### State Variables vs Memory Variables

Contract fields are more commonly known as *state variables* (i.e. they are persistent variables associated with a contract's state). Variables that are marked as `memory` or are *allocated* via the `new` keyword are known as *memory variables* (and are found within function bodies).
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://cs4998.cornellblockchain.org/introduction/hello-world/contract-structure.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.