Wikipedia

Class (computer programming) and Fire Emblem: Difference between pages

(Difference between pages)
Content deleted Content added
VisualWikitext
 
 
Line 1:
{{Unreferencedsect|date=February 2007}}
In [[object-oriented programming]], a '''class''' consists of [[Information hiding|encapsulated]] [[instance variable]]s and [[subprogram]]s, the methods mentioned below. A Class describes the rules by which [[Object (object-oriented programming)|objects]] behave; these objects are referred to as "[[instance]]s" of that class. A class specifies the structure of data which each instance contains as well as the [[Method (computer science)|methods]] ([[Function (computer science)|functions]]) which manipulate the data of the object; such methods are sometimes described as "[[behavior]]". A class is the most specific [[datatype|type]] of an object in relation to a specific [[layer]]. As a datatype, a class is a compile-time construct. A language may also support [[prototype]] or [[factory]] objects that represent run-time information about classes, but these should not be confused with classes, as these often do not include all information about classes due to concerns with space consumption.
 
[[Image:Fire_emblem_noken.jpg|thumb|250px|Eliwood, Hector and Lyn from ''Fire Emblem (Game Boy Advance)'', the first ''Fire Emblem'' to be released internationally.]]
Classes are sometimes described as "[[blueprint]]s"; instances of a class will have certain aspects in common. One might describe a "class of [[animal]]s" ([[dog]]s), or a "class of [[object|tangible objects]]" ([[computer]]s). One of the benefits of programming with classes is that all instances of a particular class will follow the defined behaviour of said class. For example: if [[human]]s are a class, then each person is an instance of an object of the human class. Each person is generally alike; but varies in such properties as "height" and "weight". The class would list such instance variables; and also define, via methods, the [[action (philosophy)|action]]s which humans can perform: "run", "jump", "sleep", "throw object", etc.
 
{{nihongo|'''''Fire Emblem'''''|ファイアーエムブレム|Faiā Emuburemu}} is a popular [[strategy game|strategy]]/[[computer role-playing games|role-playing]] [[video game]] franchise developed by [[Intelligent Systems|Intelligent Systems Co., Ltd.]] (specifically [[Shouzou Kaga]]), the makers of [[Nintendo Wars#Advance Wars|Advance Wars]], and published by [[Nintendo Co., Ltd.]]. The ''Fire Emblem'' games are known to be the first of their genre, the [[strategic role-playing game]], with a very strong emphasis on western forms of medieval folklore.
== Interface to a class ==
 
The series currently spans ten games, and has graced the [[Famicom]], [[Super Famicom]], [[Game Boy Advance]], [[GameCube]] and [[Wii]]. [[Fire Emblem: The Goddess of Dawn|The most recent title in the series]] was first released in Japan on February 22, 2007. A North American release is expected to follow at an undisclosed date in 2007.
A class implements (or realizes) one or more [[interface (computer science)|interface]]s. Each interface specifies [[operation]] signatures of some of the [[method]]s of the class. The methods of a class can either be used via one of its interfaces or directly. An interface of a class describes the possible behaviours of objects of the class from user's point of view. Multiple classes can implement the same interface. Partial implementations of interfaces are not allowed, that is, every operation has to have an implementation. However usually not every combination of parameter values need to be supported.
 
==International release==
Each interface of the class is associated with a type of [[object reference]]s referring to the interface, through which methods of objects can be invoked. Each reference points to a single instance of the class.
Since its inception in 1990, the ''Fire Emblem'' series was formerly confined to Japan. In 2001, Nintendo released ''[[Super Smash Bros. Melee]]'', a fighting game starring characters from games produced throughout the company's history. The Japanese release of the game contained two characters from the ''Fire Emblem'' series; Marth, the original protagonist in the series, starred in ''Fire Emblem: Ankoku no Ryū to Hikari no Tsurugi'', and ''Fire Emblem: Monshō no Nazo'', and Roy starred in the then-unreleased sixth game, ''Fire Emblem: Fūin no Tsurugi''. According to Nintendo's official Japanese website, Marth was put in ''Super Smash Bros. Melee'' upon the request of Japanese gamers. Marth's design and playability earned him extra attention while the game underwent debug testing in North America, and it was by the decision of Nintendo of America that he was included in the North American version. Roy had been included in Japan to promote the upcoming release of ''Fūin no Tsurugi'', and was likewise included in the North American version. It was due in part to Marth and Roy's popularity from their appearance in ''SSBM'' that Nintendo eventually decided to localize and market ''Fire Emblem'' games for North American and European release.
Each reference has a [[lifetime]], which specifies how long the reference can be used, usually bound to the time when some specific operations are invoked via the interface. It is assumed that there is a mechanism for accessing the object with a valid object reference. However, the object reference does not necessarily point to any single ___location, since the same object can be located at different times in different places.
 
''[[Fire Emblem: Rekka no Ken]]'', the seventh title in the series, became the first to see an international release in 2003. Released outside of Japan simply as ''Fire Emblem'', the game was designed specifically with newcomers to the series in mind, and the first ten chapters were structured in a manner that eased newcomers into the gameplay. All ''Fire Emblem'' titles produced since have also seen international release.
The [[object-oriented programming]] methodology is designed in such way that the operations of any interface of a class are usually chosen to be independent of each other. This means that an interface places no requirements for clients to invoke the operations of one interface in any particular order. This approach has the benefit that client code can rely that the operations of an interface are available for use whenever the client holds a valid reference to the object. This will also result in a [[client-server]] (or layered) design where servers do not depend in any
way of the clients.
 
==Gameplay==
The methods that are not in any of the interfaces of a class are private to the class, and not intended to be depended on by other classes.
===Basics===
[[Image:Thracia776Screencap.png|thumb|right|Game-play map screen from ''Fire Emblem: Thracia 776''.]]
''Fire Emblem'' is a series of [[turn-based]] strategy games that involve moving units through a map grid in order to defeat the opposition and eventually complete a mission objective, such as seizing a base, surviving for a number of turns, or defeating a boss. The combat system bases itself on a [[rock-paper-scissors]] method of fighting, as each weapon type has both an advantage and a disadvantage against other types. From ''Fire Emblem: Seisen no Keifu'' to the most recent game ''[[Fire Emblem: Akatsuki no Megami]]'', the weapon triangle has been [[lance]] beats [[sword]], sword beats [[axe]], and axe beats lance. Bows are unaffected by the triangle and can do higher amounts of damage against flying units, but this is offset by the bow-wielder's inability to counter-attack direct melee strikes.
 
A similar [[Magic in the Fire Emblem series|triangle for magic]], that varies from game to game, has also existed. The basic triangles of magic are light beats dark, dark beats anima, and anima beats light. In other games, fire beats wind, wind beats thunder and thunder beats fire. Magic is also unique in that magical attacks can be used from either a distance or in melee range.
The "set of all interfaces of a class" is sometimes called the interface of the class.
 
===Units and relationships===
The internal data structures defined as part of a class are not considered to be part of its interface. Rather, public ''accessor'' methods can be used to inspect or alter object data. The various [[object-oriented]] programming languages enforce this to various degrees. For example, [[Java programming language|Java]] does not allow the programmer to access the private data of a class at all, whereas in languages like [[Objective-C]] or [[Perl]] the programmer can do what they want. In [[C_plus_plus|C++]], private methods are visible but not accessible in the interface; however they are commonly made invisible by explicitly declaring fully abstract classes that represent the interfaces of the class.
Unlike ''Advance Wars'' and other tactical RPGs such as ''[[Final Fantasy Tactics]]'', player-generated units are absent. Instead, ''Fire Emblem'' utilizes a distinct cast of characters, each belonging to one of many [[character classes]]. Unlike most strategy games, each unit has a personality and past of its own. Money is used to buy better weapons and various items, and using units in battle will allow them to gain [[experience points]]; a character's level will increase upon gaining one hundred experience points. Leveling party members up can be a challenge, as many newly recruited units arrive with inferior levels and statistics, but because the amount of experience earned from defeating an enemy is determined by the level discrepancy between the battling units, a characters at lower levels earn more experience than more experienced characters when defeating enemies of comparable level.
 
Depending on the mechanics of the particular game, characters may change classes upon reaching a certain level, or through the use of a special item that will force a unit's promotion. Characters that change class receive a one-time statistics upgrade that is higher than the average leveling upgrade and additional abilities that are standards of the higher-tier classes. For instance, a cavalier in ''Fire Emblem: Path of Radiance'' will change classes automatically after earning enough experience to advance to level 21, becoming a level 1 paladin, will become capable of moving greaters distances in a single turn, and will become able to wield two kinds of weapons.
== Structure of a class ==
 
Typically, the size of the player's character roster is very small at the beginning of each game, but as progress is made, other units may join the player's party through story events or through actions taken. The latter games in the series typically contain playable rosters between thirty and fifty characters deep.
[[Image:oop-uml-class-example.png|frame|right|UML notation for classes]]
 
[[Romantic love|Romance]] and friendship are prevalent themes throughout the ''Fire Emblem'' series. Starting from the sixth game, ''Fuuin no Tsurugi'', this characteristic has been further emphasized in the gameplay itself through the use of support conversations. In the GBA ''Fire Emblem'' titles, these conversations could be triggered by having specific pairs of characters end their turns standing next to each other. After a specific number of turns have accumulated, the player is given the option to view a support conversation between the two characters. ''Path of Radiance'' simplified the approach by requiring characters to be in a certain number of battles together and not necessarily adjacent to one another. Each time a pair of characters engage in a support conversation, their affinity towards each other will increase, giving them statistical bonuses that activate any time the characters are next to each other on the battlefield. If two characters with a mutual romantic attraction, strong friendship, or other form of mutual connection engage in three Supports throughout the game, the result will often affect the game's ending. Depending on the characters involved, such results could include marriage, a deepening of friendship, or a continued pursuit of their continuing relationship.
A class contains a description of data ("[[state (object-oriented programming)|state]]") stored in the objects of the class. The state of an object is stored in some resource, such as memory or a file. The storage is assumed to be located in a specific ___location, such that it is possible to access the object via [[reference (computer science)|reference]]s to the [[identity (object-oriented programming)|identity]] of the objects. However, the actual storage ___location associated with an object may change with time. In such situations, the identity of the object does not change. The state is encapsulated and every access to the state occurs via methods of the class.
 
===Death===
A class implements its interfaces by specifying methods that describe what operations can be performed on the data stored in the objects of the class. Each method specifies only tasks that are related to the stored data. Multi-methods can be used when a single task requires access to many objects' data.
''Fire Emblem'' characters that run out of hit points and die cannot be brought back to life in game. This also affects recruitable NPC and enemy units. If a player wishes to continue using a character or recruit a unit that has been killed, then the chapter must be restarted from the beginning. In addition, a "Game Over" occurs whenever one of the main characters (Lords) falls, or in other situations depending on a mission's requirements. Only under special circumstances, such as being significantly related to the story, will characters who have fallen in battle not actually die. In extremely rare situations, such as in ''Fire Emblem: Seisen no Keifu'', ''Fire Emblem: The Sacred Stones'', and ''Fire Emblem: Path of Radiance'', characters that fall in battle can become playable at a later point in the game. Exceptions aside, there is normally no method for restoring a fallen character's life, such as a particular spell or scroll. When there is one, it rarely occurs and breaks with only one use.
 
{{Fire Emblem characters}}
A class also describes a set of [[invariant (computer science)|invariant]]s that are preserved by every method in the class. An invariant is a constraint on the state of an object that should be satisfied by every object of the class. The main purpose of the invariants is to establish what objects belong to the class. An invariant is what distinguishes [[datatype]]s and classes from each other, that is, a class does not allow use of all possible values for the state of the object, only those that are well-defined by the semantics of the intended use of the datatype. The set of supported methods often implicitly establishes an invariant. Some programming languages support specification of invariants as part of the definition of the class, and enforce them via the type system. Encapsulation of state is necessary for being able to enforce the invariants of the class.
 
==Naming of the series==
An implementation of a class specifies [[constructor]] and [[destructor]] functions that allow creation and destruction of objects of the class. A constructor that takes arguments can be used to create an object from [[data]]. A destructor that returns a value can be used to obtain a [[representation]] of an object of a class. The main purpose of a constructor is to establish the invariant of the class, failing if the invariant isn't valid. The main purpose of a destructor is to destroy the identity of the object, invalidating any references in the process. Constructors and destructors are also sometimes used to reserve and release resources associated with the object.
The "Fire Emblem" to which the games' title refers is a plot device or item that has taken multiple forms throughout the series, changing with the setting. The original Fire Emblem was a [[shield]] which allowed the wielder, [[Marth (Fire Emblem)|Marth]], to use the [[Falchion]] sword. In the remake of the original game in ''Monshō no Nazo'', the Fire Emblem can be used by Marth to open chests and can be upgraded with five orbs to turn it into the [[Shield of Seals]] in Book two. In ''Rekka no Ken'' and ''Fūin no Tsurugi'', the Fire Emblem is a gemstone required for a ceremony to recognize the heir to the throne of Bern. It is also used to unlock the Sword of Seals. In ''The Sacred Stones'', the Fire Emblem is the Sacred Stone of Grado, which holds the Demon King's spirit, but it is split in two (the other half forms the Dark Stone), and the Fire Emblem is crushed. In ''Path of Radiance'', it was another name for Lehran's Medallion, an artifact containing the imprisoned spirit of an evil god. In ''Seisen no Keifu'', it does not appear, but it is mentioned as the family crest of the Velthomer house by the person succeeding it. But, it was also hinted to be one of the twelve holy weapons in the game.
 
==Games==
A class can also implement a set of auxiliary [[function (programming)|functions]], sometimes called class functions or static methods. Static methods are often used to find, create or destroy objects of the class. Constructors and destructors are sometimes specified as static methods. Often, mechanisms for sending an object to another ___location or changing the class of an object are specified as static methods.
 
The following is a list of games released in the series.
==Subclasses and superclasses==
 
:''Games predating ''Rekka no Ken'' were released only in Japan. Due to this, there are no official English language titles for these games. An official English language title may be given if Nintendo of America elects to localize any of these games to North America.''
Classes are often related in some way. The most popular of these relations is [[inheritance (object-oriented programming)|inheritance]], which involves '''subclasses''' and '''superclasses''', also known respectively as '''child classes''' (or '''derived classes''') and '''parent classes''' (or '''base classes'''). If [car] was a class, then [Jaguar] and [Porsche] might be two sub-classes. If [Button] is a subclass of [Control], then all buttons are controls. Subclasses usually consists of several kinds of modifications to the base class: addition of new instance variables, addition of new methods and [[overriding]] of existing methods to support the new instance variables.
 
{| width="100%" class="wikitable"
Conceptually, a superclass should be considered as a common part of its subclasses. This factoring of commonality is one mechanism for providing [[reuse]]. Thus, extending a superclass by modifying the existing class is also likely to narrow its applicability in various situations. In [[Object-oriented design]], careful balance between applicability and functionality of superclasses should be considered. Subclassing is different from [[subtyping]] in that subtyping deals with common behaviour whereas subclassing is concerned with common structure.
|-
!Cover !! Official Western title !! Japanese title !! Japanese Title Translation !!Platform !! Year !!Notes
|-
|style="align:center"|[[Image:Fe1box.jpg|100px]]
|
|ファイアーエムブレム　暗黒竜と光の剣 <p>(''[[Fire Emblem: Ankoku Ryū to Hikari no Tsurugi]]'')
|''The Dark Dragon and Sword of Light''
|[[Famicom]]
|[[1990]]
|The first ''Fire Emblem'' title.
|-
|style="align:center"|[[Image:Fe2box.jpg|100px]]
|
|ファイアーエムブレム外伝 <p>(''[[Fire Emblem Gaiden]]'')
|''Sidestory''
|[[Famicom]]
|[[1991]]
|Side story of the first title.
|-
|style="align:center"|[[Image:Fe3box.jpg|100px]]
|
|ファイアーエムブレム　紋章の謎 <p>(''[[Fire Emblem: Monshō no Nazo]]'')
|''Mystery of the Emblem''
|[[Super Nintendo Entertainment System|Super Famicom]]
|[[1993]]
|Enhanced remake of the ''Dark Dragon and Sword of Light'' along with sequel. It was adapted into a 2-part [[OVA]] series. In the English translated credits it says the show was based on "Fire Emblem: Secret of Crest" instead of "Mystery of the Emblem".
|-
|style="align:center"|[[Image:Seisen no Keifu.jpg|100px]]
|
|ファイアーエムブレム　聖戦の系譜 <p>(''[[Fire Emblem: Seisen no Keifu]]'')
|''Genealogy of <br />the Holy War''
|[[Super Nintendo Entertainment System|Super Famicom]]
|[[1996]]
|The first ''Fire Emblem'' title set in a separate universe. Deviates from standard ''Fire Emblem'' gameplay mechanisms.
|-
|style="align:center"|[[Image:Fe5box.jpg|100px]]
|
|ファイアーエムブレム トラキア776 <p>(''[[Fire Emblem: Thracia 776]]'')
|''Fire Emblem: Thracia 776''
|[[Super Nintendo Entertainment System|Super Famicom]]
|[[Nintendo Power (cartridge)|Nintendo Power]]: [[1999]] <p> Commercial release: [[2000]]
|A sidestory of ''Seisen no Keifu''. The last commercial release of the Super Famicom.
|-
|style="align:center"|[[Image:Fuuin no Tsurugi.jpg|100px]]
|
|ファイアーエムブレム　封印の剣 <p>(''[[Fire Emblem: Fūin no Tsurugi]]'')
|''Sword of Seals''
|[[Game Boy Advance]]
|[[2002]]
|The first ''Fire Emblem'' title to appear on a Nintendo [[handheld]].
|-
|style="align:center"|[[Image:GBA Fire Emblem Box.jpg|100px]]
|''[[Fire Emblem (Game Boy Advance)|Fire Emblem]]''
|ファイアーエムブレム 烈火の剣 <p>(''Fire Emblem: Rekka no Ken'')
|''Sword of Fire''
|[[Game Boy Advance]]
|[[2003]]
|The first ''Fire Emblem'' title to be released in the West and the prequel to ''Sword of Seals''.
|-
|style="align:center"|[[Image:Fire Emblem The Sacred Stones.JPG|100px]]
|''[[Fire Emblem: The Sacred Stones]]''
|ファイアーエムブレム 聖魔の光石 <p>(''Fire Emblem: Seima no Kōseki'')
|''The Stones of Saintly and Demonic Light''
|[[Game Boy Advance]]
|Japan: [[2004]] US: [[2005]]
|First title to incorporate several play mechanics not seen since ''Fire Emblem Gaiden''.
|-
|style="align:center"|[[Image:Fire Emblem PoR Boxart.JPG|100px]]
|''[[Fire Emblem: Path of Radiance]]''
|ファイアーエムブレム 蒼炎の軌跡<p> (''Fire Emblem: Sōen no Kiseki'')
|''Trail of the Blue Flame''
|[[Nintendo Gamecube]]
|[[2005]]
|The first title in the series to be rendered in [[3D computer graphics|three-dimensions]] and to incorporate [[full motion video]].
|-
|style="align:center"|[[Image:Fire Emblem Goddess of the Dawn Japanese Boxart.jpg|100px]]
|''(Has yet to be officially titled worldwide)
|ファイアーエムブレム 暁の女神 <p> (''Fire Emblem: Akatsuki no Megami'')
|''[[Fire Emblem: The Goddess of Dawn|Goddess of Dawn]]'' <ref>{{cite web|title=Fire Emblem: The Goddess of Dawn (Wii)|url=http://www.1up.com/do/previewPage?cId=3153633|accessdate=2007-02-26|last=Kennedy|first=Sam|date=[[2006-09-14]]|publisher=[[1UP.com]]}}</ref>
|[[Wii]]
|[[2007]]
|The sequel to ''Fire Emblem: Path of Radiance''.
|}
 
==Music==
Some [[programming language|programming languages]] (for example [[C Plus Plus|C++]]) allow [[multiple inheritance]] -- they allow a child class to have more than one parent class. This technique has been criticized by some for its unnecessary complexity and being difficult to implement efficiently, though some projects have certainly benefited from its use. [[Java programming language|Java]], for example has no multiple inheritance, its designers feeling that this would be more trouble than it was worth.
The musical scores for ''Fire Emblem'' have been composed by [[Yuka Tsujiyoko]] for most of the series' history. ''Fire Emblem: The Sacred Stones'' was scored by Saki Haruyama, Yoshihiko Kitamura, and Yoshito Hirano, under Tsujiyoko's supervision. The first eight games in the series all featured soundtracks composed entirely of instrumental music. However, ''[[Fire Emblem: Path of Radiance]]'' broke from this trend with the end credit theme "Life Returns", a lyrical piece sung in the language of the fictional heron laguz tribe.
 
There are also recurring tracks in the Fire Emblem series. The most frequently used is the "Fire Emblem Main Theme" which is played at some point during each game. Its use is particularly varied, as it is sometimes used as the title screen theme, while in ''Path of Radiance'', the song isn't heard until the very end of the game, when each character's performance is ranked. Another track that is frequently remixed is a character recruitment theme entitled "Together We Ride," although it is not used in every game. Since ''[[Fire Emblem: Seisen no Keifu]]'', battle themes of previous Fire Emblem games have been remixed as arena battle themes. Similar rearranging appears in other circumstances, as well; for example, the musical score for the trial maps in ''Path of Radiance'' was originally the music score for Chapter 10 of ''Seisen no Keifu''.
Sub- and superclasses are considered to exist within a [[hierarchy (object-oriented programming)|hierarchy]] defined by the inheritance relationship. If multiple inheritance is allowed, this hierarchy is a [[directed acyclic graph]] (or DAG for short), otherwise it is a [[tree (graph theory)|tree]]. The hierarchy has classes as nodes and inheritance relationships as links. The levels of this hierarchy are called [[layer]]s or [[level of abstraction|levels of abstraction]]. Classes in the same level are more likely to be [[association (object-oriented_programming)|associated]] than classes in different levels.
 
==Other media==
There are two slightly different points of view as to whether subclasses of the same class are required to be disjoint. Sometimes, subclasses of a particular class are considered to be completely disjoint. That is, every instance of a class has exactly one ''most-derived class'', which is a subclass of every class that the instance has. This view does not allow dynamic change of object's class, as objects are assumed to be created with a fixed most-derived class. The basis for not allowing changes to object's class is that the class is a compile-time type, which does not usually change at runtime, and polymorphism is utilised for any dynamic change to the object's behaviour, so this ability is not necessary. And design that does not need to perform changes to object's type will be more robust and easy-to-use from the point of view of the users of the class.
 
*In [[1995]], an [[anime]] [[OVA]] (co-produced with [[KSS (company)|KSS]]) was produced and released; it was closely based on the first three acts of the very first game in the series or more specifically, the remake contained in ''Monshō no Nazo''. See also ''[[Fire Emblem (anime)]]''.
From another point of view, subclasses are not required to be disjoint. Then there is no concept of a most-derived class, and all types in the inheritance hierarchy that are types of the instance are considered to be equally types of the instance. This view is based on a dynamic classification of objects, such that an object may change its class at runtime. Then object's class is considered to be its ''current'' structure, but changes to it are allowed. The basis for allowing object's class to change is performance. It's more efficient to allow changes to object's type, since references to the existing instances do not need to be replaced with references to new instances when the class of the object changes. However, this ability is not readily available in all programming languages.
 
*Fire Emblem The Best Volume One was a video game music sound-track released on April 25, 1997 by Nintendo corporation (serial# PSCN-5058~9).
==Reasons for implementing classes==
 
==Trivia==
Classes, when used properly, can accelerate development by reducing redundant code entry, testing and bug fixing. If a class has been thoroughly tested and is known to be a solid work, it stands to reason that implementing that class or extending it will reduce if not eliminate the possibility of bugs propagating into the code. In the case of extension new code is being added so it also requires the same level of testing before it can be considered solid.
*A title listed as "AKANEIA" in the debug mode of ''Super Smash Bros. Melee'' suggests that an arena based upon ''Fire Emblem'' was under development, but no real map data exists and players often end up fighting against Marth and Roy in Hyrule Temple. If Marth is unlocked and all human players hold either L or R while selecting Hyrule Temple, a remixed version of Fire Emblem's main theme and the recruiting theme will play instead of its original music. The song may also play randomly if Marth is unlocked.
 
*In another Intelligent Systems game, ''[[Paper Mario: The Thousand-Year Door]]'', there is a minor character in Petalburg that raves about his favorite video games when spoken to. The first game he talks about is ''[[Fire Emblem: Rekka no Ken|Fire Emblem]]''.
Another reason for using classes is to simplify the relationships of interrelated data. Rather than writing code to repeatedly draw a GUI window on the terminal screen, it is simpler to represent the window as an object and tell it to draw itself as necessary. With classes, GUI items that are similar to windows (such as dialog boxes) can simply inherit most of their functionality and data structures from the window class. The programmer then need only add code to the dialog class that is unique to its operation. Indeed, GUIs are a very common and useful application of classes, and GUI programming is generally much easier with a good class framework.
 
*''[[Fire Emblem: Monshou no Nazo]]'' is the only Fire Emblem game to appear in [[Famitsu]]'s 2006 Top one hundred games list. Famitsu readers voted it the number sixty-eighth game of all time. It was also among the first titles released as a Virtual Console title at the launch of the Japanese region Wii Shop Channel.
==Categories of Classes==
 
*The Nintendo DS game ''[[Daigasso! Band-Brothers]]'' features the Fire Emblem theme as a song.
An '''abstract class''', or ''abstract base class'' (ABC), is one that is designed ''only'' as a [[class (object-oriented programming)|parent class]] and from which [[class (object-oriented programming)|child classes]] may be derived, and which is not itself suitable for [[instance|instantiation]]. Abstract classes are often used to represent [[abstract]] concepts or entities. The incomplete features of the abstract class are then shared by a group of sibling sub-classes which add different variations of the missing pieces. In C++, an abstract class is
defined as a class having at least one virtual function without an implementation.
 
*Fire Emblem characters are usually [[right-handed]]. One exception is that Sothe from ''Fire Emblem: Path of Radiance'' and ''Fire Emblem: The Goddess of Dawn'' is [[left-handed]], according to the official artwork.{{Fact|date=February 2007}}
Abstract classes are superclasses which contain [[abstract method]]s and are defined such that subclasses are to extend them by implementing the [[method (computer science)|method]]s. The [[behavior]]s defined by such a class are ''"generic"'' and much of the class will be [[definition|undefined]] and unimplemented. Before a class derived from an abstract class can be instantiated, it must implement particular methods for all the abstract methods of its parent classes.
 
*A red-headed girl named Anna makes appearances in numerous games in the series. Although she isn't an actual member of any ''Fire Emblem'' cast, she generally appears in games when the player is about to suspend game data or serves as the tutorial narratress.
In [[computing]], when specifying an '''abstract class''', the programmer is referring to a [[Class (computer science)|class]] which has elements that are meant to be implemented by inheritance. The [[Abstraction (computer science)|abstraction]] of the class [[Method (computer science)|methods]] to be implemented by the sub-classes is meant to simplify [[software development]].
 
==See also==
A '''concrete class''', however, is a [[Class (computer science)|class]] for which entities (instances) may be created. This contrasts with abstract classes which can not be [[instance|instantiated]] because it defeats its purpose of being an 'abstract'.
 
*[[List of character classes#Fire Emblem|List of character classes]]
==Object-based programming==
*[[Table of Fire Emblem characters]]
Some languages have objects, but no classes; in such "[[object-based programming|object-based languages]]", objects are not restricted to class structure.
*[[Fan translation]]
Object-based languages with this property do not provide the structural benefits of statically type checked interfaces for objects.
*[[Nintendo Wars]]
*[[Tear Ring Saga]]
 
==C++References==
{{Reflist}}
In [[C Plus Plus|C++]], an abstract class is a class having at least one pure virtual function.
They can not be instantiated and will generate an error if an attempt is made. They are meant to function as stubs, allowing the programmer to identify what modules of functions (behaviour or methods) are needed without having to actually implement them. This is in line with [[OOP]]'s philosophy of allowing the programmer to concentrate on how an object should behave without going into the actual detail.
 
==External links==
Most [[Object-oriented programming language|object oriented programming languages]] allow the [[programmer]] to specify which classes are considered abstract and will not allow these to be instantiated (in [[Java programming language|Java]], for example, the keyword ''abstract'' is used). This also
<!---Please don't add your own links without first discussion it on the talk page. Thanks.--->
enables the programmer to focus on planning and design. The actual
{{portal|Nintendo|Wikitendo2.svg}}
implementation of course is to be done in the derived classes.
{{wikiquote}}
*[http://www.fire-emblem.com Official US ''Fire Emblem'' website]
*[http://www.intsys.co.jp/game/fe/index.html Intelligent Systems' official ''Fire Emblem'' website (Japanese)]
*[http://www.nintendo.co.jp/fe/index.html Nintendo of Japan's official ''Fire Emblem'' website (Japanese)]
*[http://eg.nttpub.co.jp/fe/ Official Trading Card Game website (Japanese)]
*{{moby game|id=-group/fire-emblem-series|name=The ''Fire Emblem'' series}}
*[http://eaichu250.superbusnet.com/ English Fire Emblem Documentary]
 
{{Fire Emblem}}
See, for example, [[class (object-oriented programming)]] for a unified discussion.
 
== Metaclasses ==
 
Metaclasses are classes whose instances are classes. A metaclass describes a common structure of a collection of classes. A metaclass can implement a [[design pattern (computer science)|design pattern]] or describe a shorthand for particular kinds of classes. Metaclasses are often used to describe [[framework]]s.
 
== Examples ==
=== Examples in C++ ===
==== Example 1 ====
 
class example {
// this is a class
};
 
This example shows how to define a [[C Plus Plus|C++]] class. It has no data, and performs no functions; it only contains the comment, "this is a class".
 
==== Example 2 ====
 
class Abstract
{
public:
virtual void MyVirtualMethod() = 0;
};
 
class Concrete : public Abstract
{
public:
void MyVirtualMethod()
{
//do something
}
};
 
An object of class Abstract can not be created because the function MyVirtualMethod has not been defined (the =0 is C++ syntax for a pure virtual function, a function that must be part of any derived concrete class but is not defined in the abstract base class. The Concrete class is a concrete class because its functions (in this case, only one function) have been declared and implemented.
 
==== Example 3 ====
 
#include <string>
using std::string;
class InetMessage
{
string m_subject, m_to, m_from;
public:
InetMessage (const string& subject,
const string& to,
const string& from);
string subject () const;
string to () const;
string from () const;
};
</pre>
 
=== Examples in Java ===
==== Example 1 ====
 
public class Example1
{
// This is a Java class, it automatically extends the class Object
}
 
This example shows the simplest [[Java programming language|Java]] class possible.
 
==== Example 2 ====
 
public class Example2 extends Example1
{
// This is a class that extends the class created in Example 1.
protected int data;
public Example2()
{
// This is a constructor for the class. It does not have a return type.
data = 1;
}
public int getData()
{
return data;
}
public void setData(int d)
{
data = d;
}
}
 
This example shows a class that has a defined constructor, one member data, and two accessor methods for that member data. It extends the previous example's class. Note that in Java all classes automatically extend the class Object. This allows you to write generic code to deal with objects of any type.
 
==See also==
* [[Instance|Instantiation]]
* [[Hierarchy (object-oriented programming)|Hierarchy]]
* [[Unified Modeling Language]] (UML)
 
[[Category:Object-orientedFire programmingEmblem|*]]
[[Category:Video game franchises]]
 
[[de:Fire Emblem]]
[[de:Klasse (objektorientierte Programmierung)]]
[[es:Fire Emblem]]
[[ja:&#12463;&#12521;&#12473;]]
[[fifr:LuokkaFire Emblem]]
[[it:Fire Emblem]]
[[lt:Klas&#279; (programavimas)]]
[[plnl:KlasaFire abstrakcyjnaEmblem]]
[[ja:ファイアーエムブレム]]
[[sv:Klass (programmering)]]
[[frpt:ClasseFire (informatique)Emblem]]
[[ro:Fire Emblem]]
[[zh:&#31867; (&#35745;&#31639;&#26426;&#31185;&#23398;)]]
[[fi:Fire Emblem]]
[[zh:火焰之纹章]]
Retrieved from "https://en.wikipedia.org/wiki/Class_(computer_programming)"