Last Seen Blogs
treycosexual
Slightly Obsessed with Trevor Collins
today-icons
today icons
krisanimations
Kris' Dump
pussy-talk
ya girl
reimiart
Ria
Text
Strategy Pattern
A behavorial softare design pattern that enables an elgorithms begabior yo be selected at runtime.
1) defines a family of algorithms
2) encapsulates each algorithm
3) make the algorithm interchangelbal with in the family
Each algorithm must have the same methods so they can easly be changeed out.
Composition over Inheritance
Principal that classes should achieve polymorphic behavior by their compositoin, rather than inheritance
composition = Containing instances of other classes that implement the desired functionality.
In compositoin classes "has a" opposed to "is a". Reason is that the class is made up of multiple smaller classes
Strategy pattters also uses Delegation with is passing wotk to another object
We use delegation in our example by passing the cards to be passed out by the algorithm
class Cards
end
class CardGame
attr_accessor :game
def initialize(game)
@game = game
@cards = Cards.new
end
def play_game
@game.explain_rules
@game.deal_cards(@cards)
end
end
class BlackJack
def explain_rules
puts "These are my blackjack rules"
end
def deal_cards(cards)
puts "Dealing cards that I somehow have for BlackJack"
end
end
class TexasHoldem
def explain_rules
puts "These are the rules for Texas Holdem"
end
def deal_cards(cards)
puts "Dealing cards that I somehow have for TexasHoldem"
end
end
class GoFish
def explain_rules
puts "These are the rules for GoFish"
end
def deal_cards(cards)
puts "Dealing cards that I somehow have for GoFish"
end
end
a = CardGame.new(TexasHoldem.new)
a.play_game
a.game = BlackJack.new
a.play_game
0 notes
Text
Template Pattern
Lets start with Template Pattern.
The template patterns uses inheritance. The parent class defines a set of methods and a runner method. The inherited classes provide the functionality for those methods.
EXAMPLE
class CardGame
def explain_rules
puts "Everybody Listen Up!"
end
def play_game
explain_rules
deal_cards
end
# The reason we have the error is if the method in a subclass goes undefined
def deal_cards
raise "Called abstract method: deal_cards"
end
end
class BlackJack < CardGame
def explain_rules
super
puts "These are my blackjack rules"
end
def deal_cards
puts "Dealing cards that I somehow have for BlackJack"
end
end
game = BlackJack.new
#.play_game is the runner method from the CardGame class
game.play_game
#From Parent Class
=> "Everybody Listen Up!"
#From child class
=> "These are my blackjack rules"
#
#The BlackJack class re-defines the deal_card method that we first see in the CardGame class.
=> "Dealing cards that I somehow have for
0 notes
Text
When to ask for help
It is a question that you aren’t taught to handle in school, but constantly comes up. Your first feature to build is finally assigned. You start working on the feature and all the sudden you find yourself at a halt. You either can’t figure out how to build the next step or are not sure which way to implement the next step. The question is at what point do you ask your Mentor for guidance?
THE GOLDEN RULE: Never go empty handed!
Let me explain how this rule works.
Step 1. Timebox for about 20 minutes.
Step 2. Have a clear understanding of what you know and don’t know in the code.
Step 3. Understand what the problem is.
Step 4. Try different solutions and formulate theories.
Finally. When you go to your mentor don’t simply ask for the answer, explain everything you have learned in the past 20 minutes and try and figure a solution together.
The better you get at understanding problems then quicker you get at solving them.
If you find yourself in a situation where you have two choices on how to complete the following step and it will affect people on your team. Try and work around the problem until the person you need to ask has their headphones off or just shoot them a slack message and they will respond at opportune time.
0 notes
Text
The Apprenticeship Paradox
This is my first apprenticeship. I have never really had someone dig into my code and criticize it. All the criticism my mentor has given me has been obviously correct but also helpful. Criticism, though, is sometime difficult to hear.
A very good way to make it easier to absorb the criticism it to take an objective view to my code. The paradox, though, is how to remain passionate and objective about my code at the same time.
I found the solution to be in separation of my code and my craft as a software engineer.
While I am coding I must be passionate about every character I type. But when my code goes under the magnifying glass it's important for my passion to pivot from the code in front of me, to my craft as a software engineering. This allows me to become objective of my code and even begin to criticize it.
Hope this helps,
Yossi
0 notes