{
    "mode": "man",
    "parameter": "perlootut",
    "section": "1",
    "url": "https://www.chedong.com/phpMan.php/man/perlootut/1/json",
    "generated": "2026-10-10T08:36:24Z",
    "sections": {
        "NAME": {
            "content": "perlootut - Object-Oriented Programming in Perl Tutorial\n",
            "subsections": []
        },
        "DATE": {
            "content": "This document was created in February, 2011, and the last major revision was in February,\n2013.\n\nIf you are reading this in the future then it's possible that the state of the art has\nchanged. We recommend you start by reading the perlootut document in the latest stable\nrelease of Perl, rather than this version.\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "This document provides an introduction to object-oriented programming in Perl. It begins with\na brief overview of the concepts behind object oriented design. Then it introduces several\ndifferent OO systems from CPAN <https://www.cpan.org> which build on top of what Perl\nprovides.\n\nBy default, Perl's built-in OO system is very minimal, leaving you to do most of the work.\nThis minimalism made a lot of sense in 1994, but in the years since Perl 5.0 we've seen a\nnumber of common patterns emerge in Perl OO. Fortunately, Perl's flexibility has allowed a\nrich ecosystem of Perl OO systems to flourish.\n\nIf you want to know how Perl OO works under the hood, the perlobj document explains the nitty\ngritty details.\n\nThis document assumes that you already understand the basics of Perl syntax, variable types,\noperators, and subroutine calls. If you don't understand these concepts yet, please read\nperlintro first. You should also read the perlsyn, perlop, and perlsub documents.\n",
            "subsections": []
        },
        "OBJECT-ORIENTED FUNDAMENTALS": {
            "content": "Most object systems share a number of common concepts. You've probably heard terms like\n\"class\", \"object, \"method\", and \"attribute\" before.  Understanding the concepts will make it\nmuch easier to read and write object-oriented code. If you're already familiar with these\nterms, you should still skim this section, since it explains each concept in terms of Perl's\nOO implementation.\n\nPerl's OO system is class-based. Class-based OO is fairly common. It's used by Java, C++, C#,\nPython, Ruby, and many other languages. There are other object orientation paradigms as well.\nJavaScript is the most popular language to use another paradigm. JavaScript's OO system is\nprototype-based.\n",
            "subsections": [
                {
                    "name": "Object",
                    "content": "An object is a data structure that bundles together data and subroutines which operate on\nthat data. An object's data is called attributes, and its subroutines are called methods. An\nobject can be thought of as a noun (a person, a web service, a computer).\n\nAn object represents a single discrete thing. For example, an object might represent a file.\nThe attributes for a file object might include its path, content, and last modification time.\nIf we created an object to represent /etc/hostname on a machine named \"foo.example.com\", that\nobject's path would be \"/etc/hostname\", its content would be \"foo\\n\", and it's last\nmodification time would be 1304974868 seconds since the beginning of the epoch.\n\nThe methods associated with a file might include rename() and write().\n\nIn Perl most objects are hashes, but the OO systems we recommend keep you from having to\nworry about this. In practice, it's best to consider an object's internal data structure\nopaque.\n"
                },
                {
                    "name": "Class",
                    "content": "A class defines the behavior of a category of objects. A class is a name for a category (like\n\"File\"), and a class also defines the behavior of objects in that category.\n\nAll objects belong to a specific class. For example, our /etc/hostname object belongs to the\n\"File\" class. When we want to create a specific object, we start with its class, and\nconstruct or instantiate an object. A specific object is often referred to as an instance of\na class.\n\nIn Perl, any package can be a class. The difference between a package which is a class and\none which isn't is based on how the package is used. Here's our \"class declaration\" for the\n\"File\" class:\n\npackage File;\n\nIn Perl, there is no special keyword for constructing an object.  However, most OO modules on\nCPAN use a method named new() to construct a new object:\n\nmy $hostname = File->new(\npath          => '/etc/hostname',\ncontent       => \"foo\\n\",\nlastmodtime => 1304974868,\n);\n\n(Don't worry about that \"->\" operator, it will be explained later.)\n\nBlessing\n\nAs we said earlier, most Perl objects are hashes, but an object can be an instance of any\nPerl data type (scalar, array, etc.). Turning a plain data structure into an object is done\nby blessing that data structure using Perl's \"bless\" function.\n\nWhile we strongly suggest you don't build your objects from scratch, you should know the term\nbless. A blessed data structure (aka \"a referent\") is an object. We sometimes say that an\nobject has been \"blessed into a class\".\n\nOnce a referent has been blessed, the \"blessed\" function from the Scalar::Util core module\ncan tell us its class name. This subroutine returns an object's class when passed an object,\nand false otherwise.\n\nuse Scalar::Util 'blessed';\n\nprint blessed($hash);      # undef\nprint blessed($hostname);  # File\n\nConstructor\n\nA constructor creates a new object. In Perl, a class's constructor is just another method,\nunlike some other languages, which provide syntax for constructors. Most Perl classes use\n\"new\" as the name for their constructor:\n\nmy $file = File->new(...);\n"
                },
                {
                    "name": "Methods",
                    "content": "You already learned that a method is a subroutine that operates on an object. You can think\nof a method as the things that an object can do. If an object is a noun, then methods are its\nverbs (save, print, open).\n\nIn Perl, methods are simply subroutines that live in a class's package.  Methods are always\nwritten to receive the object as their first argument:\n\nsub printinfo {\nmy $self = shift;\n\nprint \"This file is at \", $self->path, \"\\n\";\n}\n\n$file->printinfo;\n# The file is at /etc/hostname\n\nWhat makes a method special is how it's called. The arrow operator (\"->\") tells Perl that we\nare calling a method.\n\nWhen we make a method call, Perl arranges for the method's invocant to be passed as the first\nargument. Invocant is a fancy name for the thing on the left side of the arrow. The invocant\ncan either be a class name or an object. We can also pass additional arguments to the method:\n\nsub printinfo {\nmy $self   = shift;\nmy $prefix = shift // \"This file is at \";\n\nprint $prefix, \", \", $self->path, \"\\n\";\n}\n\n$file->printinfo(\"The file is located at \");\n# The file is located at /etc/hostname\n"
                },
                {
                    "name": "Attributes",
                    "content": "Each class can define its attributes. When we instantiate an object, we assign values to\nthose attributes. For example, every \"File\" object has a path. Attributes are sometimes\ncalled properties.\n\nPerl has no special syntax for attributes. Under the hood, attributes are often stored as\nkeys in the object's underlying hash, but don't worry about this.\n\nWe recommend that you only access attributes via accessor methods.  These are methods that\ncan get or set the value of each attribute. We saw this earlier in the printinfo() example,\nwhich calls \"$self->path\".\n\nYou might also see the terms getter and setter. These are two types of accessors. A getter\ngets the attribute's value, while a setter sets it. Another term for a setter is mutator\n\nAttributes are typically defined as read-only or read-write. Read-only attributes can only be\nset when the object is first created, while read-write attributes can be altered at any time.\n\nThe value of an attribute may itself be another object. For example, instead of returning its\nlast mod time as a number, the \"File\" class could return a DateTime object representing that\nvalue.\n\nIt's possible to have a class that does not expose any publicly settable attributes. Not\nevery class has attributes and methods.\n"
                },
                {
                    "name": "Polymorphism",
                    "content": "Polymorphism is a fancy way of saying that objects from two different classes share an API.\nFor example, we could have \"File\" and \"WebPage\" classes which both have a printcontent()\nmethod. This method might produce different output for each class, but they share a common\ninterface.\n\nWhile the two classes may differ in many ways, when it comes to the printcontent() method,\nthey are the same. This means that we can try to call the printcontent() method on an object\nof either class, and we don't have to know what class the object belongs to!\n\nPolymorphism is one of the key concepts of object-oriented design.\n"
                },
                {
                    "name": "Inheritance",
                    "content": "Inheritance lets you create a specialized version of an existing class. Inheritance lets the\nnew class reuse the methods and attributes of another class.\n\nFor example, we could create an \"File::MP3\" class which inherits from \"File\". An \"File::MP3\"\nis-a more specific type of \"File\".  All mp3 files are files, but not all files are mp3 files.\n\nWe often refer to inheritance relationships as parent-child or \"superclass\"/\"subclass\"\nrelationships. Sometimes we say that the child has an is-a relationship with its parent\nclass.\n\n\"File\" is a superclass of \"File::MP3\", and \"File::MP3\" is a subclass of \"File\".\n\npackage File::MP3;\n\nuse parent 'File';\n\nThe parent module is one of several ways that Perl lets you define inheritance relationships.\n\nPerl allows multiple inheritance, which means that a class can inherit from multiple parents.\nWhile this is possible, we strongly recommend against it. Generally, you can use roles to do\neverything you can do with multiple inheritance, but in a cleaner way.\n\nNote that there's nothing wrong with defining multiple subclasses of a given class. This is\nboth common and safe. For example, we might define \"File::MP3::FixedBitrate\" and\n\"File::MP3::VariableBitrate\" classes to distinguish between different types of mp3 file.\n\nOverriding methods and method resolution\n\nInheritance allows two classes to share code. By default, every method in the parent class is\nalso available in the child. The child can explicitly override a parent's method to provide\nits own implementation. For example, if we have an \"File::MP3\" object, it has the\nprintinfo() method from \"File\":\n\nmy $cage = File::MP3->new(\npath          => 'mp3s/My-Body-Is-a-Cage.mp3',\ncontent       => $mp3data,\nlastmodtime => 1304974868,\ntitle         => 'My Body Is a Cage',\n);\n\n$cage->printinfo;\n# The file is at mp3s/My-Body-Is-a-Cage.mp3\n\nIf we wanted to include the mp3's title in the greeting, we could override the method:\n\npackage File::MP3;\n\nuse parent 'File';\n\nsub printinfo {\nmy $self = shift;\n\nprint \"This file is at \", $self->path, \"\\n\";\nprint \"Its title is \", $self->title, \"\\n\";\n}\n\n$cage->printinfo;\n# The file is at mp3s/My-Body-Is-a-Cage.mp3\n# Its title is My Body Is a Cage\n\nThe process of determining what method should be used is called method resolution. What Perl\ndoes is look at the object's class first (\"File::MP3\" in this case). If that class defines\nthe method, then that class's version of the method is called. If not, Perl looks at each\nparent class in turn. For \"File::MP3\", its only parent is \"File\". If \"File::MP3\" does not\ndefine the method, but \"File\" does, then Perl calls the method in \"File\".\n\nIf \"File\" inherited from \"DataSource\", which inherited from \"Thing\", then Perl would keep\nlooking \"up the chain\" if necessary.\n\nIt is possible to explicitly call a parent method from a child:\n\npackage File::MP3;\n\nuse parent 'File';\n\nsub printinfo {\nmy $self = shift;\n\n$self->SUPER::printinfo();\nprint \"Its title is \", $self->title, \"\\n\";\n}\n\nThe \"SUPER::\" bit tells Perl to look for the printinfo() in the \"File::MP3\" class's\ninheritance chain. When it finds the parent class that implements this method, the method is\ncalled.\n\nWe mentioned multiple inheritance earlier. The main problem with multiple inheritance is that\nit greatly complicates method resolution.  See perlobj for more details.\n"
                },
                {
                    "name": "Encapsulation",
                    "content": "Encapsulation is the idea that an object is opaque. When another developer uses your class,\nthey don't need to know how it is implemented, they just need to know what it does.\n\nEncapsulation is important for several reasons. First, it allows you to separate the public\nAPI from the private implementation. This means you can change that implementation without\nbreaking the API.\n\nSecond, when classes are well encapsulated, they become easier to subclass. Ideally, a\nsubclass uses the same APIs to access object data that its parent class uses. In reality,\nsubclassing sometimes involves violating encapsulation, but a good API can minimize the need\nto do this.\n\nWe mentioned earlier that most Perl objects are implemented as hashes under the hood. The\nprinciple of encapsulation tells us that we should not rely on this. Instead, we should use\naccessor methods to access the data in that hash. The object systems that we recommend below\nall automate the generation of accessor methods. If you use one of them, you should never\nhave to access the object as a hash directly.\n"
                },
                {
                    "name": "Composition",
                    "content": "In object-oriented code, we often find that one object references another object. This is\ncalled composition, or a has-a relationship.\n\nEarlier, we mentioned that the \"File\" class's \"lastmodtime\" accessor could return a\nDateTime object. This is a perfect example of composition. We could go even further, and make\nthe \"path\" and \"content\" accessors return objects as well. The \"File\" class would then be\ncomposed of several other objects.\n"
                },
                {
                    "name": "Roles",
                    "content": "Roles are something that a class does, rather than something that it is. Roles are relatively\nnew to Perl, but have become rather popular. Roles are applied to classes. Sometimes we say\nthat classes consume roles.\n\nRoles are an alternative to inheritance for providing polymorphism.  Let's assume we have two\nclasses, \"Radio\" and \"Computer\". Both of these things have on/off switches. We want to model\nthat in our class definitions.\n\nWe could have both classes inherit from a common parent, like \"Machine\", but not all machines\nhave on/off switches. We could create a parent class called \"HasOnOffSwitch\", but that is\nvery artificial.  Radios and computers are not specializations of this parent. This parent is\nreally a rather ridiculous creation.\n\nThis is where roles come in. It makes a lot of sense to create a \"HasOnOffSwitch\" role and\napply it to both classes. This role would define a known API like providing turnon() and\nturnoff() methods.\n\nPerl does not have any built-in way to express roles. In the past, people just bit the bullet\nand used multiple inheritance. Nowadays, there are several good choices on CPAN for using\nroles.\n"
                },
                {
                    "name": "When to Use OO",
                    "content": "Object Orientation is not the best solution to every problem. In Perl Best Practices\n(copyright 2004, Published by O'Reilly Media, Inc.), Damian Conway provides a list of\ncriteria to use when deciding if OO is the right fit for your problem:\n\n•   The system being designed is large, or is likely to become large.\n\n•   The  data can be aggregated into obvious structures, especially if there's a large amount\nof data in each aggregate.\n\n•   The various types of data aggregate form a natural hierarchy that facilitates the use  of\ninheritance and polymorphism.\n\n•   You have a piece of data on which many different operations are applied.\n\n•   You need to perform the same general operations on related types of data, but with slight\nvariations depending on the specific type of data the operations are applied to.\n\n•   It's likely you'll have to add new data types later.\n\n•   The typical interactions between pieces of data are best represented by operators.\n\n•   The implementation of individual components of the system is likely to change over time.\n\n•   The system design is already object-oriented.\n\n•   Large numbers of other programmers will be using your code modules.\n"
                }
            ]
        },
        "PERL OO SYSTEMS": {
            "content": "As  we  mentioned before, Perl's built-in OO system is very minimal, but also quite flexible.\nOver the years, many people have developed systems which build  on  top  of  Perl's  built-in\nsystem to provide more features and convenience.\n\nWe  strongly  recommend  that  you  use  one  of these systems. Even the most minimal of them\neliminates a lot of repetitive boilerplate. There's really  no  good  reason  to  write  your\nclasses from scratch in Perl.\n\nIf you are interested in the guts underlying these systems, check out perlobj.\n",
            "subsections": [
                {
                    "name": "Moose",
                    "content": "Moose  bills  itself  as  a  \"postmodern  object  system  for  Perl  5\". Don't be scared, the\n\"postmodern\" label is a callback to Larry's description of  Perl  as  \"the  first  postmodern\ncomputer language\".\n\n\"Moose\"  provides  a  complete,  modern  OO  system. Its biggest influence is the Common Lisp\nObject System, but it also borrows ideas from Smalltalk and several other languages.  \"Moose\"\nwas created by Stevan Little, and draws heavily from his work on the Raku OO design.\n\nHere is our \"File\" class using \"Moose\":\n\npackage File;\nuse Moose;\n\nhas path          => ( is => 'ro' );\nhas content       => ( is => 'ro' );\nhas lastmodtime => ( is => 'ro' );\n\nsub printinfo {\nmy $self = shift;\n\nprint \"This file is at \", $self->path, \"\\n\";\n}\n\n\"Moose\" provides a number of features:\n\n•   Declarative sugar\n\n\"Moose\" provides a layer of declarative \"sugar\" for defining classes.  That sugar is just\na  set  of  exported  functions that make declaring how your class works simpler and more\npalatable.  This lets you describe what your class is, rather than having  to  tell  Perl\nhow to implement your class.\n\nThe  has()  subroutine declares an attribute, and \"Moose\" automatically creates accessors\nfor these attributes. It also takes care  of  creating  a  new()  method  for  you.  This\nconstructor  knows about the attributes you declared, so you can set them when creating a\nnew \"File\".\n\n•   Roles built-in\n\n\"Moose\" lets you define roles the same way you define classes:\n\npackage HasOnOffSwitch;\nuse Moose::Role;\n\nhas ison => (\nis  => 'rw',\nisa => 'Bool',\n);\n\nsub turnon {\nmy $self = shift;\n$self->ison(1);\n}\n\nsub turnoff {\nmy $self = shift;\n$self->ison(0);\n}\n\n•   A miniature type system\n\nIn the example above, you can see that we passed \"isa => 'Bool'\" to has()  when  creating\nour \"ison\" attribute. This tells \"Moose\" that this attribute must be a boolean value. If\nwe try to set it to an invalid value, our code will throw an error.\n\n•   Full introspection and manipulation\n\nPerl's  built-in introspection features are fairly minimal. \"Moose\" builds on top of them\nand creates a full introspection layer for your classes. This lets you ask questions like\n\"what methods does the File class implement?\"  It  also  lets  you  modify  your  classes\nprogrammatically.\n\n•   Self-hosted and extensible\n\n\"Moose\"  describes  itself  using  its own introspection API. Besides being a cool trick,\nthis means that you can extend \"Moose\" using \"Moose\" itself.\n\n•   Rich ecosystem\n\nThere  is  a  rich  ecosystem  of  \"Moose\"  extensions   on   CPAN   under   the   MooseX\n<https://metacpan.org/search?q=MooseX>  namespace.  In  addition,  many  modules  on CPAN\nalready use \"Moose\", providing you with lots of examples to learn from.\n\n•   Many more features\n\n\"Moose\" is a very powerful tool, and  we  can't  cover  all  of  its  features  here.  We\nencourage  you  to  learn  more  by  reading  the  \"Moose\"  documentation,  starting with\nMoose::Manual <https://metacpan.org/pod/Moose::Manual>.\n\nOf course, \"Moose\" isn't perfect.\n\n\"Moose\" can make your code slower to load. \"Moose\" itself is not small, and it does a lot  of\ncode generation when you define your class. This code generation means that your runtime code\nis as fast as it can be, but you pay for this when your modules are first loaded.\n\nThis  load time hit can be a problem when startup speed is important, such as with a command-\nline script or a \"plain vanilla\" CGI script that must be loaded each time it is executed.\n\nBefore you panic, know that many people do use  \"Moose\"  for  command-line  tools  and  other\nstartup-sensitive  code.  We  encourage  you  to  try \"Moose\" out first before worrying about\nstartup speed.\n\n\"Moose\" also has several dependencies on other modules. Most of these are  small  stand-alone\nmodules,  a  number of which have been spun off from \"Moose\". \"Moose\" itself, and some of its\ndependencies, require a compiler. If you need to install your software on a system without  a\ncompiler, or if having any dependencies is a problem, then \"Moose\" may not be right for you.\n\nMoo\n\nIf you try \"Moose\" and find that one of these issues is preventing you from using \"Moose\", we\nencourage you to consider Moo next. \"Moo\" implements a subset of \"Moose\"'s functionality in a\nsimpler  package.  For most features that it does implement, the end-user API is identical to\n\"Moose\", meaning you can switch from \"Moo\" to \"Moose\" quite easily.\n\n\"Moo\" does not implement most of \"Moose\"'s introspection  API,  so  it's  often  faster  when\nloading  your  modules.  Additionally,  none  of  its  dependencies  require XS, so it can be\ninstalled on machines without a compiler.\n\nOne of \"Moo\"'s most compelling features is its interoperability with  \"Moose\".  When  someone\ntries  to  use  \"Moose\"'s  introspection  API  on  a \"Moo\" class or role, it is transparently\ninflated into a \"Moose\" class or role. This makes it easier to incorporate  \"Moo\"-using  code\ninto a \"Moose\" code base and vice versa.\n\nFor  example,  a  \"Moose\" class can subclass a \"Moo\" class using \"extends\" or consume a \"Moo\"\nrole using \"with\".\n\nThe \"Moose\" authors hope that one day \"Moo\" can be made obsolete by improving \"Moose\" enough,\nbut for now it provides a worthwhile alternative to \"Moose\".\n"
                },
                {
                    "name": "Class::Accessor",
                    "content": "Class::Accessor is the polar opposite of \"Moose\". It provides very few features,  nor  is  it\nself-hosting.\n\nIt is, however, very simple, pure Perl, and it has no non-core dependencies. It also provides\na \"Moose-like\" API on demand for the features it supports.\n\nEven  though  it  doesn't  do  much,  it is still preferable to writing your own classes from\nscratch.\n\nHere's our \"File\" class with \"Class::Accessor\":\n\npackage File;\nuse Class::Accessor 'antlers';\n\nhas path          => ( is => 'ro' );\nhas content       => ( is => 'ro' );\nhas lastmodtime => ( is => 'ro' );\n\nsub printinfo {\nmy $self = shift;\n\nprint \"This file is at \", $self->path, \"\\n\";\n}\n\nThe \"antlers\" import flag tells \"Class::Accessor\" that you want  to  define  your  attributes\nusing  \"Moose\"-like  syntax.  The  only  parameter  that  you  can  pass to \"has\" is \"is\". We\nrecommend that you use this Moose-like syntax if you choose \"Class::Accessor\" since it  means\nyou will have a smoother upgrade path if you later decide to move to \"Moose\".\n\nLike \"Moose\", \"Class::Accessor\" generates accessor methods and a constructor for your class.\n"
                },
                {
                    "name": "Class::Tiny",
                    "content": "Finally,  we  have  Class::Tiny. This module truly lives up to its name. It has an incredibly\nminimal API and absolutely no dependencies on any recent Perl. Still, we  think  it's  a  lot\neasier to use than writing your own OO code from scratch.\n\nHere's our \"File\" class once more:\n\npackage File;\nuse Class::Tiny qw( path content lastmodtime );\n\nsub printinfo {\nmy $self = shift;\n\nprint \"This file is at \", $self->path, \"\\n\";\n}\n\nThat's it!\n\nWith \"Class::Tiny\", all accessors are read-write. It generates a constructor for you, as well\nas the accessors you define.\n\nYou can also use Class::Tiny::Antlers for \"Moose\"-like syntax.\n"
                },
                {
                    "name": "Role::Tiny",
                    "content": "As  we  mentioned before, roles provide an alternative to inheritance, but Perl does not have\nany built-in role support. If you choose to use Moose, it  comes  with  a  full-fledged  role\nimplementation.  However,  if  you use one of our other recommended OO modules, you can still\nuse roles with Role::Tiny\n\n\"Role::Tiny\" provides some of the same features as Moose's role system, but in a much smaller\npackage. Most notably, it doesn't support any sort of attribute declaration, so you  have  to\ndo that by hand.  Still, it's useful, and works well with \"Class::Accessor\" and \"Class::Tiny\"\n"
                },
                {
                    "name": "OO System Summary",
                    "content": "Here's a brief recap of the options we covered:\n\n•   Moose\n\n\"Moose\"  is the maximal option. It has a lot of features, a big ecosystem, and a thriving\nuser base. We also covered  Moo  briefly.   \"Moo\"  is  \"Moose\"  lite,  and  a  reasonable\nalternative when Moose doesn't work for your application.\n\n•   Class::Accessor\n\n\"Class::Accessor\"  does  a  lot  less than \"Moose\", and is a nice alternative if you find\n\"Moose\" overwhelming. It's been around a long time and is well battle-tested. It also has\na minimal \"Moose\" compatibility mode which makes moving from \"Class::Accessor\" to \"Moose\"\neasy.\n\n•   Class::Tiny\n\n\"Class::Tiny\" is the absolute minimal option. It  has  no  dependencies,  and  almost  no\nsyntax  to  learn.  It's  a  good option for a super minimal environment and for throwing\nsomething together quickly without having to worry about details.\n\n•   Role::Tiny\n\nUse \"Role::Tiny\" with \"Class::Accessor\" or \"Class::Tiny\" if you find yourself considering\nmultiple inheritance. If you go with \"Moose\", it comes with its own role implementation.\n"
                },
                {
                    "name": "Other OO Systems",
                    "content": "There are literally dozens of other OO-related modules on CPAN besides  those  covered  here,\nand you're likely to run across one or more of them if you work with other people's code.\n\nIn  addition,  plenty  of  code in the wild does all of its OO \"by hand\", using just the Perl\nbuilt-in OO features. If you  need  to  maintain  such  code,  you  should  read  perlobj  to\nunderstand exactly how Perl's built-in OO works.\n"
                }
            ]
        },
        "CONCLUSION": {
            "content": "As  we  said  before,  Perl's minimal OO system has led to a profusion of OO systems on CPAN.\nWhile you can still drop down to the bare metal and  write  your  classes  by  hand,  there's\nreally no reason to do that with modern Perl.\n\nFor  small  systems, Class::Tiny and Class::Accessor both provide minimal object systems that\ntake care of basic boilerplate for you.\n\nFor bigger projects, Moose provides a rich set  of  features  that  will  let  you  focus  on\nimplementing  your  business  logic. Moo provides a nice alternative to Moose when you want a\nlot of features but need faster compile time or to avoid XS.\n\nWe encourage you to play with and evaluate Moose, Moo, Class::Accessor,  and  Class::Tiny  to\nsee which OO system is right for you.\n\nperl v5.38.2                                 2026-08-18                                 PERLOOTUT(1)",
            "subsections": []
        }
    },
    "summary": "perlootut - Object-Oriented Programming in Perl Tutorial",
    "flags": [],
    "examples": [],
    "see_also": []
}