1 / 23

Good Enough Object

Good Enough Object. a.f.hampe 2012.09.19. Super Sekret Agenda. Learn Perl’s Object Model Learn Some Basic OO Ideas ISA from HASA What is inheritance Cool Stuff. Things out of scope. Three Interesting Spaces Mouse Moose Inside Out ??? yourCultHere Procedural v. OO v. Functional.

truly
Download Presentation

Good Enough Object

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Good Enough Object a.f.hampe 2012.09.19

  2. Super Sekret Agenda • Learn Perl’s Object Model • Learn Some Basic OO Ideas • ISA from HASA • What is inheritance • Cool Stuff

  3. Things out of scope • Three Interesting Spaces • Mouse • Moose • Inside Out ??? • yourCultHere • Procedural v. OO v. Functional

  4. There are two vectors to consider • The Code side • scripts => libs => objects • The Variable side • vars => structs => objects • Data or Code? who’s on first? • We shall assume folks know scripting well enough.

  5. The Basic Lib Issue • And this does not take into account the functions. • It does raise a useful question -- how should the functions be imported? How should they be grouped? • In short, should we break this library into little groups of functions? Or into their own libs? • That is a common problem.

  6. Scary Thought Time • What one exports others import. • Best to not export by default • Saves on name space collision • In ‘C’ code macro’s and #define work because the pre-processor before compiling • Constants are subs in perl. • Why export a variable?

  7. Rethinking the constant game • Why yes, we still have N+1 sub calls in the method model. So it is not a great win in itself. • As a general rule of thumb I dislike exporting variables and specifically constants. • It gets crazier if we export with AUTOLOAD() on, and then re-exporting the symbol up the stack. What if the caller also imported from the same source?

  8. ReExporting up the stack? • Module A is imported into B and C • B exports to C AF_INET6 • C imported AF_INET6 from A • Which error message about redefining will occur at this time? • How can you turn only that warning off?

  9. The Shorter Exporter • Great for single function libs • It is ok if one has to start setting up export tags • It gets crazy if one exports constants and variables • It gets out of hand the further from the script that is executed. • It hides dependencies.

  10. A Small Object Foo::Bar • Notice, no exporting. • No lists to manage. • No worrying about what the caller does with their name space issues. • Notice, it does not require that we have a data model with data stuff! It just issues a function/method

  11. Mixing In A Module In A Script • Always a nice way to play with an idea. • It can even be all the code! no nasty modules. • No code re-use by others, but, hey...

  12. The Basic Vars of Perl • There are only four of them • scalar ( could be a ref ) • list • hash ( aka Associative Array ) • packed data (cf pack and unpack) • There is no varchar, int, float, etc • Upon these, structs && objects bloom

  13. Struct v. Object • Just use struct if any of the natural data types, including HoH or AoH, work well enough. • Never decorate what is just data • Solve the data model first before deciding on object v. struct • Will the object simplify the documentation of the work at hand?

  14. That documenting thing you do • The POD is documentation • You are probably doing it wrong if they needed • the Header File or Code to understand the documentation • a native guide to solve the inheritance chain or the lost function of foo_bar(). • you to maintain it!

  15. A simple enough struct documentation • One should explain the variables, in this case we have a ‘$ytag’ as the key to the hash reference of four keys. • I use the generic expressions ‘string’ and ‘mac_addr’ to denote that we know no more than that the ssn will be some alpha-numeric, and the macs, are mac addresses and will conform to that standard.

  16. Indicating a Hasa Requirement • Here we need two objects passed to the constructor. • In the long run, let them create them and pass them. This way the current object focuses on using the object, not on how they are constructed. • This object, has a “Hasa” relationship with it’s contained objects.

  17. The Shorter OO Perl • A reference is blessed into a ‘package’ name space. • hash refs are a good enough basic data model • The inheritance chain defines what methods are local to this package, and which are in the super class. { document your inheritance! } • nice code reuse • Hasa may require ‘adapter’ methods if you want to share the object externally. • Can just use the direct access to the ‘hash’ to do what needs to be done. Do not need accessor/mutator methods. ( I hate setter/getter rhetoric! )

  18. A simple Immutable Object • All values are passed in at create time. • We have only the three accessors. • They find their data at the named slot in the first argument passed in “@_” -- the majik perl varg. • About as close to a decorated struct as we want.

  19. Subclass of an Immutable • The ‘use base’ pragma tells us we are a subclass, and sets @ISA -- since this class isa Foo::WorkObject, so has all of the parent’s methods, plus any that we add locally. • I used this trick for two ‘auto_populate’ apps, where the second one needed a slightly different syntax. • This is a win for object over struct.

  20. SubSubClass with Super • Note, the sub-subclass overrides the ‘filter’ method that it would have inherited from it’s super class, Foo::WorkObject. • SUPER allows us to call filter() in the parent before we do our thing with it! • Note: you do not need to call SUPER to get methods that you inherited.

  21. Simple Adapter Pattern • In the node_get() there is no reason to use the NodeGet() adapter, but.... • The node_get() adds the value add, that undef means that there is no node. • We rethrow any unresolved errors, or return the data. • We do not know if this is a real opsdb or test one.

  22. Summary • A blessed hash reference is a good enough data structure to build on. • Sometimes they just return structs • Hasa v. ISA is a fun debate • Build simple things to do simple things often advocates a Hasa approach to the solution. • JeffFoxWorthy Jokes in an inheritance chain, BAD. • Sometimes you have to reach up to the parent class and get it’s work before doing your own. • Any reasonable questions?

  23. Any Unreasonable Questions • You still like inside-out objects? • My Mouse/Moose Conflict can ONLY be ONE! • insert joke here.

More Related