Aggregate pattern: Difference between revisions

Revision as of 19:17, 10 May 2005

Latest revision as of 02:53, 12 February 2025

(47 intermediate revisions by 34 users not shown)

Line 1:

{{Short description|Concepts in statistics and computer science}}

<div class="boilerplate metadata toccolours" id="vfd" style="margin: 0 2.5%; padding: 0 7px 7px 7px; border: 1px solid #aaa;">

{{one source |date=March 2024}}

'''This article is being considered for deletion in accordance with Wikipedia's [[Wikipedia:Deletion policy|deletion policy]][[Template:Vfd|.]]'''<br>

An '''Aggregate pattern''' can refer to concepts in either statistics or computer programming. Both uses simplify complexity into smaller, simpler parts.

Please see '''[[Wikipedia:Votes for deletion/{{PAGENAME}}|this article's entry]]''' on the Votes for Deletion page for voting and discussion on the matter.

== Statistics ==

Please do not remove or deface this notice or blank, merge, or move this article while the discussion is in progress. However, you are welcome to edit this article and improve it. For more information, read the [[Wikipedia:Guide to Votes for deletion|Guide to Votes for Deletion]].</div>[[Category:Pages on votes for deletion]]

An '''aggregate pattern''' is an important statistical concept in many fields that rely on [[statistics]] to predict the behavior of large groups, based on the tendanciestendencies of subgroups to consistently behave in a certain way. It is particularly useful in [[sociology]], [[economics]], [[psychology]], and [[criminology]].

== Computer programming ==

In [[computer programming]], an '''aggregate pattern''' is a [[design pattern (computer science)|design pattern]].

In ''[[Design Patterns]]'', an aggregate is not a [[Software design pattern|design pattern]] but rather refers to an object such as a list, vector, or generator which provides an interface for creating [[iterator]]s. The following example code is in [[Python (programming language)|Python]].

Members of a common subclass are each known to have certain [[method (computer science)|method]]s. These methods return information about the state of that particular object. It does happen that an application is concerned with an aggregation, or amalgamation, of data from several object of the same type. This leads to code being repeated around the program:

<syntaxhighlight lang="python">

def fibonacci(n: int):

a, b = 0, 1

count = 0

while count < n:

count += 1

a, b = b, a + b

yield a

for x in fibonacci(10):

my $subtotal;

print(x)

foreach my $item (@cart) {

$subtotal += $item->query_price();

}

def fibsum(n: int) -> int:

my $weight;

foreach my $itemtotal (@cart)= {0

$weightfor +=x $item->query_weightin fibonacci(n);:

total += x

}

return total

def fibsum_alt(n: int) -> int:

# and so on

"""

Alternate implementation. demonstration that Python's built-in function sum()

works with arbitrary iterators.

"""

return sum(fibonacci(n))

myNumbers = [1, 7, 4, 3, 22]

== Representing ==

Representing individual objects when the application is concerned about the general state of several objects is an ImpedenceMismatch. This is a common mismatch as programmers feel obligated to model the world in minute detail then are pressed with the problem of giving it all a high level interface.

def average(g) -> float:

Create an object as a [[wrapper]], using the same API, with a common subtype

return float(sum(g)) / len(g) # In Python 3 the cast to float is no longer be necessary

as a cart entry, but allow it to hold other objects of that subtype: make

</syntaxhighlight>

it a container. Define its accessors to return aggregate information

Python hides essentially all of the details using the [https://docs.python.org/3/library/stdtypes.html#iterator-types iterator protocol]. Confusingly, ''[[Design Patterns]]'' uses "aggregate" to refer to the blank in the code <code>for x in ___:</code> which is unrelated to the term "aggregation".<ref>[[Design Patterns]], p. 22: "Aggregation implies that one object owns or is responsible for another object. ... Aggregation implies that an aggregate object and its owner have identical lifetimes."</ref> Neither of these terms refer to the statistical aggregation of data such as the act of adding up the Fibonacci sequence or taking the average of a list of numbers.

on the objects it contains.

== See also ==

package Cart::Basket;

@ISA = qw(Cart::Item);

sub query_price {

my $self = shift;

my $contents = $self->{contents};

foreach my $item (@$contents) {

}

}

# other query_ routines here...

sub add_item {

my $self = shift;

my $contents = $self->{contents};

my $item = shift; $item->isa('Cart::Item') or die;

push @$contents, $item;

return 1;

}

The aggregation logic, in this case, totalling, need only exist in this

container, rather than being strewn around the entire program. Less code,

less [[code momentum]], fewer dependencies, more flexibility.

We have an object of base type //Cart::Item// that itself holds other //Cart::Item//

objects. That makes us recursive and nestable - one basket could hold several

items along with another basket, into which other items and baskets could

be placed. You may or may not want to do this intentionally, but to someone

casually calling //->query_price()// on your //Cart::Basket// object

won't have to concern himself with this - things will just work.

This will break. Unless the advice of AbstractRootClasses is followed and

different implementations of the same thing share the same interface, the

basket can't confidently aggregate things. Unless the advice of StateVsClass

is heeded, [[abstract root classes]] will never be achieved: the temptation to

draw distinctions between classes that lack certain functions will be too

strong. These distinctions run counter to AbstractRootClasses, causing

segmentation and proliferation of interfaces for no good reason. This proliferation

of types prevents aggregation in baskets and containers. Avoid this vicious

cycle. Parrots that don't squak are still parrots.

XXX IteratorInterface blurb - aggregation is kind of like iteration in

that they both present information gleaned from a number of objects through

a tidy interface in one object. While IteratorInterface deals with each

contained or known object in turn, AggregatePattern summarizes them in

one fell swoop.

''The article is originally from [[Perl Design Patterns Book]].''

==See also==

* [[Visitor pattern]]

* [[Template class]]

* [[Facade pattern]]

* [[Iterator interface]]

* [[Type safety]]

* [[Functional programming]]

* [[State vs class]]

== References ==

[[Category:Programming]]

{{Reflist}}

[[Category:Software design patterns]]

[[Category:Articles with example Python (programming language) code]]

{{statistics-stub}}

{{compu-prog-stub}}