Object-oriented design - Revision history

Klbrain: Merged content to Object-oriented analysis and design#Object-oriented design, redirecting; unopposed 2023 proposal (easy-merge)

2024-06-23T15:53:23Z

Merged content to Object-oriented analysis and design#Object-oriented design, redirecting; unopposed 2023 proposal (easy-merge)

← Previous revision		Revision as of 15:53, 23 June 2024
Line 1:		Line 1:
		⚫	#REDIRECT [[Object-oriented analysis and design#Object-oriented design]]
	{{Short description\|Approach to software design}}
	{{Merge to\|Object-oriented analysis and design\|discuss=Talk:Object-oriented analysis and design#Proposed merge of Object-oriented design into Object-oriented analysis and design\|date=September 2023}}
	{{Tone\|date=October 2021}}
	'''Object-oriented design (OOD)''' is the process of planning a [[Object-oriented programming\|system of interacting objects]] to solve a software problem. It is a method for [[software design]]. By defining classes and their functionality for their children (instantiated objects), each object can run the same implementation of the class with its state.

			{{R from merge}}
	==Overview==
			{{R to section}}
	An [[Object (computer science)\|object]] contains [[Encapsulation (computer programming)\|encapsulated]] data and procedures grouped to represent an entity. The 'object interface' defines how the [[Object (computer science)\|object]] can be interacted with. An object-oriented program is described by the interaction of these objects. Object-oriented design is the discipline of defining the [[Object (computer science)\|objects]] and their interactions to solve a problem that was identified and documented during [[object-oriented analysis and design\|object-oriented analysis]].

	What follows is a description of the [[Class-based programming\|class-based]] subset of object-oriented design, which does not include [[Prototype-based programming\|object prototype-based]] approaches where objects are not typically obtained by instantiating classes but by cloning other (prototype) objects. Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as state and dynamic models of the system under design.

	== Object-oriented design topics ==

	===Input (sources) for object-oriented design===
	The input for object-oriented design is provided by the output of [[object-oriented analysis and design\|object-oriented analysis]]. Realize that an output artifact does not need to be completely developed to serve as input of object-oriented design; analysis and design may occur in parallel, and in practice, the results of one activity can feed the other in a short feedback cycle through an iterative process. Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.

	Some typical input artifacts for object-oriented design are:

	* [[Conceptual model (computer science)\|Conceptual model]]: The result of object-oriented analysis, captures concepts in the [[domain (software engineering)\|problem domain]]. The conceptual model is explicitly chosen to be independent of implementation details, such as [[Concurrency (computer science)\|concurrency]] or data storage.
	* [[Use case]]: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more [[Scenario (computing)\|scenarios]] that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into [[Use case diagram\|use case diagrams]]. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform.
	* [[System sequence diagram]]: A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.
	* [[User interface]] documentation (if applicable): Document that shows and describes the [[look and feel]] of the end product's user interface. It is not mandatory to have this, but it helps to visualize the end product and therefore helps the designer.
	* [[Relational data model]] (if applicable): A data model is an abstract model that describes how data is represented and used. If an [[object database]] is not used, the relational data model should usually be created before the design since the strategy chosen for [[object-relational mapping]] is an output of the OO design process. However, it is possible to develop the relational data model and the object-oriented design artifacts in parallel, and the growth of an artifact can stimulate the refinement of other artifacts.

	===Object-oriented concepts ===
	The five basic concepts of object-oriented design are the implementation-level features built into the programming language. These features are often referred to by these common names:

	*[[Object (computer science)\|Object/Class]]: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a ''class'', or ''object'' (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of similar objects.
	*[[Information hiding]]: The ability to protect some object components from external entities. This is realized by language keywords to enable a variable to be declared as ''private'' or ''protected'' to the owning ''class''.
	*[[Inheritance (object-oriented programming)\|Inheritance]]: The ability for a ''class'' to extend or override the functionality of another ''class''. The so-called ''subclass'' has a whole section derived (inherited) from the ''superclass'' and has its own set of functions and data.
	*[[Interface (object-oriented programming)]]: The ability to defer the implementation of a ''method''. The ability to define the ''functions'' or ''methods'' signatures without implementing them.
	*[[Polymorphism (computer science)\|Polymorphism]] (specifically, [[Subtyping]]): The ability to replace an ''object'' with its ''sub-objects''. The ability of an ''object-variable'' to contain not only that ''object'' but also all of its ''sub-objects''.

	===Designing concepts===
	* Defining objects, creating [[class diagram]] from [[Conceptual model (computer science)\|conceptual diagram]]: Usually map entity to class.
	* Identifying [[Attribute (computing)\|attributes]] and their models.
	* Use [[design pattern]]s (if applicable): A design pattern is not a finished design, it is a description of a solution to a common problem, in a context.<ref name=gof>{{cite book
	\|author1=[[Erich Gamma]]
	\|author2=[[Richard Helm]]
	\|author3=[[Ralph Johnson (computer scientist)\|Ralph Johnson]]
	\|author4=[[John Vlissides]]
	\|title=Design Patterns: Elements of Reusable Object-Oriented Software
	\|publisher=[[Addison-Wesley]]
	\|date= January 2, 1995
	\|isbn=978-0-201-63361-0
	\|url=https://dl.acm.org/doi/10.5555/186897
	}}
	</ref>
	The main advantage of using a design pattern is that it can be reused in multiple applications. It can also be thought of as a template for how to solve a problem that can be used in many different situations and/or applications. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects involved.
	* Define [[application framework]] (if applicable): An application framework is usually a set of libraries or classes that are used to implement the standard structure of an application for a specific operating system. By bundling a large amount of reusable code into a framework, much time is saved for the developer since he/she is saved the task of rewriting large amounts of standard code for each new application that is developed.
	* Identify persistent objects/data (if applicable): Identify objects that have to last longer than a single runtime of the application. Design the object relation mapping if a [[relational database]] is used.
	* Identify and define remote objects (if applicable) and their variations.

	===Output (deliverables) of object-oriented design===
	* [[Sequence diagram]] - Extend the [[system sequence diagram]] to add specific objects that handle the system events.
	: A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur.
	* [[Class diagram]] - A class diagram is a type of static structure [[Unified Modeling Language\|UML]] diagram that describes the structure of a system by showing the system's classes, its attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system.

	===Some design principles and strategies===
	* [[Dependency injection]]: The basic idea is that if an object depends upon having an instance of some other object then the needed object is "injected" into the dependent object; for example, being passed a database connection as an argument to the [[Constructor (object-oriented programming)\|constructor]] instead of creating one internally.
	* [[Acyclic dependencies principle]]: The dependency graph of packages or components (the granularity depends on the scope of work for one developer) should have no cycles. This is also referred to as having a [[directed acyclic graph]].<ref name="objectMentor">{{cite web \|title=What Is Object-Oriented Design? \|publisher=Object Mentor \|url=http://www.objectmentor.com/omSolutions/oops_what.html \|access-date=2007-07-03 \|archive-url=https://web.archive.org/web/20070630045531/http://www.objectmentor.com/omSolutions/oops_what.html \|archive-date=2007-06-30 \|url-status=dead }}</ref> For example, package C depends on package B, which depends on package A. If package A depended on package C, you would have a cycle.
	* [[Composite reuse principle]]: Favor [[Polymorphism (computer science)\|polymorphic]] [[Object composition\|composition]] of objects over inheritance.<ref name="gof"/>

	==See also==
	* [[Class-responsibility-collaboration card]]
	* [[GRASP (object-oriented design)]]
	* [[SOLID]]
	* [[IDEF4]]
⚫	* [[Object-oriented analysis and design\|Object-oriented ~~analysis~~]]
	* [[Object-oriented programming]]

	==References==
	{{reflist}}
	{{More footnotes\|date=April 2009}}

	==External links==
	*[http://www.parlezuml.com/e-books/umlformanagers/umlformanagers_ch3.pdf ''Object-Oriented Analysis & Design''] - overview using UML
	*[http://authors.phptr.com/larman/uml_ooad/index.html Larman, Craig. ''Applying UML and Patterns - Third Edition'']
	*[http://www.informit.com/articles/article.aspx?p=360440&seqNum=8 ''Object-Oriented Analysis and Design'']
	*[http://www.lepus.org.uk LePUS3 and Class-Z]: formal modelling languages for object-oriented design

	[[Category:Software design]]		[[Category:Software design]]

Rodw: Disambiguating links to Ralph Johnson (link changed to Ralph Johnson (computer scientist)) using DisamAssist.

2024-06-04T15:12:34Z

Disambiguating links to Ralph Johnson (link changed to Ralph Johnson (computer scientist)) using DisamAssist.

← Previous revision		Revision as of 15:12, 4 June 2024
Line 37:		Line 37:
	\|author1=[[Erich Gamma]]		\|author1=[[Erich Gamma]]
	\|author2=[[Richard Helm]]		\|author2=[[Richard Helm]]
	\|author3=[[Ralph Johnson]]		\|author3=[[Ralph Johnson (computer scientist)\|Ralph Johnson]]
	\|author4=[[John Vlissides]]		\|author4=[[John Vlissides]]
	\|title=Design Patterns: Elements of Reusable Object-Oriented Software		\|title=Design Patterns: Elements of Reusable Object-Oriented Software

Laiwoonsiu: Replaced dead reference by working reference.

2024-06-01T03:47:23Z

Replaced dead reference by working reference.

@@ Line 34: / Line 34: @@
 * Defining objects, creating [[class diagram]] from [[Conceptual model (computer science)|conceptual diagram]]: Usually map entity to class.
 * Identifying [[Attribute (computing)|attributes]] and their models.
-* Use [[design pattern]]s (if applicable): A design pattern is not a finished design, it is a description of a solution to a common problem, in a context.<ref name="gof">{{cite book |title=Design Patterns: Elements of Reusable Object-Oriented Software |year=1995 |publisher=Addison-Wesley |isbn=0-201-63361-2 |url-access=registration |url=https://archive.org/details/designpatternsel00gamm }}</ref> The main advantage of using a design pattern is that it can be reused in multiple applications. It can also be thought of as a template for how to solve a problem that can be used in many different situations and/or applications. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects involved.
+* Use [[design pattern]]s (if applicable): A design pattern is not a finished design, it is a description of a solution to a common problem, in a context.<ref name=gof>{{cite book
 * Define [[application framework]] (if applicable): An application framework is usually a set of libraries or classes that are used to implement the standard structure of an application for a specific operating system. By bundling a large amount of reusable code into a framework, much time is saved for the developer since he/she is saved the task of rewriting large amounts of standard code for each new application that is developed.
 * Identify persistent objects/data (if applicable): Identify objects that have to last longer than a single runtime of the application. Design the object relation mapping if a [[relational database]] is used.

Shivacruz at 09:02, 17 May 2024

2024-05-17T09:02:12Z

Ula993: /* Object-oriented concepts */ article

2024-04-10T13:53:39Z

Object-oriented concepts: article

← Previous revision		Revision as of 13:53, 10 April 2024
Line 27:		Line 27:
	*[[Object (computer science)\|Object/Class]]: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a ''class'', or ''object'' (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of similar objects.		*[[Object (computer science)\|Object/Class]]: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a ''class'', or ''object'' (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of similar objects.
	*[[Information hiding]]: The ability to protect some object components from external entities. This is realized by language keywords to enable a variable to be declared as ''private'' or ''protected'' to the owning ''class''.		*[[Information hiding]]: The ability to protect some object components from external entities. This is realized by language keywords to enable a variable to be declared as ''private'' or ''protected'' to the owning ''class''.
	*[[Inheritance (object-oriented programming)\|Inheritance]]: The ability for a ''class'' to extend or override functionality of another ''class''. The so-called ''subclass'' has a whole section derived (inherited) from the ''superclass'' and has its own set of functions and data.		*[[Inheritance (object-oriented programming)\|Inheritance]]: The ability for a ''class'' to extend or override the functionality of another ''class''. The so-called ''subclass'' has a whole section derived (inherited) from the ''superclass'' and has its own set of functions and data.
	*[[Interface (object-oriented programming)]]: The ability to defer the implementation of a ''method''. The ability to define the ''functions'' or ''methods'' signatures without implementing them.		*[[Interface (object-oriented programming)]]: The ability to defer the implementation of a ''method''. The ability to define the ''functions'' or ''methods'' signatures without implementing them.
	*[[Polymorphism (computer science)\|Polymorphism]] (specifically, [[Subtyping]]): The ability to replace an ''object'' with its ''sub-objects''. The ability of an ''object-variable'' to contain not only that ''object'' but also all of its ''sub-objects''.		*[[Polymorphism (computer science)\|Polymorphism]] (specifically, [[Subtyping]]): The ability to replace an ''object'' with its ''sub-objects''. The ability of an ''object-variable'' to contain not only that ''object'' but also all of its ''sub-objects''.

Ula993: /* Object-oriented concepts */ remove comma

2024-04-10T13:52:57Z

Object-oriented concepts: remove comma

← Previous revision		Revision as of 13:52, 10 April 2024
Line 29:		Line 29:
	*[[Inheritance (object-oriented programming)\|Inheritance]]: The ability for a ''class'' to extend or override functionality of another ''class''. The so-called ''subclass'' has a whole section derived (inherited) from the ''superclass'' and has its own set of functions and data.		*[[Inheritance (object-oriented programming)\|Inheritance]]: The ability for a ''class'' to extend or override functionality of another ''class''. The so-called ''subclass'' has a whole section derived (inherited) from the ''superclass'' and has its own set of functions and data.
	*[[Interface (object-oriented programming)]]: The ability to defer the implementation of a ''method''. The ability to define the ''functions'' or ''methods'' signatures without implementing them.		*[[Interface (object-oriented programming)]]: The ability to defer the implementation of a ''method''. The ability to define the ''functions'' or ''methods'' signatures without implementing them.
	*[[Polymorphism (computer science)\|Polymorphism]] (specifically, [[Subtyping]]): The ability to replace an ''object'' with its ''sub-objects''. The ability of an ''object-variable'' to contain not only that ''object'', but also all of its ''sub-objects''.		*[[Polymorphism (computer science)\|Polymorphism]] (specifically, [[Subtyping]]): The ability to replace an ''object'' with its ''sub-objects''. The ability of an ''object-variable'' to contain not only that ''object'' but also all of its ''sub-objects''.

	===Designing concepts===		===Designing concepts===

Ula993: /* Object-oriented design topics */ improve

2024-04-10T13:52:28Z

Object-oriented design topics: improve

← Previous revision		Revision as of 13:52, 10 April 2024
Line 19:		Line 19:
	* [[Use case]]: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more [[Scenario (computing)\|scenarios]] that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into [[Use case diagram\|use case diagrams]]. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform.		* [[Use case]]: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more [[Scenario (computing)\|scenarios]] that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into [[Use case diagram\|use case diagrams]]. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform.
	* [[System sequence diagram]]: A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.		* [[System sequence diagram]]: A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.
	* [[User interface]] ~~documentations~~ (if applicable): Document that shows and describes the [[look and feel]] of the end product's user interface. It is not mandatory to have this, but it helps to visualize the end product and therefore helps the designer.		* [[User interface]] documentation (if applicable): Document that shows and describes the [[look and feel]] of the end product's user interface. It is not mandatory to have this, but it helps to visualize the end product and therefore helps the designer.
	* [[Relational data model]] (if applicable): A data model is an abstract model that describes how data is represented and used. If an [[object database]] is not used, the relational data model should usually be created before the design since the strategy chosen for [[object-relational mapping]] is an output of the OO design process. However, it is possible to develop the relational data model and the object-oriented design artifacts in parallel, and the growth of an artifact can stimulate the refinement of other artifacts.		* [[Relational data model]] (if applicable): A data model is an abstract model that describes how data is represented and used. If an [[object database]] is not used, the relational data model should usually be created before the design since the strategy chosen for [[object-relational mapping]] is an output of the OO design process. However, it is possible to develop the relational data model and the object-oriented design artifacts in parallel, and the growth of an artifact can stimulate the refinement of other artifacts.

Ula993: /* Input (sources) for object-oriented design */ improve

2024-04-10T13:52:12Z

Input (sources) for object-oriented design: improve

← Previous revision		Revision as of 13:52, 10 April 2024
Line 18:		Line 18:
	* [[Conceptual model (computer science)\|Conceptual model]]: The result of object-oriented analysis, captures concepts in the [[domain (software engineering)\|problem domain]]. The conceptual model is explicitly chosen to be independent of implementation details, such as [[Concurrency (computer science)\|concurrency]] or data storage.		* [[Conceptual model (computer science)\|Conceptual model]]: The result of object-oriented analysis, captures concepts in the [[domain (software engineering)\|problem domain]]. The conceptual model is explicitly chosen to be independent of implementation details, such as [[Concurrency (computer science)\|concurrency]] or data storage.
	* [[Use case]]: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more [[Scenario (computing)\|scenarios]] that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into [[Use case diagram\|use case diagrams]]. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform.		* [[Use case]]: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more [[Scenario (computing)\|scenarios]] that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into [[Use case diagram\|use case diagrams]]. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform.
	* [[System sequence diagram]]: A system sequence ~~diagrams~~ (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.		* [[System sequence diagram]]: A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.
	* [[User interface]] documentations (if applicable): Document that shows and describes the [[look and feel]] of the end product's user interface. It is not mandatory to have this, but it helps to visualize the end product and therefore helps the designer.		* [[User interface]] documentations (if applicable): Document that shows and describes the [[look and feel]] of the end product's user interface. It is not mandatory to have this, but it helps to visualize the end product and therefore helps the designer.
	* [[Relational data model]] (if applicable): A data model is an abstract model that describes how data is represented and used. If an [[object database]] is not used, the relational data model should usually be created before the design since the strategy chosen for [[object-relational mapping]] is an output of the OO design process. However, it is possible to develop the relational data model and the object-oriented design artifacts in parallel, and the growth of an artifact can stimulate the refinement of other artifacts.		* [[Relational data model]] (if applicable): A data model is an abstract model that describes how data is represented and used. If an [[object database]] is not used, the relational data model should usually be created before the design since the strategy chosen for [[object-relational mapping]] is an output of the OO design process. However, it is possible to develop the relational data model and the object-oriented design artifacts in parallel, and the growth of an artifact can stimulate the refinement of other artifacts.

Ula993: /* Input (sources) for object-oriented design */

2024-04-10T13:51:35Z

Input (sources) for object-oriented design

← Previous revision		Revision as of 13:51, 10 April 2024
Line 16:		Line 16:
	Some typical input artifacts for object-oriented design are:		Some typical input artifacts for object-oriented design are:

	* [[Conceptual model (computer science)\|Conceptual model]]: The result of object-oriented analysis, it captures concepts in the [[domain (software engineering)\|problem domain]]. The conceptual model is explicitly chosen to be independent of implementation details, such as [[Concurrency (computer science)\|concurrency]] or data storage.		* [[Conceptual model (computer science)\|Conceptual model]]: The result of object-oriented analysis, captures concepts in the [[domain (software engineering)\|problem domain]]. The conceptual model is explicitly chosen to be independent of implementation details, such as [[Concurrency (computer science)\|concurrency]] or data storage.
	* [[Use case]]: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more [[Scenario (computing)\|scenarios]] that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into [[Use case diagram\|use case diagrams]]. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform.		* [[Use case]]: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more [[Scenario (computing)\|scenarios]] that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into [[Use case diagram\|use case diagrams]]. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform.
	* [[System sequence diagram]]: A system sequence diagrams (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.		* [[System sequence diagram]]: A system sequence diagrams (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.

Ula993: /* Input (sources) for object-oriented design */ add comma

2024-04-10T13:51:06Z

Input (sources) for object-oriented design: add comma

← Previous revision		Revision as of 13:51, 10 April 2024
Line 12:		Line 12:

	===Input (sources) for object-oriented design===		===Input (sources) for object-oriented design===
	The input for object-oriented design is provided by the output of [[object-oriented analysis and design\|object-oriented analysis]]. Realize that an output artifact does not need to be completely developed to serve as input of object-oriented design; analysis and design may occur in parallel, and in practice the results of one activity can feed the other in a short feedback cycle through an iterative process. Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.		The input for object-oriented design is provided by the output of [[object-oriented analysis and design\|object-oriented analysis]]. Realize that an output artifact does not need to be completely developed to serve as input of object-oriented design; analysis and design may occur in parallel, and in practice, the results of one activity can feed the other in a short feedback cycle through an iterative process. Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.

	Some typical input artifacts for object-oriented design are:		Some typical input artifacts for object-oriented design are:

← Previous revision		Revision as of 09:02, 17 May 2024
Line 23:		Line 23:

	===Object-oriented concepts ===		===Object-oriented concepts ===
	The five basic concepts of object-oriented design are the implementation-level features built into the programming language. These features are often referred to by these common names:		The five basic concepts of object-oriented design are the implementation-level features built into the programming language. These features are often referred to by these common names:

	*[[Object (computer science)\|Object/Class]]: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a ''class'', or ''object'' (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of similar objects.		*[[Object (computer science)\|Object/Class]]: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a ''class'', or ''object'' (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of similar objects.
	*[[Information hiding]]: The ability to protect some object components from external entities. This is realized by language keywords to enable a variable to be declared as ''private'' or ''protected'' to the owning ''class''.		*[[Information hiding]]: The ability to protect some object components from external entities. This is realized by language keywords to enable a variable to be declared as ''private'' or ''protected'' to the owning ''class''.
	*[[Inheritance (object-oriented programming)\|Inheritance]]: The ability for a ''class'' to extend or override the functionality of another ''class''. The so-called ''subclass'' has a whole section derived (inherited) from the ''superclass'' and has its own set of functions and data.		*[[Inheritance (object-oriented programming)\|Inheritance]]: The ability for a ''class'' to extend or override the functionality of another ''class''. The so-called ''subclass'' has a whole section derived (inherited) from the ''superclass'' and has its own set of functions and data.
Line 42:		Line 42:
	* [[Sequence diagram]] - Extend the [[system sequence diagram]] to add specific objects that handle the system events.		* [[Sequence diagram]] - Extend the [[system sequence diagram]] to add specific objects that handle the system events.
	: A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur.		: A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur.
	* [[Class diagram]] - A class diagram is a type of static structure [[Unified Modeling Language\|UML]] diagram that describes the structure of a system by showing the system's classes, its attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system.		* [[Class diagram]] - A class diagram is a type of static structure [[Unified Modeling Language\|UML]] diagram that describes the structure of a system by showing the system's classes, its attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system.

	===Some design principles and strategies===		===Some design principles and strategies===
	* [[Dependency injection]]: The basic idea is that if an object depends upon having an instance of some other object then the needed object is "injected" into the dependent object; for example, being passed a database connection as an argument to the [[Constructor (object-oriented programming)\|constructor]] instead of creating one internally.		* [[Dependency injection]]: The basic idea is that if an object depends upon having an instance of some other object then the needed object is "injected" into the dependent object; for example, being passed a database connection as an argument to the [[Constructor (object-oriented programming)\|constructor]] instead of creating one internally.
	* [[Acyclic dependencies principle]]: The dependency graph of packages or components (the granularity depends on the scope of work for one developer) should have no cycles. This is also referred to as having a [[directed acyclic graph]].<ref name="objectMentor">{{cite web \|title=What Is Object-Oriented Design? \|publisher=Object Mentor \|url=http://www.objectmentor.com/omSolutions/oops_what.html \|access-date=2007-07-03 \|archive-url=https://web.archive.org/web/20070630045531/http://www.objectmentor.com/omSolutions/oops_what.html \|archive-date=2007-06-30 \|url-status=dead }}</ref> For example, package C depends on package B, which depends on package A. If package A depended on package C, you would have a cycle.		* [[Acyclic dependencies principle]]: The dependency graph of packages or components (the granularity depends on the scope of work for one developer) should have no cycles. This is also referred to as having a [[directed acyclic graph]].<ref name="objectMentor">{{cite web \|title=What Is Object-Oriented Design? \|publisher=Object Mentor \|url=http://www.objectmentor.com/omSolutions/oops_what.html \|access-date=2007-07-03 \|archive-url=https://web.archive.org/web/20070630045531/http://www.objectmentor.com/omSolutions/oops_what.html \|archive-date=2007-06-30 \|url-status=dead }}</ref> For example, package C depends on package B, which depends on package A. If package A depended on package C, you would have a cycle.
	* [[Composite reuse principle]]: Favor [[Polymorphism (computer science)\|polymorphic]] [[Object composition\|composition]] of objects over inheritance.<ref name="gof"/>		* [[Composite reuse principle]]: Favor [[Polymorphism (computer science)\|polymorphic]] [[Object composition\|composition]] of objects over inheritance.<ref name="gof"/>