#!/usr/bin/env python

"""This is a test program for the following classes
        waterconnection defines a connection to the water mains
        tap defines a tap thats on a connection
        supertap defines a high capatcity tap on a connection
        change defines an action turning a tap on or off

Class tap is at the "core" of the test application / suite of classes.
You define a tap on a connection, and within the tap the class retains
information about the tap and also its current state. Trying to turn a
tap on beyond its maximum flow, or beyond the maximum flow to the connection
that it's connected to, will result in it silently being limited - this
maximising being hidden within (a.k.a. "encapsulated") within the class.

A supertap is a varient of a tap. The only difference that we've defined
is that a supertap has a maximum flow that's twice that of a regular tap,
and it needs to be turned on or off twice to reach that maximum flow.
Supertap uses all the logic from tap - we have NOT duplicated the logic -
so it just overrides the methods where necessary. In OO terms, supertap
is a class that's extended from class tap, or supertap is a subclass of
tap.

The change class defines an action rather than a physical thing. It's quite
common in OO terms for a class of objects to be use to represent information
that's a concept like this, but it's quite a hard thing for trainees to
grasp sometimes. We've used the change class to let us define a piece of
data that has a number (2) of different properties - whether it's an on or
off action, and whether it's hot or cold, and to interpret a complex incoming
piece of information (a string in this case) to work out just what the action
involve is and store that action for use, perhaps many times over.

The final class (waterconnection) allows us to attach different taps to
different connections to the water mains, each of which has an overall
capacity. Within each water connection object, we're holding a state
(the current flow) and a property that we're not changing (the maximum
flow) and we're accessing those properties directly - we haven't provided
accessor methods since the data is only being looked at from within our
own other closely associated classes. It's disputable in OO terms whether
or not we should have accessed the properties this way, or provided accessor
methods for each."""

class change:
  def __init__(self):
    self.summat = 0
  def act_on(self,dowhat):
    self.temperature, self.destinedstate = dowhat.split(",")
  def gettap(self):
    return self.temperature
  def getdirn(self):
    return self.destinedstate

class waterconnection:
  def __init__(self,name,capacity):
    self.name = name
    self.mainsmax = capacity
    self.mainsnow = 0

class tap:
  def __init__(self,room,connex):
    self.mktap(room,connex,1)
  def mktap(self,room,connex,maxflow):
    # A separate method so that subclasses can create
    # taps with different maximum flows yet share the
    # constructor code
    self.title = room
    self.hot = 0
    self.cold = 0
    self.maxflow = maxflow
    self.connex = connex
  def getname(self):
    return self.title
  def gethotflow(self):
    return self.hot
  def getcoldflow(self):
    return self.cold
  def getmaxflow(self):
    return self.maxflow
  def apply(self,doingwhat):
    # This is the "heavy" logic that we want encapsulated!
    whichtap = doingwhat.gettap()
    whichway = doingwhat.getdirn()
    maxup = self.connex.mainsmax - self.connex.mainsnow
    if maxup >= 1:
      if whichway == "on":
        if whichtap == "hot":
          if self.hot < self.maxflow:
            self.hot += 1
            self.connex.mainsnow += 1
        else:
          if self.cold < self.maxflow:
            self.cold += 1
            self.connex.mainsnow += 1
      else:
        if whichtap == "hot":
          if self.hot > 0:
            self.hot -= 1
            self.connex.mainsnow -= 1
        else:
          if self.cold > 0:
            self.cold -= 1
            self.connex.mainsnow -= 1

  def __str__(self):
    # redefine the method used if we convert a tap object to
    # a string - for example if we print it out
    amount1 = self.gethotflow()
    amount2 = self.getcoldflow()
    rstring = self.title + " on '" + self.connex.name + "' connection. "
    rstring += "Current flow is "+str(amount1)+" hot "+str(amount2)+ " cold."
    return rstring

class supertap(tap):
  def __init__(self,room,connex):
    self.mktap(room,connex,2)

# ###########################################

# test program / demonstration code

if __name__ == "__main__":

# define a number of water connections

  springfield = waterconnection("403, The Spa",3);
  wellhouse = waterconnection("404, The Spa",5);

# define a number of taps

  users = []
  users.append(tap("utility room",wellhouse))
  users.append(tap("guest bedroom",springfield))
  users.append(supertap("kitchen",wellhouse))
  users.append(tap("library",wellhouse))
  users.append(tap("master bedroom",springfield))
  users.append(tap("shower room",wellhouse))

# Define what Lisa and Leah would like to do with taps

  leahdoes = change()
  lisadoes = change()
  action1 = "hot,on"
  action2 = "cold,on"
# Encapsulate the action within the "change" object because
# there's going to be some complex logic to hide
  leahdoes.act_on(action1)
  lisadoes.act_on(action2)

# Have leah and lisa visit each tap in turn and apply their changes

  for flow in users:
  # Better say which tap we're looking at to help the reader
    where = flow.getname()
    upto = flow.getmaxflow()
    print "The tap in the "+where+" has a maximum flow of "+str(upto)

  # Leah visits each tap twice and does her thing and the Lisa
  # then visits each tap once and does hers!
    flow.apply(leahdoes)
    flow.apply(leahdoes)
    flow.apply(lisadoes)

  for flow in users:
    print flow