The reason I am asking this question is I want to know how to properly call an architecture where classes have either data or logic but not both. I know this goes against object orientation and encapsulation. I want to use the proper terms for discussing this architecture.

EDIT: By reading the answers I have received, I can see my question wasn't clear. I also feel the edit that was made didn't push the question in the direction I was going for.

Is this by any chance related to the Von Neumann architecture, i.e. one in which data and instructions are stored together, and are in fact indistinguishable? AKA the stored program
–
WaelJSep 16 '11 at 16:04

A common (IMHO more common even though I have some FP background) definition of procedure/function is that a procedure doesn't return a value while a function returns a value, no matter if it's pure/referentially transparent/etc. or not.
–
delnanSep 16 '11 at 16:11

6

@StuperUser: an object that has no state and only a single method is isomorphic to a procedure/function. (In fact, this is actually how first-class procedures/functions are implemented in Scala, Python, Ruby and Smalltalk, for example.) A stateless object with multiple methods is isomorphic to a set of procedures/functions in a namespace. An object with no methods, only data is isomorphic to a struct/record (plus inheritance). An object with data and a single method is isomorphic to a closure.
–
Jörg W MittagSep 16 '11 at 17:11

3

@StuperUser: And an object with data and multiple methods (i.e. a bog-standard object) is isomorphic to record containing a set of closures that all close over the same lexical environment. (In fact, that's how objects are typically implemented in Haskell, ML, Scheme (and thus also ECMAScript) and other procedural/functional languages.)
–
Jörg W MittagSep 16 '11 at 17:13

2

@KeithS: where did I claim that an object containing only logic were a method?
–
Jörg W MittagSep 16 '11 at 17:14

3

@KeithS to be pedantic whether a procedure or function is an object depends on the language in question.
–
Davy8Sep 16 '11 at 21:38

Objects that contain and expose both logic (methods, properties) and data (fields) are simply "objects". Often, the overall behavior of this object is a model for some real-world concept or thing (this is after all the point of O-O design; to structure programs in terms of code objects that model real-world ideas), which means that an object must encapsulate both data about the state of a particular instance of that object, and also logic representing what an object can do; these stateful yet "rich" objects, as a collection in your codebase, are usually called the "domain" or "model".

An object containing only logic is rare; most objects need to store some sort of state. If you need one term for all of these, There are three major subcategories I can think of that are more commonly heard of:

Instance classes that exist as "bridges" for communications between classes or architectural layers; these are often called "controllers" because their usual function is to direct more stateful objects to perform overarching tasks that the stateful objects should not know how to do by themselves.

Instance classes that provide a means to get state information out of an external resource. The instance class itself does not "own" the state data that is exposed; it is simply a means to an end. These are generally called "repositories"; some of them may be called "proxies" depending on the basic design pattern in which the object is used.

Classes that contain only data are generally referred to as DTOs, or Data Transfer Objects. You may also hear them called "structs", but that term is usually reserved in the C-style languages for "complex value types" like DateTime, Money, Point, Vector, etc. Sometimes, data-only classes are used as the "domain", with other classes built to perform all manipulations of that data, but this is known as an "anemic domain model" and is generally considered an anti-pattern.

In computer programming, homoiconicity is a property of some
programming languages, in which the primary representation of programs
is also a data structure in a primitive type of the language itself,
from the Greek words homo meaning the same and icon meaning
representation. This makes metaprogramming easier than in a language
without this property. To put that another way, homoiconicity is where
a program's source code is written as a basic data structure that the
programming language knows how to access.